[nos-bbs] Missing something more basic?

[George (Skip) VerDuin]

Thanks so much Glenn, I believe your experience leads to my underlying
issue.
The issue is:  my jnos does not do NAT (Network Address Translation).

I've stumbled into a wide interest issue:
All you guys discussing IP over AX.25 - have you included ARP as a part
of overhead in your considerations?
All you guys discussing routing between jnos nodes mounted on
192.168.x.y private IP LANS have you considered NAT over RF?

I believe this is how my issue plays out on this thread:
When I ping from jnos, I ping from a 44... IP and everything is kewl.
When I ping from jnos host, I ping from a 192... IP and the remote jnos
routes the ICMP to it's own 192... IP LAN rather than back to me.
The proof of that requires a trace from the remote jnos - something I
don't have in hand.
The trace I have of my own node demonstrates however that NAT is not in
use, 
   and therefore the 192... (from IP) is being placed in the RF packet 
   and the "Echo Response"  ICMP packet carries the 192... in the "to"
IP 
   and that does not initiate ARP to find my call from the remote node
of jnos
   and that does not route back to to my node.

Other solutions than NAT?  Yes potentially.  ENCAP comes to mind, but I
have not got a working example yet.
NAT as a solution?  More in the next paragraph, but I found an
interesting NAT & P2P piece on pg86 of August Linux Journal.

>From day 1 (a long time ago) I considered winlink a very utilitarian
half solution to remote (also as in emergency) communication.
>From day 2 (less long ago) I considered jnos an intriguing network
alternative, enough so to put a fair amount of energy into understanding
it.
[YES - more energy needed...]
Today I see no easy solution to my desire for an AX.25 (ham radio) path
for TCP/IP traffic unless jnos is the source (still a half solution).
YES - SMTP will transport mail deposited into the jnos queue from 192...
hosts, so I have again a half solution (perhaps good enough for now)...
YES - ftp will move binary files as long as jnos sysop console is the
ftp initiator (another half solution)...

Now I don't know if there is a solution to my desire.
I know that private LAN configurations in IPv4 is real convenient and
global registration of IPs is not a solution I care to participate in.
If anyone sees an error in my analysis, I want to hear it.
As far as this thread on this reflector goes, my original premise that
jnos acts as a bridge is wrong and I'm OK with that understanding.
As far as a solution to my desire? - I'm beginning to classify it as
"pie in the sky"...


On Tue, 2006-07-18 at 14:22 -0700, Glenn Thomas wrote:

> Interesting observation...
> 
> I saw something similar years ago on a community NOS system that may 
> be related. The NOS system had RF ports on 144, 220 and 440. I would 
> occasionally lose my head and try to connect to it on 144. The issue 
> was that, in those days, the packet channel was overloaded. More 
> often than not the link would retry out. My next attempt to connect 
> was on 220, where the channel was essentially clear. The NOS system 
> apparently heard me because it responded - on 144! Apparently once it 
> heard a station on one port, it always responded to that station on 
> that port - even if the station moved to another port. This has the 
> same flavor as 'once the RF path is used that the "...$ ping ..." is 
> no longer useful'.
> 
> I dunno if this is the same issue - or even if my routing issue still 
> exists! (that was many years ago and far far away). This is just an 
> observation that may or may not be relevant...
> 
> 73 de Glenn WB6W
> 
> 
> WAR IS PEACE!
> FREEDOM IS SLAVERY!
> IGNORANCE IS STRENGTH!
> (be seeing you!)
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs


73
de Skip k8rra k


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060722/a36f90db/attachment.html>