[Bug 1779173] Re: Dell D6000 dock lacks multicast Ethernet functionality

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)

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/1779173

Title:
Dell D6000 dock lacks multicast Ethernet functionality

Status in Linux:
Confirmed
Status in linux package in Ubuntu:
Triaged

Bug description:
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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1779173/+subscriptions