Optimizations for qmi_wwan.c

[Bjørn Mork]

You are "bridging" a point-to-point IP interface with an ethernet
interface no matter how you look at this. We're just moving the
ethernet header add/remove functionality to the right or left.

The modem firmware implementation (qmi with 802.3) sucked. Too many bugs
to be fun. Even Qualcomm gave up this route.

The driver implementation (cdc_mbim) sucked. Too many corner cases to be
fun. We gave up this route when we added raw-ip qmi.

We're left with a host implmentation, where we treat the mobile network
connection as the IP tunnel it is for as long as possible.  This still
allows us to emulate whatever we need at the point where it is needed.

Now, the point is that you have to be aware of the point-to-point IP
interface regardless, even when bridge tools allow you to mix a modem
interface with an ethernet interface.  All addressing is by IP address.
Any illusion of ARP or mac addresses are just that - illusions.  This is
easy to see when you add more than one client on one of the ethernet
ports.  Similar with DHCP or other L2 services.  They are illusions
created by software running somewhere between the point-to-point
interface and the ethernet bridge.  You are much better off taking
control over that software.

Use IP forwarding, proxy arp, and a dhcp server configured by
qmicli/mbimcli/mmcli to create the bridge illusion.  It will work with
all three fimrware/driver variants, and it will properly document the
restrictions.  



Bjørn



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

> hso.c was not the best choice to follow, how come one can easily bridge an MBIM device but not a raw-ip device?
>
> The shouldn't at least not be point-to-point, the IFF_NOARP is easy to work around with ebtables and ARP-spoofing, iff there was an Ethernet frame being sent/received.
>
> //M
>
> Sent from my BlackBerry — the most secure mobile device
>
>
> 	  Original Message  
>
>
>
> From: dcbw at redhat.com
> Sent: 25 September 2019 04:05
> To: nietzsche at lysator.liu.se; libqmi-devel at lists.freedesktop.org
> Cc: bjorn at mork.no
> Subject: Re: Optimizations for qmi_wwan.c
>
>
> But... WWAN modems aren't ethernet devices. Bridging is inherently L2
> and these devices just don't operate on that level.
>
> That all said, the kernel interface that qmi_wwan exposes even for
> raw_ip mode does have a fake ethernet address so it's not like you
> can't put them into a bridge. Where does the current raw_ip
> implementation fall down when it's in a bridge? The fact that it's
> IFF_NOARP or something?
>
> Dan
>
> On Tue, 2019-09-24 at 22:37 +0200, Markus Gothe wrote:
>> As soon as you want to bridge the devices it won't work very well.
>> And that's a pretty common thing to do.
>>
>> //M
>>
>> Sent from my BlackBerry — the most secure mobile device
>>
>>
>>   Original Message 
>>
>>
>>
>> From: dcbw at redhat.com
>> Sent: 24 September 2019 21:17
>> To: nietzsche at lysator.liu.se; libqmi-devel at lists.freedesktop.org
>> Cc: bjorn at mork.no
>> Subject: Re: Optimizations for qmi_wwan.c
>>
>>
>> On Tue, 2019-09-24 at 20:38 +0200, Markus Gothe wrote:
>> > I doubt it is the correct list, but I am giving it a try. At least
>> > it
>> > is related.
>> >
>> > Today I realized the "raw ip" mode got merged a few years ago.
>> > Geesh,
>> > I am getting old.
>> >
>> > However there are some drawbacks with the implementation 1) a
>> > boolean
>> > mode of operation (instead of a tristate with fake MAC layer) 2)
>> > branching in the rx_fixup.
>> >
>> > Since one cannot change the mode of operation when the device is up
>> > and running (at least I couldn't), this seems to be the perfect
>> > place
>> > to use "static keys" a.k.a. "jump labels" a.k.a. memory patching
>> > code
>> > as outlined here
>> > https://www.kernel.org/doc/Documentation/static-keys.txt
>> >
>> > Pros? Speed ofc... Cons? If the architecture doesn't implement it
>> > correctly things might fail.
>> >
>> > To address the 1) is easy and I sent a separate driver that did
>> > fake
>> > the MAC layer here some years ago.
>>
>> Do you mean keep the device in raw_ip mode (since most recent devices
>> don't support the old 802.3 mode), but have the driver fake the MAC
>> and
>> operate like the old "802.3" as Linux/userspace sees it?
>>
>> What applications actually care about L2 Ethernet MAC addresses and
>> don't work with raw-ip mode?
>>
>> Dan
>>
>> _______________________________________________
>> libqmi-devel mailing list
>> libqmi-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel