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

Subject: Re: Deaf CIPE-Win32
From: "Ville Voipio" <ville.voipio,AT,iki,DOT,fi>
Date: Thu, 16 Nov 2000 23:01:27 +0100
In-reply-to: <000501c04c28$add564a0$822b670a@uusiville>

Sorry to bother you, but it's me again with my troublesome configuration...

I installed the newest version of Cipe-Win32. I tried it against both CIPE
1.3.0 and 1.4.3. I have not tried 1.4.4, but the differences there should
not (I know, never say "should not" with computers) be that big. All these
systems seem to work rather logically the same way; my NT machine sends data
to the Linux box with success, other way round - nope. I even tried the
"change the UDP ports" trick.

I tried one more thing; I set my NT machine as the "host" (that is with
static address) and the Linux box as the "guest" (dynamic address, daemon
started later than the Win32 one). What happened was that the Linux box
started negotiating the connection by sending one packet to the NT machine.
That packet was ignored by the NT machine, and no connection was formed
between the machines.

After this experiment it became quite evident that the CIPE-Win32 is
completely deaf. Key negotiation or anything else never goes through if it
requires a response from the CIPE Win32.

(Yes, I am on very thin ice right now, so if I'm wrong, correct me!)

The next thing I tried was some communications without any encryption,
because that way I can check the packets by hand. When I ping the remote
machine from my local machine, everything seems to go fine:

1. CIPE Win32 interface sends the packet
 2. an encapsulated UDP packet is sent from NT -> Linux
 3. Linux receives the UDP packet
4. Ping comes to the cipcb0 interface
5. Linux responds with echo-reply (seen on cipcb0)
 6. Linux sends the ping encapsulated into a UDP packet
 7. Windows NT receives the UDP packet
8. nothing happens on the CIPE-Win32 interface

So, the packet is really lost in my computer, between steps 7 and 8. The UDP
packet looks fine, but it is never unencapsulated by CIPE-Win32. And this
seems to happen with every version and combination of different CIPEs I've
tried (the count is at least ten right now).

To find out what goes wrong, I took tcpdump/windump at both ends of the UDP
connection. The packets seems to be right:

As sent by Linux:
  4500 0058 655f 0000 ff11 118b xxxx xxxx
  yyyy yyyy srcp dstp 0044 0000 4500 003c
  655e 0000 ff01 094e c0a8 65e1 c0a8 65e2
  0000 065c 0100 4e00 6162 6364 6566 6768
  696a 6b6c 6d6e 6f70 7172 7374 7576 7761
  6263 6465 6667 6869

As received by Windows:
  4500 0058 655f 0000 f311 6e2c xxxx xxxx
  zzzz zzzz srcp dstp 0044 50a1 4500 003c
  655e 0000 ff01 094e c0a8 65e1 c0a8 65e2
  0000 065c 0100 4e00 6162 6364 6566 6768
  696a 6b6c 6d6e 6f70 7172 7374 7576 7761
  6263 6465 6667 6869

Where
  xxxx xxxx -- Linux box IP,
  yyyy yyyy -- my public (dynamic) IP,
  zzzz zzzz -- my private (10.x.x.x static) IP,
  srcp      -- source port
  dstp      -- destination port

The IP header is thus fine, all differences are in addresses (there is one
translation in between), checksum, and TTL.

So, let us look at the UDP packet, as it should have been transferred
intact. But here seems to be something!!! Let us write the UDP packets on
top of each other:

Linux
  srcp dstp 0044 0000 4500 003c 655e 0000 ff01 ...
  srcp dstp 0044 50a1 4500 003c 655e 0000 ff01 ...
Windows

Look at the fourth word: The Linux box sends no UDP checksum (0 means there
is no checksum). Windows receives a checksum. A few questions arise:

1. Who does it? The packet leaves the Linux box without a checksum.
2. Does anybody check the UDP checksum? Windows? CIPE?

A checksum problem might explain the problems I have experienced, as the C/S
is generated outside of my computer. Changing harddisk, changing O/S,
changing CIPE drivers will not affect that a tiny bit.

BTW, if it is of any help, this is how the packet goes:

 Linux box
 SDSL modem
 <Big Bad Internet>
 ISP router (with address translation)
 ADSL modem
 NT machine

So something in that route calculates the C/S. And if the C/S is calculated
with some previous IP address, it'll be wrong. This should not occur, but
still might.

---

Well, that's all about this skating on thin ice. Thank you for your
patience. And as always, I'd love to hear any suggestions about what goes
wrong.

- Ville





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