[nos-bbs] HTTP server restriction maybe

[Jay Nugent]

Greetings Skip,

On Mon, 16 Apr 2007, (Skip) K8RRA wrote:

> Barry, I jumped the gun on this one - at least I included "maybe" in the
> title...
> 
> On Mon, 2007-04-16 at 03:11 -0400, Barry Siegfried wrote:
> 
> > ["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:
> > 
> > > We both fail to serve browsers at the other site across radio links.
> > > We are both successful with telnet to the other site over radio between
> > > jnos.
> > 
> > I'm sorry but that makes no sense unless you are somehow blocking HTTP
> > (port 80) connections and not blocking telnet (port 23) connections
> > over the radio link.  Also, are you sure your HTTP client (presumably
> > a machine with an operating system that supports a web browser) is using
> > the radio link to communicate to the HTTP server?
> 
> When I responded to Maiko, you note I suspected asymmetrical routing?
> It is exactly what happened on my site.
> The http query arrived on asy from the radio and the server response
> departed tun on it's way into cyberspace.


   You must follow this one rule at all times: "Think like a Packet"

   In your scenario where you are trying to access a webpage on a
44-net/AMPRnet server, through the 44-net/AMPRnet, from a browser that is
also addressed on the 44-net/AMPRnet...

  ...The browser machine sends out a packet addressed to 44.102.x.y (and 
is *from* 44.102.a.b).  Follow EACH step of the path as this packet 
traverses the entire network.  Go thru each and every routing table and 
determine exactly how that packet really gets routed.  Assume nothing!  
The packets will always do precisely what the routing tables tell them to 
do.

   On the flip side, KNOW FOR SURE what IP address the sending machine is 
using.  Because THIS *IS* the IP address that the return path will be 
based upon.  And again, repeat the process of following that packet back 
through the network, following each routing decision, all the way back 
from the web server to the web browser.

   Irrespective of what 'application' (in this case a web page) or what
'protocol' (in this case HTTP) is used, the IP route MUST be complete in
BOTH directions. Any failure in that IP route and your connection will
fail.  And my personnal belief is that Asymetrical routes *are evil*!  
They are hard to maintain and are incredibly hard to diagnose when they
fail.

   So, "Think like a Packet", crawl your way through the route tables, and 
I'm sure you will find the problem.

      --- Jay Nugent  WB8TKL

"Getting rid of terrorism is like getting rid of dandruff.  It cannot
 be done completely no matter how hard you try." -- Gore Vidal
+------------------------------------------------------------------------+
| Jay Nugent   jjn at nuge.com    (734)484-5105    (734)544-4326/Fax        |
| Nugent Telecommunications  [www.nuge.com]     (734)649-0851/Cell       |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.net] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
| LinuxNIC, Inc. [www.linuxnic.net]   Registrar of the .linux TLD        |
+------------------------------------------------------------------------+
  3:01pm  up 36 days, 10:47,  2 users,  load average: 0.32, 0.30, 0.17