Linux box doesn't send tcp ACK in handshake when receiving SYN/ACK to a broadcast address

Linux box doesn't send tcp ACK in handshake when receiving SYN/ACK to a broadcast address

Post by Adam » Fri, 10 Jun 2011 05:51:52



Hi all

I have a setup in which one of the linux boxes is forced to be sent
Ethernet frames with ff:ff:ff:ff:ff:ff:ff as a destination mac. This
box has internet connectivity - verified by pinging google.com etc..
The problem arises when this box initiates a tcp connection somewhere
and receives the syn/ack with a broadcast address. It simply refuses
to reply with an ACK and this seems to be the default behavior in both
ubuntu and fedora (verified using tcpdump/wireshark).

If I change the configuration in a way in which the box receives the
reply with its mac as a destination, everything works as it should.
How do I eliminate this default behavior?

 
 
 

Linux box doesn't send tcp ACK in handshake when receiving SYN/ACK to a broadcast address

Post by Rick Jone » Fri, 10 Jun 2011 04:50:31



> I have a setup in which one of the linux boxes is forced to be sent
> Ethernet frames with ff:ff:ff:ff:ff:ff:ff as a destination mac.

Why?!?

And based on the rest of what you said, was that as the source mac
rather than the destination?

Quote:> This box has internet connectivity - verified by pinging google.com
> etc..  The problem arises when this box initiates a tcp connection
> somewhere and receives the syn/ack with a broadcast address. It
> simply refuses to reply with an ACK and this seems to be the default
> behavior in both ubuntu and fedora (verified using
> tcpdump/wireshark).
> If I change the configuration in a way in which the box receives the
> reply with its mac as a destination, everything works as it should.
> How do I eliminate this default behavior?

You would have to get at least one IETF RFC re-written. It is
stretching the dimm wetware memory, but IIRC there is a prohibition
upon processing a frame sent to a broadcast/multicast link-layer
address carrying an IP datagram with a unicast destination address.

rick jones
--
web2.0 n, the dot.com reunion tour...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

 
 
 

Linux box doesn't send tcp ACK in handshake when receiving SYN/ACK to a broadcast address

Post by David Schwart » Sun, 12 Jun 2011 18:59:57



Quote:> If I change the configuration in a way in which the box receives the
> reply with its mac as a destination, everything works as it should.
> How do I eliminate this default behavior?

Change the configuration so the box receives the reply with its mac as
a destination.

DS

 
 
 

Linux box doesn't send tcp ACK in handshake when receiving SYN/ACK to a broadcast address

Post by Tauno Voipi » Sun, 12 Jun 2011 21:10:21



Quote:> Hi all

> I have a setup in which one of the linux boxes is forced to be sent
> Ethernet frames with ff:ff:ff:ff:ff:ff:ff as a destination mac. This
> box has internet connectivity - verified by pinging google.com etc..
> The problem arises when this box initiates a tcp connection somewhere
> and receives the syn/ack with a broadcast address. It simply refuses
> to reply with an ACK and this seems to be the default behavior in both
> ubuntu and fedora (verified using tcpdump/wireshark).

> If I change the configuration in a way in which the box receives the
> reply with its mac as a destination, everything works as it should.
> How do I eliminate this default behavior?

TCP is a point-to point connection. There is no such thing as a
broadcast TCP connection. The Linux behaviour is correct.

Change your setup to use proper target addresses instead.

--

Tauno Voipio

 
 
 

1. SYN ECHO REQUEST SYN/ACK sequence on AIX box

One of our AIX machine acts like this when receiving a TCP SYN on any port
and with any client machines

Aix machine                                Client
                                    <----       SYN
ECHO REQUEST        ---->
(even if no echo reply the aix folows with this)
SYN/ACK                    --->
                                    <---        ACK

Why this AIX send an echo request before sending the SYN/ACK ?

Thanks an regards
Christophe

2. Problem with HD-timeout

3. TCP hangs between syn and syn/ack

4. scheduling algorithm?

5. 2.2.19 pre13 doesn't like retransmitted SYN ACK packets

6. Problems when installing mod_ssl-2.5.1-1.3.11

7. Linux doesn't delay TCP ACKs -- why?

8. UDP packets

9. How to send ACKs from main receiving routine.

10. Client receives TCP packets but does not ACK

11. Question on the timeout for un-ACK-ed SYN's

12. Client receives TCP packets but does not ACK

13. server DHCPD ISC Linux and broadcast DHCP OFFER and ACK