From: Daniel Wagner <daniel.wag...@bmw-carit.de>
Hi,
This is the 3rd attempt to get DUN done (pun!). The first and second
attempt was to expose DUN devices through the oFono API. While this
sounds like a reasonable way to go it has some - let's put it
this way - ugliness involved.
- No SIM interface: This is not so bad but still we have to hack around
this problem. Since we need some uniqueness to distinguish between
services, the Serial property of the Modem interface has to be
abused for this.
- No NetworkRegistration interface: DUN only specifies ATD*99# AT command.
All other AT commands might be supported (such as AT+COPS=?) but are not
necessarily there. That means we might not get a name for a network. Whereas
you can rely to get this name for a regular modem you can't on DUN ones.
And guess what you cannot distinguish between real hardware modems and
virtual ones unless...
- Abuse Modem.Type: ... add 'dun' type and adapt the oFono plugin. That
_is_ though a very bad idea. We just introduce a mighty switch for
different oFono API behavior. Denis used strong words against this
approach.
- oFono internal design: oFono is not designed to handle this kind
of modems. The dunmodem implementation is rather obscure. The result
of this is that, as soon as a DUN device pops up, an Serial channel is
opened (rfcomm) and kept alive. Unfortunately, there are phones outside
in the wild which like to close the serial link after PPP stops.
With oFono's separation of concerns this is not easy to get working.
- Technology mess: In order to get DUN modems working you have to enable
Cellular
and Bluetooth technology. This is really really bad because we expose
the implementation details to the user. Sure, DUN is kind of dying etc.
but then, I don't think our standards are so low.
So these were the reason to try another way to solve this. Denis proposed
to create a simple DUN daemon which lives inside oFono's tree. It just
handles DUN devices. I have implemented this daemon which goes by the
name Elect. This patch series adds support for Elect to ConnMan.
Overall, this approach seems the most reasonable. The code is already quite
stable and even with the phone I test it works really stable. This phone is
known to have some strange behavior.
The API exposed by Elect is similar to the one of oFono:
Manager hierarchy
=================
Service org.ofono.elect
Interface org.ofono.elect.Manager
Object path /
Methods array{object,dict} GetDevices()
Get an array of device objects and properties
that represent the currently attached devices.
This method call should only be used once when an
application starts up. Further device additions
and removal shall be monitored via DeviceAdded and
DeviceRemoved signals.
Signals DeviceAdded(object path, dict properties)
Signal that is sent when a new device is added. It
contains the object path of new device and its
properties.
DeviceRemoved(object path)
Signal that is sent when a device has been removed.
The object path is no longer accessible after this
signal and only emitted for reference.
Device hierarchy
================
Service org.ofono.elect
Interface org.ofono.elect.Device
Object path [variable prefix]/{device0,device1,...}
Methods dict GetProperties()
Returns properties for the device object. See
the properties section for available properties.
Connect()
Establish a connection.
Disconnect()
Tear down a connection.
Signals PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
property.
Properties string Name [readonly]
Friendly name of the device.
boolean Active [readwrite]
Holds whether the device is connected.
dict Settings [readonly]
Holds all the IP network settings.
string Interface [readonly, optional]
Holds the interface of the network interface
used by this context (e.g. "ppp0" "usb0").
string Method [readonly, optional]
Holds the IP network config method.
"static"- Set IP network statically
"dhcp" - Set IP network through DHCP
string Address [readonly, optional]
Holds the IP address for this context.
string Netmask [readonly, optional]
Holds the Netmask for this context.
array{string} DomainNameServers [readonly, optional]
Holds the list of domain name servers for this
context.
I am posting the Elect daemon patches to the oFono mailing list. I guess
they will require some updates before they will be accepted. For example
we might want to expose the BDADDR in this API. Currently the device
object path contains the BDADDR but should go away.
Overall I have to say this approach is really nice. All stuff works
pretty good and no hacks are involved. Finally we even can make use of
the device->probe() hooks!
cheers,
daniel
Daniel Wagner (12):
elect: Add emply plugin
elect: Watch service on D-Bus
elect: Monitor DeviceAdded/DeviceRemoved signal
elect: Get modems when starting
elect: Parse device properties in add_device
elect: Create connman device
elect: Monitor Device.PropertyChanged signal
elect: Register connman network at core
elect: Update network connected status
elect: Add Connect()/Disconnect()
elect: Check ownership of device
bluetooth: Check ownership of device
Makefile.am | 1 +
Makefile.plugins | 13 +
bootstrap-configure | 1 +
configure.ac | 6 +
plugins/bluetooth.c | 17 +-
plugins/elect.c | 875 +++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 912 insertions(+), 1 deletions(-)
create mode 100644 plugins/elect.c
--
1.7.8.110.g4cb5d1
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
