<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.10.1">
</HEAD>
<BODY>
Greetings all.<BR>
<BR>
If you recall about a dozen days ago I put out a note titled "missing something?"...<BR>
You now may have missed the opportunity to respond "you dummy... look at the LAN bridge route table".<BR>
And there are two things going on of importance in that query:<BR>
<BR>
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.<BR>
<BR>
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?<BR>
<BR>
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: <BR>
69.214.1.47 is my end of a PPP dynamic DSL link to my ISP<BR>
44.102.132.20 is my ampr.org static IP for the jnos in use<BR>
44.102.132.1 is my hamgate.ottawa node neighbor via RF path.<BR>
My issue presents as follows - When I ping from my Linux workstation user prompt "...$ " on the LAN:<BR>
a) for 69.214.1.47 I get a response back from the internet side of my Internet bridge. <BR>
b) for 44.102.132.20 I get a response back from (the RF side - sorta) my jnos bridge.<BR>
c) for 44.102.132.1 I get NO RESPONSE although the RF port is busy (and ...1 is pingable from inside jnos).<BR>
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:-)<BR>
I now argue that once the RF path is used that the "...$ ping ..." is no longer useful - but perhaps it should be.<BR>
<BR>
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. <U>Therefore no response?</U> 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. <BR>
<BR>
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.<BR>
<BR>
If what I have said is not true, then I welcome whatever documentation addresses the issue to straighten out my understanding of network behavior.<BR>
<BR>
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...<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de Skip k8rra k
</TD>
</TR>
</TABLE>
</BODY>
</HTML>