Bug in bridge or netfilter code (REJECT + incorrect MAC)?

Bug in bridge or netfilter code (REJECT + incorrect MAC)?

[Casper Gripenberg]

Hi,

I sent this to the netfilter list, but nobody replied there.

I've found something strange with REJECT and DNAT rules
where the MAC address for packets coming back through
the bridge get rewritten incorrectly.

The setup to test this is fairly simple, and I can
reproduce it consistently on my stock Ubuntu 7.10
installation (kernel 2.6.22-14).

Is it something I'm doing wrong, or any idea what is
going on? I filed a bug report here:

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=531

Thanks.

Casper

Re: Bug in bridge or netfilter code (REJECT + incorrect MAC)?

[Patrick McHardy]

Casper Gripenberg wrote:
> 
> Hi,
> 
> I sent this to the netfilter list, but nobody replied there.
> 
> I've found something strange with REJECT and DNAT rules
> where the MAC address for packets coming back through
> the bridge get rewritten incorrectly.
> 
> The setup to test this is fairly simple, and I can
> reproduce it consistently on my stock Ubuntu 7.10
> installation (kernel 2.6.22-14).
> 
> Is it something I'm doing wrong, or any idea what is
> going on? I filed a bug report here:
> 
> https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=531


I'm wondering, why does your client care about the source MAC
address of the REJECT packet? Or is there another switch in
between that does MAC filtering?

Re: Bug in bridge or netfilter code (REJECT + incorrect MAC)?

[Casper Gripenberg]

Patrick McHardy wrote:
> Casper Gripenberg wrote:
>> [...]
>> https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=531
> 
> I'm wondering, why does your client care about the source MAC
> address of the REJECT packet? Or is there another switch in
> between that does MAC filtering?

Yes..there is a switch or router between the Linux bridge
and the computer that is supposed to receive the REJECT
packet.

The packet stops at this router, because presumably it's
doing some sort of MAC spoof filtering, or it just doesn't
understand what is happening when the MAC of the source IP
suddenly changes.

The router is my ISP's internet router, which I do not
control. But I doubt the router is doing anything wrong
though. The weirdness is more on the Linux side..

Casper

Re: Bug in bridge or netfilter code (REJECT + incorrect MAC)?

[Patrick McHardy]

Casper Gripenberg wrote:
> Patrick McHardy wrote:
>> Casper Gripenberg wrote:
>>> [...]
>>> https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=531
>>
>> I'm wondering, why does your client care about the source MAC
>> address of the REJECT packet? Or is there another switch in
>> between that does MAC filtering?
> 
> Yes..there is a switch or router between the Linux bridge
> and the computer that is supposed to receive the REJECT
> packet.
> 
> The packet stops at this router, because presumably it's
> doing some sort of MAC spoof filtering, or it just doesn't
> understand what is happening when the MAC of the source IP
> suddenly changes.
> 
> The router is my ISP's internet router, which I do not
> control. But I doubt the router is doing anything wrong
> though. The weirdness is more on the Linux side..


Sure, for full transparency the packets should ideally use
the original source MAC address. I'll see if I can come
up with a patch for this.

Re: Bug in bridge or netfilter code (REJECT + incorrect MAC)?

[Jan Engelhardt]

On Wednesday 2008-04-02 13:06, Patrick McHardy wrote:
>>
>>  The router is my ISP's internet router, which I do not
>>  control. But I doubt the router is doing anything wrong
>>  though. The weirdness is more on the Linux side..
>
> Sure, for full transparency the packets should ideally use
> the original source MAC address. I'll see if I can come
> up with a patch for this.

The problem is an interesting one. REJECT itself does not fill
in the MAC address, and probably should not try (there is more
than just Ethernet). Yet the routing code is so deeply buried
that drawing a seam through the entire call chain seems intrusive.
</random thoughts>


-- 
make boldconfig -- to boldly select what no one has selected before

Re: Bug in bridge or netfilter code (REJECT + incorrect MAC)?

[Patrick McHardy]

Jan Engelhardt wrote:
> 
> On Wednesday 2008-04-02 13:06, Patrick McHardy wrote:
>>>
>>>  The router is my ISP's internet router, which I do not
>>>  control. But I doubt the router is doing anything wrong
>>>  though. The weirdness is more on the Linux side..
>>
>> Sure, for full transparency the packets should ideally use
>> the original source MAC address. I'll see if I can come
>> up with a patch for this.
> 
> The problem is an interesting one. REJECT itself does not fill
> in the MAC address, and probably should not try (there is more
> than just Ethernet). Yet the routing code is so deeply buried
> that drawing a seam through the entire call chain seems intrusive.
> </random thoughts>


One way is to have REJECT specifically handle the bridging case
by setting up an appropriate skb->nf_bridge struct, which will
make the bridging code fill in the correct MAC address. For
REJECT this would be borderline OK, but icmp_send really shouldn't
care about this, so a generic method would be preferrable.

Re: Bug in bridge or netfilter code (REJECT + incorrect MAC)?

[Patrick McHardy]

Jan Engelhardt wrote:
> 
> On Wednesday 2008-04-02 13:06, Patrick McHardy wrote:
>>>
>>>  The router is my ISP's internet router, which I do not
>>>  control. But I doubt the router is doing anything wrong
>>>  though. The weirdness is more on the Linux side..
>>
>> Sure, for full transparency the packets should ideally use
>> the original source MAC address. I'll see if I can come
>> up with a patch for this.
> 
> The problem is an interesting one. REJECT itself does not fill
> in the MAC address, and probably should not try (there is more
> than just Ethernet). Yet the routing code is so deeply buried
> that drawing a seam through the entire call chain seems intrusive.
> </random thoughts>


Well, I didn't find a good way to fix this. Casper,
please open a bug report at bugzilla.netfilter.org
so this doesn't get lost. Thanks.