From maksim.yevmenkin at gmail.com Wed Apr 2 10:17:28 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Apr 2 10:17:34 2008 Subject: Logitech V470 Bluetooth Mouse on FreeBSD ? In-Reply-To: <1207142908.576787.1033.nullmailer@galant.ukfsn.org> References: <47ED9AC5.4050505@users.sf.net> <47EF668D.1080003@users.sf.net> <1206904241.480342.891.nullmailer@galant.ukfsn.org> <47F13BAD.9060808@users.sf.net> <1207142908.576787.1033.nullmailer@galant.ukfsn.org> Message-ID: On 4/2/08, Iain Hibbert wrote: > On Mon, 31 Mar 2008, mato wrote: > > > Well, this mouse of mine presents itself exactly as you said ... > > > > Input id=2 size=12 count=1 page=Generic_Desktop usage=X Variable Relative, > > Input id=2 size=12 count=1 page=Generic_Desktop usage=Y Variable Relative, > > wow thats a sensitive mouse, 12 bit movements! :) amazing what you can get these days, huh? :) > > Input id=2 size=8 count=1 page=Generic_Desktop usage=Wheel Variable > > Input id=2 size=8 count=1 page=Consumer usage=AC_Pan Variable Relative, > > What can be done about it ?? > > I don't know - bthidd(4) could grow the support for AC_Pan fairly easily > but I don't know how you would get that into the kernel - the mouse_info > structure has no W direction and the ioctl would need to be versioned if > the structure was extended as there was no padding.. exactly Iain. parsing hid messages in bthidd(8) and extracting all the data is trivial. the question is how to feed those data into the kernel. right now, bthidd(8) uses console ioctl to feed data into the kernel. as you pointed out, mouse_info structure (specifically mouse_data union) does not have have w direction. > btw just to make you feel better I should say that sideways scroll does > not always work in applications; eg GThumb considers the extra buttons > to be 'next' and 'prev' instead and sideways scroll just jumps to the next > picture. i have a wired usb apple mighty mouse here and horizontal scrolling does not work for me at all. quick look at ums(4) showed that it does not export w data (it tries to locate both wheel and z axis, however it does not look for ac_pan axis). so, it appears that we need to teach moused(8), sysmouse(4) and mice drivers about second wheel. it appears to be a somewhat bigger chunk of work. thanks, max > > > iain > From plunky at rya-online.net Thu Apr 3 12:11:57 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Thu Apr 3 12:12:07 2008 Subject: Logitech V470 Bluetooth Mouse on FreeBSD ? In-Reply-To: <47F13BAD.9060808@users.sf.net> References: <47ED9AC5.4050505@users.sf.net> <47EF668D.1080003@users.sf.net> <1206904241.480342.891.nullmailer@galant.ukfsn.org> <47F13BAD.9060808@users.sf.net> Message-ID: <1207142908.576787.1033.nullmailer@galant.ukfsn.org> On Mon, 31 Mar 2008, mato wrote: > Well, this mouse of mine presents itself exactly as you said ... > > Input id=2 size=12 count=1 page=Generic_Desktop usage=X Variable Relative, > Input id=2 size=12 count=1 page=Generic_Desktop usage=Y Variable Relative, wow thats a sensitive mouse, 12 bit movements! :) > Input id=2 size=8 count=1 page=Generic_Desktop usage=Wheel Variable > Input id=2 size=8 count=1 page=Consumer usage=AC_Pan Variable Relative, > > What can be done about it ?? I don't know - bthidd(4) could grow the support for AC_Pan fairly easily but I don't know how you would get that into the kernel - the mouse_info structure has no W direction and the ioctl would need to be versioned if the structure was extended as there was no padding.. btw just to make you feel better I should say that sideways scroll does not always work in applications; eg GThumb considers the extra buttons to be 'next' and 'prev' instead and sideways scroll just jumps to the next picture. iain From plunky at rya-online.net Thu Apr 3 12:11:58 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Thu Apr 3 12:12:07 2008 Subject: BT issues In-Reply-To: <47F13FEB.10503@users.sf.net> References: <47DBE7A4.3060006@users.sf.net> <47EF6AA5.60403@users.sf.net> <47F13FEB.10503@users.sf.net> Message-ID: <1207143124.467349.1017.nullmailer@galant.ukfsn.org> On Mon, 31 Mar 2008, mato wrote: > However, Windows can manage this as it asks for PIN key when connection > initiation fails. While I don't expect FreeBSD asking for a PIN, it might be > quite useful if it could automatically (upon a connection establishing > failure) throw away its stored link key and recreate it from PIN as Windows > does. btw That would be the wrong thing to do. The stored link key is the 'password' for the remote BDADDR to connect to your services and it is possible on many devices to change the bluetooth device address (BDADDR) You don't want to make it so that a remote attacker can just cause a 'password' reset by pretending to be an authorised device, and this is the reason PINs should not be permanently stored.. iain From markhobden at gmail.com Thu Apr 3 17:02:04 2008 From: markhobden at gmail.com (Mark Hobden) Date: Thu Apr 3 17:02:12 2008 Subject: Logitech V470 Bluetooth Mouse on FreeBSD ? In-Reply-To: References: <47ED9AC5.4050505@users.sf.net> <47EF668D.1080003@users.sf.net> <1206904241.480342.891.nullmailer@galant.ukfsn.org> <47F13BAD.9060808@users.sf.net> <1207142908.576787.1033.nullmailer@galant.ukfsn.org> Message-ID: On 02/04/2008, Maksim Yevmenkin wrote: > > I don't know - bthidd(4) could grow the support for AC_Pan fairly easily > > but I don't know how you would get that into the kernel - the mouse_info > > structure has no W direction and the ioctl would need to be versioned if > > the structure was extended as there was no padding.. > > exactly Iain. parsing hid messages in bthidd(8) and extracting all the > data is trivial. the question is how to feed those data into the > kernel. right now, bthidd(8) uses console ioctl to feed data into the > kernel. as you pointed out, mouse_info structure (specifically > mouse_data union) does not have have w direction. > > > btw just to make you feel better I should say that sideways scroll does > > not always work in applications; eg GThumb considers the extra buttons > > to be 'next' and 'prev' instead and sideways scroll just jumps to the next > > picture. > > i have a wired usb apple mighty mouse here and horizontal scrolling > does not work for me at all. quick look at ums(4) showed that it does > not export w data (it tries to locate both wheel and z axis, however > it does not look for ac_pan axis). > > so, it appears that we need to teach moused(8), sysmouse(4) and mice > drivers about second wheel. it appears to be a somewhat bigger chunk > of work. > > thanks, > max Hi Martin, I have a patch somewhere at home that manages to do all of the above. I had planned to re-wite part of it to not require increasing the size of an xorg structure I changed - but it doesn't look like I will have time to do that for a while. At present it applies on top of the uhidev patches but it probably wouldn't be too difficult to get it to apply without them. I have been using it for a little while now and its been working fine for me. I will try and clean it up and document what needs to be re-compiled to get it working and then post it sometime in the next few days. Kind Regards, Mark Hobden. From gamato at users.sf.net Fri Apr 4 19:03:52 2008 From: gamato at users.sf.net (mato) Date: Fri Apr 4 19:03:58 2008 Subject: BT issues In-Reply-To: References: <47DBE7A4.3060006@users.sf.net> Message-ID: <47F67B95.4060402@users.sf.net> Maksim Yevmenkin wrote: > 2) please cut and paste the following rc script into > /etc/rc.d/rfcomm_pppd_server > > == > > #!/bin/sh > # > # $FreeBSD$ > # > > # PROVIDE: rfcomm_pppd_server > # REQUIRE: DAEMON sdpd > # BEFORE: LOGIN > # KEYWORD: nojail > > . /etc/rc.subr > > name="rfcomm_pppd_server" > rcvar=`set_rcvar` > command="/usr/sbin/rfcomm_pppd" > command_args="-s" > start_precmd="rfcomm_pppd_server_prestart" > required_modules="ng_btsocket" > > rfcomm_pppd_server_prestart() > { > if [ -n "${rfcomm_pppd_server_bd_addr}" ]; then > command_args="${command_args} -a ${rfcomm_pppd_server_bd_addr}" > fi > > command_args="${command_args} -C ${rfcomm_pppd_server_channel:-1}" > > command_args="${command_args} -l > ${rfcomm_pppd_server_label:-rfcomm-server}" > > if checkyesno rfcomm_pppd_server_register_sp ; then > command_args="${command_args} -S" > fi > > if checkyesno rfcomm_pppd_server_register_dun ; then > command_args="${command_args} -D" > fi > } > > load_rc_config $name > run_rc_command "$1" > > == > > 3) to enable rfcomm_pppd server at boot time just add to your > /etc/rc.conf the following line > > rfcomm_pppd_server_enanble="YES" > rfcomm_pppd_server_channel=1 # EDIT THIS IF NEEDED > rfcomm_pppd_server_label="rfcomm-server" # EDIT THIS IF NEEDED > rfcomm_pppd_server_register_sp="NO" > rfcomm_pppd_server_register_dun="NO" > > this should start rfcomm_pppd server on boot automatically. to > start/stop rfcomm_pppd server at run time use > > /etc/rc.d/rfcomm_pppd start/stop > > Hi Max, Thanks for the script but I would need it expanded a bit. The thing is that because I connect both FreeBSD and Windows as clients I had to create 2 slightly different ppp.conf labels (it didn't work for me with one label only). Therefore I created 2 simple scripts, each starting rfcomm_pppd with different label on different channel. Then I run them manually or automatically from cron at startup. Do you think it would be possible to cover situations like mine within your script ? Something like specifying for instance rfcomm_pppd_server_channel="1,2" .. ? Cheers, Martin From gamato at users.sf.net Fri Apr 4 19:11:29 2008 From: gamato at users.sf.net (mato) Date: Fri Apr 4 19:11:35 2008 Subject: Logitech V470 Bluetooth Mouse on FreeBSD ? In-Reply-To: <1207142908.576787.1033.nullmailer@galant.ukfsn.org> References: <47ED9AC5.4050505@users.sf.net> <47EF668D.1080003@users.sf.net> <1206904241.480342.891.nullmailer@galant.ukfsn.org> <47F13BAD.9060808@users.sf.net> <1207142908.576787.1033.nullmailer@galant.ukfsn.org> Message-ID: <47F67D5F.7030103@users.sf.net> Iain Hibbert wrote: > On Mon, 31 Mar 2008, mato wrote: > > >> Well, this mouse of mine presents itself exactly as you said ... >> >> Input id=2 size=12 count=1 page=Generic_Desktop usage=X Variable Relative, >> Input id=2 size=12 count=1 page=Generic_Desktop usage=Y Variable Relative, >> > > wow thats a sensitive mouse, 12 bit movements! :) > > Well, I don't know how much is it -- 12 bits across what ? 1 inch ? Anyway, I must say that mouse is quite sensitive and I'd like to adjust it a bit as it's sometimes difficult to control. However, I've no idea how to achieve this. Any suggestions please ? >> Input id=2 size=8 count=1 page=Generic_Desktop usage=Wheel Variable >> Input id=2 size=8 count=1 page=Consumer usage=AC_Pan Variable Relative, >> >> What can be done about it ?? >> > > I don't know - bthidd(4) could grow the support for AC_Pan fairly easily > but I don't know how you would get that into the kernel - the mouse_info > structure has no W direction and the ioctl would need to be versioned if > the structure was extended as there was no padding.. > > btw just to make you feel better I should say that sideways scroll does > not always work in applications; eg GThumb considers the extra buttons > to be 'next' and 'prev' instead and sideways scroll just jumps to the next > picture. > > iain > Well, I would expect "better" applications would allow to configure those extra buttons. Anyway, it's a bit shame having these cool buttons with no way to use them. :-( Regards, Martin From gamato at users.sf.net Fri Apr 4 19:20:57 2008 From: gamato at users.sf.net (mato) Date: Fri Apr 4 19:21:01 2008 Subject: BT issues In-Reply-To: <1207143124.467349.1017.nullmailer@galant.ukfsn.org> References: <47DBE7A4.3060006@users.sf.net> <47EF6AA5.60403@users.sf.net> <47F13FEB.10503@users.sf.net> <1207143124.467349.1017.nullmailer@galant.ukfsn.org> Message-ID: <47F67F97.9040908@users.sf.net> Iain Hibbert wrote: > On Mon, 31 Mar 2008, mato wrote: > > >> However, Windows can manage this as it asks for PIN key when connection >> initiation fails. While I don't expect FreeBSD asking for a PIN, it might be >> quite useful if it could automatically (upon a connection establishing >> failure) throw away its stored link key and recreate it from PIN as Windows >> does. >> > > btw That would be the wrong thing to do. The stored link key is the > 'password' for the remote BDADDR to connect to your services and it is > possible on many devices to change the bluetooth device address (BDADDR) > > You don't want to make it so that a remote attacker can just cause a > 'password' reset by pretending to be an authorised device, and this is the > reason PINs should not be permanently stored.. > > iain > Well, I haven't thought of this and you've got a point. On the other hand, stored link key doesn't have to be reset. I can imagine that if the link key didn't work FreeBSD could fall back to PIN as it does in the beginning and only if PINs matched new link key would be stored. Thus attacker would need to know the PIN which is normally not likely. Also, PIN can and should be longer and even composed of alphanumerals. Well, at least this is what Windows do AFAIK -- when link key was changed they pop up dialogue asking for (new) PIN. The only problem I see now is with devices with predefined or, worse, set-in-stone PINs. :-/ Regards, Martin From gamato at users.sf.net Fri Apr 4 20:10:58 2008 From: gamato at users.sf.net (mato) Date: Fri Apr 4 20:11:05 2008 Subject: Logitech V470 Bluetooth Mouse on FreeBSD ? In-Reply-To: References: <47ED9AC5.4050505@users.sf.net> <47EF668D.1080003@users.sf.net> <1206904241.480342.891.nullmailer@galant.ukfsn.org> <47F13BAD.9060808@users.sf.net> <1207142908.576787.1033.nullmailer@galant.ukfsn.org> Message-ID: <47F68B4F.4080706@users.sf.net> Maksim Yevmenkin wrote: > On 4/2/08, Iain Hibbert wrote: > >> On Mon, 31 Mar 2008, mato wrote: >> >>> Input id=2 size=8 count=1 page=Generic_Desktop usage=Wheel Variable >>> Input id=2 size=8 count=1 page=Consumer usage=AC_Pan Variable Relative, >>> What can be done about it ?? >>> >> I don't know - bthidd(4) could grow the support for AC_Pan fairly easily >> but I don't know how you would get that into the kernel - the mouse_info >> structure has no W direction and the ioctl would need to be versioned if >> the structure was extended as there was no padding.. >> > > exactly Iain. parsing hid messages in bthidd(8) and extracting all the > data is trivial. the question is how to feed those data into the > kernel. right now, bthidd(8) uses console ioctl to feed data into the > kernel. as you pointed out, mouse_info structure (specifically > mouse_data union) does not have have w direction. > > >> btw just to make you feel better I should say that sideways scroll does >> not always work in applications; eg GThumb considers the extra buttons >> to be 'next' and 'prev' instead and sideways scroll just jumps to the next >> picture. >> > > i have a wired usb apple mighty mouse here and horizontal scrolling > does not work for me at all. quick look at ums(4) showed that it does > not export w data (it tries to locate both wheel and z axis, however > it does not look for ac_pan axis). > > so, it appears that we need to teach moused(8), sysmouse(4) and mice > drivers about second wheel. it appears to be a somewhat bigger chunk > of work. > > The current situation seems to me not ideal and rather complicated. You said bthidd injects messages directly to kernel. I don't know what the consequences are but I noticed the following ... When I run moused my BT mouse works in console (except double clicks etc.). Unfortunately, because I wanted extra functionality from my Synaptics touchpad I installed x11-drivers/synaptics port which required disabling moused which handled the touchpad as ps/2 mouse. Now synaptics works great in X11 but it doesn't work in console at all and my BT mouse doesn't work in console either. But if I plug in a USB mouse devd runs moused and suddenly my BT mouse works in console too. Funny but very inconvenient, I can tell you. Fortunately I don't work in console that much anymore. With regards, Martin From maksim.yevmenkin at gmail.com Mon Apr 7 17:05:46 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon Apr 7 17:05:52 2008 Subject: Logitech V470 Bluetooth Mouse on FreeBSD ? In-Reply-To: <47F68B4F.4080706@users.sf.net> References: <47ED9AC5.4050505@users.sf.net> <47EF668D.1080003@users.sf.net> <1206904241.480342.891.nullmailer@galant.ukfsn.org> <47F13BAD.9060808@users.sf.net> <1207142908.576787.1033.nullmailer@galant.ukfsn.org> <47F68B4F.4080706@users.sf.net> Message-ID: [...] > > i have a wired usb apple mighty mouse here and horizontal scrolling > > does not work for me at all. quick look at ums(4) showed that it does > > not export w data (it tries to locate both wheel and z axis, however > > it does not look for ac_pan axis). > > > > so, it appears that we need to teach moused(8), sysmouse(4) and mice > > drivers about second wheel. it appears to be a somewhat bigger chunk > > of work. > > The current situation seems to me not ideal and rather complicated. You > said bthidd injects messages directly to kernel. I don't know what the > consequences are but I noticed the following ... When I run moused my BT > mouse works in console (except double clicks etc.). Unfortunately, because > I wanted extra functionality from my Synaptics touchpad I installed > x11-drivers/synaptics port which required disabling moused which handled the > touchpad as ps/2 mouse. Now synaptics works great in X11 but it doesn't > work in console at all and my BT mouse doesn't work in console either. But > if I plug in a USB mouse devd runs moused and suddenly my BT mouse works in > console too. Funny but very inconvenient, I can tell you. Fortunately I > don't work in console that much anymore. freebsd offers something called sysmouse(4). it allows the console and the user process (such as xorg) to share the mouse. if you use sysmouse(4) in xorg - the mouse will be shared between both console and xorg. if you use specific mouse driver (such as ums(4)) you will need to put /dev/ums0 in your xorg.conf and use appropriate xorg mouse driver. in the later case, the mouse will not be shared and will not work in the console. bthidd(8) uses console ioctl's to feed bluetooth mouse events into the kernel (i.e. feed events to sysmouse(4)). this way we automatically share bluetooth mouse between console and xorg. however, because sysmouse(4) protocol lacks knowledge about all the fancy buttons and wheels we can not pass this data to xorg. basically we are limited to whatever sysmouse(4) protocol knows about. currently, it is not possible to use bluetooth mouse directly from xorg/whatever, because there is no device node for it. in other words, there is no /dev/btmsX device node that feeds data in some protocol to consumers. i guess, it would be possible to write virtual mouse vms(4) driver (similar to virtual keyboard driver vkbd(4)) that would simply be used to pass through mouse data in, say, microsoft protocol or something like that. however, i think it would be better to add another level of operation to sysmouse(4) and change protocol so it can accommodate future extensions. thanks, max > > With regards, > > Martin > From maksim.yevmenkin at gmail.com Tue Apr 8 20:52:18 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Apr 8 20:52:23 2008 Subject: BT issues In-Reply-To: <47F67B95.4060402@users.sf.net> References: <47DBE7A4.3060006@users.sf.net> <47F67B95.4060402@users.sf.net> Message-ID: On 4/4/08, mato wrote: > Maksim Yevmenkin wrote: > > Hi Max, > > Thanks for the script but I would need it expanded a bit. The thing is > that because I connect both FreeBSD and Windows as clients I had to create 2 > slightly different ppp.conf labels (it didn't work for me with one label > only). Therefore I created 2 simple scripts, each starting rfcomm_pppd with > different label on different channel. Then I run them manually or > automatically from cron at startup. > Do you think it would be possible to cover situations like mine within your > script ? Something like specifying for instance > rfcomm_pppd_server_channel="1,2" .. ? why do you need 2 different labels? having multiple instances of a rfcomm_pppd started would be possible, however i will need some time to think about it. thanks, max From jonmoldenhauer at gmail.com Thu Apr 10 17:35:31 2008 From: jonmoldenhauer at gmail.com (Jonathon Moldenhauer) Date: Thu Apr 10 17:35:35 2008 Subject: headset support Message-ID: <92abd3ae0804101010m1535c06bm89ba9002a662f26@mail.gmail.com> Hi, I have searched back through the archives here and there is discussion about FreeBSD and headset/handsfree profile support. I have seen several comments that "the code is about the be committed" so I am wondering what the status really is. If any help is needed I would be willing to test and/or work on code so that this feature can be brought to the FreeBSD platform. Thanks, Jon Moldenhauer From maksim.yevmenkin at gmail.com Thu Apr 10 17:49:11 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Apr 10 17:49:19 2008 Subject: headset support In-Reply-To: <92abd3ae0804101010m1535c06bm89ba9002a662f26@mail.gmail.com> References: <92abd3ae0804101010m1535c06bm89ba9002a662f26@mail.gmail.com> Message-ID: Jon, > I have searched back through the archives here and there is discussion about > FreeBSD and headset/handsfree profile support. I have seen several comments > that "the code is about the be committed" so I am wondering what the status > really is. If any help is needed I would be willing to test and/or work on > code so that this feature can be brought to the FreeBSD platform. first of all what exactly do you need to support? do you have any specific usage scenario in mind? i have had code to support isoc transfers in ng_ubt(4) (a must to support bluetooth audio) and bluetooth sco sockets for quite a while. i was planning to commit it, but then i changed my mind. with the code i have, i can transfer raw audio data, but what to do with the raw data is the next big question. do we need to somehow plug into sound subsystem? something else? thanks, max From jonmoldenhauer at gmail.com Thu Apr 10 18:17:51 2008 From: jonmoldenhauer at gmail.com (Jonathon Moldenhauer) Date: Thu Apr 10 18:17:53 2008 Subject: headset support In-Reply-To: References: <92abd3ae0804101010m1535c06bm89ba9002a662f26@mail.gmail.com> Message-ID: <92abd3ae0804101117r3f98ec37r67dcdc0398346cdc@mail.gmail.com> On Thu, Apr 10, 2008 at 10:49 AM, Maksim Yevmenkin wrote: > Jon, > > > I have searched back through the archives here and there is discussion about > > FreeBSD and headset/handsfree profile support. I have seen several comments > > that "the code is about the be committed" so I am wondering what the status > > really is. If any help is needed I would be willing to test and/or work on > > code so that this feature can be brought to the FreeBSD platform. > > first of all what exactly do you need to support? do you have any > specific usage scenario in mind? i have had code to support isoc > transfers in ng_ubt(4) (a must to support bluetooth audio) and > bluetooth sco sockets for quite a while. i was planning to commit it, > but then i changed my mind. with the code i have, i can transfer raw > audio data, but what to do with the raw data is the next big question. > do we need to somehow plug into sound subsystem? something else? I have a couple different scenarios in mind but the primary one I want is compatibility with asterisk's chan_mobile. Asterisk's chan_mobile talks directly to the SCO channel without using any audio resources. It uses the socket api to create a socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO) and then bind's and connect's to the src/dst bluetooth addresses. All communication is then done simply with read/write calls. Asterisk's chan_mobile also uses rfcomm to talk to the headset/handsfree profile of the device that it wants to transfer audio with and I have been able to confirm manually that I can connect using rfcomm_sppd on FreeBSD to the headset and handsfree profiles of my phone and issue AT commands and get responses back. Having the bluetooth capability in the audio system might be nice but I think just getting the data to userland would enable applications to be developed that accomplish this. It would also enable other usage scenarios, such as chan_mobile. If you already have code that does the SCO part in both the driver and the socket API, what do I need to do to test it out and see if it accomplishes compatibility with Asterisk? Thanks, Jonathon > > thanks, > max > From mwm at mired.org Thu Apr 10 21:16:20 2008 From: mwm at mired.org (Mike Meyer) Date: Thu Apr 10 21:16:25 2008 Subject: headset support In-Reply-To: References: <92abd3ae0804101010m1535c06bm89ba9002a662f26@mail.gmail.com> Message-ID: <20080410164806.0bef7f75@bhuda.mired.org> On Thu, 10 Apr 2008 10:49:09 -0700 "Maksim Yevmenkin" wrote: > Jon, > > > I have searched back through the archives here and there is discussion about > > FreeBSD and headset/handsfree profile support. I have seen several comments > > that "the code is about the be committed" so I am wondering what the status > > really is. If any help is needed I would be willing to test and/or work on > > code so that this feature can be brought to the FreeBSD platform. > > first of all what exactly do you need to support? do you have any > specific usage scenario in mind? i have had code to support isoc > transfers in ng_ubt(4) (a must to support bluetooth audio) and > bluetooth sco sockets for quite a while. i was planning to commit it, > but then i changed my mind. with the code i have, i can transfer raw > audio data, but what to do with the raw data is the next big question. > do we need to somehow plug into sound subsystem? something else? Well, I'm not the OP, but I've been trying to free time to work on this. So my answer is... I want to use my FreeBSD box'es audio system as a BT headset. The headset protocol should do the trick, but handsfree might be fun to play with. The BT code doesn't need to hook into the sound system, but the UI will need to let the user pick audio devices to hook to the streams from BT. Another - less firm - thing would be playing "BT audio switchbox". Simple devices can only pair with one other device, including some I'd like to be able to use it with more than one device. Having a box that could pair with all of those and route audio between them might be useful. But that's just brainstorming. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From saamii at gmail.com Thu Apr 10 22:36:00 2008 From: saamii at gmail.com (Sami M'Barek) Date: Thu Apr 10 22:36:03 2008 Subject: Bluetooth application Message-ID: <20080410230521.027b3b78.saamii@gmail.com> Hi, I'm just wondering. I just searched around on google and FreeBSD ports. I saw that there was an ongoing gSoC project for porting NetworkManager which is great. How ever, is there any nice working application for OBEX push and pull files between my phone and computer? Gnome-bluetooth wont compile and i can't find anything on google. I marley have the time to set up a FUSE for this cause. Is there any port going on for this or is there an ready to use application already? -- Sami M'Barek From maksim.yevmenkin at gmail.com Thu Apr 10 22:58:43 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Apr 10 22:58:50 2008 Subject: Bluetooth application In-Reply-To: <20080410230521.027b3b78.saamii@gmail.com> References: <20080410230521.027b3b78.saamii@gmail.com> Message-ID: On Thu, Apr 10, 2008 at 4:05 PM, Sami M'Barek wrote: > Hi, > > I'm just wondering. I just searched around on google and FreeBSD ports. > I saw that there was an ongoing gSoC project for porting NetworkManager which is great. > How ever, is there any nice working application for OBEX push and pull files between my phone and computer? > Gnome-bluetooth wont compile and i can't find anything on google. > I marley have the time to set up a FUSE for this cause. > > Is there any port going on for this or is there an ready to use application already? take a look at comms/obexapp. it is a command line client/server that is able to do obex push and obex file transfer. few people using it to transfer files between phone and pc. thanks, max From maksim.yevmenkin at gmail.com Fri Apr 11 23:39:05 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Apr 11 23:39:11 2008 Subject: BT issues In-Reply-To: References: <47DBE7A4.3060006@users.sf.net> <47F67B95.4060402@users.sf.net> Message-ID: > > Thanks for the script but I would need it expanded a bit. The thing is > > that because I connect both FreeBSD and Windows as clients I had to create 2 > > slightly different ppp.conf labels (it didn't work for me with one label > > only). Therefore I created 2 simple scripts, each starting rfcomm_pppd with > > different label on different channel. Then I run them manually or > > automatically from cron at startup. > > Do you think it would be possible to cover situations like mine within your > > script ? Something like specifying for instance > > rfcomm_pppd_server_channel="1,2" .. ? > > why do you need 2 different labels? having multiple instances of a > rfcomm_pppd started would be possible, however i will need some time > to think about it. i have committed to -current newer version of the rfcomm_pppd_server script === http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/rfcomm_pppd_server Add rfcomm_pppd_server rc script to allow start rfcomm_pppd(8) in server mode at boot time. Multiple profiles can be started at the same time. The whole idea is very similar to the ppp rc script. === it provides support for multiple rfcomm_pppd profiles running on multiple rfcomm channels. still not sure why you need to support this, but it was relatively painless to add such support, so i did it. give it a try and let me know if you have any problems and/or suggestions. i will mfc it in a week or so. thanks, max From info at martenvijn.nl Sat Apr 12 07:12:01 2008 From: info at martenvijn.nl (Marten Vijn) Date: Sat Apr 12 07:12:05 2008 Subject: Bluetooth application In-Reply-To: <20080410230521.027b3b78.saamii@gmail.com> References: <20080410230521.027b3b78.saamii@gmail.com> Message-ID: <1207983154.1102.3.camel@workstation.martenvijn.nl> On Thu, 2008-04-10 at 23:05 +0000, Sami M'Barek wrote: > Hi, > > I'm just wondering. I just searched around on google and FreeBSD ports. > I saw that there was an ongoing gSoC project for porting NetworkManager which is great. > How ever, is there any nice working application for OBEX push and pull files between my phone and computer? > Gnome-bluetooth wont compile and i can't find anything on google. > I marley have the time to set up a FUSE for this cause. > > Is there any port going on for this or is there an ready to use application already? > Here is script that combines bt wifi (mesh and ap). http://bluespot.wifisoft.org/svn/trunk/bt_discover.sh You can kick 90% out to make what you want. I 've never used used any graphical interfaces on bt. kind regards, Marten -- Marten Vijn http://martenvijn.nl http://wifisoft.org http://opencommunitycamp.org From maksim.yevmenkin at gmail.com Sat Apr 12 17:03:54 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Sat Apr 12 17:03:59 2008 Subject: Bluetooth application In-Reply-To: <20080412022834.4b36e8c0.saamii@gmail.com> References: <20080410230521.027b3b78.saamii@gmail.com> <20080412022834.4b36e8c0.saamii@gmail.com> Message-ID: On Fri, Apr 11, 2008 at 7:28 PM, Sami M'Barek wrote: > That is what i'v been using all along but what i want is an "easy" to use client. > Preferably GTK. what is not "easy" about obexapp? are there any particular features that you are missing? as far as gnome/kde/etc. bluetooth apps goes, pretty much of them are linux (bluez) specific.while it is somewhat trivial to port linux bluez code to freebsd, no one seems do be willing to do so. if someone is willing to do a complete survey of current gnome/kde bluetooth code and tell me what api's are missing, i will work with such a person to get missing api's into the base system. thanks, max p.s. please keep freebsd-bluetooth@ in the cc From plunky at rya-online.net Sat Apr 12 18:26:38 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Sat Apr 12 18:26:46 2008 Subject: Bluetooth application In-Reply-To: References: <20080410230521.027b3b78.saamii@gmail.com> <20080412022834.4b36e8c0.saamii@gmail.com> Message-ID: <1208024773.051889.1001.nullmailer@galant.ukfsn.org> On Sat, 12 Apr 2008, Maksim Yevmenkin wrote: > what is not "easy" about obexapp? are there any particular features > that you are missing? One thing that I have been meaning to add but haven't found the time, is that when obexapp runs in server mode, it would be good to run different services (OPUSH/FTRN) on different channels as currently they run on the same channel. The reason I want this is so I can require authorisation for FTRN but allow OPUSH to anybody. The context methodology that obexapp uses should be fairly easily extendable for this, though I found the openobex API to be complex and it might be simpler to make each service run as a separate instance. If you are planning to work on bluetooth infrastructure (what, child grown up already!? :) then even though I don't use FreeBSD, I suggest: + "Link Mode" enable AUTH and ENCRYPT flags for individual L2CAP or RFCOMM channels (eg for above). I also did SECURE (ENCRYPT plus refresh link key) and worked on MASTER but had limited success so thats on hold for now. + removal of ng_ and NG_ prefixes from public API (HCI and L2CAP IIRC) will make porting programs much easier.. I would recommend that you can take the hci.h and l2cap.h defs from NetBSD files so that the spelling is constant throughout the BSD family at least. (also, I added HCI 2.1 already) + commit the SCO code you mentioned the other day you said you didn't know how it could be used, but until it is public then of course nobody else can work on that :) regards, iain From Alexander at Leidinger.net Tue Apr 15 11:11:24 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Tue Apr 15 11:11:31 2008 Subject: Wiimote as a mouse replacement? Message-ID: <20080415120002.162247crf5fyg22o@webmail.leidinger.net> Hi, has someone already tried to connect a Wiimote to FreeBSD (as a mouse replacement)? I found a dump of the HID at http://wiibrew.org/index.php?title=Bluetooth_Specs A Wiimote looks cheap enough to think about using it in a Home Cinema System or in a presentation. It's much easier to use on a sofa than a normal mouse. Bye, Alexander. -- It is the business of little minds to shrink. -- Carl Sandburg http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From maksim.yevmenkin at gmail.com Tue Apr 15 17:31:17 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Apr 15 17:31:23 2008 Subject: Wiimote as a mouse replacement? In-Reply-To: <20080415120002.162247crf5fyg22o@webmail.leidinger.net> References: <20080415120002.162247crf5fyg22o@webmail.leidinger.net> Message-ID: On Tue, Apr 15, 2008 at 3:00 AM, Alexander Leidinger wrote: > Hi, > > has someone already tried to connect a Wiimote to FreeBSD (as a mouse > replacement)? i recall someone already played with it. i will try to dig out that old email. here you go, it was turned into sf project http://sourceforge.net/projects/bsdmoted/ > I found a dump of the HID at > http://wiibrew.org/index.php?title=Bluetooth_Specs i recently got myself a wii :) will take a look at wiimote when i have a minute to spare > A Wiimote looks cheap enough to think about using it in a Home Cinema > System or in a presentation. It's much easier to use on a sofa than a normal > mouse. $40 us is not that cheap :) but then again compared to apple mighty mouse it is cheaper :) thanks, max From maksim.yevmenkin at gmail.com Tue Apr 15 18:12:44 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Apr 15 18:12:50 2008 Subject: Wiimote as a mouse replacement? In-Reply-To: <20080415140257.15b19a4a@mbook-fbsd> References: <20080415120002.162247crf5fyg22o@webmail.leidinger.net> <20080415140257.15b19a4a@mbook-fbsd> Message-ID: On Tue, Apr 15, 2008 at 11:02 AM, Mike Meyer wrote: > On Tue, 15 Apr 2008 10:02:39 -0700 "Maksim Yevmenkin" wrote: > > > System or in a presentation. It's much easier to use on a sofa than a normal > > > mouse. > > $40 us is not that cheap :) but then again compared to apple mighty > > mouse it is cheaper :) > > The PS3 bluetooth DVD remote is $35. One of the long list of things > I'd like to get working..... $20 on amazon.com :) http://www.amazon.com/Sony-PlayStation-Blu-ray-Disc-Remote/dp/B000M17AVO thanks, max From mwm at mired.org Tue Apr 15 18:29:41 2008 From: mwm at mired.org (Mike Meyer) Date: Tue Apr 15 18:29:54 2008 Subject: Wiimote as a mouse replacement? In-Reply-To: References: <20080415120002.162247crf5fyg22o@webmail.leidinger.net> Message-ID: <20080415140257.15b19a4a@mbook-fbsd> On Tue, 15 Apr 2008 10:02:39 -0700 "Maksim Yevmenkin" wrote: > > System or in a presentation. It's much easier to use on a sofa than a normal > > mouse. > $40 us is not that cheap :) but then again compared to apple mighty > mouse it is cheaper :) The PS3 bluetooth DVD remote is $35. One of the long list of things I'd like to get working..... http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From Alexander at Leidinger.net Wed Apr 16 05:58:11 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Apr 16 05:58:16 2008 Subject: Wiimote as a mouse replacement? In-Reply-To: References: <20080415120002.162247crf5fyg22o@webmail.leidinger.net> Message-ID: <20080416075803.11882a70152y7vk0@webmail.leidinger.net> Quoting Maksim Yevmenkin (from Tue, 15 Apr 2008 10:02:39 -0700): > On Tue, Apr 15, 2008 at 3:00 AM, Alexander Leidinger > wrote: >> Hi, >> >> has someone already tried to connect a Wiimote to FreeBSD (as a mouse >> replacement)? > > i recall someone already played with it. i will try to dig out that > old email. here you go, it was turned into sf project > > http://sourceforge.net/projects/bsdmoted/ Thanks for the link, maybe I will check it out this weekend. >> I found a dump of the HID at >> http://wiibrew.org/index.php?title=Bluetooth_Specs > > i recently got myself a wii :) will take a look at wiimote when i have > a minute to spare That's the reason why I ask, I got one on my birthday and now I'm setting up my home cinema. So I would have use for this now (first I have to setup the X server on the machine in question, before I can give it a try)... It would be great if it is possible out of the box. I've found a program for linux which translates button presses and movements into Xinput data (http://www.resplect.com/xwii/), but as I haven't setup the machine I want to use there yet, I didn't even downloaded it yet. >> A Wiimote looks cheap enough to think about using it in a Home Cinema >> System or in a presentation. It's much easier to use on a sofa than a normal >> mouse. > > $40 us is not that cheap :) but then again compared to apple mighty > mouse it is cheaper :) 37 EUR for the Wiimote here in Germany (39 if you want to get WiiPlay too). For a loudspeaker, acceleration sensors, an infra-red ccd and some buttons in a nice design I would say it is not expensive. The possibilities this offers are woth the price IMO. I'm looking forward to any results you get with playing with FreeBSD+Wii. Bye, Alexander. -- H. L. Mencken suffers from the hallucination that he is H. L. Mencken -- there is no cure for a disease of that magnitude. -- Maxwell Bodenheim http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From rizzo at iet.unipi.it Thu Apr 17 12:12:05 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Apr 17 12:12:08 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? Message-ID: <20080417115631.GA72315@onelab2.iet.unipi.it> hi, is there any compelling reason to require the '-t device' option in rfcomm_sppd when used in server mode ? I tried to disable the one-line that checks it in the code, and things seem to work - and this makes the program very convenient to use in a pipeline, e.g. to receive data from a remote bluetooth device. cheers luigi From maksim.yevmenkin at gmail.com Thu Apr 17 17:39:22 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Apr 17 17:39:25 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? In-Reply-To: <20080417115631.GA72315@onelab2.iet.unipi.it> References: <20080417115631.GA72315@onelab2.iet.unipi.it> Message-ID: On Thu, Apr 17, 2008 at 4:56 AM, Luigi Rizzo wrote: > hi, is there any compelling reason to require > the '-t device' option in rfcomm_sppd when used in server mode ? technically, no. just need to be careful who is going to setup tty properly, for example make it 'raw' as rfcomm_sppd(1) does with pty. rfcomm_sppd(1) already can be used inside ppp(8), i.e. one can do something like set device '!/usr/bin/rfcomm_sppd -a mobile -c sp' in /etc/ppp.conf and it will work just fine. rfcomm_sppd(1) does not do anything to tty when running using stdin/stdout in client mode. the assumption here is that whatever calls rfcomm_sppd(1) will setup tty/fd properly. > I tried to disable the one-line that checks it in the code, and > things seem to work - and this makes the program very convenient > to use in a pipeline, e.g. to receive data from a remote bluetooth > device. right. can you please provide usage example? i certainly would not object to making the change you are requesting. thanks, max From rizzo at iet.unipi.it Thu Apr 17 18:03:57 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Apr 17 18:04:04 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? In-Reply-To: References: <20080417115631.GA72315@onelab2.iet.unipi.it> Message-ID: <20080417180601.GA76189@onelab2.iet.unipi.it> On Thu, Apr 17, 2008 at 10:39:16AM -0700, Maksim Yevmenkin wrote: > On Thu, Apr 17, 2008 at 4:56 AM, Luigi Rizzo wrote: > > hi, is there any compelling reason to require > > the '-t device' option in rfcomm_sppd when used in server mode ? > > technically, no. just need to be careful who is going to setup tty > properly, for example make it 'raw' as rfcomm_sppd(1) does with pty. > rfcomm_sppd(1) already can be used inside ppp(8), i.e. one can do > something like > > set device '!/usr/bin/rfcomm_sppd -a mobile -c sp' > > in /etc/ppp.conf and it will work just fine. rfcomm_sppd(1) does not > do anything to tty when running using stdin/stdout in client mode. the > assumption here is that whatever calls rfcomm_sppd(1) will setup > tty/fd properly. > > > I tried to disable the one-line that checks it in the code, and > > things seem to work - and this makes the program very convenient > > to use in a pipeline, e.g. to receive data from a remote bluetooth > > device. > > right. can you please provide usage example? i certainly would not > object to making the change you are requesting. sure - i need to listen to a portable ElectroCardioGram (ECG) device which talks to the external world through bluetooth. The device must have some kind of modem inside - its console port says it is issuing commands such as AT+ZV SPPConnect XXX ... where XXX is the (manually configured) address of the bluetooth dongle on the PC. On the FreeBSD side, running "rfcom_sppd -a YYY" (without the -S option, YYY is the ECG address) sometimes connects, but most of the times doesnt. With a patched rfcomm_sppp i can just do rfcomm_sppd -S -a YYY | my_data_logger rather than having to manually select an available tty/pty pair Don't know how many devices behave in this way, but a search for "AT+ZV SPPConnect" gives several matches with documentation for embedded hardware. cheers luigi From jonmoldenhauer at gmail.com Thu Apr 17 19:27:13 2008 From: jonmoldenhauer at gmail.com (Jonathon Moldenhauer) Date: Thu Apr 17 19:27:16 2008 Subject: headset support In-Reply-To: <20080410164806.0bef7f75@bhuda.mired.org> References: <92abd3ae0804101010m1535c06bm89ba9002a662f26@mail.gmail.com> <20080410164806.0bef7f75@bhuda.mired.org> Message-ID: <92abd3ae0804171227s6ab2817fjf44c65247a30153b@mail.gmail.com> On Thu, Apr 10, 2008 at 1:48 PM, Mike Meyer wrote: > On Thu, 10 Apr 2008 10:49:09 -0700 "Maksim Yevmenkin" wrote: > > Jon, > > > > > I have searched back through the archives here and there is discussion about > > > FreeBSD and headset/handsfree profile support. I have seen several comments > > > that "the code is about the be committed" so I am wondering what the status > > > really is. If any help is needed I would be willing to test and/or work on > > > code so that this feature can be brought to the FreeBSD platform. > > > > first of all what exactly do you need to support? do you have any > > specific usage scenario in mind? i have had code to support isoc > > transfers in ng_ubt(4) (a must to support bluetooth audio) and > > bluetooth sco sockets for quite a while. i was planning to commit it, > > but then i changed my mind. with the code i have, i can transfer raw > > audio data, but what to do with the raw data is the next big question. > > do we need to somehow plug into sound subsystem? something else? > > Well, I'm not the OP, but I've been trying to free time to work on > this. So my answer is... > > I want to use my FreeBSD box'es audio system as a BT headset. The > headset protocol should do the trick, but handsfree might be fun to > play with. The BT code doesn't need to hook into the sound system, but > the UI will need to let the user pick audio devices to hook to the > streams from BT. > > Another - less firm - thing would be playing "BT audio > switchbox". Simple devices can only pair with one other device, > including some I'd like to be able to use it with more than one > device. Having a box that could pair with all of those and route > audio between them might be useful. But that's just brainstorming. > > Thanks, > You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://annapurna.ifj.edu.pl/~jolanta/cgi-bin/postcard.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://annapurna.ifj.edu.pl/~jolanta/cgi-bin/postcard.exe From Alexander at Leidinger.net Sat Apr 19 10:16:59 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Apr 19 10:17:06 2008 Subject: Wiimote as a mouse replacement? In-Reply-To: References: <20080415120002.162247crf5fyg22o@webmail.leidinger.net> Message-ID: <20080419121649.70fb7cef@deskjail> Quoting "Maksim Yevmenkin" (Tue, 15 Apr 2008 10:02:39 -0700): > On Tue, Apr 15, 2008 at 3:00 AM, Alexander Leidinger > wrote: > > Hi, > > > > has someone already tried to connect a Wiimote to FreeBSD (as a mouse > > replacement)? > > i recall someone already played with it. i will try to dig out that > old email. here you go, it was turned into sf project > > http://sourceforge.net/projects/bsdmoted/ This works (tested in tilting mode with version 0.4). http://ninjin-weblog.blogspot.com/2007/06/wiimote-under-freebsd-using-bsdmoted.html is a help for the setup. > > I found a dump of the HID at > > http://wiibrew.org/index.php?title=Bluetooth_Specs > > i recently got myself a wii :) will take a look at wiimote when i have > a minute to spare It would be great if this could be integrated into bthidd (author of bsdmote CCed)... Some notes: It logs too much. After powering off the wiimote it fills the logs with reconnect tries. It would be nice to specify the led pattern in the config file to use for this wiimote (it is not convenient to have two wiimotes with led 1 active when the Wii and the bsdmode are in use). Feature requests: Being able to use the up/down/left/right buttons somehow. Either as additional button events, or to move the mouse (best solution: make it configurable). Being able to use additional controllers (e.g. Nunchuk) too (again, as additional mouse buttons or moving the mouse). Bye, Alexander. -- Ferengi Rule of Acquisition #52: Never ask when you can take. -- ST:DS9, "Rule of Acquisition" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From phil at testequipmentconnection.org Sun Apr 20 13:58:33 2008 From: phil at testequipmentconnection.org (Phil) Date: Sun Apr 20 13:58:40 2008 Subject: Refurbished Wireless Test and Repair Values Message-ID: <20080420130922.8E66B8A4097@mail.testequipmentconnection.net> We Sell Worldwide Rentals and Leasing Available Renting or leasing test equipment is today’s answer. Renting test equipment allows you to acquire test equipment without the investment of ownership. Renting test equipment is an ideal solution for companies that need additional test equipment on short notice or need test equipment for short periods of time. Rent test equipment for special projects, replace failed equipment, or evaluate test equipment before purchasing and avoid long lead times. Test Equipment Connection is expanding its rental inventory and investing in the newest and most popular test equipment. Our inventory is growing and changes daily. We offer over 28,000 test instruments from over 250 manufacturers. When you rent test equipment, rental payments are treated as operating expenses and not part of your capital equipment budget. Call or Email for a Quote Today Rental Quote Request Tight Capital Budget? - No Problem! Check Out These High Quality Refurbished Equipment Specials and Maximize Your Budget. Anritsu MT8220A/40/41 Sale $8,995 Anritsu S331B Sale $3,995 Anritsu S332C Sale $6,895 Anritsu ML2437A Sale $3,995 Agilent E6380A Sale $3,500 Agilent E4436B/Options Sale $15,900 Agilent 8712ET/1EC Sale $9,800 IFR COM120B Sale $9,290 HP 4284A Sale $9,990 HP 8560EC Sale $23,000 HP 8720D with options On Sale Call R&S FSH3 On Sale Call Over 15 Years of Sales, Service and Selection Rohde & Schwarz SME03 Sale $5,490 IFR 2945A Sale 9,495 Anritsu S332C Sale $6,895 Anritsu S331C Sale $5,495 Anritsu S331A Sale $2,995 Agilent 8753ES Sale $22,000 Tektronix TVS645 Sale $2,750 Agilent 89431A Sale $6,890 Test Equipment Connection is Actively Purchasing De-installed, Excess, New-Surplus, Off-Lease and Underutilized Equipment. Click Here for a Cash Offer R&S FSH6.26/B1/Z3 Sale $19,190 JDSU SDA5000 Sale $6,990 JDSU FST2802 Sale $8,490 JDSU FST-2310 Equipped for DS1, DS3, OC-3, & OC-12 Call JDSU ANT-5 Equipped for STM-1/-4 On Sale Call Tektronix TDS3032 Sale $3,000 Tektronix TDS3034 Sale $3,895 Tektronix TDS3054B Sale $8,490 HP 8561E Sale $11,980 Marconi 2031 Sale $3,895 Agilent E4436B w/options On Sale Call HP 8720ES/10/12/400 Sale $55,000 HP 54540C Sale $2,495 HP 8648C/1E6 Sale $7,290 Our technicians are fully trained and have extensive calibration and repair expertise on the widest variety of makes & models. We provide high quality repair and calibration services at competitive prices with responsive turn around times for evaluation, repair and calibration. N.I.S.T. traceable certificates in accordance with MIL-STD 45662A and ANSI/NSCL 540-1 can be provided with all repairs. In addition, ISO 9001-2000 UL registered calibrations and ISO/IEC 17025 calibrations accredited by A2LA are available for select items. No Capital Budget? - No Problem! We Repair and Calibrate So You Can Utilize The Equipment You Already Have. Free Evaluation Coupon Below! Click Here to View This Page on the Internet Toll Free USA & Canada 800-615-8378 Direct Worldwide 407-804-1184 email phil@testequipmentconnection.org 30 Skyline Drive Lake Mary, FL 32746 This email is sent in accordance with the US CAN-SPAM Act. *Removal* requests* can be sent to this address and will be honored and respected If you want to dis-continue this mailing click on the following email address or respond with *un-subscribe* in the subject line to: phil@testequipmentconnection.org From maksim.yevmenkin at gmail.com Mon Apr 21 18:51:58 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon Apr 21 18:52:04 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? In-Reply-To: <20080417180601.GA76189@onelab2.iet.unipi.it> References: <20080417115631.GA72315@onelab2.iet.unipi.it> <20080417180601.GA76189@onelab2.iet.unipi.it> Message-ID: On Thu, Apr 17, 2008 at 11:06 AM, Luigi Rizzo wrote: > > On Thu, Apr 17, 2008 at 10:39:16AM -0700, Maksim Yevmenkin wrote: > > On Thu, Apr 17, 2008 at 4:56 AM, Luigi Rizzo wrote: > > > hi, is there any compelling reason to require > > > the '-t device' option in rfcomm_sppd when used in server mode ? > > > > technically, no. just need to be careful who is going to setup tty > > properly, for example make it 'raw' as rfcomm_sppd(1) does with pty. > > rfcomm_sppd(1) already can be used inside ppp(8), i.e. one can do > > something like > > > > set device '!/usr/bin/rfcomm_sppd -a mobile -c sp' > > > > in /etc/ppp.conf and it will work just fine. rfcomm_sppd(1) does not > > do anything to tty when running using stdin/stdout in client mode. the > > assumption here is that whatever calls rfcomm_sppd(1) will setup > > tty/fd properly. > > > > > I tried to disable the one-line that checks it in the code, and > > > things seem to work - and this makes the program very convenient > > > to use in a pipeline, e.g. to receive data from a remote bluetooth > > > device. > > > > right. can you please provide usage example? i certainly would not > > object to making the change you are requesting. > > sure - i need to listen to a portable ElectroCardioGram (ECG) device > which talks to the external world through bluetooth. The device > must have some kind of modem inside - its console port says it is > issuing commands such as > > AT+ZV SPPConnect XXX > ... > > where XXX is the (manually configured) address of the bluetooth > dongle on the PC. On the FreeBSD side, running > "rfcom_sppd -a YYY" (without the -S option, YYY is the ECG address) > sometimes connects, but most of the times doesnt. > > With a patched rfcomm_sppp i can just do > > rfcomm_sppd -S -a YYY | my_data_logger > > rather than having to manually select an available tty/pty pair > > Don't know how many devices behave in this way, but a > search for "AT+ZV SPPConnect" gives several matches with > documentation for embedded hardware. ok, please try the attached patch and see if it works for you. i basically removed the check for tty name in server mode, bind to "wildcard" channel instead of generating one based on pid (if channel was not specified) and fixed a possible problem with service registration in server mode (i.e. always register serial port service). thanks, max > > cheers > luigi > -------------- next part -------------- Index: rfcomm_sppd.1 =================================================================== RCS file: /usr/local/cvs/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.1,v retrieving revision 1.10 diff -u -r1.10 rfcomm_sppd.1 --- rfcomm_sppd.1 21 Apr 2008 18:13:23 -0000 1.10 +++ rfcomm_sppd.1 21 Apr 2008 18:37:09 -0000 @@ -25,7 +25,7 @@ .\" $Id: rfcomm_sppd.1,v 1.10 2008/04/21 18:13:23 max Exp $ .\" $FreeBSD: src/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.1,v 1.10 2007/01/25 20:54:59 emax Exp $ .\" -.Dd January 24, 2007 +.Dd April 21, 2008 .Dt RFCOMM_SPPD 1 .Os .Sh NAME @@ -69,14 +69,15 @@ via the .Xr sdpd 8 daemon. -The +If .Fl t -option must be specified; +options was specified, the server side of the virtual serial port is attached to the pseudo-terminal .Ar tty . +Otherwise the virtual serial port is attached to the stdin/stdout. .Nm should be run as root in order to communicate with -.Xr sdp 8 +.Xr sdpd 8 in this case. .Pp The @@ -113,12 +114,18 @@ Detach from the controlling terminal, i.e., run in background. .It Fl c Ar channel In both client and server mode, -this required option specifies the RFCOMM channel to connect to or listen on. +this option specifies the RFCOMM channel to connect to or listen on. In server mode, the channel should be a number between 1 and 30. If not specified, .Nm -will try to allocate RFCOMM channel number based on process ID. +will try to bind to +.Dq wildcard +RFCOMM channel number. +The actual RFCOMM channel will be obtained via +.Xr getsockname 2 +call and will be used to register Serial Port service with +.Xr sdpd 8 . In client mode, the channel could either be a number between 1 and 30 or a service name. Supported service names are: @@ -144,8 +151,6 @@ If not set stdin/stdout will be used. This option is required if .Fl b -or -.Fl S option was specified. .El .Sh FILES Index: rfcomm_sppd.c =================================================================== RCS file: /usr/local/cvs/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.c,v retrieving revision 1.11 diff -u -r1.11 rfcomm_sppd.c --- rfcomm_sppd.c 21 Apr 2008 18:13:23 -0000 1.11 +++ rfcomm_sppd.c 21 Apr 2008 18:39:26 -0000 @@ -1,6 +1,8 @@ /* * rfcomm_sppd.c - * + */ + +/*- * Copyright (c) 2003 Maksim Yevmenkin * All rights reserved. * @@ -172,7 +174,7 @@ /* Open TTYs */ if (tty == NULL) { - if (background || doserver) + if (background) usage(); amaster = STDIN_FILENO; @@ -189,43 +191,47 @@ if (doserver) { struct sockaddr_rfcomm ma; bdaddr_t bt_addr_any; - sdp_lan_profile_t lan; + sdp_sp_profile_t sp; void *ss; uint32_t sdp_handle; int acceptsock, aaddrlen; - if (channel == 0) { - /* XXX: should check if selected channel is unused */ - channel = (getpid() % 30) + 1; - } acceptsock = socket(PF_BLUETOOTH, SOCK_STREAM, - BLUETOOTH_PROTO_RFCOMM); + BLUETOOTH_PROTO_RFCOMM); if (acceptsock < 0) err(1, "Could not create socket"); + memcpy(&bt_addr_any, NG_HCI_BDADDR_ANY, sizeof(bt_addr_any)); + memset(&ma, 0, sizeof(ma)); ma.rfcomm_len = sizeof(ma); ma.rfcomm_family = AF_BLUETOOTH; + memcpy(&ma.rfcomm_bdaddr, &bt_addr_any, sizeof(bt_addr_any)); ma.rfcomm_channel = channel; if (bind(acceptsock, (struct sockaddr *)&ma, sizeof(ma)) < 0) - err(1, "Could not bind socket -- channel %d in use?", + err(1, "Could not bind socket on channel %d", channel); if (listen(acceptsock, 10) != 0) err(1, "Could not listen on socket"); + aaddrlen = sizeof(ma); + if (getsockname(s, (struct sockaddr *)&ma, &aaddrlen) < 0) + errx(1, "Could not get socket name"); + channel = ma.rfcomm_channel; + ss = sdp_open_local(NULL); if (ss == NULL) errx(1, "Unable to create local SDP session"); if (sdp_error(ss) != 0) errx(1, "Unable to open local SDP session. %s (%d)", strerror(sdp_error(ss)), sdp_error(ss)); - memset(&lan, 0, sizeof(lan)); - lan.server_channel = channel; + memset(&sp, 0, sizeof(sp)); + sp.server_channel = channel; - memcpy(&bt_addr_any, NG_HCI_BDADDR_ANY, sizeof(bt_addr_any)); - if (sdp_register_service(ss, service, &bt_addr_any, - (void *)&lan, sizeof(lan), &sdp_handle) != 0) { + if (sdp_register_service(ss, SDP_SERVICE_CLASS_SERIAL_PORT, + &bt_addr_any, (void *)&sp, sizeof(sp), + &sdp_handle) != 0) { errx(1, "Unable to register LAN service with " "local SDP daemon. %s (%d)", strerror(sdp_error(ss)), sdp_error(ss)); From gamato at users.sf.net Tue Apr 22 19:07:20 2008 From: gamato at users.sf.net (mato) Date: Tue Apr 22 19:07:26 2008 Subject: BT issues In-Reply-To: References: <47DBE7A4.3060006@users.sf.net> <47F67B95.4060402@users.sf.net> Message-ID: <480E375D.1050302@users.sf.net> Maksim Yevmenkin wrote: > On 4/4/08, mato wrote: > >> Maksim Yevmenkin wrote: >> >> Hi Max, >> >> Thanks for the script but I would need it expanded a bit. The thing is >> that because I connect both FreeBSD and Windows as clients I had to create 2 >> slightly different ppp.conf labels (it didn't work for me with one label >> only). Therefore I created 2 simple scripts, each starting rfcomm_pppd with >> different label on different channel. Then I run them manually or >> automatically from cron at startup. >> Do you think it would be possible to cover situations like mine within your >> script ? Something like specifying for instance >> rfcomm_pppd_server_channel="1,2" .. ? >> > > why do you need 2 different labels? having multiple instances of a > rfcomm_pppd started would be possible, however i will need some time > to think about it. > > thanks, > max > I need two labels to support both FreeBSD and Windows clients. M. From gamato at users.sf.net Tue Apr 22 19:13:43 2008 From: gamato at users.sf.net (mato) Date: Tue Apr 22 19:13:49 2008 Subject: BT issues In-Reply-To: References: <47DBE7A4.3060006@users.sf.net> <47F67B95.4060402@users.sf.net> Message-ID: <480E38E5.1040506@users.sf.net> Maksim Yevmenkin wrote: >> > Thanks for the script but I would need it expanded a bit. The thing is >> > that because I connect both FreeBSD and Windows as clients I had to create 2 >> > slightly different ppp.conf labels (it didn't work for me with one label >> > only). Therefore I created 2 simple scripts, each starting rfcomm_pppd with >> > different label on different channel. Then I run them manually or >> > automatically from cron at startup. >> > Do you think it would be possible to cover situations like mine within your >> > script ? Something like specifying for instance >> > rfcomm_pppd_server_channel="1,2" .. ? >> >> why do you need 2 different labels? having multiple instances of a >> rfcomm_pppd started would be possible, however i will need some time >> to think about it. >> > > i have committed to -current newer version of the rfcomm_pppd_server script > > === > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/rfcomm_pppd_server > > Add rfcomm_pppd_server rc script to allow start rfcomm_pppd(8) in server > mode at boot time. Multiple profiles can be started at the same time. > The whole idea is very similar to the ppp rc script. > > === > > it provides support for multiple rfcomm_pppd profiles running on > multiple rfcomm channels. still not sure why you need to support this, > but it was relatively painless to add such support, so i did it. give > it a try and let me know if you have any problems and/or suggestions. > i will mfc it in a week or so. > > thanks, > max > Hi Max, I'm just upgrading my work laptop to 7-STABLE and I hope to test it soon. I need two labels because Windows clients require slightly different configuration than FreeBSD clients. I think we emailed about my difficulties with Windows clients long time ago and only later I managed to make them work and I'm not even sure how that happened. Regards, M.