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

Subject: Re: Deaf CIPE-Win32
From: "Damion K. Wilson" <dkw,AT,rcm,DOT,bm>
Date: Thu, 16 Nov 2000 23:38:17 +0100
In-reply-to: <000501c04c28$add564a0$822b670a@uusiville>

Aha.

You're using address translation. You must make sure that traffic going to
the masquerading router on the chosen CIPE port is forwarded to the right
box. You don't say how you've verified that the UDP traffic is arriving at
the NT box from the Linux box. It may be that the UDP packets are
disappearing into a "black hole" created by the ISP router's address
translation tables. First, connect the two computers to the same ethernet
segment and configure them to converse using IP. Then configure CIPE over
that. If that doesn't work then there is probably something wrong with the
CIPE-Win32 setup. If it does work, then it's your routing/ISP setup.

As it stands, you can try to verify whether or not the UDP traffic actually
gets to the NT box by using a packet monitor. Until you can verify that the
return CIPE packets are even getting across the WAN to the ADSL modem, you
can't proceed any further. Don't worry about the checksums just yet.

DKW

*********** REPLY SEPARATOR  ***********

On 11/16/00 at 11:41 PM Ville Voipio wrote:

>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
>
>
>
>--
>Message sent by the cipe-l,AT,inka,DOT,de mailing list.
>Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
>Other commands available with "help" in body to the same address.
>CIPE info and list archive:
<URL:http://sites.inka.de/~bigred/devel/cipe.html>





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