Ethernet Bridge development
 help / color / mirror / Atom feed
* [Bridge] mac table updates
@ 2005-07-28 23:23 Dirk Morris
  2005-07-29  4:33 ` Stephen Hemminger
  0 siblings, 1 reply; 3+ messages in thread
From: Dirk Morris @ 2005-07-28 23:23 UTC (permalink / raw)
  To: bridge

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

I think the new mac ageing (sometime since 2.6.8.1) may be too aggressive.
Now it updates the table at a much later time, with a comment in the 
code that leads me to believe
this is to prevent counting spoofed packets and a DOS.

My problem is that the update occurs after the netfilter hooks which may 
do weird things to change the course of the packet so that it does not 
get counted.
(in my case, redirecting, queueing to userspace, nonlocally bound 
sockets, etc).
For me this causes packets to go spewing out on the wrong interface when 
the timer expires.

I used the attached patch to revert back to the old method.

-Dirk

[-- Attachment #2: bridge-mac-ageing-fix.patch --]
[-- Type: text/x-patch, Size: 545 bytes --]

diff -urN linux-2.6.12.3/net/bridge/br_input.c linux-2.6.12.3-bridgefix/net/bridge/br_input.c
--- linux-2.6.12.3/net/bridge/br_input.c	2005-07-15 14:18:57.000000000 -0700
+++ linux-2.6.12.3-bridgefix/net/bridge/br_input.c	2005-07-25 23:19:30.903355408 -0700
@@ -111,7 +111,8 @@
 	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
 		goto err;
 
-	if (p->state == BR_STATE_LEARNING)
+	if (p->state == BR_STATE_LEARNING ||
+        p->state == BR_STATE_FORWARDING)
 		br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
 
 	if (p->br->stp_enabled &&

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bridge] mac table updates
  2005-07-28 23:23 [Bridge] mac table updates Dirk Morris
@ 2005-07-29  4:33 ` Stephen Hemminger
  2005-07-29 16:43   ` Dirk Morris
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2005-07-29  4:33 UTC (permalink / raw)
  To: Dirk Morris; +Cc: bridge

On Thu, 28 Jul 2005 16:23:43 -0700
Dirk Morris <dmorris@metaloft.com> wrote:

> I think the new mac ageing (sometime since 2.6.8.1) may be too
> aggressive. Now it updates the table at a much later time, with a
> comment in the code that leads me to believe
> this is to prevent counting spoofed packets and a DOS.
> 
> My problem is that the update occurs after the netfilter hooks which
> may do weird things to change the course of the packet so that it
> does not get counted.
> (in my case, redirecting, queueing to userspace, nonlocally bound 
> sockets, etc).
> For me this causes packets to go spewing out on the wrong interface
> when the timer expires.
> 
> I used the attached patch to revert back to the old method.
> 
> -Dirk

If you are whacking the source address, that seems wrong.  The fix for
that would be to copy the original source address somewhere, then
extract it back afterwards.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bridge] mac table updates
  2005-07-29  4:33 ` Stephen Hemminger
@ 2005-07-29 16:43   ` Dirk Morris
  0 siblings, 0 replies; 3+ messages in thread
From: Dirk Morris @ 2005-07-29 16:43 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: bridge

>
>
>>I think the new mac ageing (sometime since 2.6.8.1) may be too
>>aggressive. Now it updates the table at a much later time, with a
>>comment in the code that leads me to believe
>>this is to prevent counting spoofed packets and a DOS.
>>
>>My problem is that the update occurs after the netfilter hooks which
>>may do weird things to change the course of the packet so that it
>>does not get counted.
>>(in my case, redirecting, queueing to userspace, nonlocally bound 
>>sockets, etc).
>>For me this causes packets to go spewing out on the wrong interface
>>when the timer expires.
>>
>>I used the attached patch to revert back to the old method.
>>    
>>
>If you are whacking the source address, that seems wrong.  The fix for
>that would be to copy the original source address somewhere, then
>extract it back afterwards.
>  
>
I think I was leaving the source address, but I was queueing to 
userspace, which causes the packet
to "disappear" from the kernel, meaning the update code was just never 
reached.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-07-29 16:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-28 23:23 [Bridge] mac table updates Dirk Morris
2005-07-29  4:33 ` Stephen Hemminger
2005-07-29 16:43   ` Dirk Morris

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox