said:
>Let me correct my the wording of my intended thought. It wasn't the
>(apparent) redundancy that was causing the problem.
It shouldn't However, ISTR hearing that the extra route could cause
problems with the 32-bit stack that you are running with eCS and I don't
know the if this has been resolved, so better safe than sorry.
>I assume this needs to be true of the OS/2 machines as well. This make
The Warp4 boxes should not need anything more either, unless Injoy is
doing something I don't understand. Think of it this way. The packet is
going to get sent to the same place, with the same content regardless of
which route statement sends it there.
>file containing a few text files. First, I noticed that the result of
>netstat -n was dependent on the state of my connection to the internet.
As it should be.
>The result of "netstat -n" at boot, before connection to the Internet is
>established, is contained in atboot.txt. Notice that there is no
>interface called ppp1. After issuing a ping command (atping.txt) but
>before connection, this is similarly true. However, after connecting
Again, as it should be. Injoy is creating the interface as part of
setting up the connection. DOIP does a similar thing, but chooses to name
the interface ppp0. This is all part and parcel of how the TCP/IP stack
works.
>(atconnect.txt), the ppp1 interface is established. Even after hanging
>up, the ppp1 interface remains. This is just to give you more of a
>background on what is going on in InJoy.
I don't understand why Injoy keeps the interface up. This differs from
DOIP, which closes the ppp0 interface when the connection is shut down.
Injoy is probably doing some sort of optimization.
>interfaces are established and are temporally dependent, I think this is
>the proper way to run it (rather than "iptrace dod ppp1" as you
It doesn't matter to me as long as there's not too much lan0 traffic to
clutter up the analysis. Temporality (if that's a real word) doesn't much
matter for when we are looking at the data.
>suggested). So, I booted the gateway machine into its standard config
>(with InJoy in its dial-on-demand mode) and the client machine, basically
>quiescent. On the gateway, I started iptrace and on the client, I
>started up Netscape and simply asked to load yahoo.com. The contents of
>iptraffic.txt is the resulting output of ipformat. As expected, the
>client refused to load yahoo.com. Ultimately, I just cancelled the trace
>(and the request to load yahoo) after waiting more than long enough.
On the gateway machine, I hope.
One thing that shows up immediately is that the DNS servers at
216.171.167.011
216.171.167.012
are pretty crappy. Take a look at the number of times they refuse to
respond to a DNS request. Look for the packets with the 4 second deltas.
Looking at the trace, if this is on the gateway machine, this will never
work:
-------------------------- #:41 --------------------------
Delta Time: 0.730sec Packet Length: 344 bytes (158 hex)
DIX: Dest: 00:80:C8:E6:09:CF Source: 00:50:BA:84:07:CF
DIX: Dest: 066.218.071.084 Source: 192.168.001.014
----------------------- IP HEADER -----------------------
No TCP/IP stack in its right mind is going to send packets back to a
non-routable address.
Here's a snip of what happens on a working setup:
-------------------------- #:14 --------------------------
Delta Time: 0.000sec Packet Length: 841 bytes (349 hex)
Compressed and Unfiltered Packet Length: 808 bytes (328 hex)
PPP: Protocol 0x002D (VJ Compressed)
PPP: Dest: 066.218.071.089 Source: 209.178.189.003
----------------------- IP HEADER -----------------------
IP: Version: 4 Correct Header Length: 20 bytes
IP: Type Of Service: 00
IP: 000. .... Routine
IP: ...0 .... Normal Delay
IP: .... 0... Normal Throughput
IP: .... .0.. Normal Reliability
IP: Total Len: 840 (x348) bytes Id: 6E5D
IP: Flags: 2
IP: .1.. Don't Fragment
IP: ..0. Last Fragment
IP: Fragment Offset: 000
IP: Time To Live: 64 sec Protocol: 6 TCP
IP: Header Checksum: B069 (Correct)
IP: No Options
---------------------- TCP HEADER ----------------------
TCP: Source Port: 51798 (Unassigned port) Dest Port: 80
(Unassigned port)
TCP: Sequence #: 2326070887
TCP: Ack #: 4130634963
TCP: Offset: 20 bytes
TCP: Flags: 18
TCP: ..0. .... Urgent bit Off
TCP: ...1 .... Ack bit On
TCP: .... 1... Push bit On
TCP: .... .0.. Reset bit Off
TCP: .... ..0. Synchronize bit Off
TCP: .... ...0 Finish bit Off
TCP: Window: 33580 Checksum: B081 (Correct)
TCP: No Options
--------------------------------- DATA -----------------------------------
0000 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A GET / HTTP/1.1..
0010 48 6F 73 74 3A 20 77 77 77 2E 79 61 68 6F 6F 2E Host: www.yahoo.
0020 63 6F 6D 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A com..User-Agent:
0030 20 4D 6F 7A 69 6C 6C 61 2F 35 2E 30 20 28 4F 53 Mozilla/5.0 (OS
0040 2F 32 3B 20 55 3B 20 57 61 72 70 20 34 2E 35 3B /2; U; Warp 4.5;
0050 20 65 6E 2D 55 53 3B 20 72 76 3A 31 2E 31 61 2B en-US; rv:1.1a+
0060 29 20 47 65 63 6B 6F 2F 32 30 30 32 30 37 31 32 ) Gecko/20020712
0070 0D 0A 41 63 63 65 70 74 3A 20 74 65 78 74 2F 78 ..Accept: text/x
0080 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 ml,application/x
0090 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 ml,application/x
00A0 68 74 6D 6C 2B 78 6D 6C 2C 74 65 78 74 2F 68 74 html+xml,text/ht
Notice that both the source and destination addresses are routable.
This leaves several possibilities. One is that what you are tracing is
the packet going from the eCS machine to Injoy. That would be the case if
Injoy has been told to grap all packets sent to 192.168.001.014. If so,
you need to figure out how to trace the data going between Injoy and the
outside world. Read the Injoy docs for info how how to enable the Injoy
tracing tools.
Is that this really is the packet that's going out over the phone line.
If so, it's easy to understand why it gets no response. It's harder to
understand why it is happening.
Steven
--
---------------------------------------------------------------------
"Steven Levine" MR2/ICE 2.31a #10183 Warp4/FP15/14.085_W4
www.scoug.com irc.webbnet.org #scoug (Wed 7pm PST)
---------------------------------------------------------------------
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 16 |
July |
2002 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
