linux.git/drivers/net/usb/cdc_ether.c, branch v4.9

cdc_ether: Fix handling connection notification

2016-12-02T18:40:09+00:00

Commit bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")
introduced a work-around in usbnet_cdc_status() for devices that exported
cdc carrier on twice on connect. Before the commit, this behavior caused
the link state to be incorrect. It was assumed that all CDC Ethernet
devices would either export this behavior, or send one off and then one on
notification (which seems to be the default behavior).

Unfortunately, it turns out multiple devices sends a connection
notification multiple times per second (via an interrupt), even when
connection state does not change. This has been observed with several
different USB LAN dongles (at least), for example 13b1:0041 (Linksys).
After bfe9b9d2df66, the link state has been set as down and then up for
each notification. This has caused a flood of Netlink NEWLINK messages and
syslog to be flooded with messages similar to:

cdc_ether 2-1:2.0 eth1: kevent 12 may have been dropped

This commit fixes the behavior by reverting usbnet_cdc_status() to how it
was before bfe9b9d2df66. The work-around has been moved to a separate
status-function which is only called when a known, affect device is
detected.

v1->v2:

* Do not open-code netif_carrier_ok() (thanks Henning Schild).
* Call netif_carrier_off() instead of usb_link_change(). This prevents
calling schedule_work() twice without giving the work queue a chance to be
processed (thanks Bjørn Mork).

Fixes: bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")
Reported-by: Henning Schild 
Signed-off-by: Kristian Evensen 
Signed-off-by: David S. Miller

cdc_ether: Improve ZTE MF823/831/910 handling

2016-07-25T05:16:03+00:00

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.

v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).

v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* 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 
Acked-by: Oliver Neukum 
Signed-off-by: David S. Miller

cdc-acm: fix NULL pointer reference

2016-01-10T02:00:24+00:00

The union descriptor must be checked. Its usage was conditional
before the parser was introduced. This is important, because
many RNDIS device, which also use the common parser, have
bogus extra descriptors.

Signed-off-by: Oliver Neukum 
Tested-by: Vasily Galkin 
Signed-off-by: David S. Miller

net: usb: cdc_ether: add Dell DW5580 as a mobile broadband adapter

2015-11-16T19:58:39+00:00

Since Dell DW5580 is a 3G modem, this patch adds the device as a
mobile broadband adapter

Signed-off-by: Daniele Palmas 
Signed-off-by: David S. Miller

cdc-ether: switch to common CDC parser

2015-09-15T19:43:27+00:00

This patch uses the common parser to parse extra CDC
headers in order to reduce code duplication.

Signed-off-by: Oliver Neukum 
Signed-off-by: David S. Miller

drivers/net/usb: add device id for NVIDIA Tegra USB 3.0 Ethernet

2015-07-09T06:58:20+00:00

This device is sold as 'NVIDIA Tegra USB 3.0 Ethernet'.
Chipset is RTL8153 and works with r8152.

Signed-off-by: Zheng Liu 
Signed-off-by: David S. Miller

net/usb/r8152: add device id for Lenovo TP USB 3.0 Ethernet

2015-03-31T21:15:37+00:00

This device is sold as 'Lenovo Tinkpad USB 3.0 Ethernet 4X90E51405'.
Chipset is RTL8153 and works with r8152.

Signed-off-by: Christian Hesse 
Signed-off-by: David S. Miller

cdc-ether: implement MULTICAST flag on the device

2014-11-07T20:17:45+00:00

Olivier having laid the groundwork this patch transmits the
multicast flag to the device to save some bus traffic.

Signed-off-by: Oliver Neukum 
Signed-off-by: David S. Miller

cdc-ether: handle promiscuous mode with a set_rx_mode callback

2014-10-28T21:26:20+00:00

Promiscuous mode was not supported anymore with my Lenovo adapters
(RTL8153) since commit c472ab68ad67db23c9907a27649b7dc0899b61f9
(cdc-ether: clean packet filter upon probe).

It was not possible to use them in a bridge anymore.

Signed-off-by: Olivier Blin 
Also-analyzed-by: Loïc Yhuel 
Signed-off-by: David S. Miller

cdc-ether: extract usbnet_cdc_update_filter function

2014-10-28T21:26:19+00:00

This will be used by the set_rx_mode callback.

Also move a comment about multicast filtering in this new function.

Signed-off-by: Olivier Blin 
Signed-off-by: David S. Miller