Re: [Bluez-users] BT_ADDR Address Resolution

Re: [Bluez-users] BT_ADDR Address Resolution

[Michael Schmidt]

Hi Assed,

If BlueZ hasn't introduced a mechanism of its own recently, there is no 
dedicated BueZ IP address assignment mechanism. Of course, you may use 
DHCP if a suitable server is available.

The Bluetooth PAN specification ("Personal Area Networking Profile 
v1.0") recommends the "Zero Configuration Networking (Zeroconf)" 
standard (http://www.zeroconf.org/) with 
draft-ietf-zeroconf-ipv4-linklocal-02.txt (or actually one of its 
successors) as instant ("zero configuration") IP address assignment 
algorithm. The code for UNIX (called 'zcip') used to be available at 
http://zeroconf.sourceforge.net/?selected=zcip, but currently there seem 
to be intellectual property problems with it (see explanation on web 
page), so that the code has been removed. Actually it creates an IP 
address out of the 169.254/16 address range with a mathematical 
transform that is seeded by the network adapter's MAC address. It 
queries for potential collisions via AR, and defends an assigned IP 
address against subsequent collisions via ARP.


Hope this helps,

Michael


> Does anyone know how IP addresses in the Bluez PAN get resolved to 
> BT_ADDRs that will be used by BNEP? Is there an ARP broadcast (i.e. query 
> like slave -> master -> broadcast to all slaves) or some sort of proxy ARP
> mechanism at master (e.g. query from slave->master and then a reply 
> master->slave).
> 
> 
> Thanks,
> Assed

-- 
=================================================
Michael Schmidt
-------------------------------------------------
Institute for Data Communications Systems
University of Siegen, Germany
-------------------------------------------------
http:   www.nue.et-inf.uni-siegen.de
e-mail: schmidt@nue.et-inf.uni-siegen.de
mobile: +49 179 7810214
=================================================


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Slaves in Sniff mode

[Peter Stephenson]

tOpSy TuRvY wrote:
> Isn't it technically possible for the  master to send small amount of 
> BNEP data to PANUs in parked mode using the PSB logical channel? The 
> PANU would of course have to shift into connected mode before replying.
> 
> The above would allow the system to support a BNEP layer broadcast (e.g. 
> ARP) to all PANUs attached to the GN (i.e those in connected and parked mode)
> .

Broadcasts are allowed to parked slaves, so it's possible to do that
without unparking.  However, this is only possible master to slave and
(while I don't know much about the intervening layers) the notion of an
aysmmetric link isn't very natural at the networking layer, so you would
have to define the occasions when this would occur quite carefully.

For anything else, you would have to unpark the slave.
The spec allows the link manager to do this autonomously if data
arrives, but you can't rely on that (I don't know of anyone who does it,
offhand, but I haven't particularly looked), so the host has to be
prepared to do the unparking.

> > > One last question on this issue. Can the GN in Bluez ask the PANU to go 
> > > into sniff mode *automatically* based on some criteria (e.g. low 
> > > activity), or ask it to come out of sniff mode (e.g. based on a large 
> > > queue).
> > 
> > It would be up to the host code to do this.  There's nothing stopping
> > (say) the bnep layer from monitoring data and sending sniff and unsniff
> > requests.  There's no facility for doing this below HCI.
> > 
> 
> Isn't it better for e.g. the link manager to do this since the BNEP layer 
> can only see BNEP traffic, but the link manager can also see SCO and ACL 
> traffic.

This is why Marcel mentioned the HCI layer --- it sees all the data and
can tell the device to enter or leave sniff.  This is probably the best
bet.  There's no real gain that I can see in forcing it below HCI.
(At the last count our chip had roughly four orders of magnitude less RAM
than the average new PC.  That's why you can get dongles for $15.)

pws


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

[Bluez-users] BT_ADDR Address Resolution

[tOpSy TuRvY]

Hi,

Just wondering...

Does anyone know how IP addresses in the Bluez PAN get resolved to 
BT_ADDRs that will be used by BNEP? Is there an ARP broadcast (i.e. query 
like slave -> master -> broadcast to all slaves) or some sort of proxy ARP
mechanism at master (e.g. query from slave->master and then a reply 
master->slave).


Thanks,
Assed


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] BT_ADDR Address Resolution

[Marcel Holtmann]

Hi Assed,

> Does anyone know how IP addresses in the Bluez PAN get resolved to 
> BT_ADDRs that will be used by BNEP? Is there an ARP broadcast (i.e. query 
> like slave -> master -> broadcast to all slaves) or some sort of proxy ARP
> mechanism at master (e.g. query from slave->master and then a reply 
> master->slave).

BNEP is only an ethernet emulation over Bluetooth L2CAP. So you must use
ARP and IP for the IP addresses.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] BT_ADDR Address Resolution

[tOpSy TuRvY]

Hi Marcel,

The ARP will take place using BNEP frames right? i.e. an ARP packet 
encapsulated in a BNEP frame with a destination address corrosponding to 
a broadcast MAC address.

Assuming one PANU wishes to send IP traffic to another PANU. When this 
BNEP frame encapsulating the ARP request arrives at the GN, is it
broadcast on all bridge ports?

Also does the bridge implimentation result in one broadcast per "port" 
i.e. instead of one baseband layer broadcast (i.e. LT_ADDR = 000), we will have 
as many broadcasts as the number of connected PANUs (i.e. one per 
port)?

I hope I'm not sounding too confused.

Thanks for your explaination.

Regards,
Assed


On Thu, 24 Jun 2004, Marcel Holtmann wrote:

> Hi Assed,
> 
> > Does anyone know how IP addresses in the Bluez PAN get resolved to 
> > BT_ADDRs that will be used by BNEP? Is there an ARP broadcast (i.e. query 
> > like slave -> master -> broadcast to all slaves) or some sort of proxy ARP
> > mechanism at master (e.g. query from slave->master and then a reply 
> > master->slave).
> 
> BNEP is only an ethernet emulation over Bluetooth L2CAP. So you must use
> ARP and IP for the IP addresses.
> 
> Regards
> 
> Marcel
> 
> 
> 

Re: [Bluez-users] BT_ADDR Address Resolution

[Marcel Holtmann]

Hi Assed,

> The ARP will take place using BNEP frames right? i.e. an ARP packet 
> encapsulated in a BNEP frame with a destination address corrosponding to 
> a broadcast MAC address.
> 
> Assuming one PANU wishes to send IP traffic to another PANU. When this 
> BNEP frame encapsulating the ARP request arrives at the GN, is it
> broadcast on all bridge ports?

the Linux PAN is a point-to-point connection. If you want to build a NAP
or GN you must also use the Linux bridge. So this is not a PAN question,
this depends on how you configured your bridge.

> Also does the bridge implimentation result in one broadcast per "port" 
> i.e. instead of one baseband layer broadcast (i.e. LT_ADDR = 000), we will have 
> as many broadcasts as the number of connected PANUs (i.e. one per 
> port)?

No Bluetooth broadcast is used. Read the BNEP and PAN specifications.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] BT_ADDR Address Resolution

[tOpSy TuRvY]

Hi Marcel,

> the Linux PAN is a point-to-point connection. If you want to build a NAP
> or GN you must also use the Linux bridge. So this is not a PAN question,
> this depends on how you configured your bridge.

You are right, it was a bridge question. I think it would be fair to 
assume that the bridge is going to forward all broadcast traffic it 
recieves on all the ports (except the one it came on).

> 
> > Also does the bridge implimentation result in one broadcast per "port" 
> > i.e. instead of one baseband layer broadcast (i.e. LT_ADDR = 000), we will have 
> > as many broadcasts as the number of connected PANUs (i.e. one per 
> > port)?
> 
> No Bluetooth broadcast is used. Read the BNEP and PAN specifications.
> 

Read those and tried to understand them. What I gathered is that there 
will be one Bluetooth broadcast sent to each of the connected PANUs. i.e. 
one Bluetooth broadcast sent on each bridge port, and that seems very 
wasteful since just one bluetooth broadcast on any port would have been 
recieved by all the PANUs right?


Regards,
Assed

Re: [Bluez-users] BT_ADDR Address Resolution

[Marcel Holtmann]

Hi Assed,

> > the Linux PAN is a point-to-point connection. If you want to build a NAP
> > or GN you must also use the Linux bridge. So this is not a PAN question,
> > this depends on how you configured your bridge.
> 
> You are right, it was a bridge question. I think it would be fair to 
> assume that the bridge is going to forward all broadcast traffic it 
> recieves on all the ports (except the one it came on).

depends on your bridge configuration ;)

> > No Bluetooth broadcast is used. Read the BNEP and PAN specifications.
> 
> Read those and tried to understand them. What I gathered is that there 
> will be one Bluetooth broadcast sent to each of the connected PANUs. i.e. 
> one Bluetooth broadcast sent on each bridge port, and that seems very 
> wasteful since just one bluetooth broadcast on any port would have been 
> recieved by all the PANUs right?

Bluetooth PAN is point-to-point. It is like that you replace the CAT-5
cable between your machine and the switch with a Bluetooth connection.
Everything else is then TCP/IP specific.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users