Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #82236 > unrolled thread

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

Started byRoland Rosenfeld <roland@debian.org>
First post2024-04-16 09:40 +0200
Last post2024-05-10 11:30 +0200
Articles 13 — 5 participants

Back to article view | Back to linux.debian.kernel


Contents

  Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Roland Rosenfeld <roland@debian.org> - 2024-04-16 09:40 +0200
    Processed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB  ethernet AX88179 device name eth0 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-16 15:00 +0200
    Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Salvatore Bonaccorso <carnil@debian.org> - 2024-04-16 15:00 +0200
      Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Roland Rosenfeld <roland@debian.org> - 2024-04-16 16:50 +0200
        Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Diederik de Haas <didi.debian@cknow.org> - 2024-04-16 17:10 +0200
          Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Roland Rosenfeld <roland@debian.org> - 2024-04-16 20:40 +0200
            Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Salvatore Bonaccorso <carnil@debian.org> - 2024-04-16 22:40 +0200
            Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Roland Rosenfeld <roland@debian.org> - 2024-05-10 11:30 +0200
              Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0 Salvatore Bonaccorso <carnil@debian.org> - 2024-05-10 15:00 +0200
    Processed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB  ethernet AX88179 device name eth0 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-16 22:40 +0200
    Bug#1069082: Confirm bug Hank Barta <hbarta@gmail.com> - 2024-04-17 17:40 +0200
      Bug#1069082: Confirm bug Hank Barta <hbarta@gmail.com> - 2024-04-17 18:00 +0200
    Processed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB  ethernet AX88179 device name eth0 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-05-10 11:30 +0200

#82236 — Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

FromRoland Rosenfeld <roland@debian.org>
Date2024-04-16 09:40 +0200
SubjectBug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
Message-ID<ItLA5-6CrE-5@gated-at.bofh.it>
Package: src:linux
Version: 6.1.85-1
Severity: important

Dear Maintainer,

when upgrading from 6.1.76-1 to 6.1.85-1 my USB ethernet device
 ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
is no longer named enx00249bXXXXXX but eth0.

I see the following in dmsg:

[    1.484345] usb 4-5: Manufacturer: ASIX Elec. Corp.
[    1.484661] usb 4-5: SerialNumber: 0000249BXXXXXX
[    1.496312] ax88179_178a 4-5:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-5, ASIX AX88179 USB 3.0 Gigabit Ethernet, d2:60:4c:YY:YY:YY
[    1.497746] usbcore: registered new interface driver ax88179_178a

Unplugging and plugging again does not solve the issue, but the
interface still is named eth0.

Maybe it has to do with the following commit from
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.85

commit fc77240f6316d17fc58a8881927c3732b1d75d51
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Wed Apr 3 15:21:58 2024 +0200

    net: usb: ax88179_178a: avoid the interface always configured as random address
    
    commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream.
    
    After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
    consecutive device resets"), reset is not executed from bind operation and
    mac address is not read from the device registers or the devicetree at that
    moment. Since the check to configure if the assigned mac address is random
    or not for the interface, happens after the bind operation from
    usbnet_probe, the interface keeps configured as random address, although the
    address is correctly read and set during open operation (the only reset
    now).
    
    In order to keep only one reset for the device and to avoid the interface
    always configured as random address, after reset, configure correctly the
    suitable field from the driver, if the mac address is read successfully from
    the device registers or the devicetree. Take into account if a locally
    administered address (random) was previously stored.
    
    cc: stable@vger.kernel.org # 6.6+
    Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets")
    Reported-by: Dave Stevenson  <dave.stevenson@raspberrypi.com>
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240403132158.344838-1-jtornosm@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Seems, that I'm not alone with this issue, there are also reports in
https://www.reddit.com/r/debian/comments/1c304xn/linuximageamd64_61851_usb_link_interface_names/
and https://infosec.space/@topher/112276500329020316


All other (pci based) network interfaces still use there static names
(enp0s25, enp2s0, enp3s0), only the usb ethernet name is broken with
the new kernel.

Greetings
Roland


-- Package-specific info:
** Version:
Linux version 6.1.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-20-amd64 root=/dev/mapper/ssd-root ro

** Not tainted

