DSS usage

[Bjørn Mork]

Ben Chan <benchan at chromium.org> writes:

> 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.

I've tried to find examples of drivers doing something like that, but
have so far failed.  Looking at current networking code and lots of
drivers, I believe the comment in the up/down netdevice notifier events
in include/linux/netdevice.h applies to *any* attempt to implement this:

 #define NETDEV_UP       0x0001  /* For now you can't veto a device up/down */
 #define NETDEV_DOWN     0x0002


I also have been browsing around to find proper ways to allow a VLAN dev
to set its MTU independently of the IP MTU on the master device, but
there doesn't seem to be any way around this either. The single mtu
value of the master device is used directly both as a ceiling for VLAN
MTUs, as well as for the maximum IP fragment size for untagged IP
traffic on the master device.

So my only working proposal is to add another "magic" VLAN which, if
created by userspace, will replace wwan0 as the IP interface associated
with session 0, leaving wwan0 as a upper netdev *only*. If userspace
doesn't create this magic VLAN for session 0, then wwan0 will continue
playing its current dual role, making sure we don't break the simple
"single IP session" usecase.

But I'm not yet convinced this is a good idea, so I'd like to have more
people thinking it over before implementing it.

Pros:
 - allows MTU to be set independently for all IP and DSS sessions
 - allows bringing up and down the netdev associated with IP session 0
   without interfering with any other session

Cons:
 - obfuscated and complex user interface
 - IP session 0 will be associated with a somewhat illogical VLAN ID
 - inconsequent mapping of IP session 0 can confuse users and software

And probably more.  But that's what I came up with right now.

Thoughts?  Did I miss something when looking for other solutions?

Bjørn