1

I have this client which initiates a 3 way handshake with a SYN packet but there is no SYN ACK response. We figured out that it was because the client did not pad the end of the TCP headers with 0's or F's but with other values (we used packet builder software to confirm this). The server is Windows XP 32bits version 2002 Service Pack 3. I tried it on Windows 7 and the problem does not occur. Has anyone ever heard of this type of problem? Could it be because the server runs on windows XP? I've tried simplifying the network link (local link), i've tried with the server running in safe mode and same results occur. The providers of the client say they have validated that it works with a windows XP server on their end.

Improve this question

1 Answer 1

Reset to default
1

Padding with zeroes is the only valid TCP header padding that I know of. (Not with F's. See RFC 793 dated 1981!) It has been this way for a long time. Windows XP did this as well. The only reason why your copy of Windows XP would not be doing this (that I can think of) is because of your NIC drivers. Make sure you're using the best network card drivers.

Improve this answer
4
  • Actually our servers which are windows XP refuse to reply any client that send SYN requests with improper padding. It's our provider that affirms that they tested succesfully with a win XP server. The clients which are causing the improper paddings are not desktop OS based, they are embedded devices.
    – yan bellavance
    May 4, 2015 at 18:14
  • Well, Windows XP is not a server. Trying to use it like one will result in headaches. As you are now aware. At any rate, again, this a data link problem... there is no configuration in the operating system that you can just flip a reg key somewhere that says "accept malformed TCP packets."
    – Ryan Ries
    May 4, 2015 at 18:20
  • Yes I see that :) Thanks for your answer, I was wondering if there was an OS option. I am about to fix this problem with a proxy app that reads incoming packets in promiscuous mode and resends to the ftp server through another socket, we need this for testing, it is not part of the final product. In the mean time I will try and replace the NIC card driver and/or the card itself.
    – yan bellavance
    May 4, 2015 at 18:31
  • Good call. I just thought about what you said and realized we have usb to ethernet NICs. After switching over to a real NIC connected to the motherboard PCI, the problem went away. Thanks alot.
    – yan bellavance
    May 4, 2015 at 19:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .