[vpn-devel] shrew vid and ntoh/hton question

Paul Wouters paul at nohats.ca
Thu Oct 17 21:24:16 CDT 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 vpn-devel mailing list