Date: Tue, 13 May 2008 19:42:27 +0200 (CEST) From: freebsd-bluetooth@oldach.net (Helge Oldach) To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Cc: freebsd-bluetooth@freebsd.org Subject: Re: rfcomm_sppd -S as generic wrapper Message-ID: <200805131742.m4DHgRUD039969@sep.oldach.net> In-Reply-To: <bb4a86c70805131005h3bad26bh99a3288150deeb5@mail.gmail.com> from Maksim Yevmenkin at "13 May 2008 10:05:20"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805131742.m4DHgRUD039969>