<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: CIPE-win32 v2.0-pre2 -> CIPE 1.4.3 = frame errors
From: "Ville Voipio" <ville.voipio,AT,iki,DOT,fi>
Date: Tue, 21 Nov 2000 23:55:36 +0100
In-reply-to: <3A1ACAED.77317E75@art-render.com>

> How can I diagnose this further to identify and resolve the cause of the
> frame errors?

I am afraid you'll have to dig into the packets to be able to diagnose the
problem. This is what I did to find out what is wrong:

1. Disable encryption ("nokey true" in options file in Linux, a check box in

2. Use windump with the following command line:
     windump -nl -x -s 512 -i <your ethernet i/f number> "dst port <CIPE
   Windump is a tcpdump clone for Windows. Seems to work fine in W2k.
   You can find it in the net, it is freeware.

3. Use tcpdump in the remote end (Linux) with a similar command line:
     tcpdump -nl -x -s 512 -i <ethernet i/f> 'dst port <CIPE port>'

4. Ping the remote machine from the local machine over CIPE.

You can do this without having immediate interactive access to the Linux
machine. However, this is _much_ easier if you can set up ssh daemon on the
Linux machine. Then you can opean a console window on your W2k without
security problems.

Now, after pinging, you'll have to see what is in the packets. This is how
the packets should look like:

  <IP header 1> <UDP header> <IP header 2> <ICMP message>

The first IP header is the public Internet header. That is, the addresses
are the real IP addresses. If you can receive anything, this header should
be ok. The UDP header has the port numbers, length information, and a
checksum for the packet.

After the UDP header comes the actual tunneled IP packet. It is a full IP
packet with IP header (w/ local addresses, this time), and finally the ICMP
(ping) message.

You should compare the sent and received message. This can be done manually
pretty easily as the message is only some 80-100 bytes long. There will be
differences in the IP header, at least the TTL field will change. Also, all
address translations reflect here.

The UDP header should not change at all, and everything coming after that
(i.e. the tunneled message) must be identic in both ends of the connection.

If you are not familiar with the IP and UDP headers, you can find a quite
concise description at:


Sections "The Internet Protocol Format", "ICMP Message Types" and "The UDP
Header" are most relevant in this case.


If you can verify that the messages are identical in both ends, then you'll
have to look into the dump more closely. If the messages are fine, then you
have a problem with your CIPE in the Linux. If they are not, the problem is
in the W2k end. If you need more assistance with the headers, please mail
the hex dumps here.

Been there, done that ;)

- Ville

<< | Thread Index | >> ]    [ << | Date Index | >> ]