** Loaded modules:
[...]
ax88179_178a           36864  0
usbnet                 57344  1 ax88179_178a
mii                    16384  2 usbnet,ax88179_178a
[...]

** Network status:
*** IP interfaces and addresses:
[...]
11: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:24:9b:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet6 fe80::224:9bff:feXX:XXXX/64 scope link 
       valid_lft forever preferred_lft forever
[...]

** USB devices:
[...]
Bus 004 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
[...]

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-20-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.1.0-20-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod                                    30+20221128-1
ii  linux-base                              4.9

Versions of packages linux-image-6.1.0-20-amd64 recommends:
ii  apparmor             3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-20-amd64 suggests:
pn  debian-kernel-handbook  <none>
ii  grub-efi-amd64          2.06-13+deb12u1
pn  linux-doc-6.1           <none>

Versions of packages linux-image-6.1.0-20-amd64 is related to:
pn  firmware-amd-graphics     <none>
pn  firmware-atheros          <none>
pn  firmware-bnx2             <none>
pn  firmware-bnx2x            <none>
pn  firmware-brcm80211        <none>
pn  firmware-cavium           <none>
pn  firmware-intel-sound      <none>
pn  firmware-intelwimax       <none>
pn  firmware-ipw2x00          <none>
pn  firmware-ivtv             <none>
pn  firmware-iwlwifi          <none>
pn  firmware-libertas         <none>
pn  firmware-linux-nonfree    <none>
pn  firmware-misc-nonfree     <none>
pn  firmware-myricom          <none>
pn  firmware-netxen           <none>
pn  firmware-qlogic           <none>
pn  firmware-realtek          <none>
pn  firmware-samsung          <none>
pn  firmware-siano            <none>
pn  firmware-ti-connectivity  <none>
pn  xen-hypervisor            <none>

[toc] | [next] | [standalone]


#82243 — Processed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2024-04-16 15:00 +0200
SubjectProcessed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
Message-ID<ItQzL-6Ftv-3@gated-at.bofh.it>
In reply to#82236
Processing control commands:

> tags -1 + moreinfo
Bug #1069082 [src:linux] linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
Added tag(s) moreinfo.

-- 
1069082: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069082
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#82244

FromSalvatore Bonaccorso <carnil@debian.org>
Date2024-04-16 15:00 +0200
Message-ID<ItQzL-6Ftv-1@gated-at.bofh.it>
In reply to#82236
Control: tags -1 + moreinfo

Hi Roland,

On Tue, Apr 16, 2024 at 09:29:28AM +0200, Roland Rosenfeld wrote:
> Package: src:linux
> Version: 6.1.85-1
> Severity: important
> 
> Dear Maintainer,
> 
> when upgrading from 6.1.76-1 to 6.1.85-1 my USB ethernet device
>  ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
> is no longer named enx00249bXXXXXX but eth0.
> 
> I see the following in dmsg:
> 
> [    1.484345] usb 4-5: Manufacturer: ASIX Elec. Corp.
> [    1.484661] usb 4-5: SerialNumber: 0000249BXXXXXX
> [    1.496312] ax88179_178a 4-5:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-5, ASIX AX88179 USB 3.0 Gigabit Ethernet, d2:60:4c:YY:YY:YY
> [    1.497746] usbcore: registered new interface driver ax88179_178a
> 
> Unplugging and plugging again does not solve the issue, but the
> interface still is named eth0.
> 
> Maybe it has to do with the following commit from
> https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.85
> 
> commit fc77240f6316d17fc58a8881927c3732b1d75d51
> Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Date:   Wed Apr 3 15:21:58 2024 +0200
> 
>     net: usb: ax88179_178a: avoid the interface always configured as random address
>     
>     commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream.
>     
>     After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
>     consecutive device resets"), reset is not executed from bind operation and
>     mac address is not read from the device registers or the devicetree at that
>     moment. Since the check to configure if the assigned mac address is random
>     or not for the interface, happens after the bind operation from
>     usbnet_probe, the interface keeps configured as random address, although the
>     address is correctly read and set during open operation (the only reset
>     now).
>     
>     In order to keep only one reset for the device and to avoid the interface
>     always configured as random address, after reset, configure correctly the
>     suitable field from the driver, if the mac address is read successfully from
>     the device registers or the devicetree. Take into account if a locally
>     administered address (random) was previously stored.
>     
>     cc: stable@vger.kernel.org # 6.6+
>     Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets")
>     Reported-by: Dave Stevenson  <dave.stevenson@raspberrypi.com>
>     Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
>     Reviewed-by: Simon Horman <horms@kernel.org>
>     Link: https://lore.kernel.org/r/20240403132158.344838-1-jtornosm@redhat.com
>     Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Seems, that I'm not alone with this issue, there are also reports in
> https://www.reddit.com/r/debian/comments/1c304xn/linuximageamd64_61851_usb_link_interface_names/
> and https://infosec.space/@topher/112276500329020316
> 
> 
> All other (pci based) network interfaces still use there static names
> (enp0s25, enp2s0, enp3s0), only the usb ethernet name is broken with
> the new kernel.

If you revert that commit, does that fix your issue? Note that it
opens up again as well the referenced issue, but it would be helpfull
for reporting as regression if we know that's the case.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]


#82245

FromRoland Rosenfeld <roland@debian.org>
Date2024-04-16 16:50 +0200
Message-ID<ItSid-6GBX-1@gated-at.bofh.it>
In reply to#82244
Hi Salvatore!

On Di, 16 Apr 2024, Salvatore Bonaccorso wrote:

> > Maybe it has to do with the following commit from
> > https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.85
> > 
> > commit fc77240f6316d17fc58a8881927c3732b1d75d51
> > Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> > Date:   Wed Apr 3 15:21:58 2024 +0200
> > 
> >     net: usb: ax88179_178a: avoid the interface always configured as random address
> >     
> >     commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream.
> >     
> >     After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
> >     consecutive device resets"), reset is not executed from bind operation and
> >     mac address is not read from the device registers or the devicetree at that
> >     moment. Since the check to configure if the assigned mac address is random
> >     or not for the interface, happens after the bind operation from
> >     usbnet_probe, the interface keeps configured as random address, although the
> >     address is correctly read and set during open operation (the only reset
> >     now).
> >     
> >     In order to keep only one reset for the device and to avoid the interface
> >     always configured as random address, after reset, configure correctly the
> >     suitable field from the driver, if the mac address is read successfully from
> >     the device registers or the devicetree. Take into account if a locally
> >     administered address (random) was previously stored.
> >     
> >     cc: stable@vger.kernel.org # 6.6+
> >     Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets")
> >     Reported-by: Dave Stevenson  <dave.stevenson@raspberrypi.com>
> >     Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> >     Reviewed-by: Simon Horman <horms@kernel.org>
> >     Link: https://lore.kernel.org/r/20240403132158.344838-1-jtornosm@redhat.com
> >     Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> >     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > Seems, that I'm not alone with this issue, there are also reports in
> > https://www.reddit.com/r/debian/comments/1c304xn/linuximageamd64_61851_usb_link_interface_names/
> > and https://infosec.space/@topher/112276500329020316
> > 
> > 
> > All other (pci based) network interfaces still use there static names
> > (enp0s25, enp2s0, enp3s0), only the usb ethernet name is broken with
> > the new kernel.

> If you revert that commit, does that fix your issue? Note that it
> opens up again as well the referenced issue, but it would be helpfull
> for reporting as regression if we know that's the case.

I didn't try this out myself, but according to
https://unix.stackexchange.com/questions/774594/debian-12-all-of-sudden-my-usb3-lan-adapter-get-assigned-random-mac-address-ea
the root cause comes from the following patch:

https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.77
commit 5c4cbec5106d2f3c055ad138165e60a73f5b355c
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Mon Nov 20 13:11:41 2023 +0100

    net: usb: ax88179_178a: avoid two consecutive device resets
    
    [ Upstream commit d2689b6a86b9d23574bd4b654bf770b6034e2c7e ]
    
    The device is always reset two consecutive times (ax88179_reset is called
    twice), one from usbnet_probe during the device binding and the other from
    usbnet_open.
    
    Remove the non-necessary reset during the device binding and let the reset
    operation from open to keep the normal behavior (tested with generic ASIX
    Electronics Corp. AX88179 Gigabit Ethernet device).
    
    Reported-by: Herb Wei <weihao.bj@ieisystem.com>
    Tested-by: Herb Wei <weihao.bj@ieisystem.com>
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Link: https://lore.kernel.org/r/20231120121239.54504-1-jtornosm@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>


