Re: [PATCH net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

On Tue, 2016-07-19 at 16:54 +0200, Kristian Evensen wrote:

The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device
to
export. In addition, these devices export a REST API which can be used
to
control the type of device. So far, on Linux, the devices have been
seen as
RNDIS or CDC Ether.

When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the
devices
(at least on all firmware revisions I have found) use the bogus MAC
when
sending traffic routed from external networks. And as a final feature,
the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this
behavior,
with several different PIDs and MAC addresses.

This patch tries to improve the handling of ZTE devices by doing the
following:

* Create a new driver_info-struct that is used by ZTE devices that do
not
have an explicit entry in the product table. This struct is the same
as the
default cdc_ether driver info, but a new bind- and an
rx_fixup-function
have been added.

* In the new bind function, we check if we have read a random MAC from
the
device. If we have, then we generate a new random MAC address. This
will
ensure that all devices get a unique MAC.

* The rx_fixup-function replaces the destination MAC address in the
skb
with that of the device. I have not seen a revision of these devices
that
behaves correctly (i.e., sets the right destination MAC), so I chose
not to
do any comparison with for example the known, bogus addresses.

* The MF823/MF832/MF910 sometimes export cdc carrier on twice on
connect
(the correct behavior is off then on). Work around this by manually
setting
carrier to off if an on-notification is received and the NOCARRIER-bit
is
not set.

This change will affect all devices, but it should take care of
similar
mistakes made by other manufacturers. I tried to think of/look/test
for
problems/regressions that could be introduced by this behavior, but
could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.

I have tested this patch with multiple revisions of all three devices,
and
they behave as expected. In other words, they all got a valid, random
MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and
did
not find any problems/regressions caused by the two general changes.

v2->v3:
* I had forgot to remove the random MAC generation from
usbnet_cdc_bind()
(thanks Olive).
* Rework logic in the ZTE bind-function a bit.

v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have
a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the
default
behavior of ZTE CDC Ether devices (thanks Lars Melin).

Signed-off-by: Kristian Evensen <redacted>

Acked-by: Oliver Neukum <oneukum@suse.com>