RFCOMM Remote Port Negotiation

RFCOMM Remote Port Negotiation

[Andrea Galbusera]

Hello list,

This days I have been thinking about a project, which involves
replacing a serial cable with a bluetooth based solution. Nothing new,
you'd say and that's exactly what I thought at first. Than I had to
face this fact. Such an application involves communication between two
host over a serial connection with a baudrate that changes over time.
What I need is a "fully transparent" replacement for a serial cable
and it needs to be compatible with the current software.

I know RFCOMM standard does provide multiplexor frames and RPN
commands in particular, which allow for remote bluetooth device to be
aware of any change in serial communication parameters on the other
side. It also became pretty clear to me that what I'm supposed to
realize is an RFCOMM Type 2 device. According to RFCOMM specification,
a Type 2 device is an intermediate device that has a physical RS-232
serial port on top of RFCOMM.

My question is? How would one implement such a thing with Linux? I'm
not a kernel expert at all but, if my understanding is correct,
rfcomm_recv_rpn() function in net/bluetooth/rfcomm/core.c is designed
to reply to RPN frames (as required by the protocol specification) but
does not provide any mechanism to signal other layers (maybe the tty
device) of any remote request for changing port settings. Is my
understanding correct? Does this mean that Linux RFCOMM kernel layer
is currently designed for Type 1 devices only?

Even thinking to a user space solution for my problem does not seem
easy at all to me. When the remote host changes line settings, RFCOMM
layer will send RPN command accordingly (linux does so when changing
tty settings). How to get such an information on the other side if
rfcomm_recv_rpn() does, in fact, short-circuit RPN commands in the
kernel?

I'm quite surprised no one ever had this requirement! I couldn't find
much about RPN in the list archives and even on google. Also I noticed
that many bluetooth-serial adapters on the market do behave the same
way Linux does, and they simply reply to RPN without carrying out any
request to change settings on their serial port. This could mean I'm
completely on a wrong path!

Please! I ask you, bluetooth gurus, to improve my understanding, if
possible. If in the end you do think reasonable any extension to the
current kernel implementation, which take into account such a
scenario, I'd be glad to participate and help.

Thank you in advance
Regards,
AndreA

Re: RFCOMM Remote Port Negotiation

[Marcel Holtmann]

Hi Andrea,

> This days I have been thinking about a project, which involves
> replacing a serial cable with a bluetooth based solution. Nothing new,
> you'd say and that's exactly what I thought at first. Than I had to
> face this fact. Such an application involves communication between two
> host over a serial connection with a baudrate that changes over time.
> What I need is a "fully transparent" replacement for a serial cable
> and it needs to be compatible with the current software.
> 
> I know RFCOMM standard does provide multiplexor frames and RPN
> commands in particular, which allow for remote bluetooth device to be
> aware of any change in serial communication parameters on the other
> side. It also became pretty clear to me that what I'm supposed to
> realize is an RFCOMM Type 2 device. According to RFCOMM specification,
> a Type 2 device is an intermediate device that has a physical RS-232
> serial port on top of RFCOMM.
> 
> My question is? How would one implement such a thing with Linux? I'm
> not a kernel expert at all but, if my understanding is correct,
> rfcomm_recv_rpn() function in net/bluetooth/rfcomm/core.c is designed
> to reply to RPN frames (as required by the protocol specification) but
> does not provide any mechanism to signal other layers (maybe the tty
> device) of any remote request for changing port settings. Is my
> understanding correct? Does this mean that Linux RFCOMM kernel layer
> is currently designed for Type 1 devices only?
> 
> Even thinking to a user space solution for my problem does not seem
> easy at all to me. When the remote host changes line settings, RFCOMM
> layer will send RPN command accordingly (linux does so when changing
> tty settings). How to get such an information on the other side if
> rfcomm_recv_rpn() does, in fact, short-circuit RPN commands in the
> kernel?
> 
> I'm quite surprised no one ever had this requirement! I couldn't find
> much about RPN in the list archives and even on google. Also I noticed
> that many bluetooth-serial adapters on the market do behave the same
> way Linux does, and they simply reply to RPN without carrying out any
> request to change settings on their serial port. This could mean I'm
> completely on a wrong path!
> 
> Please! I ask you, bluetooth gurus, to improve my understanding, if
> possible. If in the end you do think reasonable any extension to the
> current kernel implementation, which take into account such a
> scenario, I'd be glad to participate and help.

