Debugging bridge behavior

I have a bridge between two ports where a packet comes into one port
destined for the other, but never seems to reach the bridge.

I am trying to implement a VPN test network using VirtualBox hosting
various VMs on an x_64 Fedora 8 host running on a Xeon.

One VPN device is a bump-in-the-wire device configured with ethernet
packets physically connected to eth1 on the VM host system.

I have used the VirtualBox usility to create a vbox0 interface which
connects to the VM, and a bridge, br0 which connects eth1 and vbox0
together.

When I run the configuration utility in the VM (...or even on the VM
host), it sends a stimulus packet to the BITW VPN, and a response
comes back through eth1, but it does not pass back through the bridge.

tcpdump shows the following on eth1:
[root@cld-interop bin]# tcpdump -i eth1 -n
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
l istening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:34:07.917327 00:80:52:00:ff:ff > 00:80:52:00:00:00, ethertype
Unknown (0x814f), length 64:
0x0000: 0000 0000 0002 0000 0000 0000 0000
0000 ................
0x0010: 0000 0000 0000 0000 0000 0000 0000
0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000
0000 ................
0x0030: 0000 ..
13:34:07.917400 00:00:00:00:00:00 > 00:80:52:00:ff:ff, ethertype
Unknown (0x814f), length 60:
0x0000: 0081 4000 0000 0002 0000 0009 0000
0000 ..@.............
0x0010: 0000 0000 0000 0000 0000 0000 0000
0000 ................
0x0020: 0000 0000 0000 0000 0000 0000
0000 ..............

The first packet is the stimulus to the BITW VPN, the second is the
response back to the config utility.

If I do tcpdump at br0 or vbox0, the outbound traffic appears, but not
the response.

Likewise, if I run the config utility directly from the VM host, it
doesn't see the response either whereas it did before I setup the
bridge. It's like something is jerking the packets right out of the
stack after tcpdump sees them but before they can get to the bridge /
config utility.

I can see that the return address is being entered into the bridge, so
if the packet got there, I would expect it to forward:
[root@cld-interop bin]# brctl showmacs br0
port no mac addr is local? ageing timer
1 00:15:17:14:b9:60 yes 0.00
2 00:80:52:00:ff:ff no 2.52
2 00:ff:69:9a:ec:8d yes 0.00

eth1 doesn't report dropping the packet.

iptables is disabled - it's a test network and I don't need the
headaches.

[root@cld-interop bin]# iptables
iptables v1.3.8: no command specified
Try `iptables -h' or 'iptables --help' for more information.
[root@cld-interop bin]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Any brilliant ideas as to where the packet is going or how to track
his progress through the system?

TIA,
- Tim.

Hello,

(E-Mail Removed) a écrit :
>
> When I run the configuration utility in the VM (...or even on the VM
> host), it sends a stimulus packet to the BITW VPN, and a response
> comes back through eth1, but it does not pass back through the bridge.
>
> tcpdump shows the following on eth1:
> [root@cld-interop bin]# tcpdump -i eth1 -n
> tcpdump: WARNING: eth1: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> l istening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> 13:34:07.917327 00:80:52:00:ff:ff > 00:80:52:00:00:00, ethertype
> Unknown (0x814f), length 64:
> 13:34:07.917400 00:00:00:00:00:00 > 00:80:52:00:ff:ff, ethertype
> Unknown (0x814f), length 60:

> The first packet is the stimulus to the BITW VPN, the second is the
> response back to the config utility.
>
> If I do tcpdump at br0 or vbox0, the outbound traffic appears, but not
> the response.
>
> Likewise, if I run the config utility directly from the VM host, it
> doesn't see the response either whereas it did before I setup the
> bridge. It's like something is jerking the packets right out of the
> stack after tcpdump sees them but before they can get to the bridge /
> config utility.
>
> Any brilliant ideas as to where the packet is going

Maybe the bridge code does not like the 00:00:00:00:00:00 source address
for some reason (is it a valid source MAC address ?).

> or how to track his progress through the system?

If ebtables is available you can log frames in the kernel log at each
step through the bridge framework.

ebtables -t broute -A BROUTING --log-prefix "eb_brt_brt "
ebtables -t nat -A PREROUTING --log-prefix "eb_nat_pre "
ebtables -t nat -A OUTPUT --log-prefix "eb_nat_out "
ebtables -t nat -A POSTROUTING --log-prefix "eb_nat_pst "
ebtables -t filter -A INPUT --log-prefix "eb_flt_inp "
ebtables -t filter -A FORWARD --log-prefix "eb_flt_fwd "
ebtables -t filter -A OUTPUT --log-prefix "eb_flt_out "

To flush all rules when done :
iptables -t mangle -F
iptables -t mangle -X
iptables -t nat -F
iptables -t nat -X
iptables -t filter -F
iptables -t filter -X

On Jul 10, 2:42*am, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
> Maybe the bridge code does not like the 00:00:00:00:00:00 source address
> for some reason (is it a valid source MAC address ?).

Actually, I think you hit it right on the head here, Pascal. The
release notes for the device mention this exact issue and its impact
on Linux bridging.

> If ebtables is available you can log frames in the kernel log at each
> step through the bridge framework.

I tried this, and I can see the traffic filtering through all the
various layers on the way out, and nothing at all shows up on the way
in, which I suppose indicates that the bridge never gets the packet,
which seems odd because the traffic got through before I enabled
bridging.

I still have problems now, but at least I know what they are.

Thanks, Pascal.
- Tim.

(E-Mail Removed) a écrit :
> On Jul 10, 2:42 am, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
> wrote:
>
>>Maybe the bridge code does not like the 00:00:00:00:00:00 source address
>>for some reason (is it a valid source MAC address ?).
>
> Actually, I think you hit it right on the head here, Pascal. The
> release notes for the device mention this exact issue and its impact
> on Linux bridging.
>
>>If ebtables is available you can log frames in the kernel log at each
>>step through the bridge framework.
>
> I tried this, and I can see the traffic filtering through all the
> various layers on the way out, and nothing at all shows up on the way
> in, which I suppose indicates that the bridge never gets the packet,
> which seems odd because the traffic got through before I enabled
> bridging.

Actually the bridge code receives the frame, but checks the source MAC
address and drops it if it's considered invalid before passing it to the
first ebtables chain. I hoped that the drop occured later (for instance
the output ethernet device driver being unable to send frames with an
all-zero address) so it may have been possible to modify the source MAC
address with ebtables, but no luck. You may consider hacking the bridge
code in the kernel source if you want to allow those packets through.

============== Found in net/bridge/br_input.c =======================

int br_handle_frame(struct net_bridge_port *p, struct sk_buff **pskb)
{
struct sk_buff *skb = *pskb;
const unsigned char *dest = eth_hdr(skb)->h_dest;

if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
goto err;

============== Found in include/linux/etherdevice.h =================

/**
* is_valid_ether_addr - Determine if the given Ethernet address is valid
* @addr: Pointer to a six-byte array containing the Ethernet address
*
* Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not
* a multicast address, and is not FF:FF:FF:FF:FF:FF.
*
* Return true if the address is valid.
*/
static inline int is_valid_ether_addr(const u8 *addr)
{
/* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to
* explicitly check for it here. */
return !is_multicast_ether_addr(addr) && !is_zero_ether_addr(addr);
}