WorksButNotTested
commented
2 years ago It looks like it determines where to send the packet around here? https://github.com/virtualsquare/picotcp/blob/529074aab4f53a87426673548d6793ced666b6ed/modules/pico_ipv4.c#L1386 and https://github.com/virtualsquare/picotcp/blob/529074aab4f53a87426673548d6793ced666b6ed/modules/pico_ethernet.c#L317
I have written a custom device to my application to allow PicoTCP to send and receive data over raw sockets on Linux. (e.g. using
socket (AF_PACKET, SOCK_RAW, htons (ETH_P_ALL)), withsendtoandrecvfrom) which is working well when sending traffic between hosts. (e.g. one app with PicoTCP embedded acting as a TCP server on one host and another app acting as the TCP client on another host).However, it would be helpful to also run this for testing purposes with both client and server running on the same host (either on a loop-back adapter or even on a physical adapter) . Unfortunately, when the client is listening for its responses on the same IP address as the server it is intending to send it's packets to, rather than the out-bound packets being sent down to the device layer to be written to the link, the client application attempts to process the out-bound packet itself resulting in an error message saying "No such port".
It would seem that the design (understandably) is such that the stack assumes it has exclusive ownership of any IP it is managing, but is there any means to modify this behavior?