It would seem that "something" happened to the file(s) that provide RJ45 Ethernet connectivity maybe as far back as F29. I can get a WiFi connection, but not an RJ45 eth0 DHCP connection. This happens in my home and at a nearby computer store, so it's not my DHCP server.
When booted up to WiFi, connecting an RJ45 Ethernet cable shuts down the existing WiFi port (normal), but never comes up with a DHCP address for the eth0 port. The network icon just loops forever. When I disconnect the RJ45 cable, WiFi connectivity resumes after 5-10 seconds.
The problem has persisted since upgrades to both F30 and F31. I'm guessing the best way to fix the problem is a fresh install of whatever packages provide eth0 connectivity. I'm at a loss to know what those packages are, and if there are any hidden potholes/landmines with simply using dnf to first remove then to install them from scratch.
If it matters, I'm using the mate v1.22.2 desktop. Here are all the *mate* packages I have installed:
# rpm -qa | grep mate | sort classmate-1.3.1-7.fc31.noarch f29-backgrounds-extras-mate-29.1.3-3.fc31.noarch f29-backgrounds-mate-29.1.3-3.fc31.noarch f30-backgrounds-extras-mate-30.1.2-2.fc31.noarch f30-backgrounds-mate-30.1.2-2.fc31.noarch f31-backgrounds-mate-31.0.4-1.fc31.noarch fedora-release-matecompiz-31-2.noarch imsettings-mate-1.8.1-2.fc31.x86_64 libmatekbd-1.22.0-2.fc31.x86_64 libmatemixer-1.22.0-2.fc31.x86_64 libmateweather-1.22.1-1.fc31.x86_64 libmateweather-data-1.22.1-1.fc31.noarch mate-applet-softupd-0.4.7-4.fc31.x86_64 mate-applets-1.22.2-1.fc31.x86_64 mate-backgrounds-1.22.0-2.fc31.noarch mate-calc-1.22.2-1.fc31.x86_64 mate-control-center-1.22.2-2.fc31.x86_64 mate-control-center-filesystem-1.22.2-2.fc31.x86_64 mate-desktop-1.22.2-1.fc31.x86_64 mate-desktop-libs-1.22.2-1.fc31.x86_64 mate-dictionary-1.22.2-2.fc31.x86_64 mate-disk-usage-analyzer-1.22.2-2.fc31.x86_64 mate-icon-theme-1.22.2-1.fc31.noarch mate-media-1.22.2-1.fc31.x86_64 mate-menu-19.04.0-2.fc31.noarch mate-menus-1.22.1-1.fc31.x86_64 mate-menus-libs-1.22.1-1.fc31.x86_64 mate-menus-preferences-category-menu-1.22.1-1.fc31.x86_64 mate-notification-daemon-1.22.1-1.fc31.x86_64 mate-panel-1.22.2-1.fc31.x86_64 mate-panel-libs-1.22.2-1.fc31.x86_64 mate-polkit-1.22.0-2.fc31.x86_64 mate-power-manager-1.22.2-1.fc31.x86_64 mate-screensaver-1.22.2-1.fc31.x86_64 mate-screenshot-1.22.2-2.fc31.x86_64 mate-search-tool-1.22.2-2.fc31.x86_64 mate-sensors-applet-1.22.1-2.fc31.x86_64 mate-session-manager-1.22.3-1.fc31.x86_64 mate-settings-daemon-1.22.1-1.fc31.x86_64 mate-system-log-1.22.2-2.fc31.x86_64 mate-system-monitor-1.22.2-1.fc31.x86_64 mate-terminal-1.22.1-3.fc31.x86_64 mate-themes-3.22.20-2.fc31.noarch mate-user-admin-1.5.1-1.fc31.x86_64 mate-user-guide-1.22.3-1.fc31.noarch mate-utils-1.22.2-2.fc31.x86_64 mate-utils-common-1.22.2-2.fc31.noarch slick-greeter-mate-1.3.1-1.fc31.noarch
Some detailed guideance would be much appreciated.
Incidentally, I have appended " net.ifnames=0" to the GRUB_CMDLINE_LINUX= line and rebuilt the initramfs to revert back to classic eth0 nomenclature for the RJ45 Ethernet port. I can't stand the new naming convention. :-)
--Doc Savage Fairview Heights, IL
On Wed, 1 Jan 2020 at 23:21, Robert G (Doc) Savage via users < users@lists.fedoraproject.org> wrote:
It would seem that "something" happened to the file(s) that provide RJ45 Ethernet connectivity maybe as far back as F29. I can get a WiFi connection, but not an RJ45 eth0 DHCP connection. This happens in my home and at a nearby computer store, so it's not my DHCP server.
Use the "ip" command to see the status of your network devices.
There have been problems with the way network devices are powered up and down due to changes in the kernel power management. If you goggle your ethernet device or the model of your system you may find the problem has already been addressed.
If you think this is a power management problem, look for ASMP (Active State Power Management) in dmesg. You can install the fwts package with dnf and run "$ sudo fwts aspm".
When booted up to WiFi, connecting an RJ45 Ethernet cable shuts down the existing WiFi port (normal), but never comes up with a DHCP address for the eth0 port. The network icon just loops forever. When I disconnect the RJ45 cable, WiFi connectivity resumes after 5-10 seconds.
Does ethernet work if you boot with the cable connected (and wifi disabled if your system has an external switch)?
The problem has persisted since upgrades to both F30 and F31. I'm guessing the best way to fix the problem is a fresh install of whatever packages provide eth0 connectivity. I'm at a loss to know what those packages are, and if there are any hidden potholes/landmines with simply using dnf to first remove then to install them from scratch.
If you have an older system you may be missing a binary blob, in which case dnf won't help.
I have semi-retired 10-year old desktop running Linux Mint. In the last year or so the linux kernel people did a purge of unmaintained, unsupported binary blobs (including the tigon3 ethernet hardware in my system). This was due to security concerns as well as the extra workload for kernel maintainers.
There was a line in dmesg giving the name of the missing file. I had to find the missing driver file and put it in the appropriate location. Check your ethernet device and the status of the drivers on the vendor's site. Fedora appears to have the binary blob for my hardware, as I was able to install Fedora 30 from a live USB and upgrade to 31.
If it matters, I'm using the mate v1.22.2 desktop. Here are all the *mate* packages I have installed:
# rpm -qa | grep mate | sort [...]
Some detailed guideance would be much appreciated.
Incidentally, I have appended " net.ifnames=0" to the GRUB_CMDLINE_LINUX= line and rebuilt the initramfs to revert back to classic eth0 nomenclature for the RJ45 Ethernet port. I can't stand the new naming convention. :-)
Does ethernet work if you revert the changes (or did it work before the changes)?
On Thu, 2020-01-02 at 09:06 -0400, George N. White III wrote:
On Wed, 1 Jan 2020 at 23:21, Robert G (Doc) Savage via users < users@lists.fedoraproject.org> wrote:
It would seem that "something" happened to the file(s) that provide
RJ45 Ethernet connectivity maybe as far back as F29. I can get a WiFi
connection, but not an RJ45 eth0 DHCP connection. This happens in my
home and at a nearby computer store, so it's not my DHCP server.
Use the "ip" command to see the status of your network devices.
When using WiFi, the eth0 port is down. This is normal operation. When an RJ45 connection is made, this is the ifcfg-eth0 file that controls it:
HWADDR=E8:6A:64:35:53:D8 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=eth0 UUID=3a1a7b73-df5e-37b9-a9af-dbc49d4120b3 ONBOOT=yes AUTOCONNECT_PRIORITY=-999
Nothing remarkable here.
There have been problems with the way network devices are powered up and down due to changes in the kernel power management. If you goggle your ethernet device or the model of your system you may find the problem has already been addressed.
If you think this is a power management problem, look for ASMP (Active State Power Management) in dmesg. You can install the fwts package with dnf and run "$ sudo fwts aspm".
When booted up to WiFi, connecting an RJ45 Ethernet cable shuts down
the existing WiFi port (normal), but never comes up with a DHCP address
for the eth0 port. The network icon just loops forever. When I
disconnect the RJ45 cable, WiFi connectivity resumes after 5-10
seconds.
Does ethernet work if you boot with the cable connected (and wifi disabled if your system has an external switch)?
No. The failure appears whenever a RH45 Ethernet cable is connected.
The problem has persisted since upgrades to both F30 and F31. I'm
guessing the best way to fix the problem is a fresh install of whatever
packages provide eth0 connectivity. I'm at a loss to know what those
packages are, and if there are any hidden potholes/landmines with
simply using dnf to first remove then to install them from scratch.
If you have an older system you may be missing a binary blob, in which case dnf won't help.
Perhaps I should have noted that this is an almost new ThinkPad P72 laptop. I installed F29 in Dec 2018 and upgraded to F30 shortly thereafter. I recently upgraded to F31. I would like to avoid the trouble of scrapping an otherwise working system that a total from- scratch installation of F31 would involve.
I have semi-retired 10-year old desktop running Linux Mint. In the last year or so the linux kernel people did a purge of unmaintained, unsupported
binary blobs (including the tigon3 ethernet hardware in my system). This was due to security concerns as well as the extra workload for kernel maintainers.
There was a line in dmesg giving the name of the missing file. I had to find the missing driver file and put it in the appropriate location. Check your ethernet device and the status of the drivers on the vendor's site. Fedora appears to have the binary blob for my hardware, as I was able to install Fedora 30 from a live USB and upgrade to 31.
If it matters, I'm using the mate v1.22.2 desktop. Here are all the
*mate* packages I have installed:
# rpm -qa | grep mate | sort [...]
Some detailed guideance would be much appreciated.
Incidentally, I have appended " net.ifnames=0" to the
GRUB_CMDLINE_LINUX= line and rebuilt the initramfs to revert back to
classic eth0 nomenclature for the RJ45 Ethernet port. I can't stand the
new naming convention. :-)
Does ethernet work if you revert the changes (or did it work before the changes)?
This was done within the past 30 days. The connection problem has existed long before the port name was changed.
--Doc Savage Fairview Heights, IL.
On 2020-01-04 08:10, Robert G (Doc) Savage via users wrote:
When using WiFi, the eth0 port is down. This is normal operation.
Why do you think this is "normal"? Have you configured your system for this? I ask since I've got multiple system with both ethernet and wifi connections up at the same time.
On Sat, 2020-01-04 at 08:34 +0800, Ed Greshko wrote:
On 2020-01-04 08:10, Robert G (Doc) Savage via users wrote:
When using WiFi, the eth0 port is down. This is normal operation.
Why do you think this is "normal"? Have you configured your system for this? I ask since I've got multiple system with both ethernet and wifi connections up at the same time.
Ed,
It has been my understanding that only one network mode could be active qt one time. On my old W700 laptop I could use the RJ45 connection at my desk, then disconnect the live laptop and take it to the dining room or wherever. Once disconnected from the RJ45, a WiFi connection was automatically spawned. Whe I returned to my desk and reconnected the RJ45 cable, the WiFi shut down and the copper Ethernet was reactivated.
What I'm seeing follows that model EXCEPT for the RJ45 Ethernet connection failing to start up and run either at initial boot or in mid session.
If this operational description is incorrect, please advise.
V/R --Doc Savage Fairview Heights, IL
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 1/3/20 9:14 PM, Robert G (Doc) Savage via users wrote:
It has been my understanding that only one network mode could be active qt one time. On my old W700 laptop I could use the RJ45 connection at my desk, then disconnect the live laptop and take it to the dining room or wherever. Once disconnected from the RJ45, a WiFi connection was automatically spawned. Whe I returned to my desk and reconnected the RJ45 cable, the WiFi shut down and the copper Ethernet was reactivated.
The wifi shouldn't be disconnected when the ethernet is, but the ethernet will have a higher priority. Unless the wifi is on a different subnet and that's where you're sending a packet to, it will go out on the ethernet connection. I often have my dhcp set up to give my wifi and ethernet the same ip address. That way I can switch between the two without losing connections.
On Fri, 2020-01-03 at 21:34 -0800, Samuel Sieb wrote:
On 1/3/20 9:14 PM, Robert G (Doc) Savage via users wrote:
It has been my understanding that only one network mode could be active qt one time. On my old W700 laptop I could use the RJ45 connection at my desk, then disconnect the live laptop and take it to the dining room or wherever. Once disconnected from the RJ45, a WiFi connection was automatically spawned. Whe I returned to my desk and reconnected the RJ45 cable, the WiFi shut down and the copper Ethernet was reactivated.
The wifi shouldn't be disconnected when the ethernet is, but the ethernet will have a higher priority. Unless the wifi is on a different subnet and that's where you're sending a packet to, it will go out on the ethernet connection. I often have my dhcp set up to give my wifi and ethernet the same ip address. That way I can switch between the two without losing connections.
I'll take your word for it Sam. I'm still unable to communicate thru the RJ45 port with my currently installed package(s) / configuration.
Unless someone can suggest a true fix, I'm still facing a package remove/replace situation. Which ones??? Otherwise my only solution would be a scorched disk total removal and replacement of the entire system.
--Doc Savage Fairview Heights, IL
On 2020-01-05 12:34, Robert G (Doc) Savage via users wrote:
On Fri, 2020-01-03 at 21:34 -0800, Samuel Sieb wrote:
On 1/3/20 9:14 PM, Robert G (Doc) Savage via users wrote:
It has been my understanding that only one network mode could be active qt one time. On my old W700 laptop I could use the RJ45 connection at my desk, then disconnect the live laptop and take it to the dining room or wherever. Once disconnected from the RJ45, a WiFi connection was automatically spawned. Whe I returned to my desk and reconnected the RJ45 cable, the WiFi shut down and the copper Ethernet was reactivated.
The wifi shouldn't be disconnected when the ethernet is, but the ethernet will have a higher priority. Unless the wifi is on a different subnet and that's where you're sending a packet to, it will go out on the ethernet connection. I often have my dhcp set up to give my wifi and ethernet the same ip address. That way I can switch between the two without losing connections.
I'll take your word for it Sam. I'm still unable to communicate thru the RJ45 port with my currently installed package(s) / configuration.
Unless someone can suggest a true fix, I'm still facing a package remove/replace situation. Which ones??? Otherwise my only solution would be a scorched disk total removal and replacement of the entire system.
Well..... I still don't think enough information has been supplied.
If you do a
nmcli connection
you should see an "ethernet" entry.
Example, on my system...
NAME UUID TYPE DEVICE enp2s0 22f19ca8-c33d-31ea-9a32-a4b1309d0b06 ethernet enp2s0
And then do...
nmcli connection show (device-name)
On 2020-01-05 12:48, Ed Greshko wrote:
Example, on my system...
NAME UUID TYPE DEVICE enp2s0 22f19ca8-c33d-31ea-9a32-a4b1309d0b06 ethernet enp2s0
And then do...
nmcli connection show (device-name)
I just realized my statement was ambiguous. The parmeter entry should be that under "NAME".
On Sun, 2020-01-05 at 12:48 +0800, Ed Greshko wrote:
On 2020-01-05 12:34, Robert G (Doc) Savage via users wrote:
On Fri, 2020-01-03 at 21:34 -0800, Samuel Sieb wrote:
On 1/3/20 9:14 PM, Robert G (Doc) Savage via users wrote:
It has been my understanding that only one network mode could be active qt one time. On my old W700 laptop I could use the RJ45 connection at my desk, then disconnect the live laptop and take it to the dining room or wherever. Once disconnected from the RJ45, a WiFi connection was automatically spawned. Whe I returned to my desk and reconnected the RJ45 cable, the WiFi shut down and the copper Ethernet was reactivated.
The wifi shouldn't be disconnected when the ethernet is, but the ethernet will have a higher priority. Unless the wifi is on a different subnet and that's where you're sending a packet to, it will go out on the ethernet connection. I often have my dhcp set up to give my wifi and ethernet the same ip address. That way I can switch between the two without losing connections.
I'll take your word for it Sam. I'm still unable to communicate thru the RJ45 port with my currently installed package(s) / configuration.
Unless someone can suggest a true fix, I'm still facing a package remove/replace situation. Which ones??? Otherwise my only solution would be a scorched disk total removal and replacement of the entire system.
Well..... I still don't think enough information has been supplied.
If you do a
nmcli connection
you should see an "ethernet" entry.
Example, on my system...
NAME UUID TYPE DEVICE enp2s0 22f19ca8-c33d-31ea-9a32-a4b1309d0b06 ethernet enp2s0
And then do...
nmcli connection show (device-name)
Ed,
# nmcli connection ... eth0: unavailable "Intel Ethernet" ethernet (e1000e), E8:6A:64:35:53:D8, hw, mtu 1500 ....
Your next request generated a lot more:
# nmcli connection show eth0 connection.id: eth0 connection.uuid: 3a1a7b73-df5e-37b9-a9af-dbc49d4120b3 connection.stable-id: -- connection.type: 802-3-ethernet connection.interface-name: -- connection.autoconnect: yes connection.autoconnect-priority: -999 connection.autoconnect-retries: -1 (default) connection.multi-connect: 0 (default) connection.auth-retries: -1 connection.timestamp: 1577737181 connection.read-only: no connection.permissions: -- connection.zone: -- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: -- connection.gateway-ping-timeout: 0 connection.metered: unknown connection.lldp: default connection.mdns: -1 (default) connection.llmnr: -1 (default) connection.wait-device-timeout: -1 802-3-ethernet.port: -- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: no 802-3-ethernet.mac-address: E8:6A:64:35:53:D8 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.generate-mac-address-mask:-- 802-3-ethernet.mac-address-blacklist: -- 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: -- 802-3-ethernet.s390-nettype: -- 802-3-ethernet.s390-options: -- 802-3-ethernet.wake-on-lan: default 802-3-ethernet.wake-on-lan-password: -- ipv4.method: auto ipv4.dns: -- ipv4.dns-search: -- ipv4.dns-options: -- ipv4.dns-priority: 0 ipv4.addresses: -- ipv4.gateway: -- ipv4.routes: -- ipv4.route-metric: -1 ipv4.route-table: 0 (unspec) ipv4.routing-rules: -- ipv4.ignore-auto-routes: no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id: -- ipv4.dhcp-timeout: 0 (default) ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.dhcp-fqdn: -- ipv4.never-default: no ipv4.may-fail: no ipv4.dad-timeout: -1 (default) ipv6.method: auto ipv6.dns: -- ipv6.dns-search: -- ipv6.dns-options: -- ipv6.dns-priority: 0 ipv6.addresses: -- ipv6.gateway: -- ipv6.routes: -- ipv6.route-metric: -1 ipv6.route-table: 0 (unspec) ipv6.routing-rules: -- ipv6.ignore-auto-routes: no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: 0 (disabled) ipv6.addr-gen-mode: stable-privacy ipv6.dhcp-duid: -- ipv6.dhcp-send-hostname: yes ipv6.dhcp-hostname: -- ipv6.token: -- proxy.method: none proxy.browser-only: no proxy.pac-url: -- proxy.pac-script: --
Lot of chaff there. Not sure if there's any wheat at all. Does anything catch your eye, Ed?
--Doc Savage Fairview Heights, IL
On 2020-01-05 13:56, Robert G (Doc) Savage via users wrote:
On Sun, 2020-01-05 at 12:48 +0800, Ed Greshko wrote:
On 2020-01-05 12:34, Robert G (Doc) Savage via users wrote:
On Fri, 2020-01-03 at 21:34 -0800, Samuel Sieb wrote:
On 1/3/20 9:14 PM, Robert G (Doc) Savage via users wrote:
It has been my understanding that only one network mode could be active qt one time. On my old W700 laptop I could use the RJ45 connection at my desk, then disconnect the live laptop and take it to the dining room or wherever. Once disconnected from the RJ45, a WiFi connection was automatically spawned. Whe I returned to my desk and reconnected the RJ45 cable, the WiFi shut down and the copper Ethernet was reactivated.
The wifi shouldn't be disconnected when the ethernet is, but the ethernet will have a higher priority. Unless the wifi is on a different subnet and that's where you're sending a packet to, it will go out on the ethernet connection. I often have my dhcp set up to give my wifi and ethernet the same ip address. That way I can switch between the two without losing connections.
I'll take your word for it Sam. I'm still unable to communicate thru the RJ45 port with my currently installed package(s) / configuration.
Unless someone can suggest a true fix, I'm still facing a package remove/replace situation. Which ones??? Otherwise my only solution would be a scorched disk total removal and replacement of the entire system.
Well..... I still don't think enough information has been supplied.
If you do a
nmcli connection
you should see an "ethernet" entry.
Example, on my system...
NAME UUID TYPE DEVICE enp2s0 22f19ca8-c33d-31ea-9a32-a4b1309d0b06 ethernet enp2s0
And then do...
nmcli connection show (device-name)
Ed,
# nmcli connection ... eth0: unavailable "Intel Ethernet" ethernet (e1000e), E8:6A:64:35:53:D8, hw, mtu 1500 ....
Well, that is wrong....
You should see something like this.... My VM has an ethernet and wifi connection currently up...
[egreshko@f31k ~]$ nmcli connection NAME UUID TYPE DEVICE eth0 b927188e-d48c-3a0d-85a9-6cb1c24418ab ethernet enp1s0 silly 4031fe2b-e441-4025-813f-01279315e760 wifi wlp0s29f7u3
I would recommend deleting the connection. You could probably just delete the file in /etc/sysconfig/network-scripts. Then just recreating it via the NM GUI, if you can.
Your next request generated a lot more:
And missing quit a bit of stuff....
In particular a section such as....
GENERAL.NAME: eth0 GENERAL.UUID: ab02770f-daca-4443-916f-df6ee9c54ac6 GENERAL.DEVICES: enp1s0 GENERAL.STATE: activated GENERAL.DEFAULT: yes GENERAL.DEFAULT6: yes GENERAL.SPEC-OBJECT: -- GENERAL.VPN: no GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveCon> GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/4 GENERAL.ZONE: public GENERAL.MASTER-PATH: --
In particular no "activated"
On 1/4/20 9:56 PM, Robert G (Doc) Savage via users wrote:
# nmcli connection
...
eth0: unavailable
"Intel Ethernet"
ethernet (e1000e), E8:6A:64:35:53:D8, hw, mtu 1500
That looks like the output from "nmcli" by itself. "nmcli connection" or just "nmcli c" should only show one line per connection.
On Sat, 2020-01-04 at 22:30 -0800, Samuel Sieb wrote:
On 1/4/20 9:56 PM, Robert G (Doc) Savage via users wrote:
# nmcli connection
...
eth0: unavailable
"Intel Ethernet" ethernet (e1000e), E8:6A:64:35:53:D8, hw, mtu 1500That looks like the output from "nmcli" by itself. "nmcli connection" or just "nmcli c" should only show one line per connection.
Ah, you're right. Here's the correct output:
# nmcli connection NAME UUID TYPE DEV ICE ATT9qua6QD 29a52e1f-717d-4e1a-887c- 6a0d799a24b6 wifi wlp0s20f3 virbr0 0b4b7d6f-4f0b-46d8-8556- d3c56cc31a02 bridge virbr0 eth0 3a1a7b73-df5e-37b9-a9af-dbc49d4120b3 ethernet -- This still indicates that the eth0 device isn't available.
--Doc Savage Fairview Heights, IL
On 2020-01-05 14:47, Robert G (Doc) Savage via users wrote:
On Sat, 2020-01-04 at 22:30 -0800, Samuel Sieb wrote:
On 1/4/20 9:56 PM, Robert G (Doc) Savage via users wrote:
# nmcli connection
...
eth0: unavailable
"Intel Ethernet"
ethernet (e1000e), E8:6A:64:35:53:D8, hw, mtu 1500
That looks like the output from "nmcli" by itself. "nmcli connection" or just "nmcli c" should only show one line per connection.
Ah, you're right. Here's the correct output:
# nmcli connection NAME UUID TYPE DEVICE ATT9qua6QD 29a52e1f-717d-4e1a-887c-6a0d799a24b6 wifi wlp0s20f3 virbr0 0b4b7d6f-4f0b-46d8-8556-d3c56cc31a02 bridge virbr0 eth0 3a1a7b73-df5e-37b9-a9af-dbc49d4120b3 ethernet --
This still indicates that the eth0 device isn't available.
I don't think that means "unavailable".
If I run "nmcli c down eth0" I get the same output.
I assume you get a time-out if you run
nmcli c up eth0
?
On 1/1/20 7:20 PM, Robert G (Doc) Savage via users wrote:
It would seem that "something" happened to the file(s) that provide RJ45 Ethernet connectivity maybe as far back as F29. I can get a WiFi connection, but not an RJ45 eth0 DHCP connection. This happens in my home and at a nearby computer store, so it's not my DHCP server.
When booted up to WiFi, connecting an RJ45 Ethernet cable shuts down the existing WiFi port (normal), but never comes up with a DHCP address for the eth0 port. The network icon just loops forever. When I disconnect the RJ45 cable, WiFi connectivity resumes after 5-10 seconds.
I just realized we are missing what is probably the most important information, the logs! In a terminal as root, run "journalctl -fa" and then plug in the ethernet cable. Copy the output, removing private information if there is any.
On Sat, 2020-01-04 at 22:16 -0800, Samuel Sieb wrote:
On 1/1/20 7:20 PM, Robert G (Doc) Savage via users wrote:
It would seem that "something" happened to the file(s) that provide RJ45 Ethernet connectivity maybe as far back as F29. I can get a WiFi connection, but not an RJ45 eth0 DHCP connection. This happens in my home and at a nearby computer store, so it's not my DHCP server.
When booted up to WiFi, connecting an RJ45 Ethernet cable shuts down the existing WiFi port (normal), but never comes up with a DHCP address for the eth0 port. The network icon just loops forever. When I disconnect the RJ45 cable, WiFi connectivity resumes after 5-10 seconds.
I just realized we are missing what is probably the most important information, the logs! In a terminal as root, run "journalctl -fa" and then plug in the ethernet cable. Copy the output, removing private information if there is any.
THIS IS MY THIRD ATTEMPT TO REPLY WITH A LOG FILE ATTACHED. THE MODERATOR EITHER DIDN'T REVIEW IT OR FELT THE SIZE OF THE MESSAGE WITH ITS LOG FILE WAS NOT WORTH SHARING WITH THE LIST.
Sam,
You've found the magic key. The output is attached. If you open it with vim and scroll down to line 167, you'll see an SELINUX audit error and its recommended solution:
Jan 05 00:54:09 tiger.protogeek.org python3[905199]: SELinux is preventing 11-dhclient from getattr access on the file /usr/bin/hostname.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that 11-dhclient should be allowed getattr access on the hostname file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c '11-dhclient' --raw | audit2allow -M my-11dhclient # semodule -X 300 -i my-11dhclient.pp21
Executing these two commands appears to have fixed the problem.
--Doc Savage Fairview Heights, IL
P.S. The performance boost is dramatic. The distance between my U-verse WiFi and the laptop in the master bedroom is about 65 feet through quite a bit of drywall. It works, but downloads of any size are slow. With the RJ45 connection I have high quality in-wall Cat5E cabling that allows full speed GigE.
I definitely owe you several beers on this one. :-)
On 1/11/20 7:24 PM, Robert G (Doc) Savage via users wrote:
If you believe that 11-dhclient should be allowed getattr access on the hostname file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c '11-dhclient' --raw | audit2allow -M my-11dhclient # semodule -X 300 -i my-11dhclient.pp21
That seems like a bug or something mislabeled.
Executing these two commands appears to have fixed the problem.
I suppose that will work, but it would have been better to solve the underlying problem.
On Sat, 2020-01-11 at 19:28 -0800, Samuel Sieb wrote:
On 1/11/20 7:24 PM, Robert G (Doc) Savage via users wrote:
If you believe that 11-dhclient should be allowed getattr access on the hostname file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c '11-dhclient' --raw | audit2allow -M my-11dhclient # semodule -X 300 -i my-11dhclient.pp21
That seems like a bug or something mislabeled.
Executing these two commands appears to have fixed the problem.
I suppose that will work, but it would have been better to solve the underlying problem.
If this is a bug, I believe it is caused by a problem in the major version upgrade process.
Remember, this system has been upgraded twice: F29 -> F30 Beta -> F31. I had very significant SELinux problems after the first upgrade to F30 Beta. I must have had a hundred "ausearch" errors I had to fix just like this one. At the suggestion of a friend, I was able to mass reset the contexts in the / filesystem. Had I done a from scratch install of F31, I don't think I would have encountered this problem. There may be more bugs lurking, but at least now I have a tool to ID and fix them.
--Doc Savage Fairview Heights, IL
-
Ed Greshko -
George N. White III -
Robert G (Doc) Savage -
Samuel Sieb