the only way this works is with the RFCOMM TTY support anyway. Since
with the RFCOMM socket we do not have any of these signals.

To be honest here, nobody ever cared about this old fashion real serial
emulation. So you need to implement the hooks between the Linux TTY
layer and Bluetooth RFCOMM TTY support to make this work.

One thing that might will make this fail is the complicated looking in
the TTY layer and the way how certain things are executed in interrupt
context. So good luck here.

Regards

Marcel

Re: RFCOMM Remote Port Negotiation

[Andrea Galbusera]

Hi Marcel,

On Fri, Nov 25, 2011 at 12:46 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Andrea,
>
>> This days I have been thinking about a project, which involves
>> replacing a serial cable with a bluetooth based solution. Nothing new,
>> you'd say and that's exactly what I thought at first. Than I had to
>> face this fact. Such an application involves communication between two
>> host over a serial connection with a baudrate that changes over time.
>> What I need is a "fully transparent" replacement for a serial cable
>> and it needs to be compatible with the current software.
>>
>> I know RFCOMM standard does provide multiplexor frames and RPN
>> commands in particular, which allow for remote bluetooth device to be
>> aware of any change in serial communication parameters on the other
>> side. It also became pretty clear to me that what I'm supposed to
>> realize is an RFCOMM Type 2 device. According to RFCOMM specification,
>> a Type 2 device is an intermediate device that has a physical RS-232
>> serial port on top of RFCOMM.
>>
>> My question is? How would one implement such a thing with Linux? I'm
>> not a kernel expert at all but, if my understanding is correct,
>> rfcomm_recv_rpn() function in net/bluetooth/rfcomm/core.c is designed
>> to reply to RPN frames (as required by the protocol specification) but
>> does not provide any mechanism to signal other layers (maybe the tty
>> device) of any remote request for changing port settings. Is my
>> understanding correct? Does this mean that Linux RFCOMM kernel layer
>> is currently designed for Type 1 devices only?
>>
>> Even thinking to a user space solution for my problem does not seem
>> easy at all to me. When the remote host changes line settings, RFCOMM
>> layer will send RPN command accordingly (linux does so when changing
>> tty settings). How to get such an information on the other side if
>> rfcomm_recv_rpn() does, in fact, short-circuit RPN commands in the
>> kernel?
>>
>> I'm quite surprised no one ever had this requirement! I couldn't find
>> much about RPN in the list archives and even on google. Also I noticed
>> that many bluetooth-serial adapters on the market do behave the same
>> way Linux does, and they simply reply to RPN without carrying out any
>> request to change settings on their serial port. This could mean I'm
>> completely on a wrong path!
>>
>> Please! I ask you, bluetooth gurus, to improve my understanding, if
>> possible. If in the end you do think reasonable any extension to the
>> current kernel implementation, which take into account such a
>> scenario, I'd be glad to participate and help.
>
> the only way this works is with the RFCOMM TTY support anyway. Since
> with the RFCOMM socket we do not have any of these signals.
> To be honest here, nobody ever cared about this old fashion real serial
> emulation.

In the industry we still have many application where, till this days,
the only available interface was the serial cable.
My primary interest is in metering, where laptops are being replaced
by smartphones and small netbooks in the toolboxes of technicians that
have to interface to metering devices on the field. In the case of
smartphones, even usb might not be an option. Hence my company, that
in the past designed serial cable based probes is now about to provide
a bluetooth based replacement for that.

> So you need to implement the hooks between the Linux TTY
> layer and Bluetooth RFCOMM TTY support to make this work.

As said, my experience in kernel development is not that much yet and
TTY things are scaring me a lot. However, your clarification is useful
to confirm that TTY should be the direction to look at.
Do you know of any other kernel layer with similar needs to notify TTY
of property changes?

> One thing that might will make this fail is the complicated looking in
> the TTY layer and the way how certain things are executed in interrupt
> context. So good luck here.

