Netgear Aircard 341U in QMI mode, switching to 802.3

[Aleksander Morgado]

>
> We have the 341u working using libqmi on an older product.
> The modem changes how it behaves depending on what mode it is in at least
> in my experience.  Various firmware updates also messed with the
> RAW/non-raw stuff quite a but.
>
> Currently we need to set the options
>
>     --device-open-net=net-802-3|net-no-qos-header
>
> for all qmi commands, ModemManager does this by default so that should be
> covered for anyone using that. In IPPassthrough mode the 341 always runs
in
> rawip mode.
>

The patch I wrote for MM will end up switching the 341 (with the IP
passthrough firmware) to 802.3, it just takes several tries until the modem
accepts to change it. It has nothing to do with the number of tries (I
think), but with the time elapsed since the modem was powered on.
ModemManager won't expose the modem in DBus until this operation has been
finished.

> It also seems to have a hardcoded MTU of 1460 that it doesn't advertise.
> At least that was our experience with multiple installs.
>
> Attached is a patch that we ran on linux 2.6.39 (old I know) but it should
> give a good basis for anyone wanting to update the driver.  Chances are I
> will be doing this work on a 4.0 kernel pretty soon anyway as our newer
> products roll out,
>
> Cheers,
> Davidm
>
>
>
>
> Markus Gothe wrote the following:
> > Long time no see Björn! Nice to see you are alive and kicking.
> >
> > Yeah it will add complexity. You did some tries with raw-ip in
qmi_wwan.c years ago and it didn’t worked that well out, so I hope we will
be able to keep the 802.3-mode.
> >
> > //M
> >
> > On 08 Jun 2015, at 12:39 , Bjørn Mork <bjorn at mork.no> wrote:
> >
> > > Markus Gothe <nietzsche at lysator.liu.se> writes:
> > >
> > >> I discovered that the UML 295 needs sync, set format etc to come in a
> > >> special sequence; if sync was run after set format things would
break.
> > >>
> > >> This is most likely the case here: one should use USBpcap in Windows
> > >> to sniff the setup.
> > >
> > > Windows sniffing would certainly help us understand how this is
intented
> > > to work from the vendor's side.
> > >
> > > I've assumed these devices come with raw-ip Windows drivers. And I
have
> > > thought about doing the same.  But contrary to Windows, we try to do
> > > thing consistently.  And this would create an inconsistence between
> > > otherwise similar devices.  Probably not a big deal as ling as MM (and
> > > other userspace applications) are aware of it.  But it in my view it
> > > will add complexity compared to the "make sure every device use 802.3"
> > > rule we have today.
> > >
> > > If we were to do this, then I we could for example enable raw-ip
through
> > > a driver read/write flag exported via the ethtool API. Maybe we also
> > > could let some devices with known 802.3 problems default to raw-ip.
But
> > > that would require QMI userspace application awareness.  Which is an
API
> > > problem if we make that change for already supported devices, so I am
> > > not sure we can do that. It is safer to just provide the raw-ip
> > > infrastructure in the driver, and leave it up to userspace to decide
> > > if/when to use it.
> > >
> > > For now, I'm feeling like relaxing (even more :) and see if
Aleksander's
> > > workaround is good enough.
> > >
> > >
> > > Bjørn
> > > _______________________________________________
> > > libqmi-devel mailing list
> > > libqmi-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
> >
> > //Markus - The panama-hat hacker
> >
>
>
>
> > _______________________________________________
> > libqmi-devel mailing list
> > libqmi-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
>
> --
> David McCullough,  davidm at spottygum.com,   Ph: 0410 560 763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150609/2e54c7cd/attachment-0001.html>