Verizon UML295

[Bjørn Mork]

Markus Gothe <nietzsche at lysator.liu.se> writes:

> I guess I was out watching the ice-hockey game both yesterday and today instead (“my” team did make it to the quarter final today).
> So I’ll will make this during the week as well as a patch for MBIM’s source mac.
>
> I figured out that in bridged mode one will never be able to use the .rx_fixup in qmi_wwan.c since MAC-adresses can start with 0x40, 0x00, 0x60 and even if we try working around this we need to have to the endpoints MAC-address as destination when doing the rewrite; not like we do today and use the device’s mac-adress in ‘fix_dest’.
>
> Also we must figure out the source adress or assume it is the default one. :-/
>
> My suggestion is to implement a parameter that can be changed on-the-fly by procfs to turn off/on the rx_fixup in qmi_wwan.c
> What do you guys think (I know you don’t bridge these things as much as me and my customers)?

I've followed some recent discussions in netdev regarding neighbour
table lookups from drivers with great interest, and briefly thought that
"we" should look deeper into this.  Maybe we actually could do true
IP=>MAC lookup from the driver, rewriting to the proper destination MAC
address on bridged devices?  That would be extremely interesting for
IPv6 I believe, where we (theoretically at least) could support multiple
distinct hosts behind a single cdc_mbim or qmi_wwan connection.

But it doesn't look good wrt finding time to actually dig into this, so
it will probably end up like most of my "good" ideas...  forgotten by
everyone except Google.  Until I get the same idea again and google it
:-) 



Bjørn

> On 09 Mar 2015, at 11:01 , Markus Gothe <nietzsche at lysator.liu.se> wrote:
>
>> I'll fix it tonight with a patch for usbmodeswitch as well.
>> 
>> //M
>> Den 9 mar 2015 10:23 skrev Bjørn Mork <bjorn at mork.no>:
>>> 
>>> Markus Gothe <nietzsche at lysator.liu.se> writes: 
>>> 
>>>> Getting hold of a device with the latest fw and using the code from Dave and reimplemented it as an usual-dev-callback I managed to switch it to QMI-mode (and it use ‘rawip’ by default). 
>>>> The trick is that the device will appear first as 0x1a9 0x606f and then wait 2-3 secs for the switch and then eject itself and come back as 0x1a9 0x6064 in www-mode if *not* switched to QMI-mode. 
>>>> 
>>>> Thanks for your help on resolving this. Especially Dave for providing the modeswitch-code. 
>>>> Here is a simple patch as a token of appreciation. 
>>>> Index: linux/drivers/usb/storage/initializers.c 
>>>> =================================================================== 
>>>> --- linux/drivers/usb/storage/initializers.c (revision 13611) 
>>>> +++ linux/drivers/usb/storage/initializers.c (working copy) 
>>>> @@ -141,6 +141,21 @@ 
>>>>   return 0; 
>>>>   } 
>>>>   
>>>> +/* This places the Pantech UML295 devices in QMI mode */ 
>>>> +int usb_stor_uml295_init(struct us_data *us) 
>>>> +{linux/ 
>>>> + int result; 
>>>> + unsigned char data = 0x00; 
>>>> + 
>>>> + result = usb_stor_control_msg(us, us->send_ctrl_pipe, 
>>>> +       0x70, 
>>>> +       0x40, 
>>>> +       0x4 /* 4 = QMI, 2 = RNDIS */, 0x0, (char*)&data, sizeof(data), 1000); 
>>>> + printk(KERN_INFO "Pantech UML295 mode set result is %d\n", result); 
>>> 
>>> Ah, nice! 
>>> 
>>> But the current policy is to do stuff like this in userspace instead of 
>>> adding new devices to unusual_devs.h.  I hope it is possible to achieve 
>>> the same result using e.g. usb_modeswitch? Yes, I know you work in 
>>> embedded systems, but I guess you do run some hotplug script or udev 
>>> equivalent there too? 
>>> 
>>> One obvious advantage having this in userspace, is that the the user 
>>> gains control over the QMI vs RNDIS selection.  You can easily adapt the 
>>> usb_modeswitch config for your preference. 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> --- linux/drivers/net/usb/qmi_wwan.c (revision 13613) 
>>>> +++ linux/drivers/net/usb/qmi_wwan.c (working copy) 
>>>> @@ -22,6 +22,10 @@ 
>>>>   USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff), 
>>>>   .driver_info        = (unsigned long)&qmi_wwan_info, 
>>>>   }, 
>>>> + { /* Pantech UML295 and more */ 
>>>> + USB_VENDOR_AND_INTERFACE_INFO(0x10a9, USB_CLASS_VENDOR_SPEC, 0xf0, 0x00), 
>>>> + .driver_info        = (unsigned long)&qmi_wwan_info, 
>>>> + }, 
>>>>   { /* Novatel USB551L and MC551 */ 
>>>>   USB_DEVICE_AND_INTERFACE_INFO(0x1410, 0xb001, 
>>>>                                 USB_CLASS_COMM, 
>>> 
>>> Could you please submit this part as a separate patch with a proper 
>>> Signed-off-by?  Thanks 
>>> 
>>> BTW, any idea why they have a new vendor ID for these devices?  The 
>>> class codes seem to match the UML290 entries. 
>>> 
>>> 
>>> Bjørn 
>> _______________________________________________
>> libqmi-devel mailing list
>> libqmi-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
> //Markus - The panama-hat hacker