Netgear Aircard 341U in QMI mode, switching to 802.3

[Markus Gothe]

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. :-)

//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