You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)), with sendto and recvfrom) 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?
The text was updated successfully, but these errors were encountered:
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))
, withsendto
andrecvfrom
) 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?
The text was updated successfully, but these errors were encountered: