The UDP packets that implement the CIPE tunnel will be handled by the tcpip
stack BEFORE they get to CIPE. You must first be able to implement raw UDP
traffic between the two computers before CIPE can even be factored in. This
traffic must be able to be initiated in either direction (i.e. from Windows
or from Linux). AFAIK CIPE only really cares about the port, address, and
payload of the tunnel-bearing packets.
Address translation by default allows traffic that is initiated in one
direction. For instance, your home network uses one box for internet
access. Each home computer can initiate a conversation and the router keeps
track of the conversants. However, in that picture, www.linux.org cannot
initiate a conversation with, say, a Macintosh on your home network,
because there wouldn't be a masquerading rule in place for that. The only
computer that www.linux.org can "see" is the router so it can only send
traffic directly to that box.
You may have to get your ISP to configure/allow the UDP behaviour you wish.
I would suggest trying out simpler tools for debugging this situation than
CIPE, because you will always have to question whether CIPE is the problem
or the transport. A good tool would be netcat (the binary is always called
nc, or nc.exe on Windows. Sorry, you'll have to do a web search). It'll let
you send and receive data to/from any tcp or udp port/s
*********** REPLY SEPARATOR ***********
On 11/17/00 at 9:48 PM Ville Voipio wrote:
>Olaf, (and other wise people)
>Is there any resonable way to switch on the UDP checksum sending in CIPE
>1.4.3? I tried editing sock.c, and there on line 622 I changed the
>This, however did not seem to produce UDP checksums on UDP packets. Is
>specified elsewhere, or is the socket handling of CIPE such that the
>checksum should be calculated manually?
>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: