Hi Gustavo and Denis.
On 15/06/2012 01:09, Denis Kenzior wrote:
Hi Gustavo,
ofonod[20340]: plugins/udevng.c:remove_device()
/sys/devices/virtual/tty/rfcomm0
ofonod[20340]: plugins/udev.c:remove_modem()
/devices/virtual/tty/rfcomm0
Actually this looks highly suspicious to me. What would still be
using RFCOMM tty emulation?
Does this work when you try to connect from a different DUN Client, like
dundee, or even trying to open the RFCOMM channel by hand using the
rfcomm
tool?
An sdptool dump before starting oFono would be useful as well.
Thanks for your help both of you.
I have investigated deeper into this issue with Frédéric Danis, and we
have found that Bluez is publishing a Dial Up Networking Service,
although oFono is not launched.
Service Name: Dial-up Networking
Service RecHandle: 0x10006
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
When I launch also oFono I have 2 DUN services.
When I try to connect with DUN client it seems we are passing through
BlueZ DUN service and not the oFono one.
This is explaining the traces with rfcomm0 I have sent.
So DUN service is published by BlueZ using pnat plugin.
The workaround I have found to test oFono DUN server is to disable the
plugin into BlueZ and then oFono DUN server is working fine.
Now I still don't understand how I could have tested it properly one
year ago without this workaround.
Kind regards,
Guillaume
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
