Ethernet-briding a MBIM-interface
nietzsche at lysator.liu.se
Thu Oct 23 09:30:43 PDT 2014
Hi, Björn and thanks for your feedback.
2G/3G networks are circuit switch running PPP over the backhaul. LTE is circuit switch and talking IP over the backhaul.
This is why Sierra’s DirectIP / sierra_net.c is a half-bridge. It is by an old design. Hiding the PPP and using a DHCP-hack (older DirectIP devices actually wants the DHCP-server to be implemented in sierra_net.c using CnS/HIP).
The local MAC-issue will be overcome by using eatables to do MAC-DNAT (been there done that before).
The use case for being able to bridge MBIM is of course embedded devices. Not computers.
Playing around with proxy arp / parprouted might be a good starter. :-)
So basically you are saying that MBIM and Sierra DirecIP is reassembling each other very close?
On 23 Oct 2014, at 13:41 , Bjørn Mork <bjorn at mork.no> wrote:
> Markus Gothe <nietzsche at lysator.liu.se> writes:
>> has anyone worked out how to bridge an MBIM-interface with a regular ethernet interface?
>> I think there are 2 ways to do it:
>> 1) Using ebtables.
>> 2) Something like this: http://www.spinics.net/lists/linux-usb/msg96303.html
> True bridging of LTE/3G interfaces is simply impossible. We can only
> fake a bridge by routing the IP packets across point-to-point links and
> moving the global IP address to the other end of this link. This is
> what the modem does when it presents its local end of the GTP tunnel as
> an MBIM IP session to the host.
> All LTE/3G modems presenting some sort of ethernet like interface to the
> host does something like this. Bridging these fake ethernet interfaces
> might be possible, depending in the implementation.
> But I believe it's impossible to bridge the interface created by the
> Linux MBIM driver due to the way it forces the usage of the local MAC
> address as a destination. The ethernet frames delievered by this driver
> will always go to the local host. Creating a bridge will not change the
> behaviour. You can probably do MAC address rewriting using ebtables to
> overcome the problem, but that is unnecessarily complicated IMHO.
> There is nothing preventing you from continuing the game played by the
> modem over more point-to-point links, including ethernet links. And you
> can make the last one of these look pretty much like an ethernet LAN
> with a DHCP server handing out a single address and a default gateway
> answering ARP requests. Making the modem firmware take care of the DHCP
> requests will just complicate this (it can be done, but I do not see the
> point). Run your own DHCP server on the ethernet LAN interface instead,
> using a config based on the MBIM IP configuraton data. The rest is
> plain IP forwarding between the ethernet and MBIM interface: A default
> route out the MBIM interface and a /32 host route out the ethernet
> interface, using proxy ARP on the ethernet interface to ensure that it
> will answer requests for the (fake) gateway address. Alternatively you
> can configure the gateway address on the ethernet interface, but it will
> then become unreachable for the connected host. Whether that is a
> problem or not is another question, but it does make the setup less
//Markus - The panama-hat hacker
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the libmbim-devel