Dell D6000 dock lacks multicast Ethernet functionality

[Miguel Rodríguez]

Dell D6000 exposes a CDC_NCM device for Ethernet traffic. However, multicast Ethernet traffic is not processed making IPv6 not functional. Other services, like mDNS used for LAN service discovery are also hindered.

The actual reason is that CDC_NCM driver was not processing requests to filter (admit) multicast traffic. I provide two patches to the linux kernel that admit all Ethernet multicast traffic whenever a multicast group is being joined.

The solution is not optimal, as it makes the system receive more traffic than that strictly needed, but otherwise this only happens when the computer is connected to a dock and thus is running on AC power. I believe it is not worth the hassle to join only the requested groups. This is the same that is done in the CDN_ETHER driver.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1779173

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[miguel (miguel-linux-kernel-bugs)]

Created attachment 276977
[PATCH 1/2] Hook into usbnet_change_mtu respecting usbnet driver_info

Dell D6000 exposes a CDC_NCM device for Ethernet traffic. However, multicast Ethernet traffic is not processed making IPv6 not functional. Other services, like mDNS used for LAN service discovery are also hindered.

The actual reason is that CDC_NCM driver was not processing requests to filter (admit) multicast traffic. I provide two patches to the linux kernel that admit all Ethernet multicast traffic whenever a multicast group is being joined.

The solution is not optimal, as it makes the system receive more traffic than that strictly needed, but otherwise this only happens when the computer is connected to a dock and thus is running on AC power. I believe it is not worth the hassle to join only the requested groups. This is the same that is done in the CDN_ETHER driver.

[miguel (miguel-linux-kernel-bugs)]

Created attachment 276979
[PATCH 2/2] Admit multicast traffic

[greg (greg-linux-kernel-bugs)]

On Thu, Jun 28, 2018 at 05:03:57PM +0000, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=200331
>
> Bug ID: 200331
> Summary: CDC NCM driver does not process multicast Ethernet
> traffic
> Product: Drivers
> Version: 2.5
> Kernel Version: 4.15

All USB bugs should be sent to the <email address hidden> mailing
list, and not entered into bugzilla. Please bring this issue up there,
if it is still a problem in the latest kernel release.

[Joseph Salisbury (jsalisbury)]

Thank you for providing a patch, and making Ubuntu better.

Can you provide some information on the status of the patch with regards to getting it merged upstream? Has it been sent upstream, what sort of feedback has it received, is it getting applied to a subsystem maintainer's tree, etc?

People affected by this bug are probably wondering why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a stable kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.

To submit your patch, send your patch with the detailed description/changelog and your Signoff (ending with Signed-off-by: your name <email>), to the emails listed from ./scripts/get_maintainer.pl drivers/SUBSYSTEM-DETAILS (the get_maintainer.pl is from the kernel sources). Once you have sent the patch upstream and it's accepted, please drop a note here so that we can cherry-pick/include the patch into Ubuntu kernel.

[Miguel Rodríguez (migrax)]

Well, the patch, and an updated version has been submitted to the linux-usb list, but sadly most it is not getting much attention. This is the link to the most recent discussion on each patch: https://www.spinics.net/lists/linux-usb/msg170611.html, https://www.spinics.net/lists/linux-usb/msg170603.html, https://www.spinics.net/lists/linux-usb/msg170567.html and https://www.spinics.net/lists/linux-usb/msg170568.html.
I don't know how should I proceed at this point.

[Stefan Bühler (stbuehler)]

I think I've hit the same bug (Debian testing 4.18.0-2-amd64, with an i-tec
docking station: https://i-tec.cz/en/produkt/cadua4kdockpdl-2/, but
same driver and problems: IPv6 RA and IPv4+IPv6 mdns not working).

I think this shows an overview of the patches you submitted:

  https://patchwork.kernel.org/project/linux-usb/list/?submitter=181339&state=%2A&archive=both

It seems patchwork can't figure out a patch series for your patches, and I'm
also lost which patches I'd have to apply if I wanted to try them. Also all
patches are "archived" (no idea what that means, but by default the search
only looks for non-archived patches).

Thanks for your work so far anyway! At least I know now it isn't my fault it
isn't working :)

[Miguel Rodríguez (migrax)]

Just use the ones attached to this bug report. They should work fine.

El 1/12/18 a las 12:03, Stefan Bühler escribió:
> I think I've hit the same bug (Debian testing 4.18.0-2-amd64, with an i-tec
> docking station: https://i-tec.cz/en/produkt/cadua4kdockpdl-2/, but
> same driver and problems: IPv6 RA and IPv4+IPv6 mdns not working).
>
> I think this shows an overview of the patches you submitted:
>
> https://patchwork.kernel.org/project/linux-
> usb/list/?submitter=181339&state=%2A&archive=both
>
> It seems patchwork can't figure out a patch series for your patches, and I'm
> also lost which patches I'd have to apply if I wanted to try them. Also all
> patches are "archived" (no idea what that means, but by default the search
> only looks for non-archived patches).
>
> Thanks for your work so far anyway! At least I know now it isn't my fault it
> isn't working :)
>

[Stefan Bühler (stbuehler)]

Thanks. So I went ahead and created an environment to build some affected
modules out of tree (also includes a dkms package):

    https://github.com/stbuehler/fixed-cdc-ether-ncm

mDNS and IPv6 working fine so far.

[Stefan Bühler (stbuehler)]

As it's rather hard to correctly respond to your mails from web archives I'm simply going to respond
here.

- [v4,1/4] Use dev->intf to get interface information:

  This is imho a bad idea; in cdc_ether `((..)(&dev->data))->control` is not necessarily the same as
  `dev->intf` (the "probed" interface); see the `rndis` quirk handling.

  To export `usbnet_cdc_update_filter` it needs a second parameter for the control interface imho (
  or maybe it needs an explicit field in `struct usbnet`?); this requires a local wrapper function
  so it can be used as set_rx_mode hook.

- [v3,2/4] Export usbnet_cdc_update_filter

  When rewriting the first patch this should probably just get merged into it.

- [v3,3/4] Replace the way cdc_ncm hooks into usbnet_change_mtu

  Many "minidrivers" define their own `struct net_device_ops` set; if you want to refactor that
  you really have to change all of them.

  But I think it looks like the maintainers don't want that (i.e. they want const `net_device_ops`
  data).

  I see only the following option: export usbnet_set_rx_mode and use it in those drivers that use
  the set_rx_mode hook and have their own net_device_ops.

- [v3,4/4] Hook into set_rx_mode to admit multicast traffic

  Fine, but needs to adapt to changes in the other patches (i.e. requires a local function
  that calls `usbnet_cdc_update_filter(dev, dev->intf);`, as in cdc_ncm the control interface
  actually always is the probed interface).

  I think some reviewer asked to add this in all mini drivers, but considering there is no generic
  control interface I don't think that is possible yet.

Right now I'm running this set of patches:
  https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches

I'm not sure why your patches got stuck ("ignored"); but one problem I see is that you didn't
consistently prefix the subject with the subsystems.

Sadly I also have to report that my docking station often resets (i.e. disconnects all devices, then
reconnects); usually just for a few minutes after booting. With my new set of patches I couldn't
reproduce it yet, but I think this might have been broken before your patches too, so not sure
whether it is related in any way.

I also sometimes get scary

    unregister_netdevice: waiting for endock to become free. Usage count = 11

messages (endock is my local interface name), which even prevent the kernel from shutting down.
Perhaps they are related to those messages:

    ACPI Error: Thread 3936419840 cannot release Mutex [PATM] acquired by thread 3940941824 (20180531/exmutex-382)
    ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.ECDV._Q66, AE_AML_NOT_OWNER (20180531/psparse-516)

[Kai-Heng Feng (kaihengfeng)]

Seems like these patches are not in upstream yet.

[Santiago Ruano Rincon (santiago-debian)]

The patches seem to fail on kernel 5.4. This is running on Debian with 5.4.0-2 packaged kernel, and using Stefan's DKMS package:

DKMS make.log for fixed-cdc-ether-ncm-0.1 for kernel 5.4.0-2-amd64 (x86_64)
Thu Jan 16 15:22:17 CET 2020
make: Entering directory '/usr/src/linux-headers-5.4.0-2-amd64'
  AR /var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/built-in.a
  CC [M] /var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/cdc_ether.o
  CC [M] /var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/cdc_ncm.o
  CC [M] /var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/cdc_mbim.o
  CC [M] /var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.o
/var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c: In function 'build_dma_sg':
/var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c:1339:31: error: initialization of 'struct skb_frag_struct *' from incompatible pointer type 'skb_frag_t *' {aka 'struct bio_vec *'} [-Werror=incompatible-pointer-types]
 1339 | struct skb_frag_struct *f = &skb_shinfo(skb)->frags[i];
      | ^
/var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c:1341:30: error: passing argument 1 of 'skb_frag_size' from incompatible pointer type [-Werror=incompatible-pointer-types]
 1341 | total_len += skb_frag_size(f);
      | ^
      | |
      | struct skb_frag_struct *
In file included from /usr/src/linux-headers-5.4.0-2-common/include/linux/if_ether.h:19,
                 from /usr/src/linux-headers-5.4.0-2-common/include/uapi/linux/ethtool.h:19,
                 from /usr/src/linux-headers-5.4.0-2-common/include/linux/ethtool.h:18,
                 from /usr/src/linux-headers-5.4.0-2-common/include/linux/netdevice.h:37,
                 from /var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c:37:
/usr/src/linux-headers-5.4.0-2-common/include/linux/skbuff.h:325:60: note: expected 'const skb_frag_t *' {aka 'const struct bio_vec *'} but argument is of type 'struct skb_frag_struct *'
  325 | static inline unsigned int skb_frag_size(const skb_frag_t *frag)
      | ~~~~~~~~~~~~~~~~~~^~~~
/var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c:1342:33: error: dereferencing pointer to incomplete type 'struct skb_frag_struct'
 1342 | sg_set_page(&urb->sg[i + s], f->page.p, f->size,
      | ^~
/var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c: In function 'usbnet_bh':
/var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c:1530:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
 1530 | kfree(entry->urb->sg);
      | ^~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.c:1531:3: note: here
 1531 | case rx_cleanup:
      | ^~~~
cc1: some warnings being treated as errors
make[5]: *** [/usr/src/linux-headers-5.4.0-2-common/scripts/Makefile.build:271: /var/lib/dkms/fixed-cdc-ether-ncm/0.1/build/drivers/net/usb/usbnet.o] Error 1
make[5]...

[Stefan Bühler (stbuehler)]

Good news everyone - this has been fixed in kernel 5.9-rc1:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=79814d8179b3c62f700196dcbd6a2ca2bb0dd188

Also see https://bugs.debian.org/965074