| frank@frank-G5:~$ grep -r 'vlan' /{lib,run,etc}/udev/hwdb.d/
grep: /run/udev/hwdb.d/: Datei oder Verzeichnis nicht gefunden
frank@frank-G5:~$ grep -r 'ethext' /{lib,run,etc}/udev/hwdb.d/
grep: /run/udev/hwdb.d/: Datei oder Verzeichnis nicht gefunden
frank@frank-G5:~$ grep -r 'rename' /{lib,run,etc}/udev/hwdb.d/
grep: /run/udev/hwdb.d/: Datei oder Verzeichnis nicht gefunden
frank@frank-G5:~$ grep -r '00:e0:4c:68:00:0e' /{lib,run,etc}/udev/hwdb.d/
grep: /run/udev/hwdb.d/: Datei oder Verzeichnis nicht gefunden
frank@frank-G5:~$
|
ohne Suchstring wirds zu viel...scheint auch nicht daher zu kommen...
ich nehme an, das ethext1 hat er (udev) noch irgendwo gecached und da die mac vom vlan gleich ist, versucht er selbe regel darauf nochmal anzuwenden und da das nicht geht, nimmt er renameX als pseudo-wert
oh...
| frank@frank-G5:~$ grep -r '00:e0:4c:68:00:0e' /{lib,run,etc}/udev/
/etc/udev/rules.d/12-techole-net.rules:SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:e0:4c:68:00:0e", NAME="ethext1"
|
ich hatte da ja noch ne udev-regel angelegt :p jetzt muss ich nur noch sicherstellen, dass diese nur für das host-interface verwendet wird...
habe versucht, via
| udevadm info --attribute-walk /sys/class/net/ethext1
|
einen Unterschied zwischen dem host und dem vlan herauszufinden, dabei scheint sich aber udevadm aufzuhängen und das ganze system friert ein (maus geht noch, aber es lässt nur noch bedingt etwas starten)...
über dmesg habe ich noch herausfinden können, dass der task_worker für mehr als 120 sekunden geblockt wurde
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 | [ 242.747332] INFO: task kworker/u24:0:8 blocked for more than 120 seconds.
[ 242.747341] Tainted: G O 5.3.0-26-generic #28~18.04.1-Ubuntu
[ 242.747343] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 242.747347] kworker/u24:0 D 0 8 2 0x80004000
[ 242.747400] Workqueue: events_power_efficient reg_check_chans_work [cfg80211]
[ 242.747403] Call Trace:
[ 242.747413] __schedule+0x2a8/0x670
[ 242.747418] schedule+0x33/0xa0
[ 242.747421] schedule_preempt_disabled+0xe/0x10
[ 242.747426] __mutex_lock.isra.9+0x26d/0x4e0
[ 242.747431] ? __switch_to_asm+0x34/0x70
[ 242.747436] ? __switch_to_asm+0x34/0x70
[ 242.747440] ? __switch_to_asm+0x40/0x70
[ 242.747445] __mutex_lock_slowpath+0x13/0x20
[ 242.747448] ? __mutex_lock_slowpath+0x13/0x20
[ 242.747451] mutex_lock+0x2f/0x40
[ 242.747456] rtnl_lock+0x15/0x20
[ 242.747491] reg_check_chans_work+0x2f/0x3a0 [cfg80211]
[ 242.747500] process_one_work+0x1fd/0x3f0
[ 242.747505] worker_thread+0x34/0x410
[ 242.747509] kthread+0x121/0x140
[ 242.747514] ? process_one_work+0x3f0/0x3f0
[ 242.747517] ? kthread_park+0xb0/0xb0
[ 242.747523] ret_from_fork+0x35/0x40
|
das für einige andere prozesse auch...
anhand von den ganze call-traces scheint es ein bug im netzwertreiber der karte zu sein
[ 242.748333] __netlink_dump_start+0x51/0x1d0
[ 242.748337] ? rtnl_xdp_prog_skb+0x60/0x60
[ 242.748340] rtnetlink_rcv_msg+0x200/0x340
[ 242.748345] ? enqueue_entity+0x111/0x650
[ 242.748348] ? rtnl_xdp_prog_skb+0x60/0x60
[ 242.748352] ? rtnl_calcit.isra.30+0x120/0x120
[ 242.748357] netlink_rcv_skb+0x51/0x120
[ 242.748361] rtnetlink_rcv+0x15/0x20
[ 242.748366] netlink_unicast+0x1a4/0x250
[ 242.748371] netlink_sendmsg+0x2d7/0x3d0
[ 242.748377] sock_sendmsg+0x63/0x70
dieses rtnl/rtnetlink/netlink ist fast in jedem calltrace drin...scheint dieser (bzw. ähnlicher) Bug zu sein: https://bugzilla.kernel.org/show_bug.cgi?id=200977
der adapter ist dieser
https://smile.amazon.de/gp/product/B0792S3SMB/ref=ppx_yo_dt_b_search_asin_image?ie=UTF8&psc=1
lt. lsusb:
Bus 002 Device 003: ID 0bda:8153 Realtek Semiconductor Corp.
https://linux-hardware.org/index.php?id=usb:0bda-8153
um es etwas abzukürzen habe ich mal einen anderen usb2eth adapter probiert und dort auf gleiche Art & Weise ein vlan angelegt:
6: enx3c18a003c3a4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 3c:18:a0:03:c3:a4 brd ff:ff:ff:ff:ff:ff
7: vlan500@enx3c18a003c3a4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 3c:18:a0:03:c3:a4 brd ff:ff:ff:ff:ff:ff
scheint also wirklich an der udev-rule zu liegen.
habe nun die regel mal deaktiviert und siehe da, das vlan bleibt wie es ist...jetzt muss ich nur noch herausfinden, wie ich meine regel nur auf das host-device anwende
vorher habe ich mal geschaut, was "udevadm monitor --property" dazu sagt (da bei walk sich das system verabschieded)
UDEV [13062.879148] add /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.4/2-3.4:1.0/net/ethext1 (net)
ACTION=add
DELL_MAC_PASSTHROUGH=1
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.4/2-3.4:1.0/net/ethext1
ID_BUS=usb
ID_MM_CANDIDATE=1
ID_MODEL=USB_10_100_1000_LAN
ID_MODEL_ENC=USB\x2010\x2f100\x2f1000\x20LAN
ID_MODEL_FROM_DATABASE=RTL8153 Gigabit Ethernet Adapter
ID_MODEL_ID=8153
ID_NET_DRIVER=r8152
ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
ID_NET_NAME=enp0s20f0u3u4
ID_NET_NAME_MAC=enx00e04c68000e
ID_NET_NAME_PATH=enp0s20f0u3u4
ID_OUI_FROM_DATABASE=REALTEK SEMICONDUCTOR CORP.
ID_PATH=pci-0000:00:14.0-usb-0:3.4:1.0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_3_4_1_0
ID_REVISION=3000
ID_SERIAL=Realtek_USB_10_100_1000_LAN_000001
ID_SERIAL_SHORT=000001
ID_TYPE=generic
ID_USB_DRIVER=r8152
ID_USB_INTERFACES=:ffff00:020600:0a0000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=Realtek
ID_VENDOR_ENC=Realtek
ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Corp.
ID_VENDOR_ID=0bda
IFINDEX=8
INTERFACE=ethext1
INTERFACE_OLD=eth0
SEQNUM=4661
SUBSYSTEM=net
SYSTEMD_ALIAS=/sys/subsystem/net/devices/ethext1
TAGS=:systemd:
USEC_INITIALIZED=13062871945
hier sehen die werte für ID_MODEL_ID=8153 und ID_NET_DRIVER=r8152 vielversprechend aus (denke so sind die nicht beim vlan dabei)...nur ist das format nicht wie in der udev-regel. das funktioniert nicht:
SUBSYSTEM=="net", ACTION=="add", ID_NET_DRIVER=="r8152", ATTR{address}=="00:e0:4c:68:00:0e", NAME="ethext1"