Andrey Vihrov | 3 Jan 19:24 2014
Picon

A problem with "rfcomm bind" and wvdial

Hello,

I'm writing to this mailing list because I was told on IRC that it's the
best place to discuss Linux Bluetooth problems, and I want to report
one.

I have a Nokia N70 phone which I use as a modem through Bluetooth. Up
until recently (~half a year ago), my workflow to establish a connection
was to

a) Call "rfcomm bind /dev/rfcomm0 <addr> <channel>" at system start (in
the past I also used /etc/bluetooth/rfcomm.conf, but that stopped
working at some point)
b) Run wvdial, which will open /dev/rfcomm0 as a modem/serial port

Now, however, when I run wvdial, I get

  Cannot open /dev/rfcomm0: Transport endpoint is not connected

I have found empirically that if I use "rfcomm connect" instead of
"rfcomm bind", and then run wvdial, then it works fine. Thus, it would
seem that the connection is not established automatically when an
application opens /dev/rfcomm0.

I have reproduced this on Arch Linux with BlueZ 5.13 and the
linux-bluetooth kernel. I'm also attaching logs of bluetoothd, btmon and
hcidump at the moment when wvdial is run.

Regarding the btmon log, I've observed that wvdial reports the
"Transport endpoint is not connected" error nearly at the same time as
(Continue reading)

Gianluca Anzolin | 5 Jan 16:49 2014
Picon

Re: A problem with "rfcomm bind" and wvdial

Hello,

I looked at your problem this afternoon and I think I know what's happening:
wvdial is opening the port with the flag O_NONBLOCK. As expected the rfcomm
code returns immediately instead of waiting for the BT connection to come
up. Then wvdial sends the AT commands and the writes fail.

In the past it worked because the carrier_raised() logic was open coded inside
the rfcomm code: it always waited for a successful or failed connection even
with a non-blocking tty.

But now the code uses the tty_port methods and won't wait for a successful
bluetooth connection on open().

But there is more: when wvdial terminates, it will set the CLOCAL flag for the
tty and this will result in the same behaviour described above, even without
setting the O_NONBLOCK flag. This will affect other users of the tty.

These two cases make clear that the use of carrier_raised() method was not that
fair after all: while that allowed us to remove some code we now have to work
around it to get the previous behaviour.

For example we could mask off the O_NONBLOCK flag before opening the port and
then restore it when the tty_port_open() is completed. We could do something
similar for the CLOCAL flag: always remove it in rfcomm_tty_set_termios().

The alternative is to remove the carrier_raised() method and wait for the BT
connection in rfcomm_dev_activate() like the old code did.

I'm CC-ing some people who know the code better than me to get a suggestion
(Continue reading)

Gianluca Anzolin | 6 Jan 12:33 2014
Picon

Re: A problem with "rfcomm bind" and wvdial

On Sun, Jan 05, 2014 at 04:49:42PM +0100, Gianluca Anzolin wrote:
> Hello,
> 
> I looked at your problem this afternoon and I think I know what's happening:
> wvdial is opening the port with the flag O_NONBLOCK. As expected the rfcomm
> code returns immediately instead of waiting for the BT connection to come
> up. Then wvdial sends the AT commands and the writes fail.

Hi,

could you please test the attached patch?

If it works and people are ok with it I'll submit it along with the other fixes
I already sent to the list.

Thank you,
Gianluca
Andrey Vihrov | 6 Jan 17:06 2014
Picon

Re: A problem with "rfcomm bind" and wvdial

Hello,

Thanks for the update. I applied the patch to the bluetooth-next
kernel and it seems to work as expected. I ran wvdial several times in a
row, and it was able to connect every time.

> On Sun, Jan 05, 2014 at 04:49:42PM +0100, Gianluca Anzolin wrote:
> > Hello,
> > 
> > I looked at your problem this afternoon and I think I know what's happening:
> > wvdial is opening the port with the flag O_NONBLOCK. As expected the rfcomm
> > code returns immediately instead of waiting for the BT connection to come
> > up. Then wvdial sends the AT commands and the writes fail.
> 
> Hi,
> 
> could you please test the attached patch?
> 
> If it works and people are ok with it I'll submit it along with the other fixes
> I already sent to the list.
> 
> Thank you,
> Gianluca

--

-- 
Andrey Vihrov <andrey.vihrov@...>


Gmane