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

Subject: RE: CIPE-WIN32 Routing Configuration
From: "Matthew Kurowski" <matthew,AT,kurowski,DOT,org>
Date: Tue, 5 Dec 2000 02:32:13 +0100
In-reply-to: <200012041631190023.850FC307@mail-server>

I removed and then installed the adapters at both locations using the new
pre3 release. It not only stopped the irp bluescreen but it also seems that
the hosts can actually talk to each other.

I've included a sample here to show the two-way communication working...

[CHI-NYC] NK_ACK: Installing new encryption key. CRC=59814252
[CHI-NYC] NK_REQ: Received request from peer to generate new sending key.
CRC=59
814252 KEYLEN=16
[CHI-NYC] NK_ACK: Installing new encryption key. CRC=2436116d
[CHI-NYC] NK_IND: Using peer's new key for decryption. Sending NK_ACK.
CRC=cb161
21b
[CHI-NYC] Sending CT_PING message
[CHI-NYC] NK_REQ: Received request from peer to generate new sending key.
CRC=24
36116d KEYLEN=16
[CHI-NYC] NK_ACK: Installing new encryption key. CRC=93d249f1
[CHI-NYC] NK_IND: Using peer's new key for decryption. Sending NK_ACK.
CRC=9d344
e37
[CHI-NYC] Sending CT_PING message
[{9A98968B-3F10-490C-A6F6-6F8CBB222632}] Generating ARP entry for
[CHI-NYC:192.1
68.69.1]
[CHI-NYC] NK_IND: Using peer's new key for decryption. Sending NK_ACK.
CRC=3a48f
366
[CHI-NYC] Sending CT_PING message
[CHI-NYC] NK_REQ: Received request from peer to generate new sending key.
CRC=93
d249f1 KEYLEN=16
[CHI-NYC] NK_ACK: Installing new encryption key. CRC=948858dc
[CHI-NYC] NK_REQ: Received request from peer to generate new sending key.
CRC=94
8858dc KEYLEN=16
[CHI-NYC] NK_ACK: Installing new encryption key. CRC=9d73bb1f
[CHI-NYC] NK_IND: Using peer's new key for decryption. Sending NK_ACK.
CRC=e1d89
a91
[CHI-NYC] Sending CT_PING message
[CHI-NYC] NK_REQ: Received request from peer to generate new sending key.
CRC=9d
73bb1f KEYLEN=16
[CHI-NYC] NK_ACK: Installing new encryption key. CRC=71095d44

This output matches on both sides. It happens more frequently than I
remember, but the CRC's do match on each side.

I pulled out the route add statements and can only get a destination
unreachable.

Here's the routing table after the following route add was put back in
(using 'route add 192.168.69.0 mask 255.255.255.0 192.168.70.1 if 2'). Only
one route add is done per site.

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...08 00 58 00 00 01 ...... DKW Heavy Industries VPN Adapter.
0x4000004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
     192.168.69.0    255.255.255.0     192.168.70.1    192.168.70.1       1
     192.168.70.0    255.255.255.0     192.168.70.1    192.168.70.1       1
     192.168.70.1  255.255.255.255        127.0.0.1       127.0.0.1       1
   192.168.70.255  255.255.255.255     192.168.70.1    192.168.70.1       1
   199.245.227.73  255.255.255.255        127.0.0.1       127.0.0.1       1
  199.245.227.255  255.255.255.255   199.245.227.73  199.245.227.73       1
Default Gateway:    199.245.227.73
===========================================================================
Persistent Routes:
  None

Here is the same as before. The 2000 box times out; the NT 4 box still goes
out to the ISP router and gets a destination unreachable. Traceroute reports
on the NT box that it's still going out the ISP interface, but on the 2000
box it just timesout.

I'm getting semi-regular Datagrams Received Errors (per Perfmon), which is
"the number of received UDP datagrams that could not be delivered for
reasons other than the lack of an application at the destination port".

Thanks again for the help. I appreciate any continued assistance. I'm going
to step back and review everything again. I noticed that when I do continual
pings to each PTP addr from the respective hosts that the REQ, ACK, and
IND's stop until the pings are stopped. The only update to the console
window after the continuous pings were 'updating adapter statistics'
messages on each end.

One last note for Damion if it helps at all with your development. Visual
Studio Debugger lists the following when try to start the console
service if the console service is already running in another window and it
doctor watson's...
error: access violation
name: this
value: vxx0017: error: symbol "this" not found

Thanks again,
Matthew

Attachment: bin00002.bin
Description: "winmail.dat"


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