[Swan] shrew vid and ntoh/hton question
Paul Wouters
paul at nohats.ca
Fri Oct 18 05:24:16 EEST 2013
Hi Matthew (and ipsec devs)
In the shrew code I see:
#define VEND_HBEAT { 0x48, 0x65, 0x61, 0x72, 0x74, 0x42, 0x65, 0x61, 0x74, 0x5f, 0x4e, 0x6f, 0x74, 0x69, 0x66, 0x79, 0x38, 0x6b, 0x01, 0x00 }
The HEARTBEAT vendor ID is "HeartBeat_Notify"
The above define seems to have been changed from host to network order
as can be seen using by running on an intel:
echo -n HeartBeat_Notify | hexdump
0000000 6548 7261 4274 6165 5f74 6f4e 6974 7966
0000010
The regular vendorid for NAT RFC style is:
echo -n "RFC 3947" | md5sum
4a131c81070358455c5728f20e95452f -
In the shrew source I see:
#define VEND_NATT_RFC { 0x4a, 0x13, 0x1c, 0x81, 0x07, 0x03, 0x58, 0x45, 0x5c, 0x57, 0x28, 0xf2, 0x0e, 0x95, 0x45, 0x2f }
which seems to be in host order
So I'm a little puzzled. The reason I got here was that I was looking at
an unknown vendorid on libreswan when shrew soft connects.
packet from 194.166.176.151:500: ignoring unknown Vendor ID payload [3b9031dce4fcf88b489a923963dd0c49]
which apparently is the VEND_DPD1_NG vendorid that I cannot find elsewhere.
#define VEND_DPD1_NG { 0x3b, 0x90, 0x31, 0xdc, 0xe4, 0xfc, 0xf8, 0x8b, 0x48, 0x9a, 0x92, 0x39, 0x63, 0xdd, 0x0c, 0x49 }
Could it be that there are some hton/ntoh mixups in iked/iked.h?
Although I cannot find either 903bdc31fce48bf89a483992dd63490c or
3b9031dce4fcf88b489a923963dd0c49 online anywhere.
Paul
More information about the Swan
mailing list