Ethernet-briding a MBIM-interface
nietzsche at lysator.liu.se
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 mork.no> wrote:
> Markus Gothe <nietzsche at lysator.liu.se> 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?
> libmbim-devel mailing list
> libmbim-devel at lists.freedesktop.org
//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