lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB6PR0501MB2712340C8CDC37F3038766AD943C0@DB6PR0501MB2712.eurprd05.prod.outlook.com>
Date:   Wed, 22 Mar 2017 13:23:41 +0000
From:   Maxime Morin <maxime.morin@...ec.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "stsp@...t.ru" <stsp@...t.ru>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "thomas.petazzoni@...e-electrons.com" 
        <thomas.petazzoni@...e-electrons.com>
Subject: Problem: net: mvneta: auto-negotiation with disconnected network
 cable

Hi all,

I work on an embedded platform based on the Marvell Armada 88F6707, that is connected to a Marvell Alaska 88E1512 ethernet transceiver. A defect has appeared recently, and it turns out to be a regression on the network part. There is a complete lost of the network when following these steps:
    1) boot the board with the network cable disconnected
    2) run the following commands (or equivalent):
        ip link set eth0 up
        ip addr add 10.0.0.80/24 dev eth0
        ethtool -s eth0 autoneg on #this is the command that really breaks the network
    3) plug the network cable
        => there is no network, and no way to have it back except by rebooting
If I do not launch the "ethtool" command, when I plug the network cable it works, so it really seems to be related to the auto-negotiation set to "on" when the network cable has never been connected.
I did a "git bisect" to find when the regression was introduced, because it previously worked with kernel 4.4, but not with the recent ones. The commit that made appear the issue is this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c0744fc1dd5b
If I remove on mvneta.c the part that was added on this commit on the function mvneta_ethtool_set_link_ksettings (mvneta_ethtool_set_settings at that time), I do not have the issue, but I can't call that a fix...
So, could it be a driver issue, or maybe a wrong configuration somewhere? If you need additional information to reproduce the problem please ask me, I will be as responsive as possible.

Best regards,
Maxime MORIN

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