Netgear Aircard 341U in QMI mode, switching to 802.3

[Markus Gothe]

Well, I dare you on this.
Go show me a PoC and I’ll consider it.

What I’ve in mind is this: http://www.spinics.net/lists/linux-usb/msg58432.html where Björn showed us off...

//M

On 10 Jun 2015, at 21:44 , Dan Williams <dcbw at redhat.com> wrote:

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

//Markus - The panama-hat hacker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150611/0f34bfdd/attachment.sig>