Bug 1659764

Is the problem still reproducible? Can you please set level=TRACE in the [logging] section of /etc/NetworkManager/NetworkManager.conf, reboot and attach the output of 'journalctl _TRANSPORT=kernel + _COMM=NetworkManager -b'?

Yes it is.

Kindly see the collected output as per your request.

Created attachment 1518078 [details]
Log with trace enabled

Hi, it seems that the ethernet interface loses the carrier shortly
after going up. Please try to downgrade NetworkManager with the
following command as root:

 dnf downgrade NetworkManager

and reboot. Maybe, the kernel driver is the culprit so a kernel
downgrade could help as well.

If the issue persists, please try the following (still as
root):

 ip -t monitor link address dev enp0s31f6 &
 systemctl mask NetworkManager
 systemctl stop NetworkManager
 sleep 5
 dhclient enp0s31f6
 sleep 5
 ip address show enp0s31f6

and paste the output here. After this, re-enable NetworkManager with:

 systemctl unmask NetworkManager
 systemctl start NetworkManager

Thanks!

I have the same issue, kernel and NetworkManager downgrade don't help

the out requested:

ip -t monitor link address dev eno1:
  Timestamp: Sun Jan  6 16:36:59 2019 613550 usec
  2: eno1    inet 192.168.1.7/24 brd 192.168.1.255 scope global dynamic eno1
        valid_lft 21660sec preferred_lft 21660sec
  Timestamp: Sun Jan  6 16:36:59 2019 613535 usec
  2: eno1    inet 192.168.1.7/24 brd 192.168.1.255 scope global dynamic eno1
        valid_lft 21660sec preferred_lft 21660sec
        
ip address show eno1:
  2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
      link/ether 80:ce:62:33:2c:9b brd ff:ff:ff:ff:ff:ff
      inet 192.168.1.7/24 brd 192.168.1.255 scope global dynamic eno1
        valid_lft 21655sec preferred_lft 21655sec

I have noted that if I disable auto-negotiation and manually set speed and duplex on network profile the problem disappears and the network go up on boot.
Could be caused by the fact that my ethernet adapter is 1Gbps and the link is 100Mbps?

Created attachment 1518811 [details]
Configured in this way seem to work

(In reply to Elia Devito from comment #5)
> I have the same issue, kernel and NetworkManager downgrade don't help
> 
> the out requested:
> 
> ip -t monitor link address dev eno1:
>   Timestamp: Sun Jan  6 16:36:59 2019 613550 usec
>   2: eno1    inet 192.168.1.7/24 brd 192.168.1.255 scope global dynamic eno1
>         valid_lft 21660sec preferred_lft 21660sec
>   Timestamp: Sun Jan  6 16:36:59 2019 613535 usec
>   2: eno1    inet 192.168.1.7/24 brd 192.168.1.255 scope global dynamic eno1
>         valid_lft 21660sec preferred_lft 21660sec
>         
> ip address show eno1:
>   2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
> UP group default qlen 1000
>       link/ether 80:ce:62:33:2c:9b brd ff:ff:ff:ff:ff:ff
>       inet 192.168.1.7/24 brd 192.168.1.255 scope global dynamic eno1
>         valid_lft 21655sec preferred_lft 21655sec
> 
> I have noted that if I disable auto-negotiation and manually set speed and
> duplex on network profile the problem disappears and the network go up on
> boot.
> Could be caused by the fact that my ethernet adapter is 1Gbps and the link
> is 100Mbps?

No, this should work out of the box with default settings.

Did you have autonegotiation enabled for the connection? Can you please paste the output of:

nmcli -f 802-3-ethernet connection show <name-of-the-ethernet-connection> ?

(In reply to Beniamino Galvani from comment #7)
> > I have noted that if I disable auto-negotiation and manually set speed and
> > duplex on network profile the problem disappears and the network go up on
> > boot.
> > Could be caused by the fact that my ethernet adapter is 1Gbps and the link
> > is 100Mbps?
> 
> No, this should work out of the box with default settings.
> 
> Did you have autonegotiation enabled for the connection? Can you please
> paste the output of:
> 
> nmcli -f 802-3-ethernet connection show <name-of-the-ethernet-connection> ?

I also have autonegotiation enabled as it was before (default)
and in my case the adapter is 1Gbps and the link is also 1Gbps

and here is the output from the command:
# nmcli -f 802-3-ethernet connection show <nic>

802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          yes
802-3-ethernet.mac-address:             54:E1:xxxxxxx(masked)
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:    --

802-3-ethernet.auto-negotiate:          yes

This makes NM issue an ioctl to enable autonegotiation on the link when connecting and I suspect it is causing the temporary carrier down.

Default values for new connections are:

 802-3-ethernet.speed:                   0
 802-3-ethernet.duplex:                  --
 802-3-ethernet.auto-negotiate:          no

which basically means that NM will not touch the interface. Can you please check if setting

 nmcli connection modify <nic> 802-3-ethernet.auto-negotiate no

makes any difference?

(In reply to Beniamino Galvani from comment #9)
> which basically means that NM will not touch the interface. Can you please
> check if setting
> 
>  nmcli connection modify <nic> 802-3-ethernet.auto-negotiate no
> 
> makes any difference?

I think it solves the problem, i tested it few times and it connects with no issues.

Update:

After disabling auto-negotiate the connection works but it sets the speed to 100Mbps, if I manually set it to 1Gbps it doesn't connect (my link/switch and my net card are both 1Gbps)

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
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 '29'.

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 29 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 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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.