* Re: [Bugme-new] [Bug 15777] New: Changing MTU after enabling GSO/GRO breaks incoming IPv6 neighbour discovery
[not found] <bug-15777-10286@https.bugzilla.kernel.org/>
@ 2010-04-13 19:37 ` Andrew Morton
0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2010-04-13 19:37 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, roman
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 13 Apr 2010 16:17:44 GMT
bugzilla-daemon@bugzilla.kernel.org 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: yoshfuji@linux-ipv6.org
> ReportedBy: roman@rm.pp.ru
> Regression: No
>
>
> I 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.
^ permalink raw reply [flat|nested] only message in thread