All of lore.kernel.org
 help / color / mirror / Atom feed
* driver r8169 suddenly failed
@ 2016-12-26  8:01 Robert Grasso
  2016-12-27  0:12 ` Francois Romieu
  0 siblings, 1 reply; 5+ messages in thread
From: Robert Grasso @ 2016-12-26  8:01 UTC (permalink / raw)
  To: Realtek linux nic maintainers, Francois Romieu; +Cc: netdev

Hello,

I am a senior Linux sysadmin.
At home, I am using a Shuttle DS47 barebones computer as my firewall; it 
contains the following two network cards :
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 
802.11b/g/n WiFi Adapter (rev 01)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

The OS is Ubuntu 14.04.5 LTS with kernel 3.13.0-101-generic. The kernel 
has been using the driver r8169 successfully from the very first 
installation (2 or 3 years ago).

The first NIC is connected onto my french provider's (Numericable) cable 
modem Netgear CBVG834G
The second NIC goes to my LAN.

Last friday, suddenly, the connection to the cable modem failed. From 
that moment, acquiring a DHCP address fails always, the request is 
looping endlessly :

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3 (xid=0x7da87c44)
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3 (xid=0x7da87c44)
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 (xid=0x7da87c44)
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6 (xid=0x7da87c44)
(...)

I tried to boot the Shuttle from an USB dongle with Ubuntu 16.04 : the 
connection failed in the same way.

My Ubuntu 16 laptop (a brand new Dell XPS)  connects successfully on the 
cable modem (through Ethernet - by choice, no wireless at my home). 
Also, I am using a cheap Ethernet-to-USB converter connected on the 
Shuttle and on the cable modem in order to get a temporary Internet 
access - this allows me to send this email.

I am using dhclient.

I just installed r8168-dkms_8.043.02-1_all.deb, but this does not fix 
the issue.

I assume that my ISP upgraded something in the cable modem.

First of all, can you confirm that I am doing right in posting to you 
(addresses found in README.Debian) ?

If I do, can you help ? I am not very proficient with Ethernet, and I am 
not able to figure out what my provider changed : their hotline is 
underqualified, they are just able to tell that "the signal on the line 
is ok". But if you want me to run various tests, try new versions, I 
would be glad to do so : I would appreciate if I could salvage this Shuttle.

Best regards

-- 
Robert Grasso
@home
---
UNIX was not designed to stop you from doing stupid things, because
   that would also stop you from doing clever things. -- Doug Gwyn

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: driver r8169 suddenly failed
  2016-12-26  8:01 driver r8169 suddenly failed Robert Grasso
@ 2016-12-27  0:12 ` Francois Romieu
  2016-12-27  7:33   ` Robert Grasso
  2016-12-27 19:41   ` Robert Grasso
  0 siblings, 2 replies; 5+ messages in thread
From: Francois Romieu @ 2016-12-27  0:12 UTC (permalink / raw)
  To: Robert Grasso; +Cc: Realtek linux nic maintainers, netdev

Robert Grasso <robert.grasso@modulonet.fr> :
[dhcp snafu]
> First of all, can you confirm that I am doing right in posting to you
> (addresses found in README.Debian) ?

It isn't completely wrong.

> If I do, can you help ? I am not very proficient with Ethernet, and I am not
> able to figure out what my provider changed : their hotline is
> underqualified, they are just able to tell that "the signal on the line is
> ok".

You're spoiled. It is more than decent for a company whose core business
used to sell cable TV.

> But if you want me to run various tests, try new versions, I would be
> glad to do so : I would appreciate if I could salvage this Shuttle.

Please try a recent stable vanilla kernel and send a complete dmesg
from boot. I need to identify the specific 816x chipset.

Then record some traffic:

# touch gonzo.pcap && tshark -w gonzo.pcap -i eth1

It should only exhibit small outgoing packets but, well, one never knows.

Check the leds activity to be sure that the network interfaces have not
been renumbered.

Use ethtool to check that tso is disabled. If it isn't, disable it.