A.B says on stackexchange, that both patches have to be reverted to
make this working again.

I did not yet try this out myself, because I use precompiled kernels
for ages and have to re-learn again how to patch and build a kernel.

Greetings
Roland

[toc] | [prev] | [next] | [standalone]


#82246

FromDiederik de Haas <didi.debian@cknow.org>
Date2024-04-16 17:10 +0200
Message-ID<ItSBz-6GYh-15@gated-at.bofh.it>
In reply to#82245

[Multipart message — attachments visible in raw view] — view raw

On Tuesday, 16 April 2024 16:41:46 CEST Roland Rosenfeld wrote:
> A.B says on stackexchange, that both patches have to be reverted to
> make this working again.
> 
> I did not yet try this out myself, because I use precompiled kernels
> for ages and have to re-learn again how to patch and build a kernel.

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes a procedure with which you can apply (the attached) patches

HTH

[toc] | [prev] | [next] | [standalone]


#82251

FromRoland Rosenfeld <roland@debian.org>
Date2024-04-16 20:40 +0200
Message-ID<ItVSN-6IUh-5@gated-at.bofh.it>
In reply to#82246
Hi Salvatore and Diederik!

On Di, 16 Apr 2024, Salvatore Bonaccorso wrote:

> If you revert that commit, does that fix your issue? Note that it
> opens up again as well the referenced issue, but it would be helpfull
> for reporting as regression if we know that's the case.

Thanks to the support by Diederik, I was able to build a new kernel
with the two patches reverted and this kernel solves the issue and
uses the correct MAC and renames the interface to enx<mac> as before
instead of using a random MAC and using eth0 as the inerface name.

On Di, 16 Apr 2024, Diederik de Haas wrote:

> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> describes a procedure with which you can apply (the attached) patches

Thanks for this hint and pointing to the perfect chapter, which made
building a test kernel really easy.

I used the two patches, that you suggested, they are exactly the
reverse of the two problem patches, that lead us to this issue.

Greetings
Roland

[toc] | [prev] | [next] | [standalone]


#82254

FromSalvatore Bonaccorso <carnil@debian.org>
Date2024-04-16 22:40 +0200
Message-ID<ItXKV-6K2F-3@gated-at.bofh.it>
In reply to#82251
Control: forwarded -1 https://lore.kernel.org/regressions/Zh7flXvNdDfattD9@eldamar.lan/T/#u

Hi both,

On Tue, Apr 16, 2024 at 08:31:23PM +0200, Roland Rosenfeld wrote:
> Hi Salvatore and Diederik!
> 
> On Di, 16 Apr 2024, Salvatore Bonaccorso wrote:
> 
> > If you revert that commit, does that fix your issue? Note that it
> > opens up again as well the referenced issue, but it would be helpfull
> > for reporting as regression if we know that's the case.
> 
> Thanks to the support by Diederik, I was able to build a new kernel
> with the two patches reverted and this kernel solves the issue and
> uses the correct MAC and renames the interface to enx<mac> as before
> instead of using a random MAC and using eth0 as the inerface name.
> 
> On Di, 16 Apr 2024, Diederik de Haas wrote:
> 
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> > describes a procedure with which you can apply (the attached) patches
> 
> Thanks for this hint and pointing to the perfect chapter, which made
> building a test kernel really easy.
> 
> I used the two patches, that you suggested, they are exactly the
> reverse of the two problem patches, that lead us to this issue.

Many thanks for testing!

I have forward your found regression to the regressions list:

https://lore.kernel.org/regressions/Zh7flXvNdDfattD9@eldamar.lan/T/#u

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]


#82399

FromRoland Rosenfeld <roland@debian.org>
Date2024-05-10 11:30 +0200
Message-ID<ICuJH-cmjZ-7@gated-at.bofh.it>
In reply to#82251
Control: fixed -1 6.1.90+1