Any idea who could help here suggesting if this could fit somehow in
linux TTY layer?

Best regards,
Andrea

Re: RFCOMM Remote Port Negotiation

[Marcel Holtmann]

Hi Andrea,

> >> This days I have been thinking about a project, which involves
> >> replacing a serial cable with a bluetooth based solution. Nothing new,
> >> you'd say and that's exactly what I thought at first. Than I had to
> >> face this fact. Such an application involves communication between two
> >> host over a serial connection with a baudrate that changes over time.
> >> What I need is a "fully transparent" replacement for a serial cable
> >> and it needs to be compatible with the current software.
> >>
> >> I know RFCOMM standard does provide multiplexor frames and RPN
> >> commands in particular, which allow for remote bluetooth device to be
> >> aware of any change in serial communication parameters on the other
> >> side. It also became pretty clear to me that what I'm supposed to
> >> realize is an RFCOMM Type 2 device. According to RFCOMM specification,
> >> a Type 2 device is an intermediate device that has a physical RS-232
> >> serial port on top of RFCOMM.
> >>
> >> My question is? How would one implement such a thing with Linux? I'm
> >> not a kernel expert at all but, if my understanding is correct,
> >> rfcomm_recv_rpn() function in net/bluetooth/rfcomm/core.c is designed
> >> to reply to RPN frames (as required by the protocol specification) but
> >> does not provide any mechanism to signal other layers (maybe the tty
> >> device) of any remote request for changing port settings. Is my
> >> understanding correct? Does this mean that Linux RFCOMM kernel layer
> >> is currently designed for Type 1 devices only?
> >>
> >> Even thinking to a user space solution for my problem does not seem
> >> easy at all to me. When the remote host changes line settings, RFCOMM
> >> layer will send RPN command accordingly (linux does so when changing
> >> tty settings). How to get such an information on the other side if
> >> rfcomm_recv_rpn() does, in fact, short-circuit RPN commands in the
> >> kernel?
> >>
> >> I'm quite surprised no one ever had this requirement! I couldn't find
> >> much about RPN in the list archives and even on google. Also I noticed
> >> that many bluetooth-serial adapters on the market do behave the same
> >> way Linux does, and they simply reply to RPN without carrying out any
> >> request to change settings on their serial port. This could mean I'm
> >> completely on a wrong path!
> >>
> >> Please! I ask you, bluetooth gurus, to improve my understanding, if
> >> possible. If in the end you do think reasonable any extension to the
> >> current kernel implementation, which take into account such a
> >> scenario, I'd be glad to participate and help.
> >
> > the only way this works is with the RFCOMM TTY support anyway. Since
> > with the RFCOMM socket we do not have any of these signals.
> > To be honest here, nobody ever cared about this old fashion real serial
> > emulation.
> 
> In the industry we still have many application where, till this days,
> the only available interface was the serial cable.
> My primary interest is in metering, where laptops are being replaced
> by smartphones and small netbooks in the toolboxes of technicians that
> have to interface to metering devices on the field. In the case of
> smartphones, even usb might not be an option. Hence my company, that
> in the past designed serial cable based probes is now about to provide
> a bluetooth based replacement for that.
> 
> > So you need to implement the hooks between the Linux TTY
> > layer and Bluetooth RFCOMM TTY support to make this work.
> 
> As said, my experience in kernel development is not that much yet and
> TTY things are scaring me a lot. However, your clarification is useful
> to confirm that TTY should be the direction to look at.
> Do you know of any other kernel layer with similar needs to notify TTY
> of property changes?
> 
> > One thing that might will make this fail is the complicated looking in
> > the TTY layer and the way how certain things are executed in interrupt
> > context. So good luck here.
> 
> Any idea who could help here suggesting if this could fit somehow in
> linux TTY layer?

we do already support TTY emulation for RFCOMM. That has been there for
ages and is actually well tested. It is just that we did not bother to
go all the way in trying to emulate a real serial cable. Especially when
it comes to RPN.

You might need to look by yourself or find a contractor that does this
for you. I can point you in a view directions if you don't wanna do it
by yourself, but are willing to invest money to get this done. And
honestly, I don't see anybody doing this just for fun.

Regards

Marcel