DSS usage

[Ben Chan]

I also have a mixed feeling. While it'd be great if we could abstract some
of the interface management, I'm not sure if it's always desirable to have
libmbim / mbim-proxy handling the wwan / vlan interface state by default.
There are tasks that we may want to do before turing the interface up, e.g.
moving the vlan interface into its own network namespace as I mentioned
before. For any DSS that ends up exposing itself as a pty, the
corresponding vlan interface should really be separated from the rest of
the system.

In the end, there is still no protection against turing wwan down while the
vlan is in use. It seems to me that some additional mechanism is needed in
the kernel driver to ensure that.


On Fri, Apr 11, 2014 at 12:51 AM, Arnaud Desmier <adesmier at sequans.com>wrote:

>  On paper this seems to be good but my main concern is that everybody has
> to play game (any connection manager) and usual command line tools (if*,
> ...) that bring interface up/down would break this, no?
>
> Arnaud
>
>  On 11/04/2014 08:56, Aleksander Morgado wrote:
>
> On Fri, Apr 11, 2014 at 4:32 AM, Arnaud Desmier <adesmier at sequans.com> <adesmier at sequans.com> wrote:
>
>  If we continue using VLAN we still depends on wwan interface status to
> access DSS channels. So we have to link NetworkManager to libmbim to avoid
> putting down wwan interface if there is any DSS channel open.
>
> What about opening DSS channel when wwan interface is down?
>
>  If there is a single process taking care of bringing up/putting down
> the MBIM WWAN interfaces, then everything would be more or less
> solved, as that process could take into account which other processes
> requested to have the interface up or down. Still believe that the
> mbim-proxy could do that; e.g. by managing the up/down state itself
> via netlink. The proxy would detect when a Connect succeeded and
> directly ifup the interface itself, and when a Disconnect succeeds it
> can also bring it down. At the same time, it could also manage the DSS
> sessions, and if there is a session ongoing it would make sure that
> the interface is kept up (or something like that). NetworkManager
> would just need to avoid bringing it up/down itself.
>
> Them, in libmbim we could have a new API like:
>
> gint
> mbim_dss_activate (
>     const MbimUuid *device_service_id,
>     guint32 dss_session_id);
>
> This method takes a service ID and session ID (for the  DSS connect
> command) and returns an open file descriptor (or a higher level
> GObject which contains more info, but that's the idea). The
> intermediate mbim-proxy could take care of exposing a temporary socket
> behind that file descriptor, and also take care of managing the whole
> stream within the channel, removing unneeded ethernet headers and
> hiding all the VLAN handling to other processes, which would only play
> with the fd.
>
> Isn't this a possible path to take? Maybe I'm missing something?
>
>
>
>  -- IMPORTANT NOTICE:
>
> The contents of this email and any attachments are confidential and may
> also be privileged. If you are not the intended recipient, please notify
> the sender immediately and do not disclose the contents to any other
> person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
>
> _______________________________________________
> libmbim-devel mailing list
> libmbim-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libmbim-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140411/c5a8fd7b/attachment.html>