said:
>
[...snip...]
> >already work as configured with InJoy in mind, I decided to look at
> >another one as a model. Two similar paths are defined on it except with
> >the following syntax:
>
> >route add default 192.168.1.1 1 > null
> >route add net 192.168.1 192.168.1.1 1 netmask 255.255.255.0 > null
>
> >I realize the redirection simply dumps into the bottomless bit bucket but
>
> Not quite. This is either incorrect usage or a typo in you copy/paste
> attempt. The output is dumped into a file name null. IMNSHO, it's a
> silly thing to do even if the correct name (i.e. nul) is used because it
> removes the opportunity for the human to see any error messages that might
> occur.
That's right. I thought it was supposed to be "nul" but since I hadn't put
that suffix there so I thought there was more substance in the automatic
configuration than I had known. Maybe not. It got put there automatically but
it's wrong.
> >non-argument-enumerated way of specifying hopcounts. The added netmask
> >shows what I was asking about the absence of a netmask earlier (and how I
> >couldn't get it with the TCPIP notebook on eCS). Just to double check
> >that it wasn't redundant, I REM'ed out the second line and the behavior
> >didn't change. Then, I added the corrected line (the one with the
>
> That's my definition of redundant.
Let me correct my the wording of my intended thought. It wasn't the (apparent)
redundancy that was causing the problem.
> >netmask) to the eCS machine. Yahoo, Google and other web sites came
> >right up. I'm not sure it's fully fixed yet because a while later, the
> >kids complained that it stopped working. Yahoo wouldn't come up anymore
>
> If you were not suppressing error messages, you would see the eCS machine
> bitch and moan about your syntax.
I suppose ... but it seems now the apparent improvement in behavior had more to
do with my quark explanation rather than there being an intrinsic fix in
removing the redundancy. A couple of tries later and it no longer worked again.
I guess it is more intermittent than it otherwise appears. Rather than it being
a 100% failure, it is more like a 90% failure. In any case, I attributed the
change in behavior incorrectly.
> It didn't. Check the syntax on an eCS machine. Your problem lies
> elsewhere.
... and so I keep looking.
> The correct syntax for TCP/IP 4.3 on eCS is:
>
> route add default 192.168.1.1 -hopcount 1
>
> That should be sufficient to send every packet to the gateway machine.
So this is what is now the sole line in the setup.cmd relating to routes. I
assume this needs to be true of the OS/2 machines as well. This make me unsure
of what InJoy is after because I set up the client machines exactly as their
manual suggests, i.e. with both routes defined.
In any case, that's a smaller problem than the one I'm working on now. Back to
iptracing. All the following comments relate to the enclosed zip 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. 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 (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 looked up the usage of iptrace and it says that all interfaces are traced if
no command line argument is given. Considering how the interfaces are
established and are temporally dependent, I think this is the proper way to run
it (rather than "iptrace dod ppp1" as you 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.
I see the DNS request satisfied and Netscape reporting itself to port 80 of the
yahoo server but little else. What else can I do? I don't know what else to
try. Should I do a corresponding trace on the client to see how the gateway and
client match up, packet for packet? This is driving me nuts. All my other
projects are on hold until I get this fixed.
Thanks again.
> Steven
-Rocky
Content Type: application/octet-stream
File attachment:
nexttest.zip
<< Previous Message <<
>> Next Message >>
Return to [ 15 |
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.
