This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

What is wrong with SYN+ACK causing SYN retransmission but looks fine in WireShark?

0

  • While working with an embedded TCPIP stack, I modified the stack not to switch to the new IP address immediately when the DHCP lease is obtained so the system can coordinate with another system that the IP address is changing and reconnect.

  • When the system comes up in static IP mode, I can connect to it from my Linux 3.2 (Ubuntu) system fine. The WireShark capture is attached. link:static-good-syn.pcap

  • When the system comes up in DHCP mode, the DHCP exchange works fine but then I cannot connect to the system from my Linux workstation. I send the SYN fine and the system responds with the SYN+ACK but the workstation just keeps resending the SYN. link:dhcp-bad-syn.pcap

Is there something wrong with the SYN+ACK frame?

Thanks

asked 07 Jan '13, 09:16

brownslink's gravatar image

brownslink
6●2●2●5
accept rate: 0%

edited 07 Jan '13, 10:19

Please upload your capture files to www.cloudshark.org and paste the links here in a comment to your question.

(beware of uploading capture files that might contain sensitive data)

(07 Jan '13, 09:20) SYN-bit ♦♦

One Answer:

1

The DST MAC address in the SYN,ACK packet is ff:ff:ff:ff:ff:ff (instead of 00:c0:49:63:6c:ea). That's the only thing I can see. What is the OS of 192.168.60.1? Maybe it does not like that (and drops the SYN,ACK packet), although I believe that this would work with the most IP stacks, unless there is some TCP/IP offloading in place on 192.168.60.1 !?!

Regards
Kurt

answered 07 Jan '13, 10:30

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 07 Jan '13, 10:44

192.168.60.1 is my (K)Ubuntu workstation. I couldn't find anything in the ethtool output or under /proc/sys/net/core that referred to offloading.

I will fix up the outgoing DST MAC address and see if that fixes it.

Thanks

(07 Jan '13, 10:52) brownslink
1

I couldn't find anything in the ethtool output

Did you run ethtool with the option -k?

I will fix up the outgoing DST MAC address and see if that fixes it.

O.K.

  • Where did you capture the traffic?
  • Do you have any firewall enabled on KUbuntu (iptables, ebtables)?
  • what is your KUbuntu version (lsb_release -a)
(07 Jan '13, 11:01) Kurt Knochner ♦

Correcting the TCPIP stack to put the DST MAC DID correct the problem.

  • I captured the traffic on my Kubuntu system
  • There is no firewall enabled
  • I am running Ubuntu 12.04.1 LTS

The output of ethtool -k is as follows

  • Offload parameters for eth0:
  • rx-checksumming: on
  • tx-checksumming: on
  • scatter-gather: on
  • tcp-segmentation-offload: off
  • udp-fragmentation-offload: off
  • generic-segmentation-offload: on
  • generic-receive-offload: on
  • large-receive-offload: off
  • rx-vlan-offload: off
  • tx-vlan-offload: off
  • ntuple-filters: off
  • receive-hashing: off
(07 Jan '13, 13:07) brownslink

Kurt -

I know that you stated that my original SYN-ACK sequence should have worked, but if you decide that this is not the case, I hope that you file a request for WireShark to validate that the SYN-ACK should not be an Ethernet broadcast. The fact that WireShark showed this frame as a valid acknowledgement to the SYN packet threw me.

Thanks for your help. Roland

(07 Jan '13, 13:44) brownslink

I don't think this is a problem/bug of Wireshark, as the TCP segment was correct and that's what Wireshark reported. The OS declined to accept the packet for a yet unknown reason. You could file a bug report to Ubuntu or Linus Torvalds (good luck with that ;-)), but I don't think they will do anything, as the main error was the sender using the wrong mac address ;-)

Correcting the TCPIP stack to put the DST MAC DID correct the problem.

Good.

HINT: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(07 Jan '13, 14:06) Kurt Knochner ♦

OK - But I can understand the Ubuntu stack requiring a SYN-ACK addressed directly to it. That is probably the way I would code it to attempt to harden against any false positives.

It seems like WireShark might want to upgrade its overall frame analysis to match the sophistication of that of the Linux kernel.

Cheers and thanks again.

(07 Jan '13, 14:24) brownslink
showing 5 of 6 show 1 more comments