public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Scholz <scholz@cs.uni-bonn.de>
To: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] PAN and bridge problem when bnep0 disconnects before bnep1
Date: Thu, 13 May 2004 14:51:54 +0200	[thread overview]
Message-ID: <1084452714.2318.12.camel@willie.informatik.uni-bonn.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

Hi,

I experienced the same problem as Matthias Thomae. I already posted this
to the mailing-list some time ago (see attached mail). It is actually a
problem with the Linux bridge code. It does not seem to be able to cope
with multiple interfaces using the same MAC-Address.

Unfortunately, I have no real solution to the problem.

Regards,

Christoph

[-- Attachment #2: Forwarded message - Problems with Bridging and PAN Profile --]
[-- Type: message/rfc822, Size: 2101 bytes --]

From: Christoph Scholz <scholz@cs.uni-bonn.de>
To: bluez-users@lists.sourceforge.net
Subject: Problems with Bridging and PAN Profile
Date: Fri, 09 Jan 2004 14:49:02 +0100
Message-ID: <1073656142.3037.32.camel@willie.informatik.uni-bonn.de>

Hi all,

I am experiencing problems with the Linux transparent bridge
implementation combined with BlueZ. Probably it is not BlueZ' fault but
related. Just wanted to know if someone else knows about this problem.

I used a very simple PAN scenario with one master (GN) and two slaves
(PANU). The GN runs a Linux bridge and the individual devices for the
slaves are added to the bridge by using the "/etc/bluetooth/pan/dev-up"
script. All similar to the PAN Howto.

After establishing the two connections everything works fine. But after
disconnecting the first slave (the one that was connected to the master
first) communication between the master and the remaining slave does not
work any more. Closer investigation shows that the failure is found in
the bridge device that does not accept the received frames any more.
Interestingly, when runing tcpdump on the bridged device everything
seems to work fine again. This is probably due to the bridge device
entering promiscuous mode. Probably, the problem is related to the
following message found in /var/log/messages:

"bnep1: attempt to add interface with same source address."

This is due to the fact that all the bnep interfaces own the same MAC
address (= BD_ADDR of the Bluetooth device).

It seems the Linux bridge does not work reliably with duplicate mac
addresses on its interface. 

Does anyone of you experienced similar problems? Any ideas on how to
resolve this?

Thanks.


Regards,

Christoph
-- 
Christoph Scholz <scholz@cs.uni-bonn.de>
University of Bonn, Institut of Computer Science IV
Römerstraße 164,
D-53117 Bonn, Germany
Phone: +49 228 73 4117
Fax: +49 228 73 4571
http://web.informatik.uni-bonn.de/IV/Mitarbeiter/scholz/

             reply	other threads:[~2004-05-13 12:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-13 12:51 Christoph Scholz [this message]
2004-05-13 14:07 ` [Bluez-devel] PAN and bridge problem when bnep0 disconnects before bnep1 Diego Liziero
2004-05-13 18:22   ` Diego Liziero
2004-05-13 14:09 ` Matthias Thomae
  -- strict thread matches above, loose matches on Subject: below --
2004-05-12 19:26 Matthias Thomae
2004-05-12 21:42 ` Marcel Holtmann
2004-05-14 13:57   ` Paulo Marques

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1084452714.2318.12.camel@willie.informatik.uni-bonn.de \
    --to=scholz@cs.uni-bonn.de \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox