[RC5] [ON TOPIC] Cedric's connection problem

Cedric Tefft cedric at earthling.net
Sat Jan 3 00:19:20 EST 1998


Aaaahhhh... Vacations are nice.

OK. I'm back.

Just as a reminder, I'm having trouble getting my clients to communicate
through the HTTP proxy at work.  Seth  asked around on IRC; apparently
without too much success.  He and I have both posted here.  I've gotten
lots of suggestions which can basically be categorized as "check your
client setting XXYYZZ", or "just transfer the blocks manually".  At this
point, I've triple checked every setting and tried every setting change
everybody's suggested, to no effect.  As for manually transferring the
blocks; that's what I've been doing for the past four weeks, and it's
getting a little old.  I'd much rather have a working client.

I thank you all for your suggestions.  I've tried pretty much all of
them, but unfortunately, none of them worked.  :-(

In the meantime, I've done a little more research.  Maybe this will
clear some things up.  I installed Network Monitor under NT and set it
up to capture the traffic between the
firewall (HTTP proxy) and rc564.  Now for some reason, I can't seem to
get the thing to capture the OUTBOUND traffic, but I know it's going out
somehow because of the message I'm getting back from the HTTP proxy (see
below). 
A third party packet capture tool gives me pretty much the same
information. 
 I suspect my NIC driver doesn't conform in some subtle way to a part of
the NDIS spec which provides for packet capture. Anyway, ignore that for
the moment and have a look at this.  Again, this
is a capture of the traffic between the firewall and the client box
trying to flush blocks.  Network Monitor is running on the client box
itself:


** HTTP Proxy ==> client machine (first packet) **

00040              48 54 54 50 2F 31 2E 30 20 34 30 34     HTTP/1.0.404
00050  20 45 72 72 6F 72 0D 0A 43 6F 6E 74 65 6E 74 2D .Error..Content-
00060  74 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D type:.text/html.
00070  0A 0D 0A                                        ...             
           
** HTTP Proxy ==> client machine (second packet) **

00040              3C 68 31 3E 45 72 72 6F 72 2D 20 34     <h1>Error-.4
00050  30 34 3C 2F 68 31 3E 0D 0A 3C 48 52 3E 0D 0A 3C 04</h1>..<HR>..<
00060  50 52 45 3E 0D 0A 52 65 71 75 65 73 74 65 64 20 PRE>..Requested.
00070  49 6E 66 6F 72 6D 61 74 69 6F 6E 3C 62 72 3E 0D Information<br>.
00080  0A 2F 63 67 69 2D 62 69 6E 2F 72 63 35 2E 63 67 ./cgi-bin/rc5.cg
00090  69 3C 62 72 3E 0D 0A 69 73 20 75 6E 61 76 61 69 i<br>..is.unavai
000A0  6C 61 62 6C 65 2E 20 46 61 69 6C 65 64 20 74 6F lable..Failed.to
000B0  20 63 6F 6E 6E 65 63 74 20 74 6F 20 73 65 72 76 .connect.to.serv
000C0  65 72 3C 62 72 3E 0D 0A 6D 69 72 72 6F 72 2E 6E er<br>..mirror.n
000D0  65 6F 73 6F 66 74 2E 63 6F 6D 20 28 32 30 36 34 eosoft.com.(2064
000E0  29 3C 62 72 3E 0D 0A 72 65 61 73 6F 6E 3A 20 63 )<br>..reason:.c
000F0  6F 6E 6E 65 63 74 3A 20 4E 6F 20 72 6F 75 74 65 onnect:.No.route
00100  20 74 6F 20 68 6F 73 74 3C 62 72 3E 0D 0A 3C 2F .to.host<br>..</
00110  50 52 45 3E 0D 0A 3C 62 72 3E 3C 68 72 3E 0D 0A PRE>..<br><hr>..
00120  3C 41 20 48 52 45 46 3D 22 68 74 74 70 3A 2F 2F <A.HREF="http://
00130  2D 69 6E 74 65 72 6E 61 6C 2D 2F 2D 68 74 74 70 -internal-/-http
00140  2D 67 77 2D 69 6E 74 65 72 6E 61 6C 2D 2F 76 65 -gw-internal-/ve
00150  72 73 69 6F 6E 2E 68 74 6D 6C 22 3E 68 74 74 70 rsion.html">http
00160  2D 67 77 20 76 65 72 73 69 6F 6E 20 20 56 33 2E -gw.version..V3.
00170  31 2E 31 20 2F 20 20 20 30 3C 2F 41 3E 0D 0A 20 1.1./...0</A>...
00180  28 31 34 38 2E 31 37 31 2E 38 37 2E 32 29 0D 0A (148.171.87.2)..


