Hide Forgot
Description of problem: I used Fedora Workstation on my Lenovo laptop. I modified the MAC address using the NetworkManager GUI program just like what I did on my desktop computer with the same version Fedora. But the desktop computer worked after this process, the laptop did not work. Version-Release number of selected component (if applicable): 1.0.12 How reproducible: Using the NetworkManager GUI program modify the MAC address of the wire interface on a laptop. Steps to Reproduce: 1. Using the NetworkManager GUI program modify the MAC address of the wire interface on a laptop. And the modified MAC address is valid. 2. connect the connection with Networkmanager. Actual results: The connection did not work! Expected results: The connection should work with the modified MAC address. And then the internet will be connected.
(In reply to Jack from comment #0) > Description of problem: > I used Fedora Workstation on my Lenovo laptop. > I modified the MAC address using the NetworkManager GUI program just like > what I did on my desktop computer with the same version Fedora. > But the desktop computer worked after this process, the laptop did not work. Can you please paste the output of "nmcli connection show <connection-name>, and do the following? - as root, run 'nmcli general logging level debug' - enable the connection - attach the output of 'journalctl -u NetworkManager -b' Thanks!
Created attachment 1165610 [details] journalctl output This is the output file of "journalctl -u NetworkManager -b"
Created attachment 1165611 [details] connection information This is the connection information about the "nmcli connection show Profile\ 1"
> 20:33:30 <info> Activation (enp2s0) Beginning DHCPv4 transaction (timeout in 45 seconds) > 20:33:34 DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 6 (xid=0x6b404a05) > 20:33:40 DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 12 (xid=0x6b404a05) > 20:33:52 DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 13 (xid=0x6b404a05) > 20:34:15 <warn> (enp2s0): DHCPv4 request timed out. > 20:34:15 <warn> (enp2s0): Activation: failed for connection 'Profile 1' Are you sure there is a DHCP server responding on the network? It seems NM is correctly trying to get the address but nobody answers...
(In reply to Beniamino Galvani from comment #4) > > 20:33:30 <info> Activation (enp2s0) Beginning DHCPv4 transaction (timeout in 45 seconds) > > 20:33:34 DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 6 (xid=0x6b404a05) > > 20:33:40 DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 12 (xid=0x6b404a05) > > 20:33:52 DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 13 (xid=0x6b404a05) > > 20:34:15 <warn> (enp2s0): DHCPv4 request timed out. > > 20:34:15 <warn> (enp2s0): Activation: failed for connection 'Profile 1' > > Are you sure there is a DHCP server responding on the network? It > seems NM is correctly trying to get the address but nobody answers... Yes, I'm sure that there is a DHCP server. If I did't modify the MAC address, the connection was correct. And it is OK on the desktop computer whether the MAC address was modified or not.
(In reply to Jack from comment #5) > Yes, I'm sure that there is a DHCP server. If I did't modify the MAC > address, the connection was correct. And it is OK on the desktop computer > whether the MAC address was modified or not. This is a real machine with a real network adapter, not a VM, right? Can you try to disable NM and check if dhclient alone works? What happens if you do (as root): systemctl mask NetworkManager systemctl stop NetworkManager ip l set enp2s0 down ip l set enp2s0 addr 2C:27:D7:1E:2D:DA ip l set enp2s0 up dhclient -d -v enp2s0 After, remember to: systemctl unmask NetworkManager systemctl start NetworkManager
Created attachment 1165844 [details] dhclient output dhclient output
[...] DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 7 (xid=0x7487d73b) DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 1 (xid=0x7487d73b) No DHCPOFFERS received. No working leases in persistent database - sleeping. Even dhclient doesn't get a response, so this is clearly not a NetworkManager issue. Can you try to execute: tcpdump -i enp0s25 port 67 or port 68 -n -e -vv in another terminal while dhclient is running? If the output still shows no response, I'm quite sure this is an issue in the network. Also, did you try with a different MAC?
(In reply to Beniamino Galvani from comment #8) > [...] > DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 7 (xid=0x7487d73b) > DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 1 (xid=0x7487d73b) > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > Even dhclient doesn't get a response, so this is clearly not a > NetworkManager issue. Can you try to execute: > > tcpdump -i enp0s25 port 67 or port 68 -n -e -vv > > in another terminal while dhclient is running? If the output still shows no > response, I'm quite sure this is an issue in the network. Also, did you try > with a different MAC? I'm sure that this is not the network issue. All the configuration is OK on the desktop computer. I think this is an issue about the driver of my ethernet card in the laptop. Because it was also not working with the normal MAC address sometimes. Maybe I should reinstall something to solve the problem as soon as possible. Thank you very much for your help!
This problem still exists after upgrade the system to Fedora24 and upgrade the kernel. Any help will be appreciated!
Hi. I had the same problem. It was caused by the optimisations generated by the powertop utility. I removed the line: echo 'auto' > '/sys/bus/pci/devices/0000:05:00.0/power/control'; from my startup script and the problem disappeared. 0000:05:00.0 is the ID of my Ethernet card. And I observed an interesting thing: when you leave running tcpdump (like in Comment 8) in a separate window, the network starts working. When you exit tcpdump, the connection breaks immediately. I use Fedora 24 with the kernel 4.6.4-301.fc24.x86_64.
Thank you very much. I followed your instruction, and the connection works! I used the tlp utility for power management. And I add the following line to the tlp configuration file /etc/default/tlp: RUNTIME_PM_BLACKLIST="02:00.0" NOTE: The "02:00.0" is my ethernet controller pci address which can get from the `tlp stat` command. After reboot the tlp service. The connection with the cloned MAC works!
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.