[Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Diego Liziero]

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.

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Stephen Hemminger]

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
--- a/net/bridge/br_fdb.c	Mon May 10 13:45:50 2004
+++ b/net/bridge/br_fdb.c	Mon May 10 13:45:50 2004
@@ -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 */

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Diego Liziero]

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

On Thu, 2004-05-13 at 19:28, Stephen Hemminger wrote:
> 2.6.6 got too picky about multiple interfaces with the same
> address. This patch has been already integrated for later releases.

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Stephen Hemminger]

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

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Diego Liziero]

On Thu, 2004-05-13 at 20:19, Stephen Hemminger wrote:
> 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

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Diego Liziero]

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

On Thu, 2004-05-13 at 20:15, Diego Liziero wrote:
> 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
> 
> On Thu, 2004-05-13 at 19:28, Stephen Hemminger wrote:
> > 2.6.6 got too picky about multiple interfaces with the same
> > address. This patch has been already integrated for later releases.
> 

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Stephen Hemminger]

On Mon, 17 May 2004 12:02:58 +0200
Diego Liziero <liziero.diego@unimore.it> wrote:

> 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?

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Diego Liziero]

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

On Wed, 2004-05-19 at 00:33, Stephen Hemminger wrote:
> 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?

Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[Stephen Hemminger]

On Mon, 17 May 2004 12:02:58 +0200
Diego Liziero <liziero.diego@unimore.it> wrote:

> 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.
>

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).

Re: [Bluez-devel] Re: [Bridge] bridging bluetooth bnep devices with kernel 2.6.6-*

[David Woodhouse]

On Tue, 2004-05-18 at 15:36 -0700, Stephen Hemminger wrote:
> 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

[Bridge] locking

[Rajashekhar Mansanpally]

When is the following lock needed ?

	br_write_lock_bh(BR_NETPROTO_LOCK);

-Raj