Don't get TCP packets when expected with netmap

[iguberman]

I retrofitted sink.c to receive TCP instead of UDP, but for some reason, no TCP packets are received when I issue a TCP connect from elsewhere.
Exact same actions with tcpdump and, naturally, I would see a few TCP packets coming through and I would expect same behavior with tcp-ed sync.c (attched as nm_recv.c.txt), but no, I only see a few ARP packets coming through after a TCP connect (followed by a bunch of unrelated IPPROTO_UDP (type 17) or IPPROTO_IGMP (2), but no IPPROTO_TCP (6) whatsoever). I tried googling netmap tcp tutorial, but only presentations/info I already saw earlier come up (as well as Sandstorm). Would greatly appreciate a netmap-TCP tutorial or example. Thank you very much!

nm_recv.c.txt

[vmaffione]

Hi Irina,
the sink program simply receives and drops anything that comes on a given physical or virtual interface. This is ok for UDP, because the UDP sender does not need any response or acknowledgement packets from the receiver.

However, for a TCP connection to work, the receiver must send a SYN+ACK, and then ACK the packets sent by the sender. This does not happen, because sink just drops, without generating any return traffic.
Even before that, the sender machine must resolve the IP address of the receiver. This explains the ARP packets that you see. You need to make sure that ARP responses come back.
What you see with TCP dump is probably your sender trying to send ARP requests, but never getting responses.

[iguberman]

Hi Vincenzo,

Thanks so much for your response.

Yeah, upon attempting TCP-connect from another host, I was expecting a couple of ARP packets followed by that TCP rejection packet (similar to what I'm seeing in tcpdump) as I just wanted to see some TCP packets gong through netmap before moving on to something more full-featured.

I did achieve that however, by first establishing the handshake without netmap and then started netmap and started sending packets through the socket established outside -- they all got through my TCP-flavoured-sync, no problem. So I guess I would need a complete TCP implementation for the entire thing to work end-to-end. If I figure out the full TCP example myself, I'd be happy to share.

[vmaffione]

Correct. If you want to intercept traffic and let it go ahead you can look at the forward program.
You can forward between two separate ports, e.g.

  # ./forward -i netmap:eth0 -i netmap:eth1

You can also forward between rings belonging to the same port, and in particular between the hardware rings and the host rings, e.g.

  # ./forward -i netmap:eth0 -i netmap:eth0^

which means that you let the traffic pass between the NIC (or virtual interface) to the host network stack, but you also intercept (and possibly drop or modify) all the packets. In this case you don't need a TCP implementation in your netmap program, because you reuse the host network stack.

[iguberman]

Actually, this was a separate, and more important question I had! ( I thought bridge netmap app would do this for me but it didn't seem to work) forward works however! That's priceless :) Thank you so much for this tip Vincenzo!

[vmaffione]

Actually bridge and forward should both work. Maybe you have not disabled the offloadings as pointed out in LINUX/README ?

[iguberman]

That's right, I haven't! Will give it another try. Thank you so much again! :)