<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> 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 <div class="moz-cite-prefix">On 11/04/2014 08:56, Aleksander Morgado wrote: </div> <blockquote cite="mid:CAAP7ucKWmypeczE9YxB+Nb8UYB9fW-PgOwZuEKsuHBWzGAsqFQ@mail.gmail.com" type="cite"> <pre wrap="">On Fri, Apr 11, 2014 at 4:32 AM, Arnaud Desmier <a class="moz-txt-link-rfc2396E" href="mailto:adesmier@sequans.com"><adesmier@sequans.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap=""> 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? </pre> </blockquote> -- 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.</body> </html>