CIPE for Windows experience|
Jan Olderdissen <jolderdissen,AT,ixiacom,DOT,com>|
Wed, 27 Feb 2002 02:39:19 +0100|
During the past two days I have spent some quality time with CIPE for
Windows. I will summarize the issues that have come up for me. Damion
already knows about the items I have found.
There are three PCs on my network, a CIPE "client" (dual P4 1.7GHz) running
Win2k SP2 at 10.105.1.4 using PTP 22.214.171.124, a CIPE "target" (Pentium MMX
233Mhz) running Win2k SP1 at 10.105.1.6 using PTP 126.96.36.199 and a test PC
running XP at 10.105.1.3. The "target" PC is an Ixia 400 test chassis
containing eight embedded PowerPCs running Linux. The client PC is
configured to route IP. The network is private, hidden behind a NAT box.
I used "Windows NDIS driver and service, version 2.0-pre9. (354k, zip)"
Issues I had in the order they crept up:
1. The cipsrvr service will crash on startup if there is no network
interface on the PC. This is repeatable.
2. The cipsrvr service will intermittently crash on startup if the network
is misconfigured as follows: both PTP addresses are the same. This is
3. When misconfigured or unconfigured, starting cipsrvr service can blue
screen the system. I only had this failure type once.
4. On uninstall, cipdrvr will occasionally blue screen. I'm not sure what
the circumstances are that make this happen. I tried to catch it with the
kernel debugger running, but I couldn't make it happen then.
5. Cipsrvr will exit without comment when the network load is high. Using
one of the eight test ports on the Ixia 400 chassis, I ran a continuous
stream of pings into the client PC at 10.105.1.4. The MAC address was set so
that the client PC would receive it, but the destination IP was set to
188.8.131.52. This forced the packets to go across the VPN tunnel. At a rate of
about 150kByte/s, cipsrvr was able to keep up. At higher rates (I tested
260kB/s), cipsrvr service would simply quit - as evidenced by 'cipsrvr
noservice' returning to the command prompt. I was able to intermittently get
the same effect by running 90kB/s worth of FTP download over the same
configuration. Both failures are fully repeatable.