As you can see, what I get back from the HTTP proxy is basically a "no
route to host" message.  Unfortunately, since I can't see what the rc5
client sent TO the server, I'm not sure where the problem is.  In any
case, I suspect the problem lies somewhere in the way the rc5 client
formats its request to the HTTP proxy.  Here's why:

1) We know the HTTP proxy address and port are correct because a) they
are the same settings that work for both IE and Netscape web browsers
and b) we're getting a response from that proxy that indicates we're
at least talking to it on the right port, if not in such a way that we
get what we're looking for.

2) We also know my userid/password for the HTTP proxy are correct since
the error I'm getting is not about proxy authentication, but about the
target host being unreachable.  I know this because I performed the same
trace above for a Netscape connection and I can verify that one must
properly authenticate to the HTTP proxy before it will even attempt to
process the HTTP request.

3) One might suspect that the problem really IS "no route to
host" as the message indicates.  Not so.  I tested this by plugging the
URL 
http://mirror.neosoft.com/ into Netscape, and sure enough, out pops
their home page.  If there were problems routing to the host
mirror.neosoft.com, I shouldn't be able to pull anything off that
machine on ANY port.

4) Astute readers might suspect it has something to do with the oddball
port 2064 (well, oddball as far as web servers are concerned anyway). 
While I can't prove this isn't the case, I can confirm that the HTTP
proxy WILL retrieve web pages from web servers on non-standard ports
(8001,etc.), so I'm disinclined to think the destination port is the
problem either.

Now, here's the tricky part:  When I throw the URL
http://mirror.neosoft.com:2064/cgi-bin/rc5.cgi into Netscape (or IE for
that matter) I get the message back from the HTTP proxy that there is no
route to host exactly as you see in the packet capture above (nicely
rendered in the browser window of course).  So, you say, it's not the
client's fault; it must be your HTTP proxy!

Er, well, yes, BUT...

First, it's a Netscape proxy which is common enough that I'm probably
not the first person who's run into this problem and I certainly won't
be the last.  I find it very telling that most of the suggestions to my
problem so far have been "workarounds" rather than actual fixes, and I
would suspect that's because a few other people in the same boat just
decided it was easier to manually ship blocks back and forth than to
spend hours (days!) banging their heads against the problem.

Second, even if the problem is Netscape's fault, there's nothing we can
do about their proxy server.  We CAN, however, modify the RC5 client to
talk to Netscape's proxy in a way it likes.

At any rate, I could certainly be wrong, but all the evidence to this
point says that my client is configured correctly, and it's either the
fault of the Netscape proxy or the RC5 client.  In either case, the only
part of the equation we can "fix" is the client.  I'm willing to do
whatever I can from this end to help diagnose/test/whatever-it-takes to
get the client talking through the Netscape proxy, but I need somebody
with source code and/or protocol specs to take an interest because I'm
pretty much at the limit of what I can do here.

That said, I think I've done my homework.  Howz about a little help?


Thanks,

- Cedric

/----------------------------------------------------------\
*      Cedric Tefft: Proto-Human, Reluctant Programmer     *
*            email: cedric at earthling.net                   *
* PGP FingerPrint: E114-CA05-E498-8A88-0762-79BB-A117-C59B *
\----------------------------------------------------------/
--
To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list