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

To: cipe-l,AT,inka,DOT,de
Subject: CPU Usage CIPE-WIN32 Windows XP
From: bhein,AT,bmc-pos,DOT,com
Date: Mon, 15 Sep 2003 16:51:08 -0400

To respond to a slightly old post, which I just read on the internet.......

I've installed CIPE for win32 on my laptop (win2k professional SP4) and on
a freshly loaded Win2kServer. Both are Pentium boxes. The problem is that

1. upon boot, the CIPE device has yet to work without a service reset
2. sometimes after the service has been restarted, its CPU consumption
skyrockets and remains there, and the system becomes unusable.
3. if the ethernet link state goes down (And back up) then the CIPE devices
sometimes becomes unstable and produces unpredictable results. For instance
full CPU consumption, and even BSOD.

From what I can tell, the problems exist within in the service cipsvr.exe.
In my humble understanding of NT Services, I know that some services depend
on other services. Perhaps CIPE fails to start because another service that
it needs hasn't yet been started when it is activated. As for the 100%CPU,
I can't imagine what would cause this. I'm not a yoda programmer, so I
won't presume to know the cause, or solution.

Snippets of my configurations follow. I used grep so that each config file
is prefixed with the filename.

Windows 2000:
Local IP Address 0.0.0.0 port 1737
Peer IP Address my.outside.IP.addrses 1736

Peer PTP Address 192.168.5.1

I'm using a 32-byte key, blowfish, and a 600 second timeout value.

Linux:

[root@ASDF endpoints]# grep . *
gmsguy:  # Surprise, this file allows comments (but only on a line by
themselves)
gmsguy:  # This is probably the minimal set of options that has to be set
gmsguy:  # Without a "device" line, the device is picked dynamically
gmsguy:  # the peer's IP address
gmsguy:ptpaddr         192.168.5.102
gmsguy:  # our CIPE device's IP address
gmsguy:ipaddr          192.168.5.1
gmsguy:  # my UDP address. Note: if you set port 0 here, the system will
pick
gmsguy:  # one and tell it to you via the ip-up script. Same holds for IP
0.0.0.0.
gmsguy:me              0.0.0.0:1734
gmsguy:  # ...and the UDP address we connect to. Of course no wildcards
here.
gmsguy:peer            0.0.0.0:1735
gmsguy:  # The static key. Keep this file secret!
gmsguy:  # The key is 128 bits in hexadecimal notation.
gmsguy:key             00000000010000000002000000000322
gmsguy:  # ping 10
gmsguy:device cipcb1
gmsguy:dynip 1
gmsguy:maxerr=-1
svr_gr:  # Surprise, this file allows comments (but only on a line by
themselves)
svr_gr:  # This is probably the minimal set of options that has to be set
svr_gr:  # Without a "device" line, the device is picked dynamically
svr_gr:  # the peer's IP address
svr_gr:ptpaddr         192.168.5.103
svr_gr:  # our CIPE device's IP address
svr_gr:ipaddr          192.168.5.1
svr_gr:  # my UDP address. Note: if you set port 0 here, the system will
pick
svr_gr:  # one and tell it to you via the ip-up script. Same holds for IP
0.0.0.0.
svr_gr:me              0.0.0.0:1736
svr_gr:  # ...and the UDP address we connect to. Of course no wildcards
here.
svr_gr:peer            0.0.0.0:1737
svr_gr:  # The static key. Keep this file secret!
svr_gr:  # The key is 128 bits in hexadecimal notation.
svr_gr:key             00000000010000000002000000000322
svr_gr:  # ping 10
svr_gr:device cipcb2
svr_gr:dynip 1
svr_gr:maxerr=-1
[root@ASDF endpoints]#

                                                                           
         To: "Cipe List (E-mail)" <cipe-l,AT,inka,DOT,de>                  
                                                                           
    Subject: CPU Usage CIPE-WIN32 Windows XP                               
                                                                           
       From: Dave <duser,AT,churchers,DOT,co,DOT,uk>                       
                                                                           
       Date: Mon, 11 Aug 2003 11:25:16 +0100                               
                                                                           

When I first enable a CIPE link either by starting the PC or by starting
the
service, the cipesrvr process uses 100% CPU for about 5 minutes constantly.
After an hour or two I again get this problem and a message about forcing
new key generation (if using the console, no messages in service mode
naturally).

Has anyone else noticed this happening? does anyone have any advice on a
possible cause?
Thanks very much for any help.

Dave

--Brad


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