Netgear Aircard 341U in QMI mode, switching to 802.3

[Dan Williams]

On Mon, 2015-06-08 at 12:39 +0200, Bjørn Mork 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

If we're going to support rawip mode, then I would advocate that we
either:

1) not use an ethernet device at all, but instead something more like
'tun' device that doesn't advertise itself as ethernet (because it's
not) and doesn't set 'type' = ARPHRD_ETHER (because it's not).  It
should be pretty clear then to userspace apps that this isn't ethernet
and shouldn't get DHCP

2) make it an ethernet-type device but do the framing in the driver,
which qmi_wwan already kinda does when fixing up stupid stuff the
firmware does.

I'd actually vote for #1 since it's clearer to userspace apps what's
going on, but both of these options would require snooping of the
cdc-wdm data to recognize the SET_DATA_FMT commands and when found to
create/destroy the appropriate network device.  Honestly I don't think
that's awful though, since the driver isn't *writing* any protocol data
to the device, only snooping it.  There's some precedent for that in the
wifi drivers to detect DHCP and 802.1x and set lower bitrates for
reliability.

Dan

> 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