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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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
>
>
>
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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.
http://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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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.
http://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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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.
>
> http://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 http://www.blackhat.com
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> 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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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.
http://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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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.
http://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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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
>
>
>
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 http://www.blackhat.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users