[Openswan dev] [xl2tpd] [PATCH] work around endianness bug in Apple's L2TP

[Brian Mastenbrook]

Apologies for the slightly off topic mail, but I tried to send this to 
the xl2tpd list and it bounced due to mailman misconfiguration; I 
thought it might reach interested folks here.

While trying to debug some issues with an Openswan + xl2tpd roadwarrior 
configuration and OS X / iPhone clients, I saw a number of messages that 
looked a lot like these:

Feb 19 06:20:43 host xl2tpd[1423]: result_code_avp: result code out of 
range (768 0 14).  Ignoring.
Feb 19 08:20:43 host xl2tpd[1423]: control_finish: Peer tried to 
disconnect without specifying result code.
Feb 19 06:20:43 host xl2tpd[1423]: result_code_avp: result code out of 
range (256 0 14).  Ignoring.
Feb 19 06:20:43 host xl2tpd[1423]: control_finish: Peer tried to 
disconnect without specifying result code.

The codes in question should have been 3 and 1, respectively. The 
problem lies in Apple's L2TP implementation:

     *((u_int16_t*)buf) = params->result_code;

and

             *((u_int16_t*)buf) = params->error_code;

from prepare_StopCCN and prepare_CDN in 
http://www.opensource.apple.com/source/ppp/ppp-412.3/Drivers/L2TP/L2TP-plugin/l2tp.c 
. Note the missing "htons". Bad Apple!

The attached patch works around the problem by treating any result code 
or error code whose low byte is 0 and high byte is a plausible 
result/error code as an indication of this bug. With the patch in place, 
tunnels are cleaned up immediately when the client disconnects.

-- 
Brian Mastenbrook
brian at mastenbrook.net
http://brian.mastenbrook.net/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xl2tpd-result-code-endian.diff
Url: http://lists.openswan.org/pipermail/dev/attachments/20110222/396148a1/attachment.pl