I think I have some time to dive back into this project.
Why are you calling connect and not bind?
Even if I call bind (or fpbind) the issue is that the sockets code seems to be oriented towards ip and port numbers.
Referencing this document
http://www.linuxhowtos.org/C_C++/socket.htmI believe the socketCAN has to address the unix domain via the Linux File system.
Recall my example from a previous post.
debian@ebb:~$ sudo /sbin/ip link set can1 up type can bitrate 250000
debian@ebb:~$ candump can1
can1 721 [1] 05
can1 1A1 [8] 20 00 FF 0F A8 FD A8 FD
The can1 is the device which in the above example is a USB based CAN dongle. On a Pi I can just as easily specify the SPI based MCP2515 CAN device in place of the USB device.
For example from this tutorial
https://www.raspberrypi.org/forums/viewtopic.php?t=141052pi@piv2:~ $ ls /sys/bus/spi/devices/spi0.0/net/
can0
pi@piv2:~ $ sudo ip link set can0 up type can bitrate 125000
pi@piv2:~ $ sudo ifconfig
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
So from the OS perspective the fact that one device is USB based and can be plugged into a WIN-PC MAC or Linux system while the other one is SPI based on the Pi the access via Linux is the same.
And the C Program candump.c creates identical output regardless of the hardware type. (BTW, it's the same with the embedded inside the processor CAN device in a BeagleBone Black).
pi@piv2:~ $ candump can0
can0 001 [8] 11 22 33 44 55 66 77 88
can0 00003456 [8] EF FE DD AD CB 67 98 AA
Now in the C world, candump.c or cansend.c can be used as a template for a customized program to do whatever... One might cut and paste parts into their application. That's because the sockets library in C handles the parameters PF_CAN and SOCK_RAW, CAN_RAW.
The FPC sockets does not. And yes I can define those but tunnel down into sockets.pp and and the system's ...sockh.inc we don't have a PF_CAN. And without a PF_CAN and AF_CAN in the socket() the connection aborts because it doesn't know what to do with it.
In order to cut and paste more of the code I'll have to continue this in another message from the Pi3 so I can post the Lazarus program I've used to discover this but I don't think the FPC code will matter at this point.
Search for candump.c and we find in
https://github.com/linux-can/can-utils/blob/master/candump.cs[i] = socket(PF_CAN, SOCK_RAW, CAN_RAW);
Later we bind to the socket
if (bind(s[i], (struct sockaddr *)&addr, sizeof(addr)) < 0) {
return 1;
}
Eventually after all the CAN_FD and filter handling we end up
nbytes = recvmsg(s[i], &msg, 0);
So in general I get the feeling that to add socketCAN support to FPC will require a fairly extensive modification of the base sockets library. Is there any interest in this? Who's allowed to change it.
The project I started in Lazarus works fine with the USB based CAN dongle by treating it as a serial port which generates strings of characters representing the messages. But I can't access the CAN devices built into the BeagleBone nor the Pi which is a cakewalk with Python or C. And I'd like to be able to demonstrate CAN bus access from a USB dongle or the embedded hardware.
What's the next step?