Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 May 2008 10:05:20 -0700
From:      "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com>
To:        "Helge Oldach" <freebsd-bluetooth@oldach.net>
Cc:        freebsd-bluetooth@freebsd.org
Subject:   Re: rfcomm_sppd -S as generic wrapper
Message-ID:  <bb4a86c70805131005h3bad26bh99a3288150deeb5@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
[...]

> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70805131005h3bad26bh99a3288150deeb5>