Netgear Aircard 341U in QMI mode, switching to 802.3

[Markus Gothe]

As a strong proponent for being able to bridge devices I think #2 MBIM-style is the way to go and let the developers do arp-spoofing by means of ebtables (for ethernet briding the device).

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