-- 
Ueimor

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: driver r8169 suddenly failed
  2016-12-27  0:12 ` Francois Romieu
@ 2016-12-27  7:33   ` Robert Grasso
  2016-12-27 19:41   ` Robert Grasso
  1 sibling, 0 replies; 5+ messages in thread
From: Robert Grasso @ 2016-12-27  7:33 UTC (permalink / raw)
  To: Francois Romieu; +Cc: Realtek linux nic maintainers, netdev

Thank you for your quick answer ! Allow me some days for this test :

1 - I am at work these days
2 - it has been a while since I have dealt with custom kernels, I am a 
bit rusty, it will be good to review this topic

-- 
Robert Grasso
@home
---
UNIX was not designed to stop you from doing stupid things, because
   that would also stop you from doing clever things. -- Doug Gwyn

On 27/12/2016 01:12, Francois Romieu wrote:
> Robert Grasso <robert.grasso@modulonet.fr> :
> [dhcp snafu]
>> First of all, can you confirm that I am doing right in posting to you
>> (addresses found in README.Debian) ?
> It isn't completely wrong.
>
>> If I do, can you help ? I am not very proficient with Ethernet, and I am not
>> able to figure out what my provider changed : their hotline is
>> underqualified, they are just able to tell that "the signal on the line is
>> ok".
> You're spoiled. It is more than decent for a company whose core business
> used to sell cable TV.
>
>> But if you want me to run various tests, try new versions, I would be
>> glad to do so : I would appreciate if I could salvage this Shuttle.
> Please try a recent stable vanilla kernel and send a complete dmesg
> from boot. I need to identify the specific 816x chipset.
>
> Then record some traffic:
>
> # touch gonzo.pcap && tshark -w gonzo.pcap -i eth1
>
> It should only exhibit small outgoing packets but, well, one never knows.
>
> Check the leds activity to be sure that the network interfaces have not
> been renumbered.
>
> Use ethtool to check that tso is disabled. If it isn't, disable it.
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: driver r8169 suddenly failed
  2016-12-27  0:12 ` Francois Romieu
  2016-12-27  7:33   ` Robert Grasso
@ 2016-12-27 19:41   ` Robert Grasso
  2016-12-27 23:12     ` Francois Romieu
  1 sibling, 1 reply; 5+ messages in thread
From: Robert Grasso @ 2016-12-27 19:41 UTC (permalink / raw)
  To: Francois Romieu; +Cc: Realtek linux nic maintainers, netdev

Hello,

I have some unexpected (and interesting) news. I did not run the test 
yet. While I was investigating my issue, I ordered a fast 
Ethernet-to-USB3 converter, able to reach 1000Mbit/s, in order to 
recover my broadband quickly : here is the chip as reported by dmesg :

[    8.114327] ax88179_178a 4-1:1.0 eth2: register 'ax88179_178a' at 
usb-0000:03:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:0e:c6:c2:ce:d1

from the chinese brand  UGreen : at first sight, you do not seem to be 
related to it. On their advertisement, they allege they are compatible 
with kernel 2.6 and higher (which I confirmed on various forums before 
ordering it). However, guess what : I have the EXACT SAME behaviour !
- connected from the Shuttle (with USB3) on my cable modem, it fails to 
acquire the IP address as well (same endless loop) !
- from my laptop with Ubuntu 16.04 now : - connected on the LAN (and 
thus, on the Shuttle which runs my local DHCP server across YOUR 
perfectly functioning interface and driver) it works perfectly
                                          - connected on the cable 
modem, it fails too !

So, what is your opinion :
- should I broaden my request for help to other teams than yours (kernel 
maintainers) ?
- are you still interested in this test you asked for ?

Best regards

-- 
Robert Grasso
@home
---
UNIX was not designed to stop you from doing stupid things, because
   that would also stop you from doing clever things. -- Doug Gwyn

On 27/12/2016 01:12, Francois Romieu wrote:
> Robert Grasso <robert.grasso@modulonet.fr> :
> [dhcp snafu]
>> First of all, can you confirm that I am doing right in posting to you
>> (addresses found in README.Debian) ?
> It isn't completely wrong.
>
>> If I do, can you help ? I am not very proficient with Ethernet, and I am not
>> able to figure out what my provider changed : their hotline is
>> underqualified, they are just able to tell that "the signal on the line is
>> ok".
> You're spoiled. It is more than decent for a company whose core business
> used to sell cable TV.
>
>> But if you want me to run various tests, try new versions, I would be
>> glad to do so : I would appreciate if I could salvage this Shuttle.
> Please try a recent stable vanilla kernel and send a complete dmesg
> from boot. I need to identify the specific 816x chipset.
>
> Then record some traffic:
>
> # touch gonzo.pcap && tshark -w gonzo.pcap -i eth1
>
> It should only exhibit small outgoing packets but, well, one never knows.
>
> Check the leds activity to be sure that the network interfaces have not
> been renumbered.
>
> Use ethtool to check that tso is disabled. If it isn't, disable it.
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: driver r8169 suddenly failed
  2016-12-27 19:41   ` Robert Grasso
@ 2016-12-27 23:12     ` Francois Romieu
  0 siblings, 0 replies; 5+ messages in thread
From: Francois Romieu @ 2016-12-27 23:12 UTC (permalink / raw)
  To: Robert Grasso; +Cc: Realtek linux nic maintainers, netdev

Robert Grasso <robert.grasso@modulonet.fr> :
[...]
> So, what is your opinion :
> - should I broaden my request for help to other teams than yours (kernel
> maintainers) ?

If I had to untangle this mess, I would check that my router is not
configured with an empty dhcp range. Then I would put each and every
interface facing it in promiscuous (tcpdump) capture mode until one
of those is able to negotiate a dhcp lease. I would thereafter replace
it with the r8169 interface and compare the traffic (+ ethtool byte/packet
counters).

-- 
Ueimor

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-12-27 23:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-26  8:01 driver r8169 suddenly failed Robert Grasso
2016-12-27  0:12 ` Francois Romieu
2016-12-27  7:33   ` Robert Grasso
2016-12-27 19:41   ` Robert Grasso
2016-12-27 23:12     ` Francois Romieu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.