Bug 1343421 - Fedora network connection with cloned MAC address not working on laptop
Summary: Fedora network connection with cloned MAC address not working on laptop
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 23
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-07 10:07 UTC by Jack
Modified: 2016-12-20 20:50 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-12-20 20:50:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
journalctl output (181.04 KB, text/plain)
2016-06-07 12:43 UTC, Jack
no flags Details
connection information (2.27 KB, text/plain)
2016-06-07 12:45 UTC, Jack
no flags Details
dhclient output (978 bytes, text/plain)
2016-06-08 07:18 UTC, Jack
no flags Details

Description Jack 2016-06-07 10:07:13 UTC
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.

Comment 1 Beniamino Galvani 2016-06-07 11:51:08 UTC
(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!

Comment 2 Jack 2016-06-07 12:43:33 UTC
Created attachment 1165610 [details]
journalctl output

This is the output file of "journalctl -u NetworkManager -b"

Comment 3 Jack 2016-06-07 12:45:09 UTC
Created attachment 1165611 [details]
connection information

This is the connection information about the "nmcli connection show Profile\ 1"

Comment 4 Beniamino Galvani 2016-06-07 13:05:37 UTC
> 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...

Comment 5 Jack 2016-06-07 13:32:07 UTC
(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.

Comment 6 Beniamino Galvani 2016-06-07 14:28:55 UTC
(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

Comment 7 Jack 2016-06-08 07:18:06 UTC
Created attachment 1165844 [details]
dhclient output

dhclient output

Comment 8 Beniamino Galvani 2016-06-08 12:08:39 UTC
[...]
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?

Comment 9 Jack 2016-06-13 12:53:31 UTC
(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!

Comment 10 Jack 2016-07-10 00:41:09 UTC
This problem still exists after upgrade the system to Fedora24 and upgrade the kernel. Any help will be appreciated!

Comment 11 appdevsw 2016-08-05 08:37:36 UTC
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.

Comment 12 Jack 2016-09-09 08:37:44 UTC
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!

Comment 13 Fedora End Of Life 2016-11-25 09:14:08 UTC
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.

Comment 14 Fedora End Of Life 2016-12-20 20:50:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.