Verizon UML295

[Markus Gothe]

Could you send me a mail on those threads?
We cannot support more than one simultanous IPv4 session in MBIM???

Sounds interesting... However it might include DHCP-snooping. Qualcomm has a buggy DHCP-server that might give out an infinite lease-time under certain situations as well as Cisco have some buggy behaviour receving it in bridged mode. So Ive implemented a DHCP-addon to ebtables for my employer, which is propertary and works really good.

So I got the basics about doing this inside the driver. One can also look at the old ugly Sierra_net.c builtin DHCP-server.

Well I have got the hardware and the time during spring methinks.

ATM I am implementing MBIM-support with umbim (which I cought an ugly bug in today) for our products which should be released in our GPL-packages when it is finished or someone request it.

//M - The panamahat hacker

Den 11 mar 2015 09:37 skrev Bjørn Mork <bjorn at mork.no>:
>
> 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