We added about 40 more folks to the beta testing today and have had the
following 2 problems.
1. User with Netscape Dialer logs in but the user can NOT get anywhere.
The user has the right assigned address and the login appears normal, but
no conectivity. The PM-3 shows the user online. When I ping the client
he can see 1 CRC errror a sec. When I stop pinging the CRC's stop. I do NOT
get a return back on the Ping.
This same machine logs into a PM2-30 fine. OS is WFWG. The user changed
to trumpet and login works fine. I asked if he would bring the machine by
the shop so we can play with it.
2. Just had a second user try logging into our beta program PM-3. He has
been having NO problem with our pool of 8 PM-2-30's All logins from him
have failed with what sounds like simular indications as the first problem
user (and my problem last night). This was after hours so I was not able
to login to the PM-3 and take a look. This one also looks like a PPP
problem. Remember he can login to the PM@-30's fine....but NO luck on the
PM-3
In two of the problems all looked OK, until the user try to do something.
In the first I know he did receive the proper IP address, so at least
there is a route to him. It looked like there is no route back across the
modem link after login. I had him look for a gateway or default
route....no luck. After replacing his Netscape dialer with trumpet all is
well. The second one sent the following message. He can still log into
the PM-2 pool fine!
**************************************************************************
>From dplast@exis.net
Date: Sat, 07 Dec 96 22:55:04 -0500
From: Don Plaster <dplast@exis.net>
To: support@exis.net
Subject: Re: Help with beta TEST of DSP Modems.
I agree to test.
I changed to the new phone number and dialed in. I successfully
established a PPP session, but could not do anything else. I tried mail,
telent and ping. The following trace is from a failed PING
mailhub.exis.net attempt:
inet_addr()
gethostbyname( "mailhub.exis.net" )
ID:0 0x0001 mailhub.exis.net
UDP 4531 -> 53 SIZE : 34
00 00 01 00 00 01 00 00 00 00 00 00 07 6d 61 69 .............mai
6c 68 75 62 04 65 78 69 73 03 6e 65 74 00 00 01 lhub.exis.net...
00 01 ..
IP 205.252.73.35 -> 205.252.72.103, Length 62, Protocol 17
Invalid FCS/Checksum Error FCS:0xd70
PPP Discarding Unknown/Uneeded Packet
ID:1 0x0001 mailhub.exis.net
I disconnected and redialed the regular number and was able to work ok.
I am sending mail via regular number. The following is a successful PING
trace via regular number:
gethostbyname( "mailhub.exis.net" )
ID:256 0x0001 mailhub.exis.net
UDP 1905 -> 53 SIZE : 34
00 01 01 00 00 01 00 00 00 00 00 00 07 6d 61 69 .............mai
6c 68 75 62 04 65 78 69 73 03 6e 65 74 00 00 01 lhub.exis.net...
00 01 ..
IP 205.252.76.130 -> 205.252.72.102, Length 62, Protocol 17
IP 205.252.76.130 <- 205.252.72.102, Length 161, Protocol 17
UDP 1905 <- 53 SIZE : 133
00 01 85 80 00 01 00 01 00 02 00 02 07 6d 61 69 .............mai
6c 68 75 62 04 65 78 69 73 03 6e 65 74 00 00 01 lhub.exis.net...
00 01 c0 0c 00 01 00 01 00 01 51 80 00 04 cd fc ..........Q.....
48 66 04 65 78 69 73 03 6e 65 74 00 00 02 00 01 Hf.exis.net.....
00 01 51 80 00 09 06 6d 61 72 6c 69 6e c0 32 c0 ..Q....marlin.2.
32 00 02 00 01 00 01 51 80 00 0a 07 67 72 6f 75 2......Q....grou
70 65 72 c0 32 c0 46 00 01 00 01 00 01 51 80 00 per.2.F......Q..
04 cd fc 48 66 c0 5b 00 01 00 01 00 01 51 80 00 ...Hf.[......Q..
04 cd fc 48 67 ...Hg
ID:256 0x8085 mailhub.exis.net ANS 1
0x51800004 205.252.72.102
socket( 2, 3, 1 )
sendto( 1, 0x3dcf:0x1208, 48, 0x0000, 0x3dcf:0x19da, 16 )
IP 205.252.76.130 -> 255.255.255.255, Length 68, Protocol 1
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4cf6 )
IP 205.252.76.130 <- 205.252.72.102, Length 68, Protocol 1
ICMP type : 0, ECHO REP, code : 0, part1 : 22808, part2 : 0
ICMP: Echo reply
recvfrom( 1, 0x3dcf:0x1208, 2000, 0x0000, 0x3dcf:0x4d1e, 0x3dcf:0x4d34 )
inet_ntoa()
sendto( 1, 0x3dcf:0x1208, 48, 0x0000, 0x3dcf:0x19da, 16 )
IP 205.252.76.130 -> 205.252.72.102, Length 68, Protocol 1
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
IP 205.252.76.130 <- 205.252.72.102, Length 68, Protocol 1
ICMP type : 0, ECHO REP, code : 0, part1 : 22808, part2 : 1
ICMP: Echo reply
recvfrom( 1, 0x3dcf:0x1208, 2000, 0x0000, 0x3dcf:0x4fb4, 0x3dcf:0x4fca )
inet_ntoa()
sendto( 1, 0x3dcf:0x1208, 48, 0x0000, 0x3dcf:0x19da, 16 )
IP 205.252.76.130 -> 205.252.72.102, Length 68, Protocol 1
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
IP 205.252.76.130 <- 205.252.72.102, Length 68, Protocol 1
ICMP type : 0, ECHO REP, code : 0, part1 : 22808, part2 : 2
ICMP: Echo reply
ioctlsocket( 1, 0x4004667f, 0x3dcf:0x4f8c )
recvfrom( 1, 0x3dcf:0x1208, 2000, 0x0000, 0x3dcf:0x4fb4, 0x3dcf:0x4fca )
inet_ntoa()
WSACancelBlockingCall()
closesocket( 1 )
I have a Practical Peripherals PM 14400 FXHC 14R4 Version 2.42 C1993
internal modem. My setup string is
AT&F1 M0 S0=0 S10=100 S108=3 S7=125 S11=65 E1Q0V1X4 &C1&D2&K3^M
I am using Spry Winsock and Spry Dialer version 4.10.01.30.
Let me know if there are other settings I can change and try it again.
Don Plaster (dplast)
**************************************************************************
I am begining to wonder if these particular winsocks NEED routing on across
the interface (trumpet MAC-PPP and Win95 seem to work fine with
routing off).....ie they do NOT have a default route. I asked the
netscape dialer user what his default route/gateway was set for and he
could not find anywhere to set it. Because of the late hour I was not
able to investigate whether the Spry dialer has a default route/gatway
setting.
I just remembered that we had turned off default routing across the link
to cut down on wasted traffic and I wonder if that is causing this
problem.???? I think I am going to turn the default route on and see if
this helps these folks while I am waiting to hear from you. (default
route is turned on in all of our PM2-30's)
Regards,
Steve