Dell system takes a long time to connect network with external dock

I would like to propose to write a rule to rename a removable Realtek 8153 interface with ID_NET_NAME_PATH instead of ID_NET_NAME_MAC.

The solution may impact users using Realtek 8153 and manipulate it by the interface name since the name is not consistent and will change when switching USB port. Networkmanager is not affected since it identifies interfaces via UUID.

So, am I understanding right that such a system will have two ethernet interfaces with identical mac addresses? Isn't that an obvious problem that should be fixed instead?

On Thu, 26 Sep 2019 at 20:11, Dan Streetman <email address hidden> wrote:
>
> So, am I understanding right that such a system will have two ethernet
> interfaces with identical mac addresses? Isn't that an obvious problem
> that should be fixed instead?

Digging into this, It seems that it is an explicitly supported
configuration that was added in 2016
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579984

Ie. the dock copies the MAC address of the laptop, such that the same
lease is still usable.

Thus the timeouts now observed, are a regression of said feature.

--
Regards,

Dimitri.

> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579984

http://patchwork.ozlabs.org/patch/631759/
"Just resubmit it and I'll apply it, I'm so tired of hearing about this..."

lol I'm relieved to see dmiller and others upstream had exactly the same concerns as me :)

If he decided wasn't bad enough to reject it's good enough for me, although it is still a really bad design.

I think the 73-usb-net-by-mac.rules needs to be changed to account for this weird situation, let's see what Debian thinks.

There is 73-special-net-names.rules which 73-usb-net-by-mac.rules was split from, and it'll execute prior to 73-usb-net-by-mac.rules.

We can keep the fixed internal MAC passthrough interface using MAC address as interface name, and let removable dongles using pathname by adding following line to 73-special-net-names.rules.

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", NAME=="", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="8153", ATTRS{removable}=="removable", IMPORT{builtin}="net_id", NAME="$env{ID_NET_NAME_PATH}"

@cktenn that could work (using special-net-names), however I'm concerned that the rule should not apply to all r8152 devices, everywhere, on everyone's systems. It should apply *only* on Dell systems where this magical MAC passthrough is enabled. What can be checked to see if the system is a Dell with the special MAC passthrough enabled?

Alternately, if the only problem is 73-usb-net-by-mac.rules fails due to the system having multiple nics with the same mac, that rule could be adjusted to check if an interface with the name already exists, and if so don't try re-setting it (since that would fail). That might be an easier sell to Debian.

What do you think?

@Dan

I've submitted a merge request to Debian that only applies to Dell system the idea mentioned in comment #4, it modifies the rule 73-special-net-names.rules.

https://salsa.debian.org/systemd-team/systemd/merge_requests/55

Please help to review this.

Thanks @cktenn - I commented there and also opened https://salsa.debian.org/systemd-team/systemd/merge_requests/56, but I have not tested with that, can you see if that fixes this problem? Assuming I'm understanding the problem correctly, that you just want 73-special-net-names.rules to ignore the second duplicated-mac interface.

@ddstreet

Based on https://salsa.debian.org/systemd-team/systemd/merge_requests/56#note_113429, is https://salsa.debian.org/systemd-team/systemd/merge_requests/55 suitable for the SRU workaround?

> Based on https://salsa.debian.org/systemd-team/systemd/merge_requests/56#note_113429,
> is https://salsa.debian.org/systemd-team/systemd/merge_requests/55 suitable for the
> SRU workaround?

Have you actually tested this using an affected system? I'm concerned that changing to use by-path naming will result in a different interface name, for the same adapter, when it's plugged into a different usb port. That doesn't matter for internal (either on-board or in-dock) usb adapters, since their device path never changes, but for people with dell systems and a separate usb nic with this usb vendor/product id, this would be a serious regression if their interface name changes 1) after simply upgrading systemd, and they reboot or hotplug their nic, even if they plug it into the same usb port; and 2) every time they hotplug the usb nic into a different usb port (or use a usb hub, etc.)

I would like to explain the original intention of the design in the udev rule.

Since it is not possible letting two NICs to have the same ifname, I tend to find a way to assign a persistent name that would not duplicate on a system for each usbnet. It is meant to break the current rule, so I was trying to reduce the number of potential victims. I found that people using NetworkManager, which identifies connections by UUID, won't be affected. Restrict the system vendor also helps to mitigate the impact.

I admit unsetting the duplicated ifname does solve the original issue without regression in a real case.

Ok, so just to clarify, the only issue here is the delay/failure for the system to finish bringing its networking up, right? The exact name of the second "duplicated mac" interface doesn't really matter?

Yes, since it will be the same result as udev failed to rename it, it doesn't matter.

@cktenn could you try the systemd package for either bionic and/or disco from here:
https://launchpad.net/~ddstreet/+archive/ubuntu/systemd

That includes:
https://git.launchpad.net/~ubuntu-support-team/ubuntu/+source/systemd/commit/?id=173071ae695e11c1549656a7b40d2201681e733e

I don't love it, but I think that is the 'least bad' way of handling this without affecting any current users.

Also I marked this invalid for Eoan, as the retry-interface-renaming has been removed in Eoan; @cktenn can you test there and verify this bug doesn't exist for Eoan?

@ddstreet

Tested on bionic/disco/eoan. All of them do not rename the second usbnet with MAC passthrough function, it keeps ifname eth0.

Thank you so much.

Hello Che, or anyone else affected,

Accepted systemd into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/240-6ubuntu5.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus-bind-exporter/unknown (armhf)
php7.2/7.2.24-0ubuntu0.19.04.1 (armhf)
gvfs/1.40.1-1ubuntu0.1 (ppc64el)
pdns-recursor/unknown (armhf)
webhook/unknown (armhf)
munin/2.0.47-1ubuntu3 (armhf, arm64)
systemd/240-6ubuntu5.8 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

I can confirm that systemd 240-6ubuntu5.8 fixes this issue for me on disco.

Hello Che, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.32 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
linux/unknown (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

I can confirm that systemd 237-3ubuntu10.32 fixes this issue for me on disco.

Hello Che, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

I can confirm that systemd 237-3ubuntu10.33 fixes this issue for me on bionic.

All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64)
dovecot/1:2.2.33.2-1ubuntu4.5 (armhf)
umockdev/0.11.1-1 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

This bug was fixed in the package systemd - 240-6ubuntu5.8

---------------
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
    Fix regression introduced by
    resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
    DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
    allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
    do not request Content-Length if Transfer-Encoding is chunked
    (LP: #1847527)
  * d/t/storage: fix flaky test
    (LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
    debian/extra/rules/73-usb-net-by-mac.rules:
    fix rename delay for systems using "Dell MAC passthrough"
    (LP: #1843381)
  * d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
    d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
    ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
    - Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
    - only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
    fix test breakage due to running in nested lxd container
    (LP: #1845337)

 -- Dan Streetman <email address hidden> Fri, 04 Oct 2019 09:06:58 -0400

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package systemd - 237-3ubuntu10.33

---------------
systemd (237-3ubuntu10.33) bionic; urgency=medium

  * d/p/lp1852754/0001-network-do-not-re-set-MTU-when-current-and-requested.patch,
    d/p/lp1852754/0002-network-call-link_acquire_conf-and-link_enter_join_n.patch,
    d/p/lp1852754/0003-network-prohibit-to-set-MTUBytes-and-UseMTU-simultan.patch:
    - Complete link setup after setting mtu (LP: #1852754)

systemd (237-3ubuntu10.32) bionic; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
    Fix regression introduced by
    resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
    DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/fix-typo-lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch:
    - Fix typo in previous patch
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
    - allow sync_file_range2 in nspawn container
      (LP: #1840640)
  * d/p/lp1783994-dissect-Don-t-count-RPMB-and-boot-partitions-8609.patch:
    - avoid systemd-gpt-auto-generator failure if mmc dev present
      (LP: #1783994)
  * d/p/lp1832672-resolved-rework-parsing-of-etc-hosts.patch:
    - do not fail entire file on error when parsing /etc/hosts
    - parse # char anywhere in line as start of comment
      (LP: #1832672)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
    debian/extra/rules/73-usb-net-by-mac.rules:
    - fix rename delay for systems using "Dell MAC passthrough"
      (LP: #1843381)
  * d/p/lp1849733/0001-resolved-longlived-TCP-connections.patch,
    d/p/lp1849733/0002-resolved-line-split-dns_stream_new-function-signatur.patch,
    d/p/lp1849733/0003-resolved-add-some-assert-s.patch,
    d/p/lp1849733/0004-stream-track-type-of-DnsStream-object.patch,
    d/p/lp1849733/0005-llmnr-add-comment-why-we-install-no-complete-handler.patch,
    d/p/lp1849733/0006-resolved-restart-stream-timeout-whenever-we-managed-.patch,
    d/p/lp1849733/0007-resolved-only-call-complete-with-zero-argument-in-LL.patch,
    d/p/lp1849733/0008-resolved-add-comment-to-dns_stream_complete-about-it.patch,
    d/p/lp1849733/0009-resolved-keep-stub-stream-connections-up-for-as-long.patch,
    d/p/lp1849733/0010-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
    d/p/lp1849733/0011-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch,
    d/p/lp1849733/0012-resolved-add-new-accessor-dns_stream_take_read_packe.patch,
    d/p/lp1849733/0013-resolve-do-not-complete-stream-transaction-when-it-i.patch:
    - add TCP pipelining to handle getaddrinfo() fallback to TCP
    - ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
    - Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/p/lp1850704/0001-networkd-Unify-set-MTU.patch,
    d/p/lp1850704/0002-network-drop-redundant-lines.patch:
    - Fix setting mtu if interface already up (LP: #1850704)
  * d/extra/dhclient-enter-resolved-hook:
    - only restart resolved if dhclient conf changed (LP: #1805183)

 -- Dan Streetman <email address hidden> Fri, 15 Nov 2019 10:01:16 -0500