Netgear Aircard 341U in QMI mode, switching to 802.3

[Markus Gothe]

Actually you can use DHCP over GTP in backhaul.

//M
Den 11 jun 2015 18:14 skrev Dan Williams <dcbw at redhat.com>:
>
> 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.
>
> Dan
>
> > > I tend to agree with Dan on the raw-ip issue.  Snooping on the device
> > > setup in the driver will allow all existing QMI userspace
> > > implementations to use raw-ip without any major changes.
> > > 
> > > But I do still hope we can avoid doing the raw-ip support at all.
> > > 
> > > 
> > > (I have a nasty feeling that we compete with the firmware setup here,
> > > and that the reason the 802.3 commands fail is that there is some
> > > firmware application needing the modem in raw-ip mode.  We risk that new
> > > firmware revisions will try even harder...)
> > 
> > Not sure this applies here,  but our 341u implementation uses current libqmi
> > and used to always pass the 802.3 flags to all calls.  This seemed to make it
> > behave consistently in normal operation.  However, when the 341u is in IPPT
> > mode,  it didn't matter,  it always seemed to run in raw-ip mode, so we
> > just stopped using the 802.3 flags on the 341.
> > 
> > IPPT mode can be enabled with:
> > 
> > at!ippassthrough=1
> > 
> > and disabled with:
> > 
> > at!ippassthrough=0
> > 
> > Cheers,
> > Davidm
> > 
>
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel