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:	Fri, 5 Aug 2011 19:36:41 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Tom London <selinux@...il.com>
cc:	Dave Jones <davej@...hat.com>, netdev@...r.kernel.org
Subject: Re: return of ip_rt_bug()


	Hello,

On Fri, 5 Aug 2011, Tom London wrote:

> I'd like to conclude that this is due to UDP casting on the wlan.
> I'll reboot with the radio on and in debug mode to see what happens.

	Sending to 255.255.255.255 without binding to source address
or output device will succeed only if there is a route that matches
the 255.255.255.255 address (default route as last option).
If no route matches, the result is ENETUNREACH and packet
should be dropped. But how input route is attached, I still don't know.

	Your ip monitor does not show fatal event that can
invalidate the source address or the default route (that
will match for 255.255.255.255) while sending packet.
It is almost impossible such problem to occur, i.e. between routing
and following re-routing the address/route to disappear.

	Such events:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether

	are may be for link, not sure. Events for addresses/routes
would show addresses and routes in a way similar to
ip addr and ip route list.

	Not sure where your logs go, may be you can add
"kern.* /var/log/kernel.log" in your /etc/rsyslog.conf. But if
you don't see the WARNING then the problem does not happen.
You can also see the ip_rt_bug line with 'dmesg'. So, can
you confirm the problem occurs only when default route
points to wlan? Even if so, I still don't see good explanation
for the error message.

Regards

--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