On Tue, Mar 16 2004 at 12:07, Stephen Hemminger <shemminger@xxxxxxxx> wrote: > On Tue, 16 Mar 2004 09:28:37 +0100 > <a.fiorino@xxxxxxxxxxxx> 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@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.osdl.org/pipermail/bridge/attachments/20040323/1c3fb4a6/bridge.sh
