netdev - Some ICMP-Reply messages don't arrive in User Space in recent Kernels

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-next>] [day] [month] [year] [list]

Date:	Tue, 13 Oct 2015 08:47:45 +0200
From:	Jörg Pommnitz <j.pommnitz@...il.com>
To:	netdev@...r.kernel.org
Subject: Some ICMP-Reply messages don't arrive in User Space in recent Kernels

Hello all,
I'm moving an application from 2.6.23 (yes, it's ancient; that's why
we are moving) to 3.18LTS. The application monitors multiple network
links to the same target with ping packets. The different links are
selected either by their next hop router (Ethernet) or the network
interface (Point-to-Point links, aka cellular data).
To force different routes to the same target, the outgoing packets are
tagged with different firewall marks. Then I'm using routing rules to
select different routing tables with different routes for the same
target.
The outgoing path works perfectly fine in both, 2.6.23 and 3.18.
However, the same is not true for the incoming ICMP replies. They are
incoming; I see them with tcpdump. But some packets do not get
delivered to user space in 3.18. I'm not 100% sure, but I think this
happens if there is no "normal" route to the ping target, e.g. the
source address of the ICMP replies. This looks like some kind of
misguided ingress filtering that keeps packets out if a normal routing
lookup fails.

Am I on the right track? If so, is there a way to disable this
filtering? If not, what could cause this changed behaviour?

Thanks in adavance and kind regards
  Joerg
--
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