-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jiri Klimes
Sent: 06 April 2009 14:20
To: [email protected]
Subject: [networking-discuss] Lost/dropped messages when sending IPv6/IPsecUDP
datagrams
Hello,
I run some tests on Solaris (Update 5).
I encounter some messages are lost when sending UDP/IPv6 over IPsec.
What was strange for me is that some messages went through, although others got
lost
(they were not even visible via wireshark, nor via DTrace (ip_drop_packet)).
I've digged into the problem and have found that messages are lost when
they are of specific length (not too short, not too long).
IMHO, it has something to do with fragmentation:
a) message is short - no need to fragment - everything is OK
b) message is of middle length (it < 1500 without, but > 1500 after including
IPsec headers) - ICMPv6 Packet Too Big is generated to self - but
I don't see the ICMP in wireshark nor in a raw socket (icmpd from Stevens
UNP book); I see the ICMP in a dtrace script as dropped incoming IPsec
packet.
The original datagram is not sent out and seen anywhere.
c) message is large (> 1500 bytes) - message is fragmented via
ipsec_out_process() - everything is OK
My concern is case b).
I would consider it a bug as the message being sent is silently dropped.
What is the reason for fragmentation longer (> 1500) packets automatically,
but dropping shorter?
The too cases are differentiated by two conditions in source code; function
ip_wput_ire_v6():
1)
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ip6.c
~ line 11090
if (ntohs(ip6h->ip6_plen) + IPV6_HDR_LEN > max_frag || (ire->ire_frag_flag &
IPH_FRAG_HDR))
Handles > 1500-bytes packets by eventually calling ipsec_out_process();
icmp_pkt2big_v6() is called just when IPV6_DONTFRAG is required
2)
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ip6.c
~ line 11132 if (ntohs(ip6h->ip6_plen) + IPV6_HDR_LEN + extra_len > max_frag)
Handles < 1500-bytes packets (case a) + b) ) But for case b) IPV6_DONTFRAG flag
is not checked and icmp_pkt2big_v6() is called causing dropping packet and
generating the ICMP.
Why the condition in point 2) is actually used? Shouldn't be deleted? Is it
complete?
I've posted this issue already at comp.unix.solaris newsgroup.
Dan McDonald suggested test on OpenSolaris. So I tried the tests on MilaX 0.3.1
Live CD, server edition.
(Sorry, I have no OpenSolaris machine available, that's why I have tried
several live CDs, but on each something was missing; e.g. BeleniX ipsec*
commands don't work - see
http://sourceforge.net/tracker/?func=detail&aid=2728217&group_id=216118&atid=1036403
Only with MilaX I've succeeded in the end.)
Well, OpenSolaris behaves almost the same as the Solaris Update 5; i.e. the
packets of about 1414 bytes of data are dropped and ICMPv6 Packet Too Big is
generated to self.
However there is a diference in function call trace of sento() - produced by
DTrace:
On Solaris 10 Update 5 there are different call stacks that leads me to
description above.
OpenSolaris' call stacks are the same for the good and failing case, which is
strange for me. Hmmm, it looks like mctl_present is false at
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ip6.c
~ line 11129 and that's why
ipsec_out_process() is not called and the flow goes to ip_xmit_v().
In the attachment you can find 3 files:
sol10_ok.txt - sendto() dtraced when sending short packet on Solaris Update 5
sol10_bad.txt - sendto() dtraced when sending packet, which is lost on
Solaris Update 5
osol.txt - sendto() dtraced when sending packet (for both good and bad
case) on OpenSolaris
How to reproduce:
1. Set an IPsec SA
2. Set an IPsec policy
3. Send a UDP packet of 1414 bytes of payload
Jiri Klimes
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs service.
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs service.
________________________________________________________________________
_______________________________________________
networking-discuss mailing list
[email protected]
