DSS usage

[Dmytro Milinevskyy]

Hi Bjørn,

I've already started to work on a concept of DSS through char dev.
In the attachment you can find the first trial. 
It's not extremely stable version but I can exchange data between the host and the device
even if the main wwan interface is down. The DSS channel is registered as a misc device.

There are several points which so far I don't know how to implement correctly:
1. how to publish/delete new DSS channel? Via ioctl for cdc-wdmXX device or via NL msg. Honestly I would prefer to use NL.
2. what is the best way to destroy DSS channels if MBIM device goes offline(i.e. it's being unbound). 
   I'm afraid that I can't sleep in this context to wait for all DSS users to finish with the cleanup
3. there's a limitation on the number of misc devices in the system since it uses same major index. 
   Don't know whether it's a big limitation though.

The attached patches are just for the review, don't try them at home ;).

best regards,
~ Dmytro


----- Original Message -----
> 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
> 


-- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drivers-net-usb-usbnet-flag-to-submit-IN-URBs-even-t.patch
Type: text/x-patch
Size: 2981 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140428/c92c64cb/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-drivers-net-usb-mbim-export-DSS-pipes-via-miscdev.patch
Type: text/x-patch
Size: 15319 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140428/c92c64cb/attachment-0003.bin>