Tags:
BlogRecent1Add my vote for this tag BlogWireless1Add my vote for this tag create new tag
view all tags

2014-06-26 - FMNC Server - It's Alive!

Finally, success on getting the FMNC back end to start working. While I had done a fair amount of work a while back with our RIPPS project that involved TCP payload rearrangement, it has been a while since I have been working with our ScaleBox code base. The issue in particular I had been wrestling was the TCP header construction for the out of order packet delivery, particularly following the three-way handshake and the first data packet from the client (ex. say a web client).

The TCP three-way handshake is fairly well defined:

  • The client sends a TCP packet with the SYN flag set and an initial sequence number of X. This is the Initial Sequence Number (ISN) for the client.
  • The server responds with a packet with the TCP packet with the SYN and ACK flags set (aka the SYN-ACK). The ISN for the server is denoted by Y which is sequence number for the newly responded packet. The Acknowledgment Number is set as X+1.
  • The client then respond with a pure ACK (typically) with the Acknowledgment Number set to Y+1. While it is technically possible to include data in that third part of the three-way handshake, most of the time it is a pure ACK. A "pure ACK" is a packet whose sole responsibility is to ACK a received packet which is denoted by a packet that contains a zero byte TCP payload.

From there, it is off to the data races. My client for this case had been curl as I was mimicking a web request. The issue that I had was that despite the fact that I sent a pure ACK back from my FMNC server to the Mac OS X client, my subsequent data packets were not being received correctly. I banged my head against this issue for a day as I was trying to figure out what was going on. The debug richness for the FMNC server and packet sending in ScaleBox got a considerable boost while trying to figure what was happening.

Well, after running things through Wireshark (which by the way does not detect this) and making my eyes go bonkers comparing various hex symbols, I thought, hey, why not just force the ACK flag and put in a good ACK even if we aren't really ACK'ing anything of importance. My muddled thinking was that why should I set the ACK if I am not ACK'ing anything, lest I convey / trigger Fast Retransmit (ACK with the same number three times in a row, trigger a quick retransmission) since the Fast Retransmit hat is what we are basing part of FMNC on via TCP Sting. Of course, had I bothered to dive a bit deeper into the standard rather than working from how I thought it should work, I would have seen that yes of course, the ACK flag needs to be set on all packets post-SYN. One minor tweak later and voila, tcpdump no longer grumps about sequence number marking and curl is a happy camper. facepalm.jpg

I did learn a few interesting things:

  • Evidently Wireshark thinks that if you don't have the ACK bit set, your ACK value should be zero. Would have been really nice for it to flag and note that any packet post-SYN for a TCP session should have its ACK flag set.
  • The -vvv option when doing a write to disk via the -w option for tcpdump tells you how many packets you have captured. Cool.
  • tcpdump was smart enough to figure out that I was hosing things up (not doing relative sequencing) but inconveniently would not point out where I was messing up. I was about an hour or so away from opening up the tcpdump source code on relative sequence number computations.

You are welcome to live on the bleeding edge with ScaleBox and can grab Subversion access for download here.

Look for some early results next week hopefully with some spiffy d3js graphs.

2014-06-26 - created by Aaron Striegel

Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpg facepalm.jpg r1 manage 12.8 K 2014-06-26 - 02:55 AaronStriegel  
Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | More topic actions
Topic revision: r1 - 2014-06-26 - AaronStriegel
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback