pan profile support in freebsd

[Maksim Yevmenkin-2]

dear freebsd-bluetooth@ users,

i'm pleased to announce that i've just imported btpand(8) daemon from
netbsd. this daemon provides support for NAP, GN and PANU profiles.
i've briefly tested it with a couple of PAN-enabled devices (i.e. my
windows-xp laptop and old hp ipaq 1940 running windows ce 4.20).

this is not yet connected to the build, but it is possible to build
and run it. please give it a try and let me know if it works for you.

====

Author: emax
Date: Fri Jan 30 22:23:21 2009
New Revision: 187938
URL: http://svn.freebsd.org/changeset/base/187938

Log:
 Add btpand(8) daemon from NetBSD. This daemon provides support for
 Bluetooth Network Access Point (NAP), Group Ad-hoc Network (GN) and
 Personal Area Network User (PANU) profiles.

 Obtained from:        NetBSD
 MFC after:    1 month

====

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Maksim Yevmenkin wrote:
> i'm pleased to announce that i've just imported btpand(8) daemon from
> netbsd. this daemon provides support for NAP, GN and PANU profiles.
> i've briefly tested it with a couple of PAN-enabled devices (i.e. my
> windows-xp laptop and old hp ipaq 1940 running windows ce 4.20).

Thanks for the good news and your work. I have managed to use by Qtek
S200 running WM 6.1 Internet Sharing service (NAP profile). It has
worked just out of the box.

The only newbie problem I had is what to specify in -d argument. NetBSD
examples specifying adapter name there, while FreeBSD does not accepts
this. I have spent some time looking for my adapter BDADDR.

PS: I have one small indirectly related, annoying problem. After some
time of being unused Qtek goes to some kind of sleep, which makes it not
responding on BT requests (both rfcomm and btpand), reporting "No route
to host". After several retries or just by running l2ping and waiting
for 3-5 seconds it successfully wakes up and working, but it makes using
it a bit annoying. Is there any known workaround for it?

PPS: Thanks again!

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

Alexander,

[...]

> Thanks for the good news and your work. I have managed to use by Qtek S200
> running WM 6.1 Internet Sharing service (NAP profile). It has worked just
> out of the box.

thanks for the report!

> The only newbie problem I had is what to specify in -d argument. NetBSD
> examples specifying adapter name there, while FreeBSD does not accepts this.
> I have spent some time looking for my adapter BDADDR.

well, it kinda does. you can edit /etc/bluetooth/hosts file and add
your adapter's bd_addr there, i.e.

00:11:22:33:44:55 mydevice

and then use -d mydevice with btpand(8).

> PS: I have one small indirectly related, annoying problem. After some time
> of being unused Qtek goes to some kind of sleep, which makes it not
> responding on BT requests (both rfcomm and btpand), reporting "No route to
> host". After several retries or just by running l2ping and waiting for 3-5
> seconds it successfully wakes up and working, but it makes using it a bit
> annoying. Is there any known workaround for it?

it depends. i'm guessing qtek device is probably putting idle
connection into 'sniff' or 'hold' (or even 'park') mode to conserve
battery life. you should be able to see what is going by running
hcidump. in any case, it should be possible to add something that
'tickles' connection once in a short while to prevent it from going
completely idle. it will drain the battery faster though.

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Maksim Yevmenkin wrote:

>> The only newbie problem I had is what to specify in -d argument. NetBSD
>> examples specifying adapter name there, while FreeBSD does not accepts this.
>> I have spent some time looking for my adapter BDADDR.
>
> well, it kinda does. you can edit /etc/bluetooth/hosts file and add
> your adapter's bd_addr there, i.e.
>
> 00:11:22:33:44:55 mydevice
>
> and then use -d mydevice with btpand(8).

I have done exactly the same, it just was not intuitive and differs from
NetBSD as I understood it. It was probably the first time when I needed
to know my adapter BDADDR.

>> PS: I have one small indirectly related, annoying problem. After some time
>> of being unused Qtek goes to some kind of sleep, which makes it not
>> responding on BT requests (both rfcomm and btpand), reporting "No route to
>> host". After several retries or just by running l2ping and waiting for 3-5
>> seconds it successfully wakes up and working, but it makes using it a bit
>> annoying. Is there any known workaround for it?
>
> it depends. i'm guessing qtek device is probably putting idle
> connection into 'sniff' or 'hold' (or even 'park') mode to conserve
> battery life. you should be able to see what is going by running
> hcidump. in any case, it should be possible to add something that
> 'tickles' connection once in a short while to prevent it from going
> completely idle. it will drain the battery faster though.

It does not happens when connection is alive, only when connection
establishes. So may be there some kind of timeout can be tuned, or
device can be forcefully woken up in some other way?

One more minor fact. Unlike rfcomm_pppd I haven't found an option to run
btpand in foreground to track connection status.

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin <mav@...> wrote:

> Maksim Yevmenkin wrote:
>>>
>>> The only newbie problem I had is what to specify in -d argument. NetBSD
>>> examples specifying adapter name there, while FreeBSD does not accepts
>>> this.
>>> I have spent some time looking for my adapter BDADDR.
>>
>> well, it kinda does. you can edit /etc/bluetooth/hosts file and add
>> your adapter's bd_addr there, i.e.
>>
>> 00:11:22:33:44:55 mydevice
>>
>> and then use -d mydevice with btpand(8).
>
> I have done exactly the same, it just was not intuitive and differs from
> NetBSD as I understood it. It was probably the first time when I needed to
> know my adapter BDADDR.

and what name would you like to use? ubt0? something else? dont forget
we dont create nodes under /dev for bluetooth devices. just netgraph
nodes. i have plan to implement libhci (a-la linux bluez etc.) shim
eventually :) if someone feels like beating me to it, i would
certainly not object to it :)

btw, obtaining bdaddr is really easy. in 99.9% cases (where there is
only one bluetooth device connected to the system) 'hccontrol
read_bd_addr' will do the trick :)

>>> PS: I have one small indirectly related, annoying problem. After some
>>> time
>>> of being unused Qtek goes to some kind of sleep, which makes it not
>>> responding on BT requests (both rfcomm and btpand), reporting "No route
>>> to
>>> host". After several retries or just by running l2ping and waiting for
>>> 3-5
>>> seconds it successfully wakes up and working, but it makes using it a bit
>>> annoying. Is there any known workaround for it?
>>
>> it depends. i'm guessing qtek device is probably putting idle
>> connection into 'sniff' or 'hold' (or even 'park') mode to conserve
>> battery life. you should be able to see what is going by running
>> hcidump. in any case, it should be possible to add something that
>> 'tickles' connection once in a short while to prevent it from going
>> completely idle. it will drain the battery faster though.
>
> It does not happens when connection is alive, only when connection
> establishes. So may be there some kind of timeout can be tuned, or device
> can be forcefully woken up in some other way?

oh, i misunderstood then. are you saying that initial connection setup
is slow? if so, then i'm guessing your qtek device is maybe missing
initial paging attempts. either this or something else is going on.
when you do inquiry what do

 Page Scan Rep. Mode
 Page Scan Period Mode
 Page Scan Mode

say for your qtek device? you can try to increase page timeout, i.e.
'hccontrol write_page_timeout' if your qtek device is timing out
during initial page attempt (default timeout is ~5sec).

in any case hcidump that shows the problem would be a good start.

> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run
> btpand in foreground to track connection status.

because there isn't one :) can be added though :) please feel free to
send in the patches :)

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Maksim Yevmenkin wrote:

> On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin <mav@...> wrote:
>> Maksim Yevmenkin wrote:
>>>> The only newbie problem I had is what to specify in -d argument. NetBSD
>>>> examples specifying adapter name there, while FreeBSD does not accepts
>>>> this.
>>>> I have spent some time looking for my adapter BDADDR.
>>> well, it kinda does. you can edit /etc/bluetooth/hosts file and add
>>> your adapter's bd_addr there, i.e.
>>>
>>> 00:11:22:33:44:55 mydevice
>>>
>>> and then use -d mydevice with btpand(8).
>> I have done exactly the same, it just was not intuitive and differs from
>> NetBSD as I understood it. It was probably the first time when I needed to
>> know my adapter BDADDR.
>
> and what name would you like to use? ubt0? something else? dont forget
> we dont create nodes under /dev for bluetooth devices. just netgraph
> nodes. i have plan to implement libhci (a-la linux bluez etc.) shim
> eventually :) if someone feels like beating me to it, i would
> certainly not object to it :)

Actually yes, ubt0. System reports it on boot, it is reported to the
peered devices in hostname and NetBSD does so. IMHO it is not a bad
choice from user's point of view.

Does actually this binding really necessary? rfcomm somehow works
without it.

> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is
> only one bluetooth device connected to the system) 'hccontrol
> read_bd_addr' will do the trick :)

Indeed. But general number of BT tools, daemons and their options just
making me sad.

>>>> PS: I have one small indirectly related, annoying problem. After some
>>>> time
>>>> of being unused Qtek goes to some kind of sleep, which makes it not
>>>> responding on BT requests (both rfcomm and btpand), reporting "No route
>>>> to
>>>> host". After several retries or just by running l2ping and waiting for
>>>> 3-5
>>>> seconds it successfully wakes up and working, but it makes using it a bit
>>>> annoying. Is there any known workaround for it?
>>> it depends. i'm guessing qtek device is probably putting idle
>>> connection into 'sniff' or 'hold' (or even 'park') mode to conserve
>>> battery life. you should be able to see what is going by running
>>> hcidump. in any case, it should be possible to add something that
>>> 'tickles' connection once in a short while to prevent it from going
>>> completely idle. it will drain the battery faster though.
>> It does not happens when connection is alive, only when connection
>> establishes. So may be there some kind of timeout can be tuned, or device
>> can be forcefully woken up in some other way?
>
> oh, i misunderstood then. are you saying that initial connection setup
> is slow? if so, then i'm guessing your qtek device is maybe missing
> initial paging attempts. either this or something else is going on.
> when you do inquiry what do
>
>  Page Scan Rep. Mode
>  Page Scan Period Mode
>  Page Scan Mode

         Page Scan Rep. Mode: 0x1
         Page Scan Period Mode: 00
         Page Scan Mode: 00

> say for your qtek device? you can try to increase page timeout, i.e.
> 'hccontrol write_page_timeout' if your qtek device is timing out
> during initial page attempt (default timeout is ~5sec).
>
> in any case hcidump that shows the problem would be a good start.

First run:

< HCI Command: Create Connection(0x01|0x0005) plen 13
 > HCI Event: Command Status(0x0f) plen 4
 > HCI Event: Connect Complete(0x03) plen 11

btpand[4215]: NAP: Host is down

Second run:

< HCI Command: Create Connection(0x01|0x0005) plen 13
 > HCI Event: Command Status(0x0f) plen 4
 > HCI Event: Connect Complete(0x03) plen 11
< HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4
< ACL data: handle 0x000b flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x00b0
 > HCI Event: Command Complete(0x0e) plen 6
 > HCI Event: Max Slots Change(0x1b) plen 3

btpand[4222]: Searching for NAP service at 00:12:d1:38:4a:fa
btpand[4222]: Found PSM 15 for service NAP
btpand[4222]: Opening connection to service 0x1116 at 00:12:d1:38:4a:fa
btpand[4222]: channel_open: (fd#4)
btpand[4222]: Using interface tap10 with addr 00:00:d9:fb:48:16
btpand[4222]: channel_open: (fd#5)

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Iain Hibbert]

On Tue, 3 Feb 2009, Maksim Yevmenkin wrote:

> i have plan to implement libhci (a-la linux bluez etc.) shim
> eventually :) if someone feels like beating me to it, i would
> certainly not object to it :)

what api would you envisage?

iain
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Iain Hibbert]

On Wed, 4 Feb 2009, Alexander Motin wrote:
[relating to -d device]
> Does actually this binding really necessary? rfcomm somehow works without it.

This binding is used (in original version) to set the tap interface
address to be the same as the bdaddr.  I did consider allowing to use it
without setting that but then ethernet packets are being transmitted with
a source address that is not the bdaddr. Now, IIRC it would seem that the
spec allows this, but my windows mobile device (for instance) fails to
route packets back to the computer.

there are a couple of ways around this I could see

1.  skip the bdaddr_any(local_bdaddr) check while validating the command
   line options, but add something to set it if it is unset. That would
   be the easiest option I guess but you need to be able to find the
   device with the best route to remote (could be first device, could be
   we already have a connection to remote device - I don't know what
   FreeBSD provides here?)

2. perform 'address rewriting' on ethernet packets. Actually this is not
   that difficult to do and I had it going during testing (when receiving
   packets, if the source address is the same as the remote bdaddr, or the
   ethernet tap address, set it to NULL. When sending, if the source is
   NULL, use the local bdaddr or ethernet tap address.)  This also allows
   a single btpand instance to straddle multiple controllers but I thought
   it might be better to keep it simple in the beginning.

the fact of it requiring the commandline argument at first I prefer -
because its always possible to relax a requirement but not to tighten one
up :)

iain
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Iain Hibbert]

On Wed, 4 Feb 2009, Alexander Motin wrote:

> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run
> btpand in foreground to track connection status.

what would you like to accomplish?

I made some effort for it to not detach until the setup is complete, but
it kind of needs to then in order for 'connection up' activities to
commence (eg proceeding to run dhclient)..  at least on my machine I have
logging turned up and do get some shutdown messages on the console when it
detaches.

I have not run it as a NAP or GN so I'm not sure if anything needs to
happen when connections come and go there but I thought maybe not as its
similar to plugging other computers in the other side of a switch.

iain
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

[...]

>> and what name would you like to use? ubt0? something else? dont forget
>> we dont create nodes under /dev for bluetooth devices. just netgraph
>> nodes. i have plan to implement libhci (a-la linux bluez etc.) shim
>> eventually :) if someone feels like beating me to it, i would
>> certainly not object to it :)
>
> Actually yes, ubt0. System reports it on boot, it is reported to the peered
> devices in hostname and NetBSD does so. IMHO it is not a bad choice from
> user's point of view.

ok, i will look into it. this will definitely be after hci shims.
enumerating all the radios in the system is the job for hci shim.
there is something already in hccontrol(8) to do that, but i do not
want to duplicate the code and rather move it into hci shim.

> Does actually this binding really necessary? rfcomm somehow works without
> it.

please see Iain's response :) i knew he would chime in :) thanks Iain!

and, yes, i suspected that it would be something related to mac
addresses on virtual ethernet interface. i do not have a copy of spec
handy, but i recall something about setting mac address to be the same
as radio's bd_addr. dont remember if it was a requirement or more of a
guideline.

in any case, i like Iain's suggestion to rewrite mac addresses on the
fly. i would have done it this way. also, i think, nap server should
just act as ethernet hub, i.e. forward everything everywhere. after
all, nap is supposed to be like local ethernet network :)

>> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is
>> only one bluetooth device connected to the system) 'hccontrol
>> read_bd_addr' will do the trick :)
>
> Indeed. But general number of BT tools, daemons and their options just
> making me sad.

i'm not sure how to read that :) there is, like, less than 10
bluetooth related daemons in total. each has, like, may be 10 options.
compare this to the number of options ls(1) has :) not sure what could
possibly make you sad here. if you feel that the documentation is not
adequate, please feel free to fix it :)

[....]

>>> It does not happens when connection is alive, only when connection
>>> establishes. So may be there some kind of timeout can be tuned, or device
>>> can be forcefully woken up in some other way?
>>
>> oh, i misunderstood then. are you saying that initial connection setup
>> is slow? if so, then i'm guessing your qtek device is maybe missing
>> initial paging attempts. either this or something else is going on.
>> when you do inquiry what do
>>
>>  Page Scan Rep. Mode
>>  Page Scan Period Mode
>>  Page Scan Mode
>
>        Page Scan Rep. Mode: 0x1
>        Page Scan Period Mode: 00
>        Page Scan Mode: 00

ah, so your device wants to use r1 page scan repetition mode.
off-the-shelf dongles usually use r2 mode. that is basically defines
how radio will scan for page/attempt to page. its basically
baseband/link manager (aka firmware on the device itself - not stack)

>> say for your qtek device? you can try to increase page timeout, i.e.
>> 'hccontrol write_page_timeout' if your qtek device is timing out
>> during initial page attempt (default timeout is ~5sec).
>>
>> in any case hcidump that shows the problem would be a good start.
>
> First run:
>
> < HCI Command: Create Connection(0x01|0x0005) plen 13
>> HCI Event: Command Status(0x0f) plen 4
>> HCI Event: Connect Complete(0x03) plen 11
>
> btpand[4215]: NAP: Host is down
>
> Second run:
>
> < HCI Command: Create Connection(0x01|0x0005) plen 13
>> HCI Event: Command Status(0x0f) plen 4
>> HCI Event: Connect Complete(0x03) plen 11
> < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4
> < ACL data: handle 0x000b flags 0x02 dlen 12
>    L2CAP(s): Connect req: psm 1 scid 0x00b0
>> HCI Event: Command Complete(0x0e) plen 6
>> HCI Event: Max Slots Change(0x1b) plen 3
>
> btpand[4222]: Searching for NAP service at 00:12:d1:38:4a:fa
> btpand[4222]: Found PSM 15 for service NAP
> btpand[4222]: Opening connection to service 0x1116 at 00:12:d1:38:4a:fa
> btpand[4222]: channel_open: (fd#4)
> btpand[4222]: Using interface tap10 with addr 00:00:d9:fb:48:16
> btpand[4222]: channel_open: (fd#5)

right, next time please either user '-x' or '-w' option to hcidump. in
this case, it does not matter, since, in failure case, clearly nothing
happens after connection_complete event, so we could not even
establish baseband connection (i can not see the error code on the
dump but i'm guessing its page timeout).

like i said, you could try to increase page timeout of your local
radio, or, you could try to find if your device has knobs that would
allow to set radio's scan window and scan interval.

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

On Wed, Feb 4, 2009 at 6:41 AM, Iain Hibbert <plunky@...> wrote:
> On Tue, 3 Feb 2009, Maksim Yevmenkin wrote:
>
>> i have plan to implement libhci (a-la linux bluez etc.) shim
>> eventually :) if someone feels like beating me to it, i would
>> certainly not object to it :)
>
> what api would you envisage?

i was thinking about doing most of the

http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=lib/hci.c;hb=1fa3750cb917358a6fb6bc718429c9000dd61ab3

starting from

int hci_inquiry(...)

and all the way down to the end of the file :) basically map dev_id to
unit numbers, i.e. dev_id 0 is "ubt0" node, etc.

i'm a bit concerned that if we follow linux too closely someone might
throw a hissy fit about bsd stealing linux's code and not using gpl :)
so we have to tread lightly here, imo :)

and, btw, i do not think i'm going to create a separate libhci for
this. existing libbluetooth is perfectly fine.

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Iain Hibbert wrote:
> On Wed, 4 Feb 2009, Alexander Motin wrote:
>
>> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run
>> btpand in foreground to track connection status.
>
> what would you like to accomplish?

For example, to initiate reconnect on connection failure. Sure it can be
done in many other ways, but running in foreground seems to be usual
practice for many places, like ppp.

> I made some effort for it to not detach until the setup is complete, but
> it kind of needs to then in order for 'connection up' activities to
> commence (eg proceeding to run dhclient)..  at least on my machine I have
> logging turned up and do get some shutdown messages on the console when it
> detaches.

I think dhclient, for example, could be run via devd when interface
comes up, alike to normal Ethernet. Not sure TAP supports devd not, but
I think it could be fixed.

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Iain Hibbert wrote:

> On Wed, 4 Feb 2009, Alexander Motin wrote:
> [relating to -d device]
>> Does actually this binding really necessary? rfcomm somehow works without it.
>
> This binding is used (in original version) to set the tap interface
> address to be the same as the bdaddr.  I did consider allowing to use it
> without setting that but then ethernet packets are being transmitted with
> a source address that is not the bdaddr. Now, IIRC it would seem that the
> spec allows this, but my windows mobile device (for instance) fails to
> route packets back to the computer.
>
> there are a couple of ways around this I could see
>
> 1.  skip the bdaddr_any(local_bdaddr) check while validating the command
>    line options, but add something to set it if it is unset. That would
>    be the easiest option I guess but you need to be able to find the
>    device with the best route to remote (could be first device, could be
>    we already have a connection to remote device - I don't know what
>    FreeBSD provides here?)

Have no idea how routing expected to work in case of several BT
adapters, this it is interesting, but I think quite rare case. I think
it could be good to be implemented alike to usual inet connectivity,
when unbinded accepting connection sets remotely requested IP as it's
local, and outgoing connecting socket choose local IP using routing
table. I am not sure if terms or routing applicable here, but at least
we have some mesh of peered devices and if there is several peered, we
could choose one of using some algorithm, depending on load or order, or
just round-robin.

> 2. perform 'address rewriting' on ethernet packets. Actually this is not
>    that difficult to do and I had it going during testing (when receiving
>    packets, if the source address is the same as the remote bdaddr, or the
>    ethernet tap address, set it to NULL. When sending, if the source is
>    NULL, use the local bdaddr or ethernet tap address.)  This also allows
>    a single btpand instance to straddle multiple controllers but I thought
>    it might be better to keep it simple in the beginning.

I don't very like idea of rewriting. It looks like a hack and may
confuse somebody. Also if it works as plain Ethernet, then you will
probably have to rewrite ARP for IPv4 and it's equivalent for IPv6, and
something other for other protocols. It could become a permanent pain.

> the fact of it requiring the commandline argument at first I prefer -
> because its always possible to relax a requirement but not to tighten one
> up :)

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Maksim Yevmenkin wrote:

>> Does actually this binding really necessary? rfcomm somehow works without
>> it.
>
> please see Iain's response :) i knew he would chime in :) thanks Iain!
>
> and, yes, i suspected that it would be something related to mac
> addresses on virtual ethernet interface. i do not have a copy of spec
> handy, but i recall something about setting mac address to be the same
> as radio's bd_addr. dont remember if it was a requirement or more of a
> guideline.
>
> in any case, i like Iain's suggestion to rewrite mac addresses on the
> fly. i would have done it this way. also, i think, nap server should
> just act as ethernet hub, i.e. forward everything everywhere. after
> all, nap is supposed to be like local ethernet network :)

Hmm. Working like an Ethernet hub also means that every single hub port
(in our case every single point-to-point BT link) may transmit packets
from different source MAC addresses, that can't be equal to BT adapter
address. So or I don't understand your example, or something is wrong here.

>>> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is
>>> only one bluetooth device connected to the system) 'hccontrol
>>> read_bd_addr' will do the trick :)
>> Indeed. But general number of BT tools, daemons and their options just
>> making me sad.
>
> i'm not sure how to read that :) there is, like, less than 10
> bluetooth related daemons in total. each has, like, may be 10 options.
> compare this to the number of options ls(1) has :) not sure what could
> possibly make you sad here. if you feel that the documentation is not
> adequate, please feel free to fix it :)

10 daemons is understood, as BT is not that simple and IP stack also
have many different tools. But anyway having about 70 defined and
undocumented arguments of hccontrol alone, one of which should be used
for such basic thing as getting local btaddr, are not looking so funny
for anybody who are not BT guru. May be writing of some man page with
some BT basics to cross reference that basic tools could help. Or just
better cross reference existing pages.

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Iain Hibbert]

On Wed, 4 Feb 2009, Alexander Motin wrote:

> Iain Hibbert wrote:
> > On Wed, 4 Feb 2009, Alexander Motin wrote:
> >
> > > One more minor fact. Unlike rfcomm_pppd I haven't found an option to run
> > > btpand in foreground to track connection status.
> >
> > what would you like to accomplish?
>
> For example, to initiate reconnect on connection failure. Sure it can be done
> in many other ways, but running in foreground seems to be usual practice for
> many places, like ppp.
>
> > I made some effort for it to not detach until the setup is complete, but
> > it kind of needs to then in order for 'connection up' activities to
> > commence (eg proceeding to run dhclient)..  at least on my machine I have
> > logging turned up and do get some shutdown messages on the console when it
> > detaches.
>
> I think dhclient, for example, could be run via devd when interface comes up,
> alike to normal Ethernet. Not sure TAP supports devd not, but I think it could
> be fixed.

One thing that I have in mind is to make btpand shutdown the tap interface
when exiting (as it marks it up when starting). Would that make it
possible to use devd to trigger a reconnect if desired?  I think its
better to have a "event->action" model rather than hang it all together
with scripts.

iain
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Iain Hibbert wrote:

> On Wed, 4 Feb 2009, Alexander Motin wrote:
>
>> Iain Hibbert wrote:
>>> On Wed, 4 Feb 2009, Alexander Motin wrote:
>>>
>>>> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run
>>>> btpand in foreground to track connection status.
>>> what would you like to accomplish?
>> For example, to initiate reconnect on connection failure. Sure it can be done
>> in many other ways, but running in foreground seems to be usual practice for
>> many places, like ppp.
>>
>>> I made some effort for it to not detach until the setup is complete, but
>>> it kind of needs to then in order for 'connection up' activities to
>>> commence (eg proceeding to run dhclient)..  at least on my machine I have
>>> logging turned up and do get some shutdown messages on the console when it
>>> detaches.
>> I think dhclient, for example, could be run via devd when interface comes up,
>> alike to normal Ethernet. Not sure TAP supports devd not, but I think it could
>> be fixed.
>
> One thing that I have in mind is to make btpand shutdown the tap interface
> when exiting (as it marks it up when starting). Would that make it
> possible to use devd to trigger a reconnect if desired?  I think its
> better to have a "event->action" model rather than hang it all together
> with scripts.

It already removes UP status from interface, so there is action which
could be tracked by devd. No need to destroy interface if it was not
created by you. But from other side devd is more complicated and
system-wide case that some trivial custom shell script, so I would
prefer to use it just for something common, like running dhclient with
adding something like ifconfig_tap1="DHCP" to rc.conf alike to normal
Ethernets.

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin <mav@...> wrote:

> Maksim Yevmenkin wrote:
>>>
>>> Does actually this binding really necessary? rfcomm somehow works without
>>> it.
>>
>> please see Iain's response :) i knew he would chime in :) thanks Iain!
>>
>> and, yes, i suspected that it would be something related to mac
>> addresses on virtual ethernet interface. i do not have a copy of spec
>> handy, but i recall something about setting mac address to be the same
>> as radio's bd_addr. dont remember if it was a requirement or more of a
>> guideline.
>>
>> in any case, i like Iain's suggestion to rewrite mac addresses on the
>> fly. i would have done it this way. also, i think, nap server should
>> just act as ethernet hub, i.e. forward everything everywhere. after
>> all, nap is supposed to be like local ethernet network :)
>
> Hmm. Working like an Ethernet hub also means that every single hub port (in
> our case every single point-to-point BT link) may transmit packets from
> different source MAC addresses, that can't be equal to BT adapter address.
> So or I don't understand your example, or something is wrong here.

why do you think it is wrong? logically all the radios are on the same
virtual ethernet network. i think the only issue here is that
apparently some clients are picky about src mac address and that
complicates the case when nap server has multiple radios.

[...]

>>> Indeed. But general number of BT tools, daemons and their options just
>>> making me sad.
>>
>> i'm not sure how to read that :) there is, like, less than 10
>> bluetooth related daemons in total. each has, like, may be 10 options.
>> compare this to the number of options ls(1) has :) not sure what could
>> possibly make you sad here. if you feel that the documentation is not
>> adequate, please feel free to fix it :)
>
> 10 daemons is understood, as BT is not that simple and IP stack also have
> many different tools. But anyway having about 70 defined and undocumented
> arguments of hccontrol alone, one of which should be used for such basic
> thing as getting local btaddr, are not looking so funny for anybody who are
> not BT guru. May be writing of some man page with some BT basics to cross
> reference that basic tools could help. Or just better cross reference
> existing pages.

oh, please :) man hccontrol(8) gives you all the commands. it also
tells you to use 'help <command>' to get more information. also help
for each command is taken directly from the bluetooth specification.
i'm not sure how much more documentation can we put here. there are
also man pages for ng_hci(4) and ng_l2cap(4).  that is already so much
more information than you can ever get on vast majority of bluetooth
enabled gadgets. oh, and btw, users are not even supposed to
know/touch any of this stuff. so if your bluetooth gadget does not
work - you sh*t out of luck for the most of the time :)

in ideal world, everything should just work. in real world, like
everything that has to do with rf, sometimes it doesn't :)

i agree, documentation could always be better, and i repeatedly asked
for help here. i do not know why, but for whatever reason people
prefer to put stuff on their private webpages/blogs/forums/etc.
instead of just saying "hey, i had this problem and here is how i
fixed it. wouldn't it be nice if you could document this in man
page/handbook. btw, here is the patch."

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Alexander Motin]

Maksim Yevmenkin wrote:

> On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin <mav@...> wrote:
>> Maksim Yevmenkin wrote:
>>>> Does actually this binding really necessary? rfcomm somehow works without
>>>> it.
>>> please see Iain's response :) i knew he would chime in :) thanks Iain!
>>>
>>> and, yes, i suspected that it would be something related to mac
>>> addresses on virtual ethernet interface. i do not have a copy of spec
>>> handy, but i recall something about setting mac address to be the same
>>> as radio's bd_addr. dont remember if it was a requirement or more of a
>>> guideline.
>>>
>>> in any case, i like Iain's suggestion to rewrite mac addresses on the
>>> fly. i would have done it this way. also, i think, nap server should
>>> just act as ethernet hub, i.e. forward everything everywhere. after
>>> all, nap is supposed to be like local ethernet network :)
>> Hmm. Working like an Ethernet hub also means that every single hub port (in
>> our case every single point-to-point BT link) may transmit packets from
>> different source MAC addresses, that can't be equal to BT adapter address.
>> So or I don't understand your example, or something is wrong here.
>
> why do you think it is wrong? logically all the radios are on the same
> virtual ethernet network. i think the only issue here is that
> apparently some clients are picky about src mac address and that
> complicates the case when nap server has multiple radios.

You have told that NAP server works as hub. So, as I have understood, it
retransmits upstream traffic back down to all/some clients. So, it
transmits packets with MAC addresses of other clients via it's BT
adapter. So, source MAC address will not match his BDADDR. Or server is
an exception, which can violate the rule of equal addresses?

--
Alexander Motin
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Iain Hibbert]

On Wed, 4 Feb 2009, Alexander Motin wrote:

> Iain Hibbert wrote:
> > One thing that I have in mind is to make btpand shutdown the tap interface
> > when exiting (as it marks it up when starting). Would that make it
> > possible to use devd to trigger a reconnect if desired?  I think its
> > better to have a "event->action" model rather than hang it all together
> > with scripts.
>
> It already removes UP status from interface, so there is action which could be
> tracked by devd.

Ah, I see. That is a difference in FreeBSD tap(4) device and I wondered
about that but will put it on my list to see if its desireable for NetBSD,
rather than modifying btpand to do the same.

> No need to destroy interface if it was not created by you.

no, thats all automatic

> But from other side devd is more complicated and system-wide case that some
> trivial custom shell script, so I would prefer to use it just for something
> common, like running dhclient with adding something like ifconfig_tap1="DHCP"
> to rc.conf alike to normal Ethernets.

There may be trouble there because network is started before bluetooth,
but adding a 'stay in foreground' switch should not be difficult.

iain
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

On Wed, Feb 4, 2009 at 12:13 PM, Alexander Motin <mav@...> wrote:

> Maksim Yevmenkin wrote:
>>
>> On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin <mav@...>
>> wrote:
>>>
>>> Maksim Yevmenkin wrote:
>>>>>
>>>>> Does actually this binding really necessary? rfcomm somehow works
>>>>> without
>>>>> it.
>>>>
>>>> please see Iain's response :) i knew he would chime in :) thanks Iain!
>>>>
>>>> and, yes, i suspected that it would be something related to mac
>>>> addresses on virtual ethernet interface. i do not have a copy of spec
>>>> handy, but i recall something about setting mac address to be the same
>>>> as radio's bd_addr. dont remember if it was a requirement or more of a
>>>> guideline.
>>>>
>>>> in any case, i like Iain's suggestion to rewrite mac addresses on the
>>>> fly. i would have done it this way. also, i think, nap server should
>>>> just act as ethernet hub, i.e. forward everything everywhere. after
>>>> all, nap is supposed to be like local ethernet network :)
>>>
>>> Hmm. Working like an Ethernet hub also means that every single hub port
>>> (in
>>> our case every single point-to-point BT link) may transmit packets from
>>> different source MAC addresses, that can't be equal to BT adapter
>>> address.
>>> So or I don't understand your example, or something is wrong here.
>>
>> why do you think it is wrong? logically all the radios are on the same
>> virtual ethernet network. i think the only issue here is that
>> apparently some clients are picky about src mac address and that
>> complicates the case when nap server has multiple radios.
>
> You have told that NAP server works as hub. So, as I have understood, it
> retransmits upstream traffic back down to all/some clients. So, it transmits
> packets with MAC addresses of other clients via it's BT adapter. So, source
> MAC address will not match his BDADDR. Or server is an exception, which can
> violate the rule of equal addresses?

well, i think we have a disconnect here ;) you see, bnep strips
ethernet header completely and replaces it with one of the bnep
ethernet headers. your options basically are

1) bnep ethernet header that has both src and dst "mac addresses"
(that is both src and dst radio bd_addr's)

2) bnep ethernet header that has only src "mac address" (that is src
radio bd_addr only)

3) bnep ethernet header that has only dst "mac address" (that is dst
radio bd_addr only)

(2) and (3) are basically short forms of (1) and used when it is
possible to figure out missing dst or src "mac address" (that is
bd_addr really) because there is a directly "attached" rf link.

in other words, if i know that you are the final recipient of the
packet and i have a direct rf link to you, i'm not going to bother to
set dst "mac address" in bnep packet, because you obviously know your
"mac address" (bd_addr).

or

if i generate a packet and i have a direct rf link to you, i'm not
going to set src "mac address" (that is bd_addr really) because you
know that this packet can only come from me and you already know my
"mac address" (bd_addr)

so, imo, there is nothing really prevents us from using multiple local
radios. also mac address on tap interface is really does not matter,
because its get stripped anyway. that is unless tap interface checks
dst mac address and make sure it matches (like freebsd does) before
passing packet up the stack. if any case, setting promisc. flag on
interface will fix it. the only mess here is that arp responses for
local tap interface will contain mac address of tap interface and not
bd_addr of (one of the) local radio(s). i say, who cares, as long as
its properly encapsulated into bnep, imo, it should work. so even if
both endpoints have a direct rf link, it will look like they are not.

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."