Ethernet-briding a MBIM-interface

Markus Gothe nietzsche at
Tue Oct 28 00:52:33 PDT 2014

I’ve a patch for with improved ARP-handling and setting the mac source,
 which gives me a DHCP-lease when briding a device…
I’ll try more when I got everything at my hands. Running Linux inside a VM isn’t a good test case.


On 28 Oct 2014, at 08:41 , Bjørn Mork <bjorn at> wrote:

> Markus Gothe <nietzsche at> writes:
>> The rationale for having a null mac adress as the ethernet source
>> adress would be nice to know.
> This just wasn't given much thought.  I couldn't imagine where it would
> make a difference, and not copying anything seemed like slightly less
> work than copying something which wouldn't matter anyway. The driver
> give the frames to usbnet_skb_return() which does eth_type_trans() on
> them.  This pulls the ethernet header from the skb after looking at the
> h_proto and h_dest fields.  I obviously didn't think about what happens
> to frames being snooped or bridged...
>> Wouldnt it be better to keep it the same as the ethernet destination
>> adress (like some CDC ECM implementations)??? This is afaik to be
>> considered a bug. :-)
> Yes, that would be more consistent also with the IFF_NOARP frames coming
> from the modem.  I believe we can change this if you can point to any
> use case where it actually matters.  I'm not sure I care enough to try
> to push the change without any justification.
> Is bridging such a use case?  Would it sort of work if the source
> address was saner?
> Bjørn
> _______________________________________________
> libmbim-devel mailing list
> libmbim-devel at

//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: <>

More information about the libmbim-devel mailing list