> The UDP packets that implement the CIPE tunnel will be handled by the
> 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.
True. And that is why my CIPE failed. UDP packets arrive, but the ISP screws
their checksum. So, Windows discards these packets and they are never handed
over to CIPE. So, all the CIPE configurations I've tried have most probably
been just fine.
> Address translation by default allows traffic that is initiated in one
Generally true, but in this case the address translation is one-to-one.
I.e., I have a fixed public IP for my computer, and I have a fixed private
IP for my computer. This is not a NAT (or masquerade) system, and all
connections (including TCP SYN's) to both directions and all ports are
> You may have to get your ISP to configure/allow the UDP behaviour you
That is what I hope. But as I explained earlier, the problem is that my ISP
does not handle correctly UDP packets with no checksum (i.e. checksum is
zero). This may be a firmware problem in some router, or something. Quite
difficult to track down, as my ISP has not told me what kind of hardware
This is the reason why I would like to have CIPE in Linux to send the
checksum, because the ISP bug does not affect packets with the correct
checksum. The ISP problem occurs only when a UDP packet with checksum = 0 is
sent (indicating that the packet is not checksummed, as is the case with
CIPE in Linux).
> 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
> you send and receive data to/from any tcp or udp port/s
Great. That is something I really need, as with that tool I can show the ISP
that their system does not conform to RFC's talking about UDP checksums.
Have a nice weekend,