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-prev] [day] [month] [year] [list]
Date:   Sat, 23 Mar 2019 01:26:10 +0000
From:   Alex Xu <alex_y_xu@...oo.ca>
To:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Cc:     gnomes@...rguk.ukuu.org.uk
Subject: Re: r8169 only works in promisc mode

I have done some more investigation, some of which I posted on the
Bugzilla bug.

I believe the promisc issue is due to the MAC address receive filter
being silently reset to the invalid burned-in address. I used wireshark
and determined that the outgoing MAC address after suspend is the
overridden value. Re-setting the overridden value with "ip link set eth0
address" appears to have no effect. Setting it to a different overridden
value works normally and resolves the packet loss issue. Removing the
module and re-inserting it also resolves the issue.

I also attempted to determine why the MAC address on boot is
8e:00:00:00:8e:8e. As far as I can tell, this value is burned into the
flash somewhere. I tried turning off the machine, unplugging the power,
pressing the power button several times, then plugging it back in and
immediately booting into Windows; the incorrect MAC address was shown.

This reminded me that I am experiencing another firmware-related issue,
namely that it appears that the machine is only able to reach S1 or
possibly S2 sleep mode, even when specifying S3, and even in Windows. I
think there may be some flash bitrot, but clearing the firmware
settings, by all of: in the interface, removing the battery, and setting
the jumper; had no effect. I also tried reinstalling the BIOS using the
vendor-provided Windows updater, which also had no effect.

In conclusion: I think my firmware is broken (even moreso than regular
PC firmware), but I believe there is in fact some bug with r8169 on
"RTL8211B" in 5.0-rc1.

I can try bisecting if someone more competent than me believes that
would be helpful.

Thanks,
Alex.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