netdev - Re: return of ip_rt

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]

Message-ID: <alpine.LFD.2.00.1108051931250.29588@ja.ssi.bg>
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