[Bluez-users] Max Number of PANUs supported in PAN

[Bluez-users] Max Number of PANUs supported in PAN

[tOpSy TuRvY]

Hello,

Can someone tell me the maximum number of users supported in one PAN?
I guess this question boils down to:

a) Are PANUs in Parked mode supported (i.e. 200+ PANUs in one PAN 
possible).
b) Is the PAN able to juggle PANUs between active and parked mode so 
they all seem "connected" and are able to communicate with each 
other.

Also, can something tell me if something like above is possible in the BT 
SIG PAN specification, or does it also support a maximum of 8 users in a 
PAN.

Thank you in advance.

Regards,
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] Max Number of PANUs supported in PAN

[Marcel Holtmann]

Hi Assed,

> Can someone tell me the maximum number of users supported in one PAN?
> I guess this question boils down to:
> 
> a) Are PANUs in Parked mode supported (i.e. 200+ PANUs in one PAN 
> possible).
> b) Is the PAN able to juggle PANUs between active and parked mode so 
> they all seem "connected" and are able to communicate with each 
> other.
> 
> Also, can something tell me if something like above is possible in the BT 
> SIG PAN specification, or does it also support a maximum of 8 users in a 
> PAN.

actually this might be possible. I never tried it, but the bigger
problem will be to find a Bluetooth chip that is tested to work with
seven actives slaves and a big number of parked devices in one piconet.

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] Max Number of PANUs supported in PAN

[tOpSy TuRvY]

Hi Marcel,

I am not really interested in the actual number of parked devices, I just 
assumed if you can support one parked slave, you can support an arbirtary 
number.

I will therefore re-phrase my question to: Can one PAN support 9 PANUs, 
i.e. there will always be atleast one parked PANU. The GN will now have to 
juggle PANUs between active and parked modes so they all seem "connected" 
and are able to communicate with each other.

Thanks.

Regards,
Assed


Can one PAN support 9 devices i.e. 8 active and 1 parked

On Tue, 22 Jun 2004, Marcel Holtmann wrote:

> Hi Assed,
> 
> > Can someone tell me the maximum number of users supported in one PAN?
> > I guess this question boils down to:
> > 
> > a) Are PANUs in Parked mode supported (i.e. 200+ PANUs in one PAN 
> > possible).
> > b) Is the PAN able to juggle PANUs between active and parked mode so 
> > they all seem "connected" and are able to communicate with each 
> > other.
> > 
> > Also, can something tell me if something like above is possible in the BT 
> > SIG PAN specification, or does it also support a maximum of 8 users in a 
> > PAN.
> 
> actually this might be possible. I never tried it, but the bigger
> problem will be to find a Bluetooth chip that is tested to work with
> seven actives slaves and a big number of parked devices in one piconet.
> 
> Regards
> 
> Marcel
> 
> 
> 

Re: [Bluez-users] Max Number of PANUs supported in PAN

[Marcel Holtmann]

Hi Assed,

> I am not really interested in the actual number of parked devices, I just 
> assumed if you can support one parked slave, you can support an arbirtary 
> number.

I only wanna warn you of the Bluetooth chip limitations. You will play
in a league that is not fun ;)

> I will therefore re-phrase my question to: Can one PAN support 9 PANUs, 
> i.e. there will always be atleast one parked PANU. The GN will now have to 
> juggle PANUs between active and parked modes so they all seem "connected" 
> and are able to communicate with each other.

So actually it is possible to create a PAN with more than 8 members, but
you must manage the parking by yourself. I never tested such stuff and
some broadcast traffic may kick your ass.

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

[Bluez-users] Slaves in Sniff mode

[tOpSy TuRvY]

Hi,

Does anyone know if the master delays ACL transmittions to slaves in sniff 
mode (i.e. till they become active again), or will it just keep on 
transmitting the baseband frame till the slave eventually wakes up and can 
send an ACK.

Regards,
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] Slaves in Sniff mode

[Peter Stephenson]

tOpSy TuRvY wrote:
> Does anyone know if the master delays ACL transmittions to slaves in sniff 
> mode (i.e. till they become active again), or will it just keep on 
> transmitting the baseband frame till the slave eventually wakes up and can 
> send an ACK.

It should transmit any data during the sniff window.  The rules there
are identical to those in active mode, although obviously you will
get very much reduced throughput.

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

Re: [Bluez-users] Slaves in Sniff mode

[Marcel Holtmann]

Hi Assed,

> Does anyone know if the master delays ACL transmittions to slaves in sniff 
> mode (i.e. till they become active again), or will it just keep on 
> transmitting the baseband frame till the slave eventually wakes up and can 
> send an ACK.

the master should request an unsiff before it sends the next ACL packet.

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] Slaves in Sniff mode

[tOpSy TuRvY]

Hi Marcel,

I'm wondering how the master can request an unsniff if the slave is not 
listening to the channel.

I suppose the master should delay transmission till the next sniff window 
starts (i.e. as Peter suggested). Of course I'm guessing that at this 
point it could request an unsniff if the packet to be transmitted will 
not fit the sniff window.

Regards,
Assed

p.s. I'm also wondering how you get the time to reply to everybodys 
questions!

On Wed, 23 Jun 2004, Marcel Holtmann wrote:

> Hi Assed,
> 
> > Does anyone know if the master delays ACL transmittions to slaves in sniff 
> > mode (i.e. till they become active again), or will it just keep on 
> > transmitting the baseband frame till the slave eventually wakes up and can 
> > send an ACK.
> 
> the master should request an unsiff before it sends the next ACL packet.
> 
> 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] Slaves in Sniff mode

[Marcel Holtmann]

Hi Assed,

> I'm wondering how the master can request an unsniff if the slave is not 
> listening to the channel.
> 
> I suppose the master should delay transmission till the next sniff window 
> starts (i.e. as Peter suggested). Of course I'm guessing that at this 
> point it could request an unsniff if the packet to be transmitted will 
> not fit the sniff window.

everything depends on the sniff window, but the HCI also defines an exit
sniff mode command. I don't know how this is implemented on link manager
level.

> p.s. I'm also wondering how you get the time to reply to everybodys 
> questions!

I do my best ;)

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] Slaves in Sniff mode

[Peter Stephenson]

tOpSy TuRvY wrote:
> Hi Marcel,
> 
> I'm wondering how the master can request an unsniff if the slave is not 
> listening to the channel.
> 
> I suppose the master should delay transmission till the next sniff window 
> starts (i.e. as Peter suggested). Of course I'm guessing that at this 
> point it could request an unsniff if the packet to be transmitted will 
> not fit the sniff window.

It's designed so that data in sniff is pretty much transparent --- this
is what HID devices use to achieve low power consumption with low
latency.  (If I made that sound easy, you can take my word for it it
isn't, particularly with multiple devices :-/)

You can queue data for sending on the host just like normal.  You will
simply find it arrives on the other side in globs.  The baseband
fragments packets as necessary, so you don't have to worry about this at
the L2CAP level or above.

If you need data to come across faster, you must issue
HCI_exit_sniff_mode to the link.  You don't need to stop data while you
do that, the link manager traffic will fit in automatically.

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

Re: [Bluez-users] Slaves in Sniff mode

[Marcel Holtmann]

Hi Peter,

> It's designed so that data in sniff is pretty much transparent --- this
> is what HID devices use to achieve low power consumption with low
> latency.  (If I made that sound easy, you can take my word for it it
> isn't, particularly with multiple devices :-/)

and the CSR chip is the only one I found so far, that seems to work
nicely with a full piconet of HID devices ;)

Thanks for your explanation.

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] Slaves in Sniff mode

[tOpSy TuRvY]

Hi Peter,

Assume that the communication is taking place between two PANUs (i.e. 
slaves) in a PAN, where the destination PANU is in sniff mode. From your 
answer, am I correct in concluding that:

a) The fact that the receiving PANU is in sniff mode is transparent to the 
sender (except that the transfer rate will be lower and there may be some 
delays)

b) The queueing you mentioned will take place at the GN

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


Regards,
Assed

On Wed, 23 Jun 2004, Peter Stephenson wrote:

> tOpSy TuRvY wrote:
> > Hi Marcel,
> > 
> > I'm wondering how the master can request an unsniff if the slave is not 
> > listening to the channel.
> > 
> > I suppose the master should delay transmission till the next sniff window 
> > starts (i.e. as Peter suggested). Of course I'm guessing that at this 
> > point it could request an unsniff if the packet to be transmitted will 
> > not fit the sniff window.
> 
> It's designed so that data in sniff is pretty much transparent --- this
> is what HID devices use to achieve low power consumption with low
> latency.  (If I made that sound easy, you can take my word for it it
> isn't, particularly with multiple devices :-/)
> 
> You can queue data for sending on the host just like normal.  You will
> simply find it arrives on the other side in globs.  The baseband
> fragments packets as necessary, so you don't have to worry about this at
> the L2CAP level or above.
> 
> If you need data to come across faster, you must issue
> HCI_exit_sniff_mode to the link.  You don't need to stop data while you
> do that, the link manager traffic will fit in automatically.
> 
> 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
> 


-------------------------------------------------------
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:
> Assume that the communication is taking place between two PANUs (i.e. 
> slaves) in a PAN, where the destination PANU is in sniff mode. From your 
> answer, am I correct in concluding that:
> 
> a) The fact that the receiving PANU is in sniff mode is transparent to the 
> sender (except that the transfer rate will be lower and there may be some 
> delays)

Yes, there's no reason the sender would notice apart from the data in
small bursts.  (It's not like park mode where data isn't sent.)

> b) The queueing you mentioned will take place at the GN

So you're sending data PANU -> GN -> PANU?  If both links are in sniff,
the most likely place for data to queue up is at the sending PANU.  But
this is simply a question of available bandwidth, there's no specific
dependence on sniff.  You'd get the same thing if, say, the link quality
was very poor, or you were using one of our competitors' devices :-).

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

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

Re: [Bluez-users] Slaves in Sniff mode

[tOpSy TuRvY]

Hi,

On Wed, 23 Jun 2004, Peter Stephenson wrote:

> 
> Yes, there's no reason the sender would notice apart from the data in
> small bursts.  (It's not like park mode where data isn't sent.)

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


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

Thanks for your explaination.

Regards,
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] 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

Re: [Bluez-users] Slaves in Sniff mode

[Marcel Holtmann]

Hi Assed,

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

some time ago (a year a so) I made a proposal for adding automatic sniff
mode to the HCI core. However nobody (not even me) has started coding
this.

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

[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