Netgear Aircard 341U in QMI mode, switching to 802.3

[David McCullough]

Hi all,

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.

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 --------------
A non-text attachment was scrubbed...
Name: linux-2.6.39-Sprint-341u.patch
Type: text/x-diff
Size: 9928 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150609/dc9fa27a/attachment-0001.patch>