[Bridge] Re: Strange DHCP behaviour with bridging

[Mike Snitzer]

On Tue, Mar 16 2004 at 12:07,
Stephen Hemminger <shemminger at osdl.org> wrote:

> On Tue, 16 Mar 2004 09:28:37 +0100
> <a.fiorino at chibacity.it> wrote:
> > Here is the scenario: I have one server with kernel 2.4.24 with a
> > bridge br0 made of 2 interfaces, eth0 and tap0 (the last is an OpenVPN
> > tunnel), and one remote computer connetting through tap0. 
> > 
> > If I assign a static IP to the remote computer, the bridge works perfecly 
> > (so I think the problem is not OpenVPN-related). If I start a DHCPd on the
> > server and I configure the remote client to get the IP from it,
> > something strange happens: if I "sniff" on the br0 interface, I can
> > see the DHCP requests coming from the client (from 0.0.0.0.bootpc to
> > 255.255.255.bootps) and the DHCPd answers going back from
> > ip.of.the.server.bootps to 255.255.255.255.bootpc; also sniffing on
> > eth0 gives the same result, but if I sniff on the tap0 interface, I
> > don't see the replies! So the client never get its own IP. What I'm
> > doing wrong? To add some mistery, sometimes (one try out of 10) the
> > reply flows correctly to the remote client. All the three interfaces
> > (eth0, br0, tap0) doesn't have firewalling enabled, and under /proc
> > ip_forwarding is enabled and rp_filter is disabled for all
> > interfaces. brctl showmacs br0 correctly shows the remote virtual
> > interface MAC address as not local.Both eth0 and tap0 have been
> > configured with ifconfig 0.0.0.0 promisc up.
> 
> So the packet makes it into the tap0 device, but the bridge doesn't know
> where to send the output.  Are you running spanning tree protocol or not?
> Look at the contents of the forwarding table (brctl showmacs br0)
> Spanning tree does take a while to settle on startup so it could be that
> you need to wait about a minute till the bridge starts running.
> 
> Or may the tap device doesn't have a real hardware mac
> address is confusing it.

Hello,

I have been trying to get bridging with tap devices working for a few
days; it would appear as though the bridge is unable to properly forward
traffic to the remote end of a tap device from another tap (specifically
between 2 UMLs).  

If I enslave 2 tap devices to the bridge and then start 2 UMLs that supply
the remote (non-local) ends of the tap the bridge shows:

snitm at amstel:~> sudo brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     00:ff:33:9f:43:45       yes                0.00
  2     00:ff:91:17:3a:d5       yes                0.00
  1     fe:fd:c0:a8:00:02       no                30.74
  2     fe:fd:c0:a8:00:03       no                 0.27

NOTE:
local #1 is tap0
local #2 is tap1
non-local #1 is uml0's eth0
non-local #2 is uml1's eth0

>From within either guest UML I can ping the host but I cannot ping the
other guest UML.  On the host I can ping each eth0 interface of the guest
UMLs.  If I go ahead and enslave an ethernet device on the host (making
other machines available through that device) the UML guests can't ping
those machines either.  Meanwhile the bridge (host/umlhost) is able to
ping all enslaved members of the switch (local or non-local).

I even have iptables MASQ going on the host so that traffic from br0 is
routed out eth0 to the greater internet; the guest UMLs can get out to the
net fine.  

SO ultimately attempts to communicate through a tap device to other
members of the ethernet bridge fail (except for the bridge's IP and other
physical devices on the host machine).

My findings with pinging other machines that are available through a eth
device that I enslave closely mirror what was describved earlier on this
list:

http://lists.osdl.org/pipermail/bridge/2004-February/000188.html

Any insight into the bridging code's ability to _really_ work with tap
devices would be greatly appreciated.

I've attached a script that I use to easily start and stop the bridge and
tap devices; maybe it could help others trying to reproduce these tap
issues with bridging.

Regards,
Mike

FYI.
I've subscribed to the bridge list but haven't been approved yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bridge.sh
Type: application/x-sh
Size: 2811 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/bridge/attachments/20040323/1c3fb4a6/bridge-0002.sh