I’ve got this situation. I have CalDigit TS3 thunderbolt 3 Dock. It has a gigabit LAN card in it.
If I boot my laptop while dock is attached, Network Interface is not created (i.e. ifconfig -a dos not show the interface). But if I check Yast hardware information, it says that drivers (module igb) are loaded.
However, If I attach (or re-attach) the dock after system has booted, it works just fine.
Is there a way to manfully initiate/create network interface?
With the laptop in the dock, show the output of
/usr/sbin/hwinfo --netcard
or
/sbin/lspci -nnk|grep '\02' -A3
and
/sbin/ifconfig -a
If the network device node is not present, then the device is effectively inhibited so not available for the kernel to enumerate/use.
Hi, here’s the output right after booting the laptop with the dock attached:
/usr/sbin/hwinfo --netcard26: PCI 200.0: 0282 WLAN controller
[Created at pci.378]
Unique ID: y9sn.EMhO8DU4670
Parent ID: z8Q3.Gk8dpL0ks1F
SysFS ID: /devices/pci0000:00/0000:00:1c.0/0000:02:00.0
SysFS BusID: 0000:02:00.0
Hardware Class: network
Model: "Broadcom BCM43602 802.11ac Wireless LAN SoC"
Vendor: pci 0x14e4 "Broadcom"
Device: pci 0x43ba "BCM43602 802.11ac Wireless LAN SoC"
SubVendor: pci 0x1028 "Dell"
SubDevice: pci 0x0020
Revision: 0x01
Driver: "brcmfmac"
Driver Modules: "brcmfmac", "brcmfmac"
Device File: wlan0
Features: WLAN
Memory Range: 0xdd800000-0xdd807fff (rw,non-prefetchable)
Memory Range: 0xdd400000-0xdd7fffff (rw,non-prefetchable)
IRQ: 155 (4029 events)
HW Address: 48:e2:44:f4:bb:5b
Permanent HW Address: 48:e2:44:f4:bb:5b
Link detected: yes
WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140
WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 5.18 5.2 5.22 5.24 5.26 5.28 5.3 5.32 5.5 5.52 5.54 5.56 5.58 5.6 5.62 5.64 5.66 5.68 5.7
WLAN encryption modes: WEP40 WEP104 TKIP CCMP
WLAN authentication modes: open sharedkey wpa-psk wpa-eap
Module Alias: "pci:v000014E4d000043BAsv00001028sd00000020bc02sc80i00"
Driver Info #0:
Driver Status: brcmfmac is active
Driver Activation Cmd: "modprobe brcmfmac"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #16 (PCI bridge)
39: PCI b00.0: 0200 Ethernet controller
[Created at pci.378]
Unique ID: IluS.Z6BiwDRtMw9
Parent ID: cuhJ.pr9IP4gA3e9
SysFS ID: /devices/pci0000:00/0000:00:1d.6/0000:06:00.0/0000:07:01.0/0000:09:00.0/0000:0a:00.0/0000:0b:00.0
SysFS BusID: 0000:0b:00.0
Hardware Class: network
Model: "Intel I210 Gigabit Network Connection"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x1533 "I210 Gigabit Network Connection"
SubVendor: pci 0x1ab6 "CalDigit, Inc."
SubDevice: pci 0x0212
Revision: 0x03
Memory Range: 0xc4100000-0xc41fffff (rw,non-prefetchable)
I/O Ports: 0xb000-0xbfff (rw,disabled)
Memory Range: 0xc4200000-0xc4203fff (rw,non-prefetchable)
Memory Range: 0xc4000000-0xc40fffff (ro,non-prefetchable,disabled)
IRQ: 19 (no events)
Module Alias: "pci:v00008086d00001533sv00001AB6sd00000212bc02sc00i00"
Driver Info #0:
Driver Status: igb is active
Driver Activation Cmd: "modprobe igb"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #35 (PCI bridge)
and
ifconfig -a lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:2978 errors:0 dropped:0 overruns:0 frame:0
TX packets:2978 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:148900 (145.4 Kb) TX bytes:148900 (145.4 Kb)
virbr0 Link encap:Ethernet HWaddr 52:54:00:3B:0C:95
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
virbr0-ni Link encap:Ethernet HWaddr 52:54:00:3B:0C:95
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
virbr1 Link encap:Ethernet HWaddr 52:54:00:C3:3A:F1
inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
virbr1-ni Link encap:Ethernet HWaddr 52:54:00:C3:3A:F1
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wlan0 Link encap:Ethernet HWaddr 48:E2:44:F4:BB:5B
inet addr:192.168.1.23 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::4ae2:44ff:fef4:bb5b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2980 errors:0 dropped:185 overruns:0 frame:0
TX packets:2696 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1835741 (1.7 Mb) TX bytes:510632 (498.6 Kb)
So, as I was saying, hardware is detected, but network interface is not created.
Perhaps if the external network device isn’t quie ready when the system boots. What happens when you reload the driver manually with
modprobe -r igp;modprobe igp
Is the ethernet device node then present?
If this works, then perhaps it could be incorporated into boot.local. Another idea I had was to re-initialise the device using the approach described here
https://forums.opensuse.org/showthread.php/525950-e1000e-failed-after-zypper-update?p=2831151#post2831151
again automating by way of a boot script if necessary.
Thank you for the tips. I’ll try them out when I get back home tonight.
Hi again,
the modprobe didn’t work. However, “Softreboot” (removing pci device and re-scanning) did create the p1p1 network interface. Problem is, the interface does not receive the IP from DHCP. Assigning static IP doesn’t help either, can’t even ping my router. Restarting NetworkManager service does not help. Switching from Network Manager to Wicked with DHCP does not help, manually defining IP with Wicked does not help.
The only thing that seems to work - unplugging and re-plugging thunderbolt cable. Are the any other command I can try to reinitialise the network interface without re-plugging the cable?
For the case of using wicked, do you have a configuration existing specifically for this device yet? If not, create one via YaST, and the ‘STARTMODE=’ option may be important here too eg 'STARTMODE=‘ifplugd’
For Network Manager, is the connection profile for the wired ethernet set up to automatically connect?
However, “Softreboot” (removing pci device and re-scanning) did create the p1p1 network interface. Problem is, the interface does not receive the IP from DHCP. Assigning static IP doesn’t help either, can’t even ping my router.
Assuming wicked, what happens when you do this manually?
wicked ifup <interface_device>
The status can be reported using
wicked status all
or just specifiy the device concerned eg for eth0…
wicked status eth0
If the interface can be brought up like this, then it should be possible to add it to after.local (and making sure that after-local.service is enabled), so that it is brought up after the device as been warm-booted earlier via boot.local. YMMV.
I’m not sure I understood this. I haven’t used wicked before. What I did was, open Yast, go to Network settings, switch from Network Manager Service to Wicket Service and set my p1p1 interface to get IP from DHCP and rebooted. Am I suppose to set some environmental variable as well?
What do you mean by
? If I plug in thunderbolt cable after the system has booted - p1p1 interface gets IP from DHCP and works just fine.
If using wicked, there are options under the ‘Network Card Setup’ that allow ‘On Cable Connection’, ‘On hotplug’ etc. That’s what I was referring to. You can check the current config in /etc/sysconfig/network/ifcfg-…
To save confusion though, you should just say whether you’re using wicked or NM. If NM the above does not apply.
Thanks for your patience. I normally use NM, but I don’t mind too much switching to wicked, if that solves my problem. At the moment, I’ve switched to wicked. after doing ifdown and ifup I get
larry@xps9550:~> sudo wicked ifstatus p1p1
wicked: ifcfg-br0: bridge config contains wireless variables
p1p1 setup-in-progress
link: #3, state device-up, mtu 1500
type: ethernet, hwaddr 64:4b:f0:01:91:f6
config: compat:suse:/etc/sysconfig/network/ifcfg-p1p1
leases: ipv4 dhcp requesting
and it never get’s the IP
config file is this
BOOTPROTO='dhcp'
BROADCAST=''
DHCLIENT_SET_DEFAULT_ROUTE='yes'
ETHTOOL_OPTIONS=''
IFPLUGD_PRIORITY='0'
IPADDR=''
MTU=''
NAME='I210 Gigabit Network Connection'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='ifplugd'
PREFIXLEN='24'
Interesting. I guess we need to understand why the lease never comes.
You could try monitoring the system journal with something like
journalctl -f|grep wicked
then watch while doing this in another terminal
wicked ifup p1p1
I wonder if toggling it would make any difference…
wicked ifdown p1p1; wicked ifup p1p1
config file is this
BOOTPROTO='dhcp' BROADCAST='' DHCLIENT_SET_DEFAULT_ROUTE='yes' ETHTOOL_OPTIONS='' IFPLUGD_PRIORITY='0' IPADDR='' MTU='' NAME='I210 Gigabit Network Connection' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='ifplugd' PREFIXLEN='24'
That looks fine to me.
If tried ifdown then ifup, it didn’t make a difference. I’ll try monitoring logs tonight and see if it gives any clues.
Ok, and maybe try this too…
wicked test dhcp4 p1p1
If wicked is restarted, I assume that will work too?
systemctl restart wicked
Wirdly enough, nothing helped (ifdown/ifup, restarting wicked service). Journal sais:
Aug 10 09:06:14 mypc wickedd-dhcp4[2132]: unable to confirm lease Aug 10 09:06:17 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-000031000000
Aug 10 09:06:27 mypc wickedd-dhcp4[2132]: unable to confirm lease
Aug 10 09:06:31 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-000031000000
Aug 10 09:06:41 mypc wickedd-dhcp4[2132]: unable to confirm lease
Aug 10 09:06:45 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-000031000000
Aug 10 09:06:56 mypc wickedd-dhcp4[2132]: unable to confirm lease
Aug 10 09:06:59 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-000031000000
Aug 10 09:07:03 mypc sudo[24385]: me : TTY=pts/6 ; PWD=/home/me ; USER=root ; COMMAND=/usr/sbin/wicked ifdown p1p1
Aug 10 09:07:03 mypc wickedd-dhcp4[2132]: p1p1: Request to release DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-000031000000: releasing...
Aug 10 09:07:05 mypc sudo[24568]: me : TTY=pts/6 ; PWD=/home/me ; USER=root ; COMMAND=/usr/sbin/wicked ifup p1p1
Aug 10 09:07:05 mypc wicked[24571]: ifcfg-br0: bridge config contains wireless variables
Aug 10 09:07:11 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000
Aug 10 09:07:21 mypc wickedd-dhcp4[2132]: unable to confirm lease
Aug 10 09:07:25 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000
Aug 10 09:07:34 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000
Aug 10 09:07:42 mypc sudo[24906]: me : TTY=pts/6 ; PWD=/home/me ; USER=root ; COMMAND=/usr/sbin/wicked test dhcp4 p1p1
Aug 10 09:07:43 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000
Aug 10 09:07:45 mypc wicked[24907]: p1p1: Request to acquire DHCPv4 lease with UUID 2ef88b59-208d-0900-4b61-000001000000
Aug 10 09:07:52 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000
Aug 10 09:07:55 mypc wicked[24907]: p1p1: DHCP4 discovery failed
Aug 10 09:08:01 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000
Aug 10 09:08:10 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000
Aug 10 09:08:14 mypc sudo[25159]: me : TTY=pts/6 ; PWD=/home/me ; USER=root ; COMMAND=/usr/bin/systemctl restart wicked
Aug 10 09:08:14 mypc systemd[1]: Stopping wicked managed network interfaces...
Aug 10 09:08:14 mypc wickedd-dhcp4[2132]: wlan0: Request to release DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-000005000000: releasing...
Aug 10 09:08:14 mypc wickedd-dhcp4[2132]: p1p1: Request to release DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000de020000: releasing...
Aug 10 09:08:21 mypc wicked[25166]: wlan0 device-ready
Aug 10 09:08:21 mypc wicked[25166]: p1p1 device-ready
Aug 10 09:08:21 mypc systemd[1]: Stopped wicked managed network interfaces.
Aug 10 09:08:22 mypc systemd[1]: Starting wicked managed network interfaces...
Aug 10 09:08:22 mypc wicked[25491]: ifcfg-br0: bridge config contains wireless variables
Aug 10 09:08:27 mypc wickedd-dhcp4[2132]: wlan0: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000ec020000
Aug 10 09:08:28 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000ed020000
Aug 10 09:08:32 mypc wickedd-dhcp4[2132]: wlan0: Committed DHCPv4 lease with address 192.168.1.23 (lease time 600 sec, renew in 300 sec, rebind in 525 sec)
Aug 10 09:08:39 mypc wickedd-dhcp4[2132]: unable to confirm lease
Aug 10 09:08:44 mypc wickedd-dhcp4[2132]: p1p1: defer timeout 15 reached (state INIT)
Aug 10 09:08:45 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000ed020000
Aug 10 09:08:52 mypc wicked[25491]: lo up
Aug 10 09:08:52 mypc wicked[25491]: wlan0 up
Aug 10 09:08:52 mypc wicked[25491]: p1p1 setup-in-progress
Aug 10 09:08:52 mypc wicked[25491]: eth0 no-device
Aug 10 09:08:52 mypc systemd[1]: Started wicked managed network interfaces.
Aug 10 09:08:54 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000ed020000
Aug 10 09:09:03 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000ed020000
Aug 10 09:09:14 mypc wickedd-dhcp4[2132]: unable to confirm lease
Aug 10 09:09:17 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000ed020000
Aug 10 09:09:27 mypc wickedd-dhcp4[2132]: unable to confirm lease
Aug 10 09:09:31 mypc wickedd-dhcp4[2132]: p1p1: Request to acquire DHCPv4 lease with UUID 37d18b59-6eff-0300-8408-0000ed020000
I note from an earlier post that there is a bridge config…
larry@xps9550:~> sudo wicked ifstatus p1p1
wicked: ifcfg-br0: bridge config contains wireless variables
Is the bridge interface associated with the physical p1p1 interface? (This might not have anything to do with the problem, but best to get a complete picture here.)
I’m not sure what “ifcfg-br0” is. It is not a network interface. My guess it is something to do with KVM (virtualisation) or VitualBox. I can try disabling NIC’s on virtual machines to see if “ifcfg-br0” goes away.
But, peculiar thing is this. If I boot my laptop with dock attached, remove and re-scan pci device, end up in the situation where NIC does not get IP from DHCP and then simply remove and re-attach (no reboot required) the thunderbolt cable - NIC works just fine, obtains IP from DHCP with no extra configuration.
No, that will be the reason this virtual interface exists. I assume it’s the wlan0 interface that is bridged?
But, peculiar thing is this. If I boot my laptop with dock attached, remove and re-scan pci device, end up in the situation where NIC does not get IP from DHCP and then simply remove and re-attach (no reboot required) the thunderbolt cable - NIC works just fine, obtains IP from DHCP with no extra configuration.
Yes, that is strange.
Let’s examine the link status following the warm boot. I don’t actually expect to see a problem with this as wicked would not initiate a DHCP request without the ethernet device being ready at layer 1. Anyway…
/sbin/ethtool p1p1
I did check that. It does say that link is detected.
Unless wicked is doing something in the background. I definitely did not set up any bridging between p1p1 and wifi interfaces.