Re: r8169 nic sometimes doesn't work after changing the mac address

[Maximilian Engelhardt <maxi@daemonizer.de>]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

On Saturday 12 December 2015 22:43:45 Maximilian Engelhardt wrote:
> Hello,
> 
> I'm using a Lenovo TinkPad Edge E135 notebook that has a Realtek wired
> network interface inbuilt. Under some conditions the nic doesn't work after
> changing the mac address.
> 
> It took me some time to figure out that it makes a difference if I (re)boot
> my notebook with or without the power supply plugged in. When I boot the
> system with the power supply plugged in everything does work fine as
> expected. But if I boot with the power supply unplugged and I change the
> mac address the network card doesn't work.
> 
> 
> This is how I am testing and how I can reproduce the behavior on my system:
> 
> * Boot Linux (Debian stable with a newer kernel)
> * Network is still turned off, only loopback is enabled by default in my
> setup. * I run the following commands:
>   ip link set dev eth0 address 00:12:0c:96:a7:2e # a randomly generated mac
>   ip link set dev eth0 up
>   ip addr add dev eth0 10.0.252.50/24
>   ip route add default via 10.0.252.1
> 
> When the notebook is booted with the power supply plugged in the network is
> working as expected, e. g. I can ping the gateway.
> 
> But when the notebook was booted without the power supply attached the
> network is not working e. g. pinging the gateway doesn't get any replies.
> 
> I found two ways to get the network working from this state (beside
> rebooting with power plugged in):
> 
> * If I enable promiscous mode the network connections are working again:
>   # ip link set dev eth0 promisc on
> 
> * Alternatively I can set the same mac address again while the interface is
> up:
>   # ip link set dev eth0 address 00:12:0c:96:a7:2e # same mac as before
> 
> 
> So it seems like a mac filter in the network card is not set up right.
> 
> 
> Attached are dmesg output of a boot with and without power supply attached
> as well as the output of lspci -vvv.
> 
> 
> Please let me know If you need more information.
> 
> Thanks,
> Maxi


Hello,

Anyone had a look at this? I can confirm that the problem is still present in 
kernel 4.4.2.

I just did a quick tcpdump and found out that packets are transmitted fine, but 
the replay of the other end gets lost somewhere in the nic/driver e. i. it 
seems to never reach the kernel network stack.

Please let me know if you need more information from me.

Thanks,
Maxi

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]