[Bridge] Unexpected bridge behavior (Bug? You decide.)
magnus at alum.mit.edu
Tue Jan 25 20:31:05 PST 2005
>>>>> "Stephen" == Stephen Hemminger <shemminger at osdl.org> writes:
Stephen> On Sun, 23 Jan 2005 19:49:48 -0500
Stephen> Daniel Risacher <magnus at alum.mit.edu> wrote:
>> While using the linux bridge module in 2.6.10, the kernel seems
>> to munge the source IP address of broadcast UDP packets if they
>> come from "0.0.0.1", and sticks on an address of the linux
Stephen> That seems real surprising.
>> I humbly submit that re-writing the source address of packets
>> is not proper behavior for a bridge, even if those source
>> addresses are not traditionally valid.
Stephen> Are you running bridging with filtering (ebtables) or
Stephen> just pure bridging. The bridge code itself never looks
Stephen> at IP portion of the packet at all!
When I originally saw the problem, I did not have ebtables loaded. I
since loaded it as a module and see no change. I do have iptables
loaded, and had a MASQUERADE rule in POSTROUTE chain of the nat table.
Thinking this might be related, I deleted this rule and turned off
ip_forward; no change.
I removed the ipt_MASQUERADE module; no change. I removed the
iptable_nat module; eureka! Even when I had no rules in the nat
table, the iptable_nat module was modifying my source addresses.
>> [SNIP] removed problem description, see original article at :
Stephen> [SNIP] removed other troubleshooting questions (and the
Stephen> answers I was composing).
That solves my specific problem, but leads me to ponder if there's not
a bug lurking in the iptable_nat module.
I had similar problems with locally-generated UDP a few months ago: it
seemed like the kernel slapped on some source address that was
different from address of the bound socket. As it turns out, this
problem also goes away if I remove the iptable_nat module.
"The blues are multicolored." -- Dave Lambert
Daniel Risacher magnus at alum.mit.edu
More information about the Bridge