netdev - [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110705204200@it-loops.com>
Date:	Tue, 5 Jul 2011 20:43:40 +0200
From:	Michael Guntsche <mike@...loops.com>
To:	xu@...son.comsick.at
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup

Hello,

After updating from 3.0.0-rc5 to rc6 I noticed that my cellphone was no
longer able to get an address assigned from my DHCP server. While trying
to figure out the problem I noticed that tracing with tcpdump made it
work again.

The setup I have here is the following:
PPC embedded board where the wired NIC and the wlan NIC are in a bridge.
Dnsmasq is listening on the Bridge device itself.

Looking at the changes between rc5 and rc6 I noticed commit

 bd4265fe365c0f3945d: bridge: Only flood unregistered groups to routers

For testing purposes I reverted it and the cellphone immediately got an
address even without running tcpdump. Now apparently the commit states
that the user can always force flooding behaviour to any given port by
marking it as a router but I did not find any documentation how to do
that.

Now my question? Is it "normal" that this change breaks my setup here
and if it is expected how can I force my ports to the old behaviour
without reverting the commit.

Thank you very much in advance,
Michael 
--
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