Ethernet-briding a MBIM-interface

[Markus Gothe]

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?

//M
 
On 23 Oct 2014, at 13:41 , Bjørn Mork <bjorn at mork.no> wrote:

> Markus Gothe <nietzsche at lysator.liu.se> writes:
> 
>> Hi,
>> 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
> transparent.
> 
> 
> Bjørn



//Markus - The panama-hat hacker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20141023/561ab691/attachment.sig>