From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 16:25:12 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6ECB106566C for ; Tue, 13 May 2008 16:25:12 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from rigel.oldach.net (rigel.oldach.net [194.8.96.250]) by mx1.freebsd.org (Postfix) with ESMTP id 443FD8FC22 for ; Tue, 13 May 2008 16:25:11 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (hmo.in-dsl.de [217.197.85.210]) by rigel.oldach.net (8.14.2/8.14.2/hmo30jul04) with ESMTP id m4DFqSR9063632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2008 17:52:29 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.14.2/8.14.2/hmo26jun05) with ESMTP id m4DFqSXQ031045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 17:52:28 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.14.2/8.14.2/Submit/hmo26jun05) id m4DFqQOW031043; Tue, 13 May 2008 17:52:27 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Message-Id: <200805131552.m4DFqQOW031043@sep.oldach.net> In-Reply-To: from Maksim Yevmenkin at "21 Apr 2008 11:51:55" To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Date: Tue, 13 May 2008 17:52:26 +0200 (CEST) From: freebsd-bluetooth@oldach.net (Helge Oldach) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, rizzo@iet.unipi.it Subject: Re: any reason to require -t dev in rfcomm_sppd -S ? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 16:25:13 -0000 Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST): > 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). Your patch applies cleanly, but I just get # rfcomm_sppd -S rfcomm_sppd: Could not get socket name # It seems that getsockbyname fails. What is the reason for that anyway? BTW, Luigi's pipe application is interesting, but what about true two-way communcation? For instance, I would like to have something like # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" ...meaning: Upon receipt of a SP connection request from myPalm we would fork coldsync to synchronize the Palm (just like USB or serial sync, but now bluetooth). This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the request terminates. I'm currently doing this in two separate steps, first starting rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. So yes, this definitely works. Regards, Helge From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 16:48:08 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6C9F106564A for ; Tue, 13 May 2008 16:48:08 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 0D0E48FC0A for ; Tue, 13 May 2008 16:48:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so4645005fgb.35 for ; Tue, 13 May 2008 09:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=jpY9NJQbFWAef2P0P3LVqyNNHrgxbGk9FNKEKsD/hXo=; b=dae/pMFakAkxD52m66c9138+6rt4EUTOYnKo/Kh5aDGfpwoJKTMTzynOEyH+T9NeMKNM4+nac8eCAPUgYAvx7LqOpfRb0vT00qT+4/37j+0tgP9PDqkpkS69QcBnkvPvTPd8OKyd5+9k1aN4FejUDPvfaGxDYKFFf6PrvYJZNj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=K/JeMokG3/pYjpBj3kJdefJMcxIYqhHHHBdDiL7H+UgdetOXq2MxZKaPqasMaEeqWQCVbIXrjy4w11JDY9ojcQFzK98I3PAT4M3wHfi+yOM36+ZWCCKN4TTudweHjUc66qyMGLLsJsO6XqoU5oH1DE9ao7wQMBXg4XixPuSBZsM= Received: by 10.86.94.11 with SMTP id r11mr38947fgb.0.1210697286739; Tue, 13 May 2008 09:48:06 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Tue, 13 May 2008 09:48:06 -0700 (PDT) Message-ID: Date: Tue, 13 May 2008 09:48:06 -0700 From: "Maksim Yevmenkin" To: "Helge Oldach" In-Reply-To: <200805131552.m4DFqQOW031043@sep.oldach.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8614_29769232.1210697286687" References: <200805131552.m4DFqQOW031043@sep.oldach.net> Cc: freebsd-bluetooth@freebsd.org, rizzo@iet.unipi.it Subject: Re: any reason to require -t dev in rfcomm_sppd -S ? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 16:48:08 -0000 ------=_Part_8614_29769232.1210697286687 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, May 13, 2008 at 8:52 AM, Helge Oldach wrote: > Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST): >> 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). > > Your patch applies cleanly, but I just get > > # rfcomm_sppd -S > rfcomm_sppd: Could not get socket name > # > > It seems that getsockbyname fails. What is the reason for that anyway? > > BTW, Luigi's pipe application is interesting, but what about true > two-way communcation? For instance, I would like to have something like > > # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" > > ...meaning: Upon receipt of a SP connection request from myPalm we would > fork coldsync to synchronize the Palm (just like USB or serial sync, but > now bluetooth). > > This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the > request terminates. > > I'm currently doing this in two separate steps, first starting > rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. > So yes, this definitely works. well, there is a problem with my previous patch. please try the attached updated patch. thanks, max ------=_Part_8614_29769232.1210697286687 Content-Type: text/plain; name=rfcomm_sppd.patch.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fg6pw4500 Content-Disposition: attachment; filename=rfcomm_sppd.patch.txt SW5kZXg6IHJmY29tbV9zcHBkLjEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Vzci9sb2NhbC9jdnMv dXNyLmJpbi9ibHVldG9vdGgvcmZjb21tX3NwcGQvcmZjb21tX3NwcGQuMSx2CnJldHJpZXZpbmcg cmV2aXNpb24gMS4xMApkaWZmIC11IC1yMS4xMCByZmNvbW1fc3BwZC4xCi0tLSByZmNvbW1fc3Bw ZC4xCTIxIEFwciAyMDA4IDE4OjEzOjIzIC0wMDAwCTEuMTAKKysrIHJmY29tbV9zcHBkLjEJMjEg QXByIDIwMDggMTg6Mzc6MDkgLTAwMDAKQEAgLTI1LDcgKzI1LDcgQEAKIC5cIiAkSWQ6IHJmY29t bV9zcHBkLjEsdiAxLjEwIDIwMDgvMDQvMjEgMTg6MTM6MjMgbWF4IEV4cCAkCiAuXCIgJEZyZWVC U0Q6IHNyYy91c3IuYmluL2JsdWV0b290aC9yZmNvbW1fc3BwZC9yZmNvbW1fc3BwZC4xLHYgMS4x MCAyMDA3LzAxLzI1IDIwOjU0OjU5IGVtYXggRXhwICQKIC5cIgotLkRkIEphbnVhcnkgMjQsIDIw MDcKKy5EZCBBcHJpbCAyMSwgMjAwOAogLkR0IFJGQ09NTV9TUFBEIDEKIC5PcwogLlNoIE5BTUUK QEAgLTY5LDE0ICs2OSwxNSBAQAogdmlhIHRoZQogLlhyIHNkcGQgOAogZGFlbW9uLgotVGhlCitJ ZgogLkZsIHQKLW9wdGlvbiBtdXN0IGJlIHNwZWNpZmllZDsKK29wdGlvbnMgd2FzIHNwZWNpZmll ZCwKIHRoZSBzZXJ2ZXIgc2lkZSBvZiB0aGUgdmlydHVhbCBzZXJpYWwgcG9ydCBpcyBhdHRhY2hl ZCB0byB0aGUgcHNldWRvLXRlcm1pbmFsCiAuQXIgdHR5IC4KK090aGVyd2lzZSB0aGUgdmlydHVh bCBzZXJpYWwgcG9ydCBpcyBhdHRhY2hlZCB0byB0aGUgc3RkaW4vc3Rkb3V0LgogLk5tCiBzaG91 bGQgYmUgcnVuIGFzIHJvb3QgaW4gb3JkZXIgdG8gY29tbXVuaWNhdGUgd2l0aAotLlhyIHNkcCA4 CisuWHIgc2RwZCA4CiBpbiB0aGlzIGNhc2UuCiAuUHAKIFRoZQpAQCAtMTEzLDEyICsxMTQsMTgg QEAKIERldGFjaCBmcm9tIHRoZSBjb250cm9sbGluZyB0ZXJtaW5hbCwgaS5lLiwgcnVuIGluIGJh Y2tncm91bmQuCiAuSXQgRmwgYyBBciBjaGFubmVsCiBJbiBib3RoIGNsaWVudCBhbmQgc2VydmVy IG1vZGUsCi10aGlzIHJlcXVpcmVkIG9wdGlvbiBzcGVjaWZpZXMgdGhlIFJGQ09NTSBjaGFubmVs IHRvIGNvbm5lY3QgdG8gb3IgbGlzdGVuIG9uLgordGhpcyBvcHRpb24gc3BlY2lmaWVzIHRoZSBS RkNPTU0gY2hhbm5lbCB0byBjb25uZWN0IHRvIG9yIGxpc3RlbiBvbi4KIEluIHNlcnZlciBtb2Rl LAogdGhlIGNoYW5uZWwgc2hvdWxkIGJlIGEgbnVtYmVyIGJldHdlZW4gMSBhbmQgMzAuCiBJZiBu b3Qgc3BlY2lmaWVkLAogLk5tCi13aWxsIHRyeSB0byBhbGxvY2F0ZSBSRkNPTU0gY2hhbm5lbCBu dW1iZXIgYmFzZWQgb24gcHJvY2VzcyBJRC4KK3dpbGwgdHJ5IHRvIGJpbmQgdG8KKy5EcSB3aWxk Y2FyZAorUkZDT01NIGNoYW5uZWwgbnVtYmVyLgorVGhlIGFjdHVhbCBSRkNPTU0gY2hhbm5lbCB3 aWxsIGJlIG9idGFpbmVkIHZpYQorLlhyIGdldHNvY2tuYW1lIDIKK2NhbGwgYW5kIHdpbGwgYmUg dXNlZCB0byByZWdpc3RlciBTZXJpYWwgUG9ydCBzZXJ2aWNlIHdpdGgKKy5YciBzZHBkIDggLgog SW4gY2xpZW50IG1vZGUsCiB0aGUgY2hhbm5lbCBjb3VsZCBlaXRoZXIgYmUgYSBudW1iZXIgYmV0 d2VlbiAxIGFuZCAzMCBvciBhIHNlcnZpY2UgbmFtZS4KIFN1cHBvcnRlZCBzZXJ2aWNlIG5hbWVz IGFyZToKQEAgLTE0NCw4ICsxNTEsNiBAQAogSWYgbm90IHNldCBzdGRpbi9zdGRvdXQgd2lsbCBi ZSB1c2VkLgogVGhpcyBvcHRpb24gaXMgcmVxdWlyZWQgaWYKIC5GbCBiCi1vcgotLkZsIFMKIG9w dGlvbiB3YXMgc3BlY2lmaWVkLgogLkVsCiAuU2ggRklMRVMKSW5kZXg6IHJmY29tbV9zcHBkLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQpSQ1MgZmlsZTogL3Vzci9sb2NhbC9jdnMvdXNyLmJpbi9ibHVldG9vdGgvcmZj b21tX3NwcGQvcmZjb21tX3NwcGQuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMQpkaWZmIC11 IC1yMS4xMSByZmNvbW1fc3BwZC5jCi0tLSByZmNvbW1fc3BwZC5jCTIxIEFwciAyMDA4IDE4OjEz OjIzIC0wMDAwCTEuMTEKKysrIHJmY29tbV9zcHBkLmMJMTMgTWF5IDIwMDggMTY6NDQ6MjQgLTAw MDAKQEAgLTEsNiArMSw4IEBACiAvKgogICogcmZjb21tX3NwcGQuYwotICoKKyAqLworCisvKi0K ICAqIENvcHlyaWdodCAoYykgMjAwMyBNYWtzaW0gWWV2bWVua2luIDxtX2V2bWVua2luQHlhaG9v LmNvbT4KICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCiAgKgpAQCAtMTcyLDcgKzE3NCw3IEBACiAK IAkvKiBPcGVuIFRUWXMgKi8KIAlpZiAodHR5ID09IE5VTEwpIHsKLQkJaWYgKGJhY2tncm91bmQg fHwgZG9zZXJ2ZXIpCisJCWlmIChiYWNrZ3JvdW5kKQogCQkJdXNhZ2UoKTsKIAogCQlhbWFzdGVy ID0gU1RESU5fRklMRU5POwpAQCAtMTg5LDQzICsxOTEsNDYgQEAKIAlpZiAoZG9zZXJ2ZXIpIHsK IAkJc3RydWN0IHNvY2thZGRyX3JmY29tbQkgbWE7CiAJCWJkYWRkcl90CQkgYnRfYWRkcl9hbnk7 Ci0JCXNkcF9sYW5fcHJvZmlsZV90CSBsYW47CisJCXNkcF9zcF9wcm9maWxlX3QJIHNwOwogCQl2 b2lkCQkJKnNzOwogCQl1aW50MzJfdAkJIHNkcF9oYW5kbGU7CiAJCWludAkJCSBhY2NlcHRzb2Nr LCBhYWRkcmxlbjsKIAotCQlpZiAoY2hhbm5lbCA9PSAwKSB7Ci0JCQkvKiBYWFg6IHNob3VsZCBj aGVjayBpZiBzZWxlY3RlZCBjaGFubmVsIGlzIHVudXNlZCAqLwotCQkJY2hhbm5lbCA9IChnZXRw aWQoKSAlIDMwKSArIDE7Ci0JCX0KIAkJYWNjZXB0c29jayA9IHNvY2tldChQRl9CTFVFVE9PVEgs IFNPQ0tfU1RSRUFNLAotCQkgICAgQkxVRVRPT1RIX1BST1RPX1JGQ09NTSk7CisJCQkJCUJMVUVU T09USF9QUk9UT19SRkNPTU0pOwogCQlpZiAoYWNjZXB0c29jayA8IDApCiAJCQllcnIoMSwgIkNv dWxkIG5vdCBjcmVhdGUgc29ja2V0Iik7CiAKKwkJbWVtY3B5KCZidF9hZGRyX2FueSwgTkdfSENJ X0JEQUREUl9BTlksIHNpemVvZihidF9hZGRyX2FueSkpOworCiAJCW1lbXNldCgmbWEsIDAsIHNp emVvZihtYSkpOwogCQltYS5yZmNvbW1fbGVuID0gc2l6ZW9mKG1hKTsKIAkJbWEucmZjb21tX2Zh bWlseSA9IEFGX0JMVUVUT09USDsKKwkJbWVtY3B5KCZtYS5yZmNvbW1fYmRhZGRyLCAmYnRfYWRk cl9hbnksIHNpemVvZihidF9hZGRyX2FueSkpOwogCQltYS5yZmNvbW1fY2hhbm5lbCA9IGNoYW5u ZWw7CiAKIAkJaWYgKGJpbmQoYWNjZXB0c29jaywgKHN0cnVjdCBzb2NrYWRkciAqKSZtYSwgc2l6 ZW9mKG1hKSkgPCAwKQotCQkJZXJyKDEsICJDb3VsZCBub3QgYmluZCBzb2NrZXQgLS0gY2hhbm5l bCAlZCBpbiB1c2U/IiwKLQkJCSAgICBjaGFubmVsKTsKKwkJCWVycigxLCAiQ291bGQgbm90IGJp bmQgc29ja2V0IG9uIGNoYW5uZWwgJWQiLCBjaGFubmVsKTsKIAkJaWYgKGxpc3RlbihhY2NlcHRz b2NrLCAxMCkgIT0gMCkKIAkJCWVycigxLCAiQ291bGQgbm90IGxpc3RlbiBvbiBzb2NrZXQiKTsK IAorCQlhYWRkcmxlbiA9IHNpemVvZihtYSk7CisJCWlmIChnZXRzb2NrbmFtZShhY2NlcHRzb2Nr LCAoc3RydWN0IHNvY2thZGRyICopJm1hLCAmYWFkZHJsZW4pIDwgMCkKKwkJCWVycigxLCAiQ291 bGQgbm90IGdldCBzb2NrZXQgbmFtZSIpOworCQljaGFubmVsID0gbWEucmZjb21tX2NoYW5uZWw7 CisKIAkJc3MgPSBzZHBfb3Blbl9sb2NhbChOVUxMKTsKIAkJaWYgKHNzID09IE5VTEwpCiAJCQll cnJ4KDEsICJVbmFibGUgdG8gY3JlYXRlIGxvY2FsIFNEUCBzZXNzaW9uIik7CiAJCWlmIChzZHBf ZXJyb3Ioc3MpICE9IDApCiAJCQllcnJ4KDEsICJVbmFibGUgdG8gb3BlbiBsb2NhbCBTRFAgc2Vz c2lvbi4gJXMgKCVkKSIsCiAJCQkgICAgc3RyZXJyb3Ioc2RwX2Vycm9yKHNzKSksIHNkcF9lcnJv cihzcykpOwotCQltZW1zZXQoJmxhbiwgMCwgc2l6ZW9mKGxhbikpOwotCQlsYW4uc2VydmVyX2No YW5uZWwgPSBjaGFubmVsOworCQltZW1zZXQoJnNwLCAwLCBzaXplb2Yoc3ApKTsKKwkJc3Auc2Vy dmVyX2NoYW5uZWwgPSBjaGFubmVsOwogCi0JCW1lbWNweSgmYnRfYWRkcl9hbnksIE5HX0hDSV9C REFERFJfQU5ZLCBzaXplb2YoYnRfYWRkcl9hbnkpKTsKLQkJaWYgKHNkcF9yZWdpc3Rlcl9zZXJ2 aWNlKHNzLCBzZXJ2aWNlLCAmYnRfYWRkcl9hbnksCi0JCSAgICAodm9pZCAqKSZsYW4sIHNpemVv ZihsYW4pLCAmc2RwX2hhbmRsZSkgIT0gMCkgeworCQlpZiAoc2RwX3JlZ2lzdGVyX3NlcnZpY2Uo c3MsIFNEUF9TRVJWSUNFX0NMQVNTX1NFUklBTF9QT1JULAorCQkJCSZidF9hZGRyX2FueSwgKHZv aWQgKikmc3AsIHNpemVvZihzcCksCisJCQkJJnNkcF9oYW5kbGUpICE9IDApIHsKIAkJCWVycngo MSwgIlVuYWJsZSB0byByZWdpc3RlciBMQU4gc2VydmljZSB3aXRoICIKIAkJCSAgICAibG9jYWwg U0RQIGRhZW1vbi4gJXMgKCVkKSIsCiAJCQkgICAgc3RyZXJyb3Ioc2RwX2Vycm9yKHNzKSksIHNk cF9lcnJvcihzcykpOwo= ------=_Part_8614_29769232.1210697286687-- From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 17:05:21 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E818B1065672 for ; Tue, 13 May 2008 17:05:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1638FC15 for ; Tue, 13 May 2008 17:05:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so4650349fgb.35 for ; Tue, 13 May 2008 10:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=nyq5rf8MvRkQczbCRXoxNdUfN2yvsIFLeGTbhGo6osU=; b=d95pBsQU8K90+VOUxsCK4o407ox+7/aUIOYheqcii3DMvhCllplgvWOHUNMkJ08p/ji4ttfeumRTwhj+w1i7/NDSOa2t3PwgjdccbLWps8ReVc8fPHlk+j5RkevZ5EBA1yJ9+8Jvv2Km9uT/Qv6hL0KdbOOXr94UcgmhvwnhiIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ej8ThjOg5Qoz1VC7VYBFhf6HgDD/rBFELcnjmcsGwXWBZUjVy3HIZFHPZGQCt4seg9BE143nibg1C3Bv4tBTPSn+S5IdSj69j+5/itVDi4sGbX9g2OdQWiqEerPJnPefWZVRUDitw0oIEcDPkBUCpOjMWpBwbCQ+EN9OhMkgqeo= Received: by 10.86.90.2 with SMTP id n2mr662200fgb.51.1210698320091; Tue, 13 May 2008 10:05:20 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Tue, 13 May 2008 10:05:20 -0700 (PDT) Message-ID: Date: Tue, 13 May 2008 10:05:20 -0700 From: "Maksim Yevmenkin" To: "Helge Oldach" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-bluetooth@freebsd.org Subject: Re: rfcomm_sppd -S as generic wrapper X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 17:05:22 -0000 [...] > BTW, Luigi's pipe application is interesting, but what about true > two-way communcation? For instance, I would like to have something like > > # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" > > ...meaning: Upon receipt of a SP connection request from myPalm we would > fork coldsync to synchronize the Palm (just like USB or serial sync, but > now bluetooth). > > This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the > request terminates. well, i thought about this, but not really sure how to do it cleanly. here is what i mean. with rfcomm_pppd(8) (lan service wrapper) we only need to start one server and register one lan service with local sdpd(8). as soon as client connects to rfcomm_pppd(8) it forks and starts separate ppp(8) instance that handles this particular client. this model works well (imo) here. i'm not sure what rfcomm_sppd(8) wrapper behavior should be. what you seems to be suggesting is that a single rfcomm_sppd(8) instance can only handle single client at a time. this could be a reasonable assumption. > I'm currently doing this in two separate steps, first starting > rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. > So yes, this definitely works. also your idea about putting rfcomm_sppd(8) entries into /etc/ttys should work as it is, no? did you try to put rfcomm_sppd(8) into /etc/tty entry for the pseudo terminal (slave) part and run coldsync on mater pty? thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 17:42:32 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A00A3106570F for ; Tue, 13 May 2008 17:42:32 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from rigel.oldach.net (rigel.oldach.net [194.8.96.250]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3378FC49 for ; Tue, 13 May 2008 17:42:31 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (hmo.in-dsl.de [217.197.85.210]) by rigel.oldach.net (8.14.2/8.14.2/hmo30jul04) with ESMTP id m4DHgSnP077086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2008 19:42:29 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.14.2/8.14.2/hmo26jun05) with ESMTP id m4DHgRWO039970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 19:42:28 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.14.2/8.14.2/Submit/hmo26jun05) id m4DHgRUD039969; Tue, 13 May 2008 19:42:27 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Message-Id: <200805131742.m4DHgRUD039969@sep.oldach.net> In-Reply-To: from Maksim Yevmenkin at "13 May 2008 10:05:20" To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Date: Tue, 13 May 2008 19:42:27 +0200 (CEST) From: freebsd-bluetooth@oldach.net (Helge Oldach) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: rfcomm_sppd -S as generic wrapper X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 17:42:32 -0000 Maksim Yevmenkin wrote on Tue, 13 May 2008 19:05:20 +0200 (CEST): > > BTW, Luigi's pipe application is interesting, but what about true > > two-way communcation? For instance, I would like to have something like > > > > # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" > > > > ...meaning: Upon receipt of a SP connection request from myPalm we would > > fork coldsync to synchronize the Palm (just like USB or serial sync, but > > now bluetooth). > > > > This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the > > request terminates. > > well, i thought about this, but not really sure how to do it cleanly. > here is what i mean. with rfcomm_pppd(8) (lan service wrapper) we > only need to start one server and register one lan service with local > sdpd(8). as soon as client connects to rfcomm_pppd(8) it forks and > starts separate ppp(8) instance that handles this particular client. > this model works well (imo) here. > > i'm not sure what rfcomm_sppd(8) wrapper behavior should be. what you > seems to be suggesting is that a single rfcomm_sppd(8) instance can > only handle single client at a time. this could be a reasonable > assumption. Good point. However rfcomm_sppd can distinguish different BT peers already, wouldn't that work by starting a separate rfcomm_sppd for each BT peer? > > I'm currently doing this in two separate steps, first starting > > rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. > > So yes, this definitely works. > > also your idea about putting rfcomm_sppd(8) entries into /etc/ttys > should work as it is, no? did you try to put rfcomm_sppd(8) into > /etc/tty entry for the pseudo terminal (slave) part and run coldsync > on mater pty? Yes, it works. But I'd also have coldsync in /etc/ttys, similar to palm "/usr/local/bin/coldsync -t serial -s -md" unknown on Hmm. Thinking about it, indeed in my case coldsync is the "getty replacement". Putting rfcomm_sppd into /etc/ttys is merely a hack, working around the fact that it terminates after each session. So rfcomm_sppd should probably have some "service selection" mechanism, similar to what pppd does. I know I could do my Palm sync task running network sync via TCP via PPP, however that's a fair bit of overhead. PalmOS can talk serial natively, so why not use that straight away? Actually "network sync" is essentially a 1:1 copy of serial sync (which was invented first), as is USB sync. Regards, Helge From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 17:43:50 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D135106567B for ; Tue, 13 May 2008 17:43:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id E2B9C8FC16 for ; Tue, 13 May 2008 17:43:49 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so4661964fgb.35 for ; Tue, 13 May 2008 10:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=x75OlY09q8eJ235HWVuinlb0rEL0AAsAA9qrvVb2JiM=; b=tz4W/Xb4VNEcHFguNQmgtglwVLe8hdQYkPHeoDHSRkknMMYQo9v4Sor4CARu7z2CV7Y9YjEXg2CBpHnHDYHUsXO0e/SJnZoEjwjo5afn4AMEeWGPX1b9ocvxSRJ23ISFwPPPG2GCd2uRqE9HisplN5AF9xJeUJNDmsIDtthbg+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Of4XRTG0tNRO0aCAGWyHFwJJB1LulRMxRqADYTJq5JjDeheQeO94HTu8SM17/JKEMGs8V4Y/Ve7HnlI0XYX2mFnM5Pfh+eVEhb7YgY72i7+TPANqe2cyWlCLypb852cVwsD6/HdCyOs1+EqMbsyI5OQddMWvTCzFDX8nzod37mQ= Received: by 10.86.90.2 with SMTP id n2mr68363fgb.51.1210700619076; Tue, 13 May 2008 10:43:39 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Tue, 13 May 2008 10:43:39 -0700 (PDT) Message-ID: Date: Tue, 13 May 2008 10:43:39 -0700 From: "Maksim Yevmenkin" To: "freebsd-bluetooth@freebsd.org" , mad@madpilot.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: obexapp 1.4.9 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 17:43:50 -0000 hello, obexapp 1.4.9 was uploaded at http://www.geocities.com/m_evmenkin/obexapp-1.4.9.tar.gz the only (minor) change is work around for dirname(3). some implementations may modify string passed to dirname(3) therefor do not assume const pointer argument in dirname(3) and always pass a local copy. this is done to be compatible with netbsd. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 19:44:48 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F25C106566C for ; Tue, 13 May 2008 19:44:48 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from rigel.oldach.net (rigel.oldach.net [194.8.96.250]) by mx1.freebsd.org (Postfix) with ESMTP id B358B8FC1E for ; Tue, 13 May 2008 19:44:47 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (hmo.in-dsl.de [217.197.85.210]) by rigel.oldach.net (8.14.2/8.14.2/hmo30jul04) with ESMTP id m4DJiiiM090469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2008 21:44:45 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.14.2/8.14.2/hmo26jun05) with ESMTP id m4DJihAV002591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 21:44:43 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.14.2/8.14.2/Submit/hmo26jun05) id m4DJieQL002589; Tue, 13 May 2008 21:44:40 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Message-Id: <200805131944.m4DJieQL002589@sep.oldach.net> In-Reply-To: from Maksim Yevmenkin at "13 May 2008 09:48:06" To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Date: Tue, 13 May 2008 21:44:40 +0200 (CEST) From: freebsd-bluetooth@oldach.net (Helge Oldach) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, rizzo@iet.unipi.it Subject: Re: any reason to require -t dev in rfcomm_sppd -S ? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 19:44:48 -0000 Maksim Yevmenkin wrote on Tue, 13 May 2008 18:48:06 +0200 (CEST): > On Tue, May 13, 2008 at 8:52 AM, Helge Oldach wrote: > > Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST): > >> 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 ? > >> > > > >> > > 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). > > > > Your patch applies cleanly, but I just get > > > > # rfcomm_sppd -S > > rfcomm_sppd: Could not get socket name > > # > > > > It seems that getsockbyname fails. What is the reason for that anyway? > > well, there is a problem with my previous patch. please try the > attached updated patch. Oops, the case is pretty clear. I should have seen that myself. All is fine with this patch. Helge From owner-freebsd-bluetooth@FreeBSD.ORG Wed May 14 16:55:53 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA37106564A for ; Wed, 14 May 2008 16:55:53 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 63D9B8FC14 for ; Wed, 14 May 2008 16:55:51 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so5107113fgb.35 for ; Wed, 14 May 2008 09:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nsH+XzqAbH4HFMDdV8VTpJ+ETw5ppTnSMUDzF2UsWE0=; b=F1nUOEl3/mnoo96hqF4hsobIkzdMoDnQFPKJTiK7bsTheM9/RY8MYZarfPvbSPcSCb2O7mdkO8LnviQwvzKaVtz0XP3DC2v8Ci9vNB5xRt6nHgUDiCSgjClGkXloH7nAEA8blKtD+K79dvCBNqLP6lJN+Apg33fvrbHgL4HJ+/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tMfLfvyDk1Y/fCwEtI6gqPhkdN4xemOJhE74/PYeoDaG/9n3Mewy/P+oZEV+JthFaYNwi3eCxeSmTVb9PtcShKwKT3cZ7kYhF7uKfDzh3L7ZbOdL+q4jAcahW69fP1L4ys2TmIc5FXQlCBtd5BX6M/j7tjIp90aOQYCRP7+uH/4= Received: by 10.125.131.7 with SMTP id i7mr603907mkn.96.1210784149641; Wed, 14 May 2008 09:55:49 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Wed, 14 May 2008 09:55:49 -0700 (PDT) Message-ID: Date: Wed, 14 May 2008 09:55:49 -0700 From: "Maksim Yevmenkin" To: "Helge Oldach" In-Reply-To: <200805131944.m4DJieQL002589@sep.oldach.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200805131944.m4DJieQL002589@sep.oldach.net> Cc: freebsd-bluetooth@freebsd.org, rizzo@iet.unipi.it Subject: Re: any reason to require -t dev in rfcomm_sppd -S ? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 16:55:54 -0000 [...] >> > Your patch applies cleanly, but I just get >> > >> > # rfcomm_sppd -S >> > rfcomm_sppd: Could not get socket name >> > # >> > >> > It seems that getsockbyname fails. What is the reason for that anyway? >> >> well, there is a problem with my previous patch. please try the >> attached updated patch. > > Oops, the case is pretty clear. I should have seen that myself. > > All is fine with this patch. i've just committed the patch. thanks for your help. max From owner-freebsd-bluetooth@FreeBSD.ORG Thu May 15 13:58:01 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 038D51065670 for ; Thu, 15 May 2008 13:58:01 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 851C88FC15 for ; Thu, 15 May 2008 13:58:00 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so330845fkk.11 for ; Thu, 15 May 2008 06:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Y2mxtrdeGNlq0d2M/YISQOMY4Rdo3XtUkzhvmobDFx0=; b=u/PHp/WB/njSKesepsmDrAgyN9Xu26AvbS6ANvc8VlGUiq8TtnNjXC5RPRjPmMYh5gmsmqnjl/YIEgafoUgg5VmmD0lS949WzOD/iyCla57976gvyuJbiFC6+jwHVLaEd8GPbVkch7bP9gYLNCrmQpGtKDlODGju7hoycv6PTaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O1x2HbbRq8iBO1S7UVebQm3/+FWWiO/xUNSgdFjjigaSzUK4+6OO5VWfYDzdhlTifoYZFS2nycsU+608e3lnEeIfdWuI+yLGTSpXAR3QXHH7oXu5WQxhie/Q+ysA+2Ez4bG0N4H+V7nviXD/aS50pqTwghsWQGkNokJmicHLYH0= Received: by 10.124.46.8 with SMTP id t8mr1349320mkt.149.1210859879243; Thu, 15 May 2008 06:57:59 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Thu, 15 May 2008 06:57:59 -0700 (PDT) Message-ID: Date: Thu, 15 May 2008 06:57:59 -0700 From: "Maksim Yevmenkin" To: "Daniel O'Connor" In-Reply-To: <200805151814.14386.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805151814.14386.doconnor@gsoft.com.au> Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2008 13:58:01 -0000 [moving to freebsd-bluetooth@] On 5/15/08, Daniel O'Connor wrote: > On Thu, 15 May 2008, Maksim Yevmenkin wrote: > > Modified files: > > usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c > > Log: > > Make -t optional in server mode. If not specified use > > stdin/stdout. Document this. Do not require channel number in server > > mode. If not specified - bind to ''wildcard'' channel zero. Real > > channel number will be obtained automatically and registered with > > local sdpd(8). While I'm here fix serial port service registration. > > How hard would it be to have a '-t auto' and have it print out the pty > it just allocated? It would make it much easier for scripts to work if > that was possible. > > (Maybe just call openpty()?) not hard at all. however, how would rfcomm_sppd(1) print tty name if, say, it was asked to run in background? perhaps it would be better to teach rfcomm_sppd(1) to work with nmdm(4)? thanks, max