Thread (16 messages) 16 messages, 2 authors, 2008-11-07

Re: IP-less bridge as a martian source

From: Ferenc Wagner <hidden>
Date: 2008-11-06 14:31:47

Jarek Poplawski [off-list ref] writes:
On Thu, Nov 06, 2008 at 01:00:05PM +0100, Ferenc Wagner wrote:
quoted
Jarek Poplawski [off-list ref] writes:
quoted
quoted
wferi@xen1:~$ sudo cat /proc/net/vlan/vlan891 
[...]
EGRESSS priority Mappings: 
Should be corrected: maybe you will send a patch? (Otherwise let me now.)
I sent one.  Hope it's OK.
Looks OK to me.
Still I'm afraid it would break some users' scripts... ;)
quoted
My question is: why does the IP-less bridge pick up any packets?
Does the host-based addressing model require this, if the host has
any IP address at all (on some other interface)?
Do you mean why it's routed at all?
Yes, probably that's what I mean.  I expected such packages to stay in
the link layer (http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png)
Hmm.  In my case the only possible way out is "Bridging Decision" in
the input phase.  That surely kicks in, as these packages are destined
to ff:ff:ff:ff:ff:ff...  Confirmed: after ebtables -A INPUT -j DROP
those "martian source" warnings don't appear anymore.

Btw what is that "Processing decision" right after Qdisc Deque(ue)?  A
check whether the destination MAC is ours?  I also wonder where
tcpdump attaches its probe on that picture...
Probably it's something about bridge configs, like BRIDGE_EBT_BROUTE
etc. You could try to analyze net/bridge/br_input.c/br_handle_frame()
for cases when it returns skb (instead of NULL).
Thanks, that set me on track.  Although ebtable_broute was not loaded
originally, now ebtable_filter is.
quoted
I didn't mean separating the ports of the bridge, but separating the
host running the bridge from the traffic the bridge forwards.  It
should be able to forward all the strangest IP or non-IP traffic of
the world and stay totally unaffected.
Yes, I missed your point. So I think this should be configurable.
Turns out it is, sort of, by ebtables.

But the directed broadcast pings (destined to the network broadcast
address) also have full-one destination MAC, and they weren't
logged...  Even though the host didn't know about those networks
either.  So part of the mistery remains.
Are you sure they use something else then 0.0.0.0 as a source address
with these 255.255.255.255 packets?
Yes, as my previous log summary shows, they usually carry the actual
source address.  DHCP is different in this respect.  Also, there are
different types of WoL, some masquerade as UDP, some do not.
-- 
Regards,
Feri.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help