New: Changing MTU after enabling GSO/GRO breaks incoming IPv6 neighbour discovery
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]/
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 41 lines · On Tue, 13 Apr 2010 16:17:44 GMT [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=15777
Summary: Changing MTU after enabling GSO/GRO breaks incoming
IPv6 neighbour discovery
Product: Networking
Version: 2.5
Kernel Version: 2.6.33
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV6
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: NoI have discovered that on one machine, if I enable either GSO or GRO (with ethtool -K), and then change the interface MTU, the machine ceases to be IPv6 neighbour-discoverable. After the following commands:
ethtool -K eth0 gro on gso on # doesn't matter which of them, or both ifconfig eth0 mtu 4082
the machine is no longer ping6'able from LAN by "new" hosts (which haven't seen it recently) -- until something ELSE is adjusted on the same interface of that machine, e.g. the following command helps (I don't know why, the PROMISC mode is already disabled when it runs):
ifconfig eth0 -promisc
The NIC (using the "skge" driver):
00:08.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T
[Marvell] (rev 10)The system is a Debian Squeeze with 2.6.33 kernel and ethtool 2.6.33.
The issue is 100% reproducible.