Hi,

We are trying to write a client/server program in c++. We have tried to use pcap to inject raw packets and sockets to receive packets. When the traffic are sent between two different computers everything seems to be ok. The problem occurs when the traffic are sent to the loopback. The packets are visible via Wireshark (driver level) but they never reaches the destination (application level).


Thanks in advance!
Best regards,
CC and EE

Why are you using "pcap to inject raw packets"?

Why not just write a standard socket server and client? Make the server listen on INADDR_ANY:

Code:

/* Address to accept any incoming messages. */
#define	INADDR_ANY		((unsigned long int) 0x00000000)

and it will listen on all available interfaces.

Make the client connect to "127.0.0.1", and it can run on the same machine as the server.

If you need the ability to run the client on the same machine as the server and on other machines, make the default address "127.0.0.1" and add a command line option to specify the server address.

The reason for not using standard sockets is that the client in this case has it's own TCP/IP-stack and therefore we need to use methods like raw sockets or pcap.

I'll try to describe the whole scenario a bit more.

The client (A) will try to establish a TCP connection to the server (B). B is listening using standard sockets while A first ensembles the whole packet internally via it's own stack and we must then make this packet appear at B. Since it is TCP we are using then we must establish the connection in a way so that the stack in linux, somehow, get's in the same stat as the stack inside A.

In short: Stack in A should be synced with linux stack (at B).

What device are you using to capture packets? Are you putting the device in promiscuous mode?

On the server-side we are using lo, which has a bunch aliases attached to it. We have also tried to use ethX, which results in the same.

Since we are using standard sockets (server-side) there is no need to use that mode for that purpose, but at the client-side it is necessary for receiving packets without having to bind to a specific port etc..

We have tried two different raw sockets, namely: link-layer and ip-layer.
When we are using the ip-layer the server receives, for example a TCP-syn, the packet successfully, but when the server answers with TCP-syn-ack it will be blocked by the TCP/IP-stack in the linux kernel, because there is no process which is listening/expecting such packet. Linux kernel will therefore send a TCP-rst back to the server, which destroys our connection.

Problem: How to get the linux kernel accept the TCP-syn-ack without listening via standard sockets (client-side)?

Problem: How to receive packets, locally, which are sent via PF_PACKET socket?

Probably impossible without modifying the Linux kernel.

Same solution as above.

You are basically violating the rules used by the stack for determining how to respond to a SYN request. It sees that there is no corresponding local client and (properly) rejects it.

Yes, we guess that is one solution. Though it is not the most beautiful one out there, but we'll investigate this further. I guess we need to try to grab the packet very early, and that is on the agenda for tomorrow!

Have you ever been in contact with UML (User mode linux) ? They must have solved this in some neat way, because they actually have two, or more, instances of the Linux's TCP/IP-stack. It seems that TAP is somewhat central around the UML, and perhaps that could be something to investigate as well?

Thank you very much for your feedback, it's really nice to have someone to share our thoughts with!

Not yet. If you learn something from its maintainers, please post your findings here so that others may benefit.