Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: Tether WiFi to cellular modem uplink (Patrik Flykt)
2. RE: Tethering bridge interface (Blanquicet-Melendez Jose (MM))
3. Re: Using connman with multiple active interfaces (Lukasz Nowak)
4. Re: Tether WiFi to cellular modem uplink (Evade Flow)
----------------------------------------------------------------------
Message: 1
Date: Tue, 13 Dec 2016 12:55:46 +0200
From: Patrik Flykt <[email protected]>
To: Evade Flow <[email protected]>, [email protected]
Subject: Re: Tether WiFi to cellular modem uplink
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, 2016-12-08 at 18:00 -0500, Evade Flow wrote:
> I guess I should start by confessing that I was completely mystified
> by ofono, so I gave up trying to use it to configure the modem
> connection. Instead, I wrote some udev rules that do (more-or-less)
> the following:
>
> ? ? ip link set eth0 down
> ? ? qmi-cli -p -d /dev/cdc-wdm0 --wda-set-data-format=802-3
> ? ? qmicli -p -d /dev/cdc-wdm0 --wds-start-network=apn=fast.t-
> mobile.com --client-no-release-cid
> ? ? killall -TERM dhclient
> ? ? dhclient wwan0
> ? ? ip link set eth0 up
This then means that oFono is not working. No oFono, no cellular uplink
connection in ConnMan either.
> This 'works' in the sense that the routing table is correct
> ? ?
> embedded-dev $ connmanctl tether wifi enable
> ? ? Enabled tethering for wifi
So far so good.
> I suspect this is because connman knows *nothing* about the cellular
> connection:
>
> ? ? $ # These commands were run back on the embedded device:
> ? ? $ connmanctl technologies
> ? ? /net/connman/technology/p2p
> ? ? ? Name = P2P
> ? ? ? Type = p2p
> ? ? ? Powered = False
> ? ? ? Connected = False
> ? ? ? Tethering = False
> ? ? ? TetheringAt5ghz = False
> ? ? /net/connman/technology/bluetooth
> ? ? ? Name = Bluetooth
> ? ? ? Type = bluetooth
> ? ? ? Powered = True
> ? ? ? Connected = False
> ? ? ? Tethering = False
> ? ? ? TetheringAt5ghz = False
> ? ? /net/connman/technology/wifi
> ? ? ? Name = WiFi
> ? ? ? Type = wifi
> ? ? ? Powered = True
> ? ? ? Connected = False
> ? ? ? Tethering = True
> ? ? ? TetheringIdentifier = myapn
> ? ? ? TetheringPassphrase = myapnpasswd
> ? ? ? TetheringAt5ghz = False
> ? ? /net/connman/technology/ethernet
> ? ? ? Name = Wired
> ? ? ? Type = ethernet
> ? ? ? Powered = True
> ? ? ? Connected = True
> ? ? ? Tethering = False
> ? ? ? TetheringAt5ghz = False
There is no 'cellular' technology here so thus no cellular uplink. The
problem is that oFono wasn't properly configured, so there is no
cellular connection in use, neither a technology that should have shown
up in the first place.
Cheers,
Patrik
------------------------------
Message: 2
Date: Tue, 13 Dec 2016 11:02:15 +0000
From: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
To: Patrik Flykt <[email protected]>
Cc: "[email protected]" <[email protected]>, Daniel Wagner
<[email protected]>
Subject: RE: Tethering bridge interface
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> -----Original Message-----
> From: Patrik Flykt [mailto:[email protected]]
> Sent: mercoled? 7 dicembre 2016 15:04
> To: Daniel Wagner; Blanquicet-Melendez Jose (MM); [email protected]
> Subject: Re: Tethering bridge interface
>
> On Tue, 2016-12-06 at 09:33 +0100, Daniel Wagner wrote:
> > Hi,
> >
> > On 12/05/2016 04:57 PM, Blanquicet-Melendez Jose (MM) wrote:
> > > We continue studying how tethering is implemented and we were
> > > wondering what is the purpose of creating the bridge interface
> > > "tether". For instance, hostapd does not do this thus it seems to
> > > not be strictly mandatory.
> >
> > I don't know the answer here, but I suspect it has something to do
> > that we also support BT and that might need it.
>
> When tethering, we want to connect all technologies together into one
> network be they Bluetooth, ethernet, WiFi or anything else. Works without
> an uplink interface too and has only one knob 'Tethering'
> turned on for those network technologies we want to share the possible
> uplink connection with.
Understood. Thanks both for the support.
Cheers,
Jose
VISITA IL NOSTRO SITO WEB! - VISIT OUR WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain
proprietary, confidential and/or legally protected information and is intended
solely for the use of the designated addressee(s) above. If you are not the
intended recipient be aware that any downloading, copying, disclosure,
distribution or use of the contents of the above information is strictly
prohibited. If you have received this communication by mistake, please forward
the message back to the sender at the email address above, delete the message
from all mailboxes and any other electronic storage medium and destroy all
copies. Disclaimer Notice: Internet communications cannot be guaranteed to be
safe or error-free. Therefore we do not assure that this message is complete or
accurate and we do not accept liability for any errors or omissions in the
contents of this message.
------------------------------
Message: 3
Date: Tue, 13 Dec 2016 11:07:02 +0000
From: Lukasz Nowak <[email protected]>
To: Patrik Flykt <[email protected]>, Daniel Wagner
<[email protected]>, [email protected]
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
Sorry it took a while, but I finally posted a set of patches
yesterday, which implement the per-interface routing through
sessions. I added the following:
1. A session config field which filters on interface name
This allows an application to start a session and attach it
to a specific interface.
2. Another session config field enabling source ip address
rule in iptables, and the required fwmark rule in iproute.
This allows the application to do a bind before connect
for each socket, and have the traffic routed through the
selected interface.
3. Fixed a bug where ppp sessions would not create a
per-session routing table due to having no gateway.
Let me know if this makes sense.
Thanks.
Lukasz
On 04/11/16 08:11, Patrik Flykt wrote:
> On Thu, 2016-11-03 at 14:00 +0000, Lukasz Nowak wrote:
>> So I had a good look at the sessions. If I understand correctly,
>> each session sets an iproute2 rule to forward packets
>> with a session-specific fwmark to the correct routing table.
>> The marks are added with iptables based on UID, GID or SELINUX.
>>
>> This is quite a bit off from what we need: having one application
>> freely choosing which interface to send traffic through.
>
> IIRC sessions are also ending up with only one default route. This has
> been the current best practise so far. But that does not mean it cannot
> be changed. The user expectation when connecting to a WiFi is that
> traffic moves over to WiFi from e.g. cellular; with this in mind the
> corner case then is whether a connection is still kept on cellular or
> whether it is to break and re-establish itself over WiFi.
>
>> Firstly, can a single application connect multiple sessions?
>> (one for each interface)
>
> The code seems to be happy with multiple sessions being created.
>
>> Even if yes, all the sessions would then receive the same policy,
>> so only one iptables marking entry would be active, i.e. only
>> one routing table would be used. The application would not have
>> a way to change that.
>>
>> Also, if I understand correctly, if an application opens a session
>> with a UID/GID policy, the iptables/iproute rules will immediately
>> affect all processes with the same UID/GID - is that correct?
>
> Yes. So something additional is needed as the first UID, GID or Selinux
> rule matches.
>
>> Ideally, what we need would is either:
>> - set an iproute2 rule to use correct routing table based on packet
>> source ip
>> - use iptables to mark packets based on source ip
>>
>> In either case, I cannot see how it can be easily added to the
>> policy model. Unless the application could choose a specific policy
>> when creating a session.
>>
>>
>> For the AlwaysConnectedTechnologies: this change does not do
>> a lot. We can achieve the same effect by the application manually
>> connecting all services. In either case, the routing table will
>> only be established for one service. So the services in Ready
>> state will not be usable for sending external traffic.
>
> This is the first step towards connecting more than one service
> automatically; the same will be achieved right now by connecting every
> other service manually.
>
>> Automatically adding additional routing tables for each
>> AlwaysConnectedTechnology,
>> and iproute2 rules based on source ip, would do the job. But it
>> would have to be independent of the Sessions.
>
> That'd be the next issue to sort out.
>
> Cheers,
>
> Patrik
>
------------------------------
Message: 4
Date: Tue, 13 Dec 2016 14:51:41 -0500
From: Evade Flow <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: Tether WiFi to cellular modem uplink
Message-ID:
<CAMAb8ZP=tvyjyokauuszqc_vm0rh_flcyzqso7ms7vahcbw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for your reply!
> This then means that oFono is not working. No oFono, no cellular uplink
> connection in ConnMan either.
> ...
> There is no 'cellular' technology here so thus no cellular uplink. The
> problem is that oFono wasn't properly configured
Do you mean that it's not possible for the tether to access the cellular
link unless I
configure oFono? I'm not opposed to trying this, but... I have no idea
where to
start. How does one 'configure' oFono? Pointers to any available docs,
tutorials,
videos, books, etc. would be much appreciated.
Up to now I've only managed to find this video:
- https://www.youtube.com/watch?v=uG3NugVeiqE
and the the text files in the `doc` folder of the oFono source. From them,
my impression
is that oFono is supposed to 'just work' for most uses, but they don't give
much advice
about what to do when it doesn't.
FWIW, the modem I want to establish an LTE connection with is a Sierra
Wireless
AC 340U, using the qmi_wwan driver...
On Tue, Dec 13, 2016 at 5:55 AM, Patrik Flykt <[email protected]>
wrote:
>
> Hi,
>
> On Thu, 2016-12-08 at 18:00 -0500, Evade Flow wrote:
> > I guess I should start by confessing that I was completely mystified
> > by ofono, so I gave up trying to use it to configure the modem
> > connection. Instead, I wrote some udev rules that do (more-or-less)
> > the following:
> >
> > ip link set eth0 down
> > qmi-cli -p -d /dev/cdc-wdm0 --wda-set-data-format=802-3
> > qmicli -p -d /dev/cdc-wdm0 --wds-start-network=apn=fast.t-
> > mobile.com --client-no-release-cid
> > killall -TERM dhclient
> > dhclient wwan0
> > ip link set eth0 up
>
> This then means that oFono is not working. No oFono, no cellular uplink
> connection in ConnMan either.
>
> > This 'works' in the sense that the routing table is correct
> >
> > embedded-dev $ connmanctl tether wifi enable
> > Enabled tethering for wifi
>
> So far so good.
>
> > I suspect this is because connman knows *nothing* about the cellular
> > connection:
> >
> > $ # These commands were run back on the embedded device:
> > $ connmanctl technologies
> > /net/connman/technology/p2p
> > Name = P2P
> > Type = p2p
> > Powered = False
> > Connected = False
> > Tethering = False
> > TetheringAt5ghz = False
> > /net/connman/technology/bluetooth
> > Name = Bluetooth
> > Type = bluetooth
> > Powered = True
> > Connected = False
> > Tethering = False
> > TetheringAt5ghz = False
> > /net/connman/technology/wifi
> > Name = WiFi
> > Type = wifi
> > Powered = True
> > Connected = False
> > Tethering = True
> > TetheringIdentifier = myapn
> > TetheringPassphrase = myapnpasswd
> > TetheringAt5ghz = False
> > /net/connman/technology/ethernet
> > Name = Wired
> > Type = ethernet
> > Powered = True
> > Connected = True
> > Tethering = False
> > TetheringAt5ghz = False
>
> There is no 'cellular' technology here so thus no cellular uplink. The
> problem is that oFono wasn't properly configured, so there is no
> cellular connection in use, neither a technology that should have shown
> up in the first place.
>
> Cheers,
>
> Patrik
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161213/6b5b735a/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 18
***************************************
