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

Adam <(E-Mail Removed)> wrote:

> 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?

> 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...

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?

On Jun 8, 1:51*pm, Adam <adamka...@gmail.com> wrote:

> 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

On 8.6.11 11:51 , Adam wrote:
> 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