bridging bluetooth bnep devices with kernel 2.6.6-*

It seems that switching from 2.4.x to 2.6.x
caused the bridge of more than a bnep (Bluetooth) device to stop to work.

Details on this kind of bridging at:
http://www.cs.ucla.edu/~cclljj/interest/notes/bluez/pand_bridge_nap.html

Note that the MAC address of all these devices is the same, as they belong to the same bluetooth device.

# ifconfig bnep0
bnep0     Link encap:Ethernet  HWaddr 00:02:72:80:1B:3B
          inet6 addr: fe80::202:72ff:fe80:1b3b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:537 errors:0 dropped:0 overruns:0 frame:0
          TX packets:138 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:69267 (67.6 KiB)  TX bytes:24779 (24.1 KiB)

# ifconfig bnep1
bnep1     Link encap:Ethernet  HWaddr 00:02:72:80:1B:3B
          inet6 addr: fe80::202:72ff:fe80:1b3b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5094 (4.9 KiB)  TX bytes:356 (356.0 b)

What I did is:

# brctl addbr pan0
# ifconfig pan0 192.168.111.1
# brctl setfd pan0 0
# brctl stp pan0 disable

# brctl addif pan0 bnep0
# ifconfig bnep0 0.0.0.0

And the first bluetooth link works fine,
but when I try to add a second link I get:

# brctl addif pan0 bnep1
can't add bnep1 to bridge pan0: File exists
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

if I try to remove bnep1:

# brctl delif pan0 bnep1
device bnep1 is not a slave of pan0

With kernel 2.4.x instead everything works.
Any suggestion?

Regards,

Diego.

2.6.6 got too picky about multiple interfaces with the same address. This patch has been already integrated for later releases.

diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
@@ -277,18 +277,18 @@
 		if (!memcmp(fdb->addr.addr, addr, ETH_ALEN)) {
 			/* attempt to update an entry for a local interface */
 			if (unlikely(fdb->is_local)) {
-				if (is_local) 
-					printk(KERN_INFO "%s: attempt to add"
-					       " interface with same source address.\n",
-					       source->dev->name);
-				else if (net_ratelimit()) 
-					printk(KERN_WARNING "%s: received packet with "
-					       " own address as source address\n",
-					       source->dev->name);
-				ret = -EEXIST;
+				/* it is okay to have multiple ports with same 
+				 * address, just don't allow to be spoofed.
+				 */
+				if (!is_local) {
+					if (net_ratelimit()) 
+						printk(KERN_WARNING "%s: received packet with "
+						       " own address as source address\n",
+						       source->dev->name);
+					ret = -EEXIST;
+				}
 				goto out;
 			}
-
 
 			if (likely(!fdb->is_static || is_local)) {
 				/* move to end of age list */

Sorry, I've been too quick in writing without realizing that the patch had been already posted to this mailing list.

This patch solved everything.

Thank you.

BTW, there is another issue that may be related to the bridge that is being discussed on bluez-devel mailing list:

http://thread.gmane.org/gmane.linux.bluez.devel/2160

Regards,

Diego

I do think each bluetooth device should have a different hardware address to keep themselves sane.

Things are not so easy.

Each bluetooth dongle has it's own harware address (MAC) and in a piconet (one master and up to 7 slaves)
at each PAN connection a device called bnep0, ... bnep6
is created on the master PC by bluez with the same MAC of the dongle.

Each device bnep? for each maste-slave point to point connection.

And the bad thing is that when one of these connection is closed, its relative device (bnep?) cease to exist.

And this create serious problems with things like a dhcp server and a bridge.

Regards,
Diego

Thanks for your support.

I'm back with the "brige freezes when bluetooth bnep0 disconnects before bnep1" issue.

As reported in the bluez-devel mailing list, in a bridge called pan0 with the interfaces bnep0, bnep1, .. bnep6 connected, if the interface bnep6 is disconnected first, everything works fine, but if bnep0 is disconnected before the others, the bridge stops to work.

Arping from bnep1 to the brige results in just the first answer received.

To make it work again I have to use the following dirty hack:
brctl delif pan0 bnep1
brctl addif pan0 bnep1

Someone in the bluez-devel mailing list told that also setting the bridge in promiscuous mode with tcpdump makes the bridge back to work.

Now I'm removing and re-adding all the bridge components when hotplug detects that a "bnep?" device ceases to exist.

Any better solution?

Regards,
Diego

Sounds like an issue with how the bnep does promiscious mode. Do you see messages on the console like:
device bnep0 left promiscious mode

Also, the bnep driver seems to need BT_BNEP_MC_FILTER enabled to do multicast.

When you remove bnep0 first, what does "brctl showstp pan0" show?

Thanks for your help.

I forgot to mention the steps I did to setup the bridge.

I have 2 ethernet cards, eth0->to internet, eth1->192.168.* natted lan.

I'm using a Debian with hotplug and in /etc/network/interfaces I have the following lines:

iface pan0 inet static
pre-up brctl addbr pan0
pre-up brctl addif pan0 eth1
pre-up ifconfig eth1 0.0.0.0
address 192.168.111.1
netmask 255.255.255.0
up brctl setfd pan0 0
up brctl stp pan0 disable
up /etc/init.d/dhcp3-server restart
post-down brctl delbr pan0
post-down ifconfig eth1 192.168.111.1 netmask 255.255.255.0
post-down /etc/init.d/dhcp3-server restart
iface bnep0 inet static
address 192.168.111.70
netmask 255.255.255.0
pre-up brctl addif pan0 $IFACE
up ifconfig $IFACE 0.0.0.0
down brctl delif pan0 $IFACE

iface bnep1 inet static

        address 192.168.111.71
        netmask 255.255.255.0
        pre-up brctl addif pan0 $IFACE
        up ifconfig $IFACE 0.0.0.0
        down brctl delif pan0 $IFACE

When the first PDA is connected I get the following in the syslog:

net.agent[7222]: invoke ifup bnep0=hotplug
kernel: device bnep0 entered promiscuous mode
pand[7220]: New connection from 00:80:C8:1F:E3:77 bnep0
kernel: pan0: port 2(bnep0) entering learning state
kernel: pan0: topology change detected, propgating
kernel: pan0: port 2(bnep0) entering forwarding state
dhcpd: DHCPREQUEST for 192.168.111.171 from 00:80:c8:1f:e3:77 via pan0
dhcpd: DHCPACK on 192.168.111.171 to 00:80:c8:1f:e3:77 via pan0

When I connect the second one:

net.agent[7271]: invoke ifup bnep1=hotplug
pand[7269]: New connection from 00:40:05:60:5A:14 bnep1
kernel: device bnep1 entered promiscuous mode
kernel: pan0: port 3(bnep1) entering learning state
kernel: pan0: topology change detected, propgating
kernel: pan0: port 3(bnep1) entering forwarding state
dhcpd: DHCPDISCOVER from 00:40:05:60:5a:14 via pan0
dhcpd: DHCPOFFER on 192.168.111.172 to 00:40:05:60:5a:14 via pan0
dhcpd: DHCPREQUEST for 192.168.111.172 (192.168.111.1) from 00:40:05:60:5a:14 via pan0
dhcpd: DHCPACK on 192.168.111.172 to 00:40:05:60:5a:14 via pan0

When I disconnect the first one (bnep0) first:

net.agent[7299]: invoke ifdown bnep0
kernel: pan0: port 2(bnep0) entering disabled state
kernel: pan0: port 2(bnep0) entering disabled state
kernel: device bnep0 left promiscuous mode

# brctl showstp pan0
pan0
 STP is disabled for this interface

When I disconnect also the second one (bnep1):

kernel: pan0: port 3(bnep1) entering disabled state
kernel: pan0: port 3(bnep1) entering disabled state
kernel: device bnep1 left promiscuous mode net.agent[7319]: invoke ifdown bnep1

Regards,
Diego

Hmm, since all the blue tooth devices have the same address. Deleting the first one will cause the entry in the forwarding table to be deleted, that might cause your problem. Perhaps we need a reference count on the number of interfaces with the same address (yuck).

That seems like a reasonable answer. I believe there's also some workstation hardware with multiple Ethernet devices, all sharing the same MAC address (== hostid). It's not just Bluetooth. How does this work with VLAN bridging?

Precisely what is it that's indexed on the interface's MAC address, rather than the (index of the) physical interface itself?

dwmw2

When is the following lock needed ?

	br_write_lock_bh(BR_NETPROTO_LOCK);

-Raj