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  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, 7 Apr 2014 12:55:59 +0200
From:	Steffen Klassert <>
To:	Martin Pelikan <>
CC:	<>
Subject: Re: (patch needs review) NULL dereference in xfrm_output with NAT

On Fri, Apr 04, 2014 at 02:29:17PM +0200, Martin Pelikan wrote:
> Your patch avoids the crash the same way as mine, but doesn't fix my related
> problem: I have two flows through that IPv6 endpoint: IPv6 default gw tunnel
> + IPv4 tunnel between two private networks.  But only one of them works at a
> time, and it is the one which was set up first.
> The other endpoint is OpenBSD with iked(8) and I can see the replies going
> into enc0 there, ESP packets arriving into this Linux box at enp4s6, but the
> traffic isn't being decapsulated and sent further away on br0.
> If I disable the working tunnel (v6 for example), the other one (v4) starts
> working immediately, so it's probably not caused by bad strongSwan config.
> Do you think these bugs might be related?  Any ideas how to proceed without
> spending days on it? 

A good starting point for further debugging would be to find out
where the packets are dropped. xfrm increases a counter whenever
a packet is dropped in the xfrm layer. You can find these counters
in /proc/net/xfrm_stat.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists