icon against anything, and the network_applet says "Connecting..."
This all worked fine two days ago in Londoni (and here is texas a week
ago with eduroam) It also worked find at home this morning. .
On 14/12/19 7:38 am, William Unruh wrote:
icon against anything, and the network_applet says "Connecting..."
This all worked fine two days ago in Londoni (and here is texas a week
ago with eduroam) It also worked find at home this morning. .
I can sympathies with the problem.
In spite of BitTwisters heroic efforts, my network ethernet is not functioning as it did in Mga6
My net_applet tool tip says Network is up...etc
IPv6 address: 192.168.1.100... that's already not good
This morning there is no net_applet right click menu to enable shutdown. After the next boot there maybe, it seems erratic.
When it does work, I can shut down the ethernet port but then I need to bring up network centre to restart it - actually re-setup the network
Once upon a time I could right click on task bar icon - select
disconnect network. right click on the task bar icon - select reconnect network. All this has gone.
I don't shut it down anymore.. There are bugs, maybe hardware specific.
I do not understand why "that's already not good" ?
IPv6 address: is just poor coding if ipv6 is disabled.
192.168.1.100 is a valid ipv4 address especially on a system where it
is the static ip address for the Internet nic.
I would have assumed you would be able to just click the connect/disconnect button would get the nic back online.
Next time you get in that condition, get to a root prompt and use ifconfig
to bring up/check the nic status. Example: ifconfig enp0s31f6 up
and ifconfig enp0s31f6 when you want to check status.
It's a exercise in chasing goalposts. I don't think you can win.
So checking I find once again the last update has slipped in a rogue script
network-scripts]$ ls -l ifcfg*
-rw-r--r-- 1 root root 45 Dec 13 14:44 ifcfg-enp0s20f0u1
-rwxr-xr-x 1 root root 257 Dec 15 08:28 ifcfg-enp0s31f6*
-rw-r--r-- 1 root root 254 Feb 15 2019 ifcfg-lo
Every time this happens there are network problems.
When I get network nonsense I check for the extra script.
Pretty much never fails
Next time you get in that condition, get to a root prompt and use ifconfig >> to bring up/check the nic status. Example: ifconfig enp0s31f6 up
and ifconfig enp0s31f6 when you want to check status.
NIC is down
~]$ /usr/sbin/ifconfig $_net_nic
enp0s31f6: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 1c:1b:0d:a4:b2:8f txqueuelen 1000 (Ethernet)
RX packets 645 bytes 226088 (220.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 812 bytes 101524 (99.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xf7700000-f7720000
~]$ /usr/sbin/ifconfig $_net_nic up
SIOCSIFFLAGS: Operation not permitted
[permissions thing?]
All right. I can assume at that point hardware detection found a nic
at a new address ifcfg-enp0s20f0u1. It is funny that the execute bit
is not set.
hwinfo can be used to get hardware information. enp Nic name is made up
of its bus/slot/id value. As root
hwinfo | grep 'Ethernet controller' | grep ': PCI'
Do we assume you are deleting enp0s20f0u1 file.
On 15/12/19 10:20 am, Bit Twister wrote:
All right. I can assume at that point hardware detection found a nic
at a new address ifcfg-enp0s20f0u1. It is funny that the execute bit
is not set.
Well something found something that wasn't there, Bits
Indeed! found but not activated
hwinfo can be used to get hardware information. enp Nic name is made up >> of its bus/slot/id value. As root
hwinfo | grep 'Ethernet controller' | grep ': PCI'
~]# hwinfo | grep 'Ethernet controller' | grep ': PCI'
40: PCI 1f.6: 0200 Ethernet controller
Do we assume you are deleting enp0s20f0u1 file.
Nope!. just renamed it "*.old"
On Mon, 16 Dec 2019 08:47:14 +1100, faeychild wrote:
~]# hwinfo | grep 'Ethernet controller' | grep ': PCI'
40: PCI 1f.6: 0200 Ethernet controller
Ok, only one nic found. Assuming that is slot 3 and eth0 then
we get enp0s31f6. See how that works. :)
On 14/12/19 9:02 am, Bit Twister wrote:
I do not understand why "that's already not good" ?
IPv6 address: is just poor coding if ipv6 is disabled.
If we already have poor coding with the report of an incorrect IPv6
address, then that's not good when coupled with the rest of the quirky bugs
192.168.1.100 is a valid ipv4 address especially on a system where it
is the static ip address for the Internet nic.
Yes! But when reported as an IPv6 address it doers not inspire confidence
I would have assumed you would be able to just click the connect/disconnect >> button would get the nic back online.
Ah Ha! Yes ! you can. The network center pops up. I haven't used it
before. Using this has also re established the right click menu on the "net_applet".
But clicking the "Connect wired ethernet" pops up a root password dialog
Back to that one again.
MCC > Network Allow user to control network is checked
It's a exercise in chasing goalposts. I don't think you can win.
So checking I find once again the last update has slipped in a rogue script
network-scripts]$ ls -l ifcfg*
-rw-r--r-- 1 root root 45 Dec 13 14:44 ifcfg-enp0s20f0u1
-rwxr-xr-x 1 root root 257 Dec 15 08:28 ifcfg-enp0s31f6*
-rw-r--r-- 1 root root 254 Feb 15 2019 ifcfg-lo
Every time this happens there are network problems.
When I get network nonsense I check for the extra script.
Pretty much never fails
Next time you get in that condition, get to a root prompt and use ifconfig >> to bring up/check the nic status. Example: ifconfig enp0s31f6 up
and ifconfig enp0s31f6 when you want to check status.
NIC is down
~]$ /usr/sbin/ifconfig $_net_nic
enp0s31f6: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 1c:1b:0d:a4:b2:8f txqueuelen 1000 (Ethernet)
RX packets 645 bytes 226088 (220.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 812 bytes 101524 (99.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xf7700000-f7720000
~]$ /usr/sbin/ifconfig $_net_nic up
SIOCSIFFLAGS: Operation not permitted
[permissions thing?]
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; generated)
Active: failed (Result: exit-code) since Sun 2019-12-15 08:23:04
AEDT; 48s ago
Docs: man:systemd-sysv-generator(8)
Process: 1175 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
Dec 15 08:23:04 unimatrix.cryptid ifplugd(enp0s31f6)[3909]: Using
interface enp0s31f6/1C:1B:0D:A4:B2:8F with driver <e1000e> (version: 3.2.> Dec 15 08:23:04 unimatrix.cryptid ifplugd(enp0s31f6)[3909]: Using
detection mode: SIOCETHTOOL
Dec 15 08:23:04 unimatrix.cryptid ifplugd(enp0s31f6)[3909]:
Initialization complete, link beat not detected.
Dec 15 08:23:04 unimatrix.cryptid network[1175]: Bringing up interface enp0s31f6: [ OK ]
Dec 15 08:23:04 unimatrix.cryptid systemd[1]: network.service: Control process exited, code=exited, status=1/FAILURE
Dec 15 08:23:04 unimatrix.cryptid systemd[1]: network.service: Failed
with result 'exit-code'.
Dec 15 08:23:04 unimatrix.cryptid systemd[1]: Failed to start LSB: Bring up/down networking.
Dec 15 08:23:10 unimatrix.cryptid ifplugd(enp0s31f6)[3909]: Link beat detected.
Dec 15 08:23:11 unimatrix.cryptid ifplugd(enp0s31f6)[3909]: Executing '/etc/ifplugd/ifplugd.action enp0s31f6 up'.
Dec 15 08:23:15 unimatrix.cryptid ifplugd(enp0s31f6)[3909]: Program
executed successfully.
Despite the alarming message the network does come up OK
"Failed to start LSB" is a kernel message I get three times during boot, with time outs.
At least I now know where they are coming from. :-)
regards
On Mon, 16 Dec 2019 08:47:14 +1100, faeychild wrote:
On 15/12/19 10:20 am, Bit Twister wrote:
All right. I can assume at that point hardware detection found a nic
at a new address ifcfg-enp0s20f0u1. It is funny that the execute bit
is not set.
Well something found something that wasn't there, Bits
Indeed! found but not activated
hwinfo can be used to get hardware information. enp Nic name is made up
of its bus/slot/id value. As root
hwinfo | grep 'Ethernet controller' | grep ': PCI'
~]# hwinfo | grep 'Ethernet controller' | grep ': PCI'
40: PCI 1f.6: 0200 Ethernet controller
Ok, only one nic found. Assuming that is slot 3 and eth0 then
we get enp0s31f6. See how that works. :)
If you have not been swapping out or changing location of pci cards
that does NOT look good that enp0s20f0u1 was created.
Do we assume you are deleting enp0s20f0u1 file.
Nope!. just renamed it "*.old"
That will bite you every time when script hunts for something like
ifcfg-*
Been there, seen it happen more than once. Anytime I want to back up
a configuration file I will create a bk_up sub-directory and copy or
move file into bk_up/
Changing execute bit does not always disable a drop in/configuration file. For ifcfg-* files you would have to edit it, and change the onboot to no.
Look at /sys/class/net to find out the nic names other then lo.
If it's a usb connected ethernet device, moving it from one usb slot to another will change the slot, and device name.
If the system only has one ethernet interface, net.ifnames=0 can be<snip for the brain file as well>
added to
the kernel cmdline so the nic will remain as eth0 instead of being
renamed to
match the pci slot. That's what I have on this installation.
That is not a script it is simply a list of environment variables used
by the script (eg ifup-eth) to set up the netwok on the device
enp0s13f6. Does your machine have two ethernet cards?
I have also never seen the f0u1 or f6 type of label. What kind of
ethernet cards do you have?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 291 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 143:02:52 |
| Calls: | 6,611 |
| Calls today: | 1 |
| Files: | 12,159 |
| Messages: | 5,310,438 |