Netgear Aircard 341U in QMI mode, switching to 802.3

[Dan Williams]

On Wed, 2015-06-10 at 20:20 +0200, Markus Gothe wrote:
> I dont see how snooping the WDM device is necessary if the device supports WDA's get format. Which is what at least the Sprint 770S does. :-)

The snooping would be necessary because we don't want drivers sending
these kinds of commands to the firmware and implementing a firmware
communication stack.  Here, the driver would only have to listen to
traffic already going through it, which is a lot less code and requires
little of the protocol handling of a full get/reply cycle.

Dan

> //M
> 
> Den 9 jun 2015 16:30 skrev Dan Williams <dcbw at redhat.com>:
> >
> > 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
> >
> > _______________________________________________
> > libqmi-devel mailing list
> > libqmi-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel