Netgear Aircard 341U in QMI mode, switching to 802.3

[David McCullough]

Dan Williams wrote the following:
> On Thu, 2015-06-11 at 22:16 +1000, David McCullough wrote:
> > Bjørn Mork wrote the following:
> > > Markus Gothe <nietzsche at lysator.liu.se> writes:
> > > 
> > > > Well, I dare you on this.
> > > > Go show me a PoC and I’ll consider it.
> > > 
> > > It's possible, but I agree that it quickly will become ugly.
> > > 
> > > I tried something like this for MBIM IP session IDs while experimenting
> > > with different ways to solve the MBIM multiplexing.  As you know now, I
> > > ended up dropping all that. Instead userspace have to syncronize netdev
> > > creation with MBIM session creation.  I'm still not sure which solution
> > > is best/worst.  Both have their advantages and disadvantages.  But I
> > > know why I selected the one I did:  It was the simplest one for me :)
> > > 
> > > Do note though, that there aren't yet any userspace implementation of
> > > the MBIM multiplexed sessions (AFAIK).  Adding some userspace PoC for
> > > this has been on my TODO list for quite a while, but is still not done.
> > > That's also a factor to consider here.
> > > 
> > > > What I’ve in mind is this:
> > > > http://www.spinics.net/lists/linux-usb/msg58432.html where Björn
> > > > showed us off...
> > > 
> > > Which has the disadvantage that it adds yet another userspace API, with
> > > strict rules on how it should interact with the existing API, while
> > > offloading all the policing to userspace.  Not nice.
> > > 
> > > The userspace QMI offloading was a success, but if we go too far in that
> > > direction then we risk making it impossible to create userspace tools.
> > > Having a single well-defined management protocol managed by userspace is
> > > fine.  Combining it with rules on how to configure the netdev is not.
> > > (Which means that the qmi_wwan driver ideally should do the MTU setup
> > > for example.  But it doesn't.)
> > 
> > My .2c,  people think of these things as network interfaces,  its nice if
> > you can use standard network tools / apps when dealing dealing with them.
> > For me,  not being able to run dhcp is a deterent.  Any thing that
> > unifies any part of the already widely varying modem API's is a good thing.
> 
> They are network interfaces, but they are not necessarily *ethernet*
> interfaces, nor do they necessarily support DHCP.  But that's fine,
> neither did PPP-based modems.  I agree that having an ethernet-based
> DHCP-capable network interface is somewhat simpler, but the additional
> complexity of DHCP and ethernet encap/decap has to come from somewhere,
> since no modems are ethernet-based nor do they use DHCP.
> 
> (well OK, they are supposed to do passthrough DHCPv6 but that still
> isn't ethernet.  Plus CDMA devices actually do use PPP over the air, but
> I doubt they just pass through PPP packets from the host's pppd...)
> 
> And since we don't control the firmware, we obviously have to handle
> cases where the firmware doesn't support DHCP or doesn't support 802.3
> mode, or both...  yay for networking.
> 
> TLDR; yeah DHCP + ethernet would be nice but supporting these
> "standards" is more work for the firmware writers, and we cannot count
> on them to do it, or do it well.  At some point we'll find modems that
> don't do DHCP or don't do ethernet, and we'll need to talk to them too.

Absoluetely agree,  just didn't want to see DHCP support excluded if the
device actually does implemented it ;-)

Cheers,
Davidm


-- 
David McCullough,  david.mccullough at accelecon.com,   Ph: 0410 560 763