From: "Bjørn Mork" <bjorn@mork.no>
To: Bobby Jones <rjones@gateworks.com>
Cc: netdev@vger.kernel.org
Subject: Re: Toby MPCI - L201 cellular modem http hang after random MAC address assignment
Date: Fri, 27 Mar 2020 22:47:09 +0100 [thread overview]
Message-ID: <871rpdeahu.fsf@miraculix.mork.no> (raw)
In-Reply-To: <CALAE=UDvPU-MBX5B7NU1A7WPq1gofUnr8Rf+v81AxHLLcZhMvA@mail.gmail.com> (Bobby Jones's message of "Mon, 23 Mar 2020 10:21:36 -0700")
Bobby Jones <rjones@gateworks.com> writes:
>> --- a/drivers/net/usb/rndis_host.c
>> +++ b/drivers/net/usb/rndis_host.c
>> @@ -428,7 +428,11 @@ generic_rndis_bind(struct usbnet *dev, struct usb_interface *intf, int flags)
>> dev_err(&intf->dev, "rndis get ethaddr, %d\n", retval);
>> goto halt_fail_and_release;
>> }
>> - memcpy(net->dev_addr, bp, ETH_ALEN);
>> +
>> + if (bp[0] & 0x02)
>> + eth_hw_addr_random(net);
>> + else
>> + ether_addr_copy(net->dev_addr, bp);
>>
>> /* set a nonzero filter to enable data transfers */
>> memset(u.set, 0, sizeof *u.set);
>
> I know that there is some internal routing done by the modem firmware,
> and I'm assuming that overwriting the MAC address breaks said routing.
> Can anyone suggest what a proper fix would be?
That change should not break anything that wasn't already broken, given
that the driver allows userspace to set any valid ethernet address.
But I'm sure you're right that the modem doesn't like it. Since the
patch also fixed a real problem, then I guess we need to add a device
specific workaround for this modem.
I know exactly nothing about RNDIS and have no such device. But looking
at this now I wonder if the driver should have informed the device about
any adress changes? I note that we have an
RNDIS_OID_802_3_CURRENT_ADDRESS, which is unused by the usb host driver.
Looking at the rndis gadget driver, I also note that it would refuse
setting RNDIS_OID_802_3_CURRENT_ADDRESS, Which probably means that any
Linux based device would fail if we tried that. So it's probably not
a good idea as a workaround even if it helped your case. Which is very
unlikely after all. Don't even know if that's how it was supposed to
be.
Oh well. Just add a device specific exception. Look at the
RNDIS_DRIVER_DATA_POLL_STATUS thing and do something similar for this
case, avoiding the unwanted address update
Bjørn
prev parent reply other threads:[~2020-03-27 21:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 17:21 Toby MPCI - L201 cellular modem http hang after random MAC address assignment Bobby Jones
2020-03-27 20:56 ` Bobby Jones
2020-03-27 21:47 ` Bjørn Mork [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871rpdeahu.fsf@miraculix.mork.no \
--to=bjorn@mork.no \
--cc=netdev@vger.kernel.org \
--cc=rjones@gateworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).