In the meantime I upgraded to linux-image-6.1.0-21-amd64 (6.1.90+1).
With this version the issue is solved for me.

Greetings
Roland

[toc] | [prev] | [next] | [standalone]


#82401

FromSalvatore Bonaccorso <carnil@debian.org>
Date2024-05-10 15:00 +0200
Message-ID<ICy0V-cof2-5@gated-at.bofh.it>
In reply to#82399
Hi Roland,

On Fri, May 10, 2024 at 11:18:17AM +0200, Roland Rosenfeld wrote:
> Control: fixed -1 6.1.90+1
> 
> In the meantime I upgraded to linux-image-6.1.0-21-amd64 (6.1.90+1).
> With this version the issue is solved for me.

Thanks for confirming. I in fact missed to add the bug closer for this
in the changelog once the upstream patch got indeed backported as well
to the 6.1.y series.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]


#82255 — Processed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2024-04-16 22:40 +0200
SubjectProcessed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
Message-ID<ItXKV-6K2F-1@gated-at.bofh.it>
In reply to#82236
Processing control commands:

> forwarded -1 https://lore.kernel.org/regressions/Zh7flXvNdDfattD9@eldamar.lan/T/#u
Bug #1069082 [src:linux] linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
Set Bug forwarded-to-address to 'https://lore.kernel.org/regressions/Zh7flXvNdDfattD9@eldamar.lan/T/#u'.

-- 
1069082: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069082
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#82263 — Bug#1069082: Confirm bug

FromHank Barta <hbarta@gmail.com>
Date2024-04-17 17:40 +0200
SubjectBug#1069082: Confirm bug
Message-ID<Iufy9-6Vc6-3@gated-at.bofh.it>
In reply to#82236

[Multipart message — attachments visible in raw view] — view raw

I can confirm that I have experienced this on a Debian Bookworm install but
am unable to duplicate it at the moment. The kernel installed is

```text
hbarta@sutyzam:~$ uname -a
Linux sutyzam 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1
(2024-02-01) x86_64 GNU/Linux
hbarta@sutyzam:~$
```

In addition to the changing MAC, I recall that the device name (presently
`enx0050b6239f84`) was also changing. That seems to make sense as the
device name was derived from the MAC address `00:50:b6:23:9f:84`.

I was able to work around this using a .link file in `/etc/systemd/network`
and matching on the driver, reported by `ethtool` as:

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

`lsusb` reports it as

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

And this is the "Amazon Basics" USB3/1Gb adapter.

best,

-- 
Beautiful Sunny Winfield

[toc] | [prev] | [next] | [standalone]


#82264 — Bug#1069082: Confirm bug

FromHank Barta <hbarta@gmail.com>
Date2024-04-17 18:00 +0200
SubjectBug#1069082: Confirm bug
Message-ID<IufRv-6Vit-1@gated-at.bofh.it>
In reply to#82263
(Resending using "plain text mode due to misunderstanding Google
settings to accomplish this.)

I can confirm that I have experienced this on a Debian Bookworm
install but am unable to duplicate it at the moment. The kernel
installed is

```text
hbarta@sutyzam:~$ uname -a
Linux sutyzam 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1
(2024-02-01) x86_64 GNU/Linux
hbarta@sutyzam:~$
```

In addition to the changing MAC, I recall that the device name
(presently `enx0050b6239f84`) was also changing. That seems to make
sense as the device name was derived from the MAC address
`00:50:b6:23:9f:84`.

I was able to work around this using a .link file in
`/etc/systemd/network` and matching on the driver, reported by
`ethtool` as:

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

`lsusb` reports it as

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

And this is the "Amazon Basics" USB3/1Gb adapter.

best,


-- 
Beautiful Sunny Winfield

[toc] | [prev] | [next] | [standalone]


#82398 — Processed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2024-05-10 11:30 +0200
SubjectProcessed: Re: Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
Message-ID<ICuJH-cmjZ-5@gated-at.bofh.it>
In reply to#82236
Processing control commands:

> fixed -1 6.1.90+1
Bug #1069082 [src:linux] linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0
The source 'linux' and version '6.1.90+1' do not appear to match any binary packages
Marked as fixed in versions linux/6.1.90+1.

-- 
1069082: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069082
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web