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:	Mon, 16 Apr 2012 13:37:14 +0300
From:	Denys Fedoryshchenko <denys@...p.net.lb>
To:	Stian Skjelstad <stian@...ia.no>, <eric.dumazet@...il.com>,
	<stephen.hemminger@...tta.com>
Cc:	<netdev@...r.kernel.org>
Subject: Re: SV: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

After digging the code, i came to conclusion:
fib_del_ifaddr, will check if deleted address are exist as prefsrc or 
interface are shut down, they will do fi->fib_flags |= RTNH_F_DEAD;
Then fib_flush -> fib_table_flush -> trie_flush_leaf -> trie_flush_list 
will delete such routes.
But trie_flush_list won't notify over netlink that route are deleted.

So the only solution is to fetch first, then keep full routing table in 
userspace also, and keep tracking if local addresses deleted, and do the 
same in userspace and check for prefsrc...

Maybe it should be fixed? E.g. netlink message sent when any route are 
deleted, even over the flush

On 2012-04-13 16:59, Stian Skjelstad wrote:
> I've seen the same issue, and got no response so far to that very
> same question. Have you tested this on older kernels? I have worked
> around this issue by testing my local copy of routing entries that 
> use
> 'via'. If they are not routable when after the RTM_DELROUTE event, I
> autoremove them from my local copy.
>
> Stian Skjelstad
>
> -----Opprinnelig melding-----
> Fra: netdev-owner@...r.kernel.org
> [mailto:netdev-owner@...r.kernel.org] På vegne av Denys 
> Fedoryshchenko
> Sendt: 13. april 2012 14:11
> Til: netdev@...r.kernel.org
> Emne: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer
> address. Bug or feature?
>
> Hi
>
> I am trying to implement my own routing daemon, and using
> RTMGRP_IPV4_ROUTE to monitor routes.
> I notice, that on PPPoE, when interface disappearing, RTM_DELROUTE
> will be sent to listener only for local address, but nothing about
> peer address attached to this interface.
>
> CBSS_PPPoE ~ # ifconfig ppp0
> ppp0      Link encap:Point-to-Point Protocol
>            inet addr:172.16.146.1  P-t-P:172.16.146.10
> Mask:255.255.255.255
>            UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1200  Metric:1
>            RX packets:40439 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:63211 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:3
>            RX bytes:3584507 (3.4 MiB)  TX bytes:47180929 (44.9 MiB)
>
> CBSS_PPPoE ~ # pppkill tek234@...p.net.lb  (this is killing pppd
> process for ppp0 interface)
>
> ip monitor route will show only RTM_DELROUTE for RTN_LOCAL, but
> nothing about RTN_UNICAST for 172.16.146.10.
> "Deleted local 172.16.146.1 dev ppp0  table local  proto kernel
> scope host  src 172.16.146.1"
> My program also receive same.
>
> Is it a bug, that no RTM_DELROUTE issued for peer ip address? Or
> should i monitor also RTMGRP_IPV4_IFADDR for link disappearance?
>
> Thanks for help!
> --
> 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
>
> --
> 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
--
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