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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 17 Aug 2010 18:23:18 -0700
From:	"Matt Carlson" <mcarlson@...adcom.com>
To:	"Thomas Habets" <thomas@...ets.pp.se>
cc:	"Matthew Carlson" <mcarlson@...adcom.com>,
	"Eric Dumazet" <eric.dumazet@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	"Michael Chan" <mchan@...adcom.com>
Subject: Re: BUG: IPv6 stops working after a while, needs ip ne del
 command to reset

On Tue, Aug 17, 2010 at 11:52:27AM -0700, Thomas Habets wrote:
> On Tue, 17 Aug 2010, Matt Carlson wrote:
> > Thanks.  I put the question out to the firmware developer.  While we
> > wait, can you keep Eric's patch in place and give me the results along
> > with the output of 'ethtool -d eth0 | grep 0x047' after the problem
> > happens?
> 
> Sure.
> 
> I think the problem occurs shortly after booting, or is triggered by it 
> Linux getting a neighbor table entry for the router. The reason it took a 
> while for everything to actually stop working is that the router was 
> caching and presumably updating its neighbors cache when it saw traffic.
> 
> That is, maybe it only works if the router sets up its neigbor table 
> first, and not otherwise.
> 
> The problem is there now. Last output in the kernel log about this is:
> 
> $ dmesg | egrep 'eth0|^add mc|^filters='
> [...]
> add mc_addr(ha->addr=33:33:00:00:00:01)
> add mc_addr(ha->addr=01:00:5e:00:00:01)
> add mc_addr(ha->addr=33:33:ff:5c:00:02)
> add mc_addr(ha->addr=33:33:ff:a3:44:24)
> filters=80020001 00000000 00000000 40000000
> 
> $ sudo ethtool -d eth0 | grep 0x047
> 0x0470	0x80020001
> 0x0474	0x00000000
> 0x0478	0x00000000
> 0x047c	0x40000000
> 
> > Eric's patch shows the hash registers at the time they are programmed.
> > I'm interested to see if the values change (by firmware) after the
> > failure.
> 
> Look the same.
> 
> But a strange thing is that if I delete the ipv6 neighbor on the Linux 
> box (ip ne del 2a00:800:752:1::5c:1 dev eth0) it suddenly answers a ND 
> solicitation. I tried it just now and it "wakes it up".
> 
> Nothing was written to the kernel log when I ran this command, and the 
> ethtools -d output is the same afterwards as it was before. So unless 
> there's another code path that changes the registers when I do "ip ne 
> del" it may still be something else.

Do you have access to any diagnostic software that might have come with
your machine?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