[nos-bbs] Missing something more basic?

[George (Skip) VerDuin]

Greetings all.

If you recall about a dozen days ago I put out a note titled "missing
something?"...
You now may have missed the opportunity to respond "you dummy... look at
the LAN bridge route table".
And there are two things going on of importance in that query:

First it is common wisdom using the Linux platform that when the tun
device IP is set to 192.168.2.1 on the jnos stack then packets
from ...2.1 are no longer routable on the ...1.0 net with 255.255.255.0
netmask.  Thus static routing table adjustments must be inserted
throughout the entire LAN to pass this traffic, and upon setting the
static route table on the bridge one problem was solved.  There may be
alternate solution, but this works.  I believe Maiko may have addressed
this in his work, but I neglected to apply it in my work for the example
I put on this reflector.  Therefore since I neglected the "entire LAN" I
deserve the "dummy" label.

The second thing of importance may be worth a review of jnos technical
specs?  In this issue, the 44... IP address space seems difficult to
approach from the LAN side of routing.  I do remember a statement
somewhere that the 44... IP address space was intended as only an RF
device address interpretation?  I'd like to open this for discussion
here?

The example I put forward is based on the presumption that jnos is
gateway software [the current definition of "gateway"] and serves an
identical purpose as the Internet bridge appliances ["router" in current
vernacular] many of us use like Linksys brand or others.  In my case I
use a Caman brand.  My local configuration is: 
   69.214.1.47 is my end of a PPP dynamic DSL link to my ISP
   44.102.132.20 is my ampr.org static IP for the jnos in use
   44.102.132.1  is my hamgate.ottawa node neighbor via RF path.
My issue presents as follows - When I ping from my Linux workstation
user prompt "...$ " on the LAN:
  a) for 69.214.1.47     I get a response back from the internet side of
my Internet bridge. 
  b) for 44.102.132.20  I get a response back from (the RF side - sorta)
my jnos bridge.
  c) for 44.102.132.1    I get NO RESPONSE although the RF port is busy
(and ...1 is pingable from inside jnos).
I observe that the 44...20 address is similar to the 69...47 address in
that they both lie across the "bridge" and are both "local" in that they
are on the stacks of physically touchable hardware while I sit at my
desk --> & they do act similarly:-)
I now argue that once the RF path is used that the "...$ ping ..." is no
longer useful - but perhaps it should be.

Detail analysis demonstrates that the packet sequence is different when
initiated from workstation ping than when initiated by jnos ping .  In
the case of the jnos-ping prior to receipt of "ICMP echo response"
packets there is an ARP transaction between the stations following the
"ICMP echo request".  It seems to me that the jnos ping causes the ARP
but the workstation ping does not cause the ARP in a timely manner.
Therefore no response?  I have not waited more than 10 seconds from
workstation [...$ ping -c5 -i10 -n4]  where jnos gets response in 3.75
seconds.  So therefore using the above example, jnos may not adhere to
similar network standards for other routers or bridges, and therefore
requires different treatment during application.  

If what I have said is true, and is to remain true, I am OK with the
decision - except to say perhaps we need better focus on this difference
in our documentation on jnos.

If what I have said is not true, then I welcome whatever documentation
addresses the issue to straighten out my understanding of network
behavior.

So I'd like to open this to discussion.  My opinion is that ...$
ping ... probably should work from outside jnos just as effectively as
from the jnos command line.  It's a utilitarian thing...


73
de Skip k8rra k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060718/6d4cebb5/attachment.html>