<br><font size=2 face="sans-serif">Hi</font>
<br>
<br><font size=2 face="sans-serif">I am using strongSwan 4.5.1 on two virtual
machines running Linux kernel 2.6</font>
<br>
<br><font size=2 face="sans-serif">For performance tests of the IPsec protocol
over an error-prone channel, I am injecting</font>
<br><font size=2 face="sans-serif">bit errors at predefined rates into
the packets. However I noticed that for certain cases</font>
<br><font size=2 face="sans-serif">the responding virtual machine froze
completely.</font>
<br>
<br><font size=2 face="sans-serif">After a lot of debugging using wireshark
and some other tools, I was able to find out that</font>
<br><font size=2 face="sans-serif">the error occurs for fragmented packets
only (in my case, the IKE_AUTH request</font>
<br><font size=2 face="sans-serif">from the initiator gets fragmented into
2 fragments).</font>
<br>
<br><font size=2 face="sans-serif">More precisely, the affected field is
the ip_total_length field of the second fragment.</font>
<br><font size=2 face="sans-serif">I found out, that when the resulting
ip_total_length value is smaller than the originally</font>
<br><font size=2 face="sans-serif">generated value, the machine crashes
after a few more message exchanges (surprisingly</font>
<br><font size=2 face="sans-serif"> it does not crash instantly).</font>
<br>
<br><font size=2 face="sans-serif">WhenI tried to reproduce the error,
I also found out that the error only occurs, if there are</font>
<br><font size=2 face="sans-serif">also error-free fragments sent once
in a while (e.g. 50% chance to corrupt ip_total_length).</font>
<br><font size=2 face="sans-serif">I assume that when reassembling the
ip packets, strongSwan somehow gets confused</font>
<br><font size=2 face="sans-serif">when mixing both error-prone and error-free
packets and subsequently crashes the whole</font>
<br><font size=2 face="sans-serif">system.</font>
<br>
<br><font size=2 face="sans-serif">My setup works completely fine except
for this special case where (in a fragmented packet)</font>
<br><font size=2 face="sans-serif">the ip_total_length field is modified
so that the result is less than the original.</font>
<br>
<br><font size=2 face="sans-serif">I also had a look at the strongSwan
source to find a cause for this. However, I came to the</font>
<br><font size=2 face="sans-serif">conclusion that reassembly is done by
the Linux kernel by calling </font>
<br>
<br><font size=2 face="sans-serif">        select(max_fd
+ 1, &rfds, NULL, NULL, NULL)</font>
<br>
<br><font size=2 face="sans-serif">in socket_default_socket.c</font>
<br>
<br><font size=2 face="sans-serif">I am not very familiar with socket programming,
so this might be a misinterpretation by me</font>
<br><font size=2 face="sans-serif">because I failed to recreate the error
for other applications than strongSwan. But that is</font>
<br><font size=2 face="sans-serif">probably no evidence that the problem
rises from strongSwan...</font>
<br>
<br><font size=2 face="sans-serif">Although this is probably a very special
and individual issue, I hope that someone can</font>
<br><font size=2 face="sans-serif">give me some thoughts or advice on the
topic. Maybe there is a piece of souce code I</font>
<br><font size=2 face="sans-serif">should review to debug the problem?
Is it actually a strongSwan issue or rather a kernel</font>
<br><font size=2 face="sans-serif">bug?</font>
<br>
<br><font size=2 face="sans-serif">I would appreciate any help!</font>
<br>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Daniel Merget</font>