netdev - Re: IP-less bridge as a martian source

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 7 Nov 2008 10:19:46 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Ferenc Wagner <wferi@...f.hu>
Cc:	netdev@...r.kernel.org
Subject: Re: IP-less bridge as a martian source

On Thu, Nov 06, 2008 at 03:31:44PM +0100, Ferenc Wagner wrote:
> Jarek Poplawski <jarkao2@...il.com> writes:
> 
> > On Thu, Nov 06, 2008 at 01:00:05PM +0100, Ferenc Wagner wrote:
> >> Jarek Poplawski <jarkao2@...il.com> writes:
> >>
> >>>> wferi@...1:~$ 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... ;)

Don't worry! (I don't use vlans...;)

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

This picture isn't probably exact enough. Have a look at net/core/dev.c
netif_receive_skb(). There are hooks for: netpoll(netconsole), bond,
taps (e.g. tcpdump), ingress qdisc, bridge, macvlan and protocols loop
(e.g. ip with routing, iptables etc.) These hooks can usually stop later
processing returning NULL. So, there are more processing decisions, and
maybe this one on the picture should be renamed to "Bridge Processing
Decission".

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

This is probably because of this special treatment of 255.255.255.255
(FFFFFFFF) in ip_route_input_slow(). Others could simply get
EHOSTUNREACH return only.

Regards,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html