Verizon UML295

[Bjørn Mork]

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

> Could you send me a mail on those threads?

I was thinking about the discussions following the initial "add IPv4
routing FIB support for swdev" mail:
http://permalink.gmane.org/gmane.linux.network/344342

I'm not claiming that I have actually read all of that, and much less
understood any of it... But the first glimpse made me think that I
should *try* to understand it and that it might be relevant wrt our
"driver needs to look up l2 neigbour" use case.

Might be completely wrong...

> We cannot support more than one simultanous IPv4 session in MBIM???

Of course we can.  What I meant is that a single session will have a
single IPv4 address, which limits our ability to map it to more than a
single host (without looking further into the IP header, but I don't
think you want to go there in a bridge - TCP/UDP port based switching?
Ugh..)

The reason I mentioned that IPv6 might be different is that a single
IPv6 session will have a whole /64 prefix to play with.  This means that
we have lots of addresses we can give different meanings, like mapping
them to different hosts.

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

Yes, I think that is the best solution.  We don't really want the DHCP
mess in the driver, and we would have been better off if it hadn't been
implemented in firmware at all.  The address configuration is part of
the session management and should really use the out-of-band management
protocol.  I.e. QMI for QMI devices.

This is one area where MBIM is a great improvement IMHO, because the
MBIM IP configuration is mandatory and you cannot assume DHCP support.
For IPv4 at least.  The fact that the IPv6 MBIM IP configuration support
is non-functional in the Sierra Wireless EM7345 (and presumably most
other Intel XMM7160 devices) indicates that Windows use SLAAC for IPv6.
Which probably means that we have to trust whatever buggy RA daemon the
firmware implements, even for MBIM.


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

Yes.  Too late to do now, but I believe it would have been better to
implement the DIP (HIP) support in userspace, similar to the QMI
support.  That would have made it easy to extend it to mcuh more than
the currently supported 3 (!) HIP messages, and things like IP
configuration could have been implemented in userspace on the host
instead of in firmware on the device.

I guess it's time again to thank Dan, Marcel and others who convinced me
not to repeat that error in the qmi_wwan driver.  That wasn't easy :-)

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

Great! The current umbim implementation could need some love, especially
in the "make it work for generic/most modems" area. I like that it is
based on the libmbim JSON data, which makes it easier to share
developement resources between the two projects, but I don't think the
current simple strategy converting these to structs will fly.  There is
no way you can make that work well with MBIM arrays AFAICS.

I'd really like to start playing with OpenWRT again. Hopefully with a
little more success than my last project, which was stolen together with
the motorcycle it was installed in :-(

Don't you too think that someone should add a few hours to the normal
day?


Bjørn