netrom

netrom

[Shane Deering]

G'day all.
Wonder if someone can help me out.
I've just set up my good computer (this one) for packet.
Using kernel 2.4.9-31 and the latest libs, tools and apps.
AX25 seems to work ok on the 2 test ports I've set up (call, mheard).
But i'm having problems setting up netrom. Doing what the ax25 how-to say to 
do (I think), but I get the following-

[root@vk3bvp-6 root]# nrattach netrom
NET/ROM port netrom bound to device nr0
[root@vk3bvp-6 root]# /usr/sbin/netromd -i
nrconfig: port netrom not active
netromd: no NET/ROM ports defined

My axports file-

# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
vhf	VK3BVP-8	2400	255	2	144.825 MHz (1200  bps)
win	VK3BVP-9	57600	255	2	link to winfbb

My nrports file-

# /etc/ax25/nrports
#
# The format of this file is:
#
# name callsign alias paclen description
#
netrom	VK3BVP-10 LINODE	235	Switch Port

The kissatach commands and responses have scrolled off my xterm but from 
history I used these to create ax0 and ax1 -
[root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS0 vhf 44.135.96.242
[root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS1 win 44.135.96.241

Don't worry about the IP addresses , they are just for testing.

Any idea why NET/ROM isn't working?

-- 
Shane Deering
vk3bvp@vk3bvp.#sev.vic.aus.oc / vk3bvp@qsl.net
http://www.qsl.net/vk3bvp/
Sent with KMail v1.3.2 on Sun Apr 14 15:31:19 EST 2002

Re: netrom

[Arno Verhoeven]

Shane Deering wrote:
> G'day all.
> Wonder if someone can help me out.
> I've just set up my good computer (this one) for packet.
> Using kernel 2.4.9-31 and the latest libs, tools and apps.
> AX25 seems to work ok on the 2 test ports I've set up (call, mheard).
> But i'm having problems setting up netrom. Doing what the ax25 how-to say to 
> 
> Any idea why NET/ROM isn't working?
> 
> 

Have you also setup /etc/ax25/nrbroadcast ?

This file should list at least one valid AX.25 port.


-- 
73, PE1ICQ  Arno Verhoeven
--------------------------------
AX.25  pe1icq@pi8zaa.#nbo.nld.eu
smtp   pe1icq@pi8zaa.ampr.org
inet   pe1icq@amsat.org

Re: netrom

[Shane Deering]

On Sunday 14 April 2002 17:25, Arno Verhoeven wrote:
> Shane Deering wrote:
> > G'day all.
> > Wonder if someone can help me out.
> > I've just set up my good computer (this one) for packet.
> > Using kernel 2.4.9-31 and the latest libs, tools and apps.
> > AX25 seems to work ok on the 2 test ports I've set up (call, mheard).
> > But i'm having problems setting up netrom. Doing what the ax25 how-to say
> > to
> >
> > Any idea why NET/ROM isn't working?
>
> Have you also setup /etc/ax25/nrbroadcast ?
>
> This file should list at least one valid AX.25 port.

Thanks Arno.
I have got /etc/ax25/nrbroadcast set up OK. I knew I'd forget something in my 
post :-)

Netrom is now working. I added IP address and port name to nrattach and it 
worked.

I guess my next stop will be the xfbb list.
That seems to be working OK, just looks like crap.

-- 
Shane Deering
vk3bvp@vk3bvp.#sev.vic.aus.oc / vk3bvp@qsl.net
http://www.qsl.net/vk3bvp/
Sent with KMail v1.3.2 on Sun Apr 14 18:22:57 EST 2002

Re: netrom

[Richard Adams]

On Sunday 14 April 2002 05:58, Shane Deering wrote:
> G'day all.
> Wonder if someone can help me out.
> I've just set up my good computer (this one) for packet.
> Using kernel 2.4.9-31 and the latest libs, tools and apps.
> AX25 seems to work ok on the 2 test ports I've set up (call, mheard).
> But i'm having problems setting up netrom. Doing what the ax25 how-to say
> to do (I think), but I get the following-
>
> [root@vk3bvp-6 root]# nrattach netrom
> NET/ROM port netrom bound to device nr0
> [root@vk3bvp-6 root]# /usr/sbin/netromd -i
> nrconfig: port netrom not active
> netromd: no NET/ROM ports defined

Have you tryed.
nrattach [-i inetaddr] [-m mtu] [-v] port

>
> My axports file-
>
> # /etc/ax25/axports
> #
> # The format of this file is:
> #
> # name callsign speed paclen window description
> #
> vhf	VK3BVP-8	2400	255	2	144.825 MHz (1200  bps)
> win	VK3BVP-9	57600	255	2	link to winfbb
>
> My nrports file-
>
> # /etc/ax25/nrports
> #
> # The format of this file is:
> #
> # name callsign alias paclen description
> #
> netrom	VK3BVP-10 LINODE	235	Switch Port
>
> The kissatach commands and responses have scrolled off my xterm but from
> history I used these to create ax0 and ax1 -
> [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS0 vhf 44.135.96.242
> [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS1 win 44.135.96.241
>
> Don't worry about the IP addresses , they are just for testing.
>
> Any idea why NET/ROM isn't working?

-- 
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/

Re: netrom

[Shane Deering]

On Sunday 14 April 2002 20:11, Richard Adams wrote:
> On Sunday 14 April 2002 05:58, Shane Deering wrote:
> > G'day all.
> > Wonder if someone can help me out.
> > I've just set up my good computer (this one) for packet.
> > Using kernel 2.4.9-31 and the latest libs, tools and apps.
> > AX25 seems to work ok on the 2 test ports I've set up (call, mheard).
> > But i'm having problems setting up netrom. Doing what the ax25 how-to say
> > to do (I think), but I get the following-
> >
> > [root@vk3bvp-6 root]# nrattach netrom
> > NET/ROM port netrom bound to device nr0
> > [root@vk3bvp-6 root]# /usr/sbin/netromd -i
> > nrconfig: port netrom not active
> > netromd: no NET/ROM ports defined
>
> Have you tryed.
> nrattach [-i inetaddr] [-m mtu] [-v] port

I found something like that on a web site including an example and that got 
got me going. 

My Winfbb has done a netrom connect to my Linfbb and forwarded about 600
messages to date. Everything seems to be working OK so far.
I'm now writing a simple startup script before I forget everything. I'll 
refine it at a later date.

-- 
Shane Deering
vk3bvp@vk3bvp.#sev.vic.aus.oc / vk3bvp@qsl.net
http://www.qsl.net/vk3bvp/
Sent with KMail v1.3.2 on Sun Apr 14 22:35:38 EST 2002

Re: netrom

[M Taylor]

On Sun, Apr 14, 2002 at 03:58:02PM +1000, Shane Deering wrote:
> 
> The kissatach commands and responses have scrolled off my xterm but from 
> history I used these to create ax0 and ax1 -
> [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS0 vhf 44.135.96.242
> [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS1 win 44.135.96.241
> 
> Don't worry about the IP addresses , they are just for testing.

Please do not randomly used a 44. address without allocation.
44.135.96/24  is Ottawa, Ontario, Canada (ve3), so I
suspect that you do not have it allocated to you (having a vk
callsign I assume you are not operating in Canada).

Use a non-routable Private IP (RFC 1918) such as 10.0.0.1.

Thank you.

Re: netrom

[Riley Williams]

Hi.

>> The kissatach commands and responses have scrolled off my xterm but
>> from history I used these to create ax0 and ax1 -
>>
>> [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS0 vhf 44.135.96.242
>> [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS1 win 44.135.96.241
>> 
>> Don't worry about the IP addresses , they are just for testing.

> Please do not randomly used a 44. address without allocation.
> 44.135.96/24 is Ottawa, Ontario, Canada (ve3), so I suspect that you
> do not have it allocated to you (having a vk callsign I assume you
> are not operating in Canada).
> 
> Use a non-routable Private IP (RFC 1918) such as 10.0.0.1.

Alternatively, I understand that 44.128.* addresses are reserved for
testing as well, and can be freely used as a result.

Perhaps somebody could clarify that for me though?

Best wishes from Riley.

Re: netrom

[Walter R Fletcher]

All,

From the 12 Dec 2001 list of AMPR IP address coordinators:

# 44.128 is reserved for testing.  Do not use for operational networks.
# You may safely assume that any packets with 44.128 addresses are bogons
# unless you are using them for some sort of testing.

     44.128.x.y may be allocated for 44.x.y.z internal testing but
what happens to them depends on the net 44 routers being set up
properly such that they dispose of the test packets.  Using the
10.x.y.z addresses gives you a certainty that if your test packets
inadvertantly leak out of the 44.x.y.z net, they will promptly and
safely be dropped.  Either way would be using the addresses for what
they were intended of course.  It's a matter of making things happen
that are proper and predictable, hence good network etiquette.

--  Reid


  Reid Fletcher / WB7CJO
  Senior Systems Analyst / Unix Systems Administrator
  Department of Geology and Geophysics                  P. O. Box 3006
  University of Wyoming                                 1-307-766-6227
  Laramie,  WY   82071                  Internet:  Fletcher @ UWyo.Edu

On Sun, 14 Apr 2002, Riley Williams as an addendum to others, wrote:
 
> > Please do not randomly used a 44. address without allocation.
> > 44.135.96/24 is Ottawa, Ontario, Canada (ve3), so I suspect that you
> > do not have it allocated to you (having a vk callsign I assume you
> > are not operating in Canada).
> > 
> > Use a non-routable Private IP (RFC 1918) such as 10.0.0.1.
> 
> Alternatively, I understand that 44.128.* addresses are reserved for
> testing as well, and can be freely used as a result.
> 
> Perhaps somebody could clarify that for me though?
> 
> Best wishes from Riley.

Re: netrom

[Shane Deering]

On Monday 15 April 2002 08:06, M Taylor wrote:
> On Sun, Apr 14, 2002 at 03:58:02PM +1000, Shane Deering wrote:
> > The kissatach commands and responses have scrolled off my xterm but from
> > history I used these to create ax0 and ax1 -
> > [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS0 vhf 44.135.96.242
> > [root@vk3bvp-6 root]# /usr/sbin/kissattach /dev/ttyS1 win 44.135.96.241
> >
> > Don't worry about the IP addresses , they are just for testing.
>
> Please do not randomly used a 44. address without allocation.


> 44.135.96/24  is Ottawa, Ontario, Canada (ve3), so I
> suspect that you do not have it allocated to you (having a vk
> callsign I assume you are not operating in Canada).
>
> Use a non-routable Private IP (RFC 1918) such as 10.0.0.1.

Every IP address is unroutable from here.
There is no IP network here.
My allocated addresses are in use on my perminent packet computer.

I understand where you're coming from, but at this point in time it is rather 
trivial.

-- 
Shane Deering
vk3bvp@vk3bvp.#sev.vic.aus.oc / vk3bvp@qsl.net
http://www.qsl.net/vk3bvp/
Sent with KMail v1.3.2 on Mon Apr 15 10:42:39 EST 2002

Re: netrom

[Riley Williams]

Hi Walter.

>>> Please do not randomly used a 44. address without allocation.
>>> 44.135.96/24 is Ottawa, Ontario, Canada (ve3), so I suspect that
>>> you do not have it allocated to you (having a vk callsign I
>>> assume you are not operating in Canada).
>>> 
>>> Use a non-routable Private IP (RFC 1918) such as 10.0.0.1.

>> Alternatively, I understand that 44.128.* addresses are reserved
>> for testing as well, and can be freely used as a result.
>> 
>> Perhaps somebody could clarify that for me though?

> From the 12 Dec 2001 list of AMPR IP address coordinators:

> # 44.128 is reserved for testing. Do not use for operational
> # networks. You may safely assume that any packets with 44.128
> # addresses are bogons unless you are using them for some sort
> # of testing.

> 44.128.x.y may be allocated for 44.x.y.z internal testing but what
> happens to them depends on the net 44 routers being set up properly
> such that they dispose of the test packets.

Fairy Nuff.

> Using the 10.x.y.z addresses gives you a certainty that if your test
> packets inadvertantly leak out of the 44.x.y.z net, they will
> promptly and safely be dropped.

Not if you use IC24 as your IP - they allocate 10.* addresses to your
modem and the router at the other end, and their DHCP servers provide
a routing line that routes ALL 10.* IP addresses across the modem link
to the router you're dialled up to.

Incidentally, I didn't know that when I posted the original message, and
only discovered it because one of my customers has them as their ISP and
I was sorting their computer out Saturday afternoon.

Probably a better choice would be to use 172.24.* addresses for this
purpose if your ISP does the above, and probably even if they don't.

> Either way would be using the addresses for what they were intended
> of course. It's a matter of making things happen that are proper and
> predictable, hence good network etiquette.

Just ensure that whatever you use doesn't conflict with your ISP
either. Here's the allocated ranges that I'm aware of:

	10.*		Use with care - some ISP's use this.

	172.16.*
	172.17.*
	172.18.*
	172.19.*
	172.20.*
	172.21.*
	172.22.*
	172.23.*
	172.24.*
	172.25.*
	172.26.*
	172.27.*
	172.28.*
	172.29.*
	172.30.*
	172.31.*

	192.168.*	Most home networks use this.

Best wishes from Riley.

Re: netrom

[Richard Adams]

On Monday 15 April 2002 17:55, Riley Williams wrote:

> Not if you use IC24 as your IP - they allocate 10.* addresses to your
> modem and the router at the other end, and their DHCP servers provide
> a routing line that routes ALL 10.* IP addresses across the modem link
> to the router you're dialled up to.

If that provider is using 10.*.*.* numbers across a network then AFAIK that 
is not in accordance with RFC 1918 which states;

  The Internet Assigned Numbers Authority (IANA) has reserved the
  following three blocks of the IP address space for private networks:
 
                10.0.0.0        -   10.255.255.255
                172.16.0.0      -   172.31.255.255
                192.168.0.0     -   192.168.255.255

Now i have little idea where or what this thread started about, however if 
one wants to use 10.0.0.1 for his private network then he/she has "every 
right" to do so, even IF an ISP uses it to do some or other smart tricks with 
period. I wonder if an ISP could even be reprimanded for using an RFC 1918 
address for financial gain, not that it is of concern to me, it is more  a 
question of "rules are rules"... After all what else are all RFC;s for period.

I have not read that RFC rule in full, however reading what i have says to me 
they are "private addresses period".

Anyway my commentry stops here, this is getting way off topic.

-- 
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/

netrom

[Tom Vavra]

I am trying to get AX25/NETROM going and cannot get NETROM working.  My
system is:
RedHat 7.3
kernel 2.4.18

I have installed the following:
ax25-apps-0.0.6
ax25-tools-0.0.8
libax25-0.0.11
node-0.3.1

When trying to start ax25 and netrom I get the following:

[root@localhost root]# /usr/sbin/kissattach /dev/ttyS1 port1 44.0.0.1
AX.25 port port1 bound to device ax0
[root@localhost root]# /usr/sbin/nrattach thenet
NET/ROM port thenet bound to device nr0
[root@localhost root]# /usr/sbin/netromd -i
nrconfig: port thenet not active
netromd: no NET/ROM ports defined
[root@localhost root]#

ax25d wont start either.  When I remove all references to thenet from the
configuration files, kissattach and ax25d start and run just fine.

Can anyone tell me what I am overlooking or need to upgrade to get netrom
going?

One other point that may or may not have a bearing:  When I recompiled the
kernel to include kiss support, support for something called DEVPTS fell
off.  The boot sequences complains that it is not in the kernel (because
there is a line in /etc/fstab calling for it.)  I've tried a number of ways
of forcing it to compile but something in the make process always keeps
turning it off.

Thanks in advance for you help.     73   Tom  WB8ZRL

Re: netrom

[Tomi Manninen]

On Fri, 2004-02-20 at 20:32, Tom Vavra wrote:

> [root@localhost root]# /usr/sbin/nrattach thenet
> NET/ROM port thenet bound to device nr0
> [root@localhost root]# /usr/sbin/netromd -i
> nrconfig: port thenet not active
> netromd: no NET/ROM ports defined

You need to give the netrom port an IP address with -i option.
The address doesn't need to be valid (unless you plan on running
IP-over-NETROM) so something from the 10.x.x.x or 192.168.x.x
blocks should be ok.

-- 
Tomi Manninen / OH2BNS / KP20ME04

Re: Netrom

[Brian Rogers]

Greetings;

On Mon, 2013-07-08 at 21:37 -0700, Cathryn Mataga wrote:

> Hmm, interesting that this would be an issue.   The Linux code does 
> ignore a node if its best neighbor is one's self.    

That's fine, however it should also work in reverse;

NODEA <> NODEB <> NODEC
If I am node c,  and I get a broadcast from node b that he has routing
for node a, I should not send back to node b that node a exists on me.
In fact, I should not broadcast back any nodes he's sent me at all to
him. Doing such keeps non-existant nodes listed. For example if you
search hard enough you'll find the nodes UROHUB and IPURO still being
kept alive between xnet and linux systems on the internet. These nodes I
used to run have not been in existance since June 2009.


> I wonder if there's 
> a degenerate case, if 3 nodes all have their default_quality set to 255, 
> where the 'neighbor' can all be the third station in the pair, and then 
> the node broadcast just goes around and around for all eternity because 
> the quality never decreases at all.

Misconfigured and mismatched systems will do this as well.

> In this equation,
> 
>   = ((quality * best_quality) + 128) /256;
> 
> Could it be that 128 is a mistake, in a world with so many ip based 
> systems that set default quality at a high value. Without the 128 then a 
> default_quality of 255 turn a 255 quality node into 254, so the infinite 
> loop would end eventually.    

> If we don't want to touch the code, maybe 
> we should discourage anyone from ever setting a def_qual=255.  That this 
> just seems likely to cause problems to me.

You're correct there, but don't you know the name of the game? (S)he
with the most netrom nodes wins. Connectivity isn't the concern it's how
much we can flood the screen with non-existant and non-connectable
nodes. A good number of systems out there aren't maintained anymore but
still exist, and others simply don't want to be bothered because in
their eyes it's working so why fix it. 

In regards to the Xnet nodes, it uses a different formula for
calculating quality if I'm not mistaken, and I don't believe you have
the ability to set a min or even a default quality. It's been a while
but I think it's based off of a sort of ping response and if it's quick
(ie: inet) then it's obs are set to 6, and quality to 255. Again, I'm
going off of memory and I have aged hi!

-- 
73 de Brian Rogers - N1URO
email: <n1uro@n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Delaware, all New England, 
and New Jersey.

Re: Netrom

[Thomas Osterried]

On 2013-07-09 08:05:46 -0400, Brian Rogers <n1uro@n1uro.ampr.org>
wrote in <1373371546.6646.26.camel@n1uro.ampr.org>:
> Greetings;
> 
> On Mon, 2013-07-08 at 21:37 -0700, Cathryn Mataga wrote:
> 
> > Hmm, interesting that this would be an issue.   The Linux code does 
> > ignore a node if its best neighbor is one's self.    
> 
> That's fine, however it should also work in reverse;
> 
> NODEA <> NODEB <> NODEC
> If I am node c,  and I get a broadcast from node b that he has routing
> for node a, I should not send back to node b that node a exists on me.
> In fact, I should not broadcast back any nodes he's sent me at all to
> him. Doing such keeps non-existant nodes listed. For example if you
> search hard enough you'll find the nodes UROHUB and IPURO still being
> kept alive between xnet and linux systems on the internet. These nodes I
> used to run have not been in existance since June 2009.

Buggy software may the cause.

I think you're wrong with your assumtion, "I should not send back to
node b that node a exists on me."
Netrom is a broadcast protocol (we're talking about "it's broadcast" anyway).
It's designed, that multible nodes are on the same frequency, and broadcast
their knowledge abount the net. That means, NodeA rebroadcasts what he's
heard from NodeB and NodeC (with decreased quality, due to the algorithm
we've discussed before). And i.E. a NodeD (who hears only NodeA directly)
learns what NodeA broadcasts (that is, everything A has learned from B and C),

If NodeA has learned UROHUB with Quality 200, it calculates the new
quality (let's say 100) and broadcasts it. NodeB and NodeC will rebroadcast
it i.E. with quality 50.
If NodeA has no beacon heared from UROHUB, it times out (obsolescence timer).
NodeA will learn from NodeB and NodeC that the quality is 50, and computes
i.E. 25.
NodeB and NodeC will have to adjust the new quality, because they initialy
learned UROHUB from NodeA.
This count-to-zero may take some time (long time).
The worst_qual parameter helps to make this stop earlier.

Btw, I asked the maintainer of the TNN (TheNetNode) software. He says, that
that software has no capability to configure worst_qual (hardcoded 0).
TNN was used in north-west germany for many many years.

> > I wonder if there's 
> > a degenerate case, if 3 nodes all have their default_quality set to 255, 
> > where the 'neighbor' can all be the third station in the pair, and then 
> > the node broadcast just goes around and around for all eternity because 
> > the quality never decreases at all.
> 
> Misconfigured and mismatched systems will do this as well.
> 
> > In this equation,
> > 
> >   = ((quality * best_quality) + 128) /256;
> > 
> > Could it be that 128 is a mistake, in a world with so many ip based 
> > systems that set default quality at a high value. Without the 128 then a 
> > default_quality of 255 turn a 255 quality node into 254, so the infinite 
> > loop would end eventually.    


((255*255)+128)/256 = 254

=> It does decrease on the next hop and behind.

> > If we don't want to touch the code, maybe 
> > we should discourage anyone from ever setting a def_qual=255.  That this 
> > just seems likely to cause problems to me.
> 
> You're correct there, but don't you know the name of the game? (S)he
> with the most netrom nodes wins. Connectivity isn't the concern it's how
> much we can flood the screen with non-existant and non-connectable
> nodes. A good number of systems out there aren't maintained anymore but
> still exist, and others simply don't want to be bothered because in
> their eyes it's working so why fix it. 
> 
> In regards to the Xnet nodes, it uses a different formula for
> calculating quality if I'm not mistaken, and I don't believe you have
> the ability to set a min or even a default quality. It's been a while
> but I think it's based off of a sort of ping response and if it's quick
> (ie: inet) then it's obs are set to 6, and quality to 255. Again, I'm
> going off of memory and I have aged hi!

xnet (and tnn) people normaly use the netrom-derivate INP3, which scales
much better.

vy 73,
	- Thomas  dl9sau

> 
> -- 
> 73 de Brian Rogers - N1URO
> email: <n1uro@n1uro.ampr.org>
> Web: http://www.n1uro.net/
> Ampr1: http://n1uro.ampr.org/
> Ampr2: http://nos.n1uro.ampr.org
> Linux Amateur Radio Services
> axMail-Fax & URONode
> AmprNet coordinator for:
> Delaware, all New England, 
> and New Jersey.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Netrom

[Cathryn Mataga]

On 7/9/13 3:34 PM, Thomas Osterried wrote:
> ((255*255)+128)/256 = 254 => It does decrease on the next hop and behind.



Oops, you're right.  So what about this situation.

A -- B   -- C
          \   /
            D


If A sends a broadcast to B.   The link from B back to A should decrease 
the 'obsolete' value with each broadcasts.  But can the listing loop 
around from C to D back to B?

But the loop of death should eventually run out of gas when the quality 
hits 0.  So, how are all those nodes sticking around for years and 
years.  Even if misconfigured, can Netrom do this all by itself.  Hmm.

Re: Netrom

[Cathryn Mataga]

On 7/9/13 7:08 PM, Cathryn Mataga wrote:
> On 7/9/13 3:34 PM, Thomas Osterried wrote:
>> ((255*255)+128)/256 = 254 => It does decrease on the next hop and 
>> behind.
>
>
>
> Oops, you're right.  So what about this situation.
>
> A -- B   -- C
>          \   /
>            D
>
>
> If A sends a broadcast to B.   The link from B back to A should 
> decrease the 'obsolete' value with each broadcasts.  But can the 
> listing loop around from C to D back to B?
>
> But the loop of death should eventually run out of gas when the 
> quality hits 0.  So, how are all those nodes sticking around for years 
> and years.  Even if misconfigured, can Netrom do this all by itself.  
> Hmm.
> --

Err, if A sends a broadast to B and then disconnects.

Re: Netrom

[Nate Bargmann]

* On 2013 09 Jul 21:15 -0500, Cathryn Mataga wrote:
> On 7/9/13 7:08 PM, Cathryn Mataga wrote:
> >On 7/9/13 3:34 PM, Thomas Osterried wrote:
> >>((255*255)+128)/256 = 254 => It does decrease on the next hop
> >>and behind.
> >
> >
> >
> >Oops, you're right.  So what about this situation.
> >
> >A -- B   -- C
> >         \   /
> >           D
> >
> >
> >If A sends a broadcast to B.   The link from B back to A should
> >decrease the 'obsolete' value with each broadcasts.  But can the
> >listing loop around from C to D back to B?
> >
> >But the loop of death should eventually run out of gas when the
> >quality hits 0.  So, how are all those nodes sticking around for
> >years and years.  Even if misconfigured, can Netrom do this all by
> >itself.  Hmm.
> >--
> 
> Err, if A sends a broadast to B and then disconnects.

It has been a long time, nearly 20 years since I worked with NetROM, but
I do recall this.  Broadcasts are AX.25 UI (unconnected) packets and are
sent to the destination of NODES, at least that is what I recall of the
original NetROM, early TheNet, and G8BPQ nodes.  So Node A in this case
does not "disconnect" nor does it ever send its nodes list as part of
the connected level 2/level 3 session.  Even when there was a level
2/level 3 connection between nodes, the nodes broadcast was a UI packet
typically broadcast every 60 minutes often refered to as "node barf" by
some who didn't care to understand about their operation.

Most of us ran the nodes at the firmware default values although I'm
sure somebody tweaked things for better performance.

Actually, while NetROM was deployed on a single frequency in many areas,
particularly here in Kansas, Oklahoma and Nebraska due to financial
constraints, doing so really hurt performance.  As I recall, the system
was really designed to be sort of a cellular system with neighboring
user nodes on separate frequencies tied together by a common higher
speed backbone and coordination used to isolate user nodes.  However,
out here in the sticks, just getting one node on the air was an
accomplishment let alone doing it right.  But that is a topic for
another time.  In this scenario, user nodes would not send a nodes
broadcast on their radio port but would over the RS-232 port which is
how back-to-back and node stacks were built (three or more TNCs were
tied via a diode matrix to each other's RS-232 port to build a stack),
thus eliminating node barf from being seen by the users.

Once upon a time I had a Software 2000 NetROM manual that described a
lot of the protocol.  I have no idea if the authors of the Linux NetROM
code had access to that document or any other reference.  After years of
watching it, even when I had access to a NetROM network with a backbone,
NetROM seemed to fall apart after more than about three or four hops.
The most reliable way to make BBS forwarding work was to script the
connection through each node to the next manually as then a weaker path
would retry more often at level 2.  Otherwise, connecting to a distant
node a few hops away would result in level 3 timeouts from the first
node and kill the connection.  The nodes had no ability for true store
and forward and did not behave like routers.  

All of this is a bit hazy in my memory.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Re: Netrom

[Brian Rogers]

On Tue, 2013-07-09 at 22:17 -0500, Nate Bargmann wrote:

> It has been a long time, nearly 20 years since I worked with NetROM, but
> I do recall this.  Broadcasts are AX.25 UI (unconnected) packets and are
> sent to the destination of NODES, at least that is what I recall of the
> original NetROM, early TheNet, and G8BPQ nodes.  So Node A in this case
> does not "disconnect" nor does it ever send its nodes list as part of
> the connected level 2/level 3 session.  Even when there was a level
> 2/level 3 connection between nodes, the nodes broadcast was a UI packet
> typically broadcast every 60 minutes often refered to as "node barf" by
> some who didn't care to understand about their operation.

Absolutely the way it was (and in some parts still is). If you can find
some of the old NEDA pages, they used a default quality of 203, and a
min qual of 50. Only user tnc's were shown and never broadcast nodes as
you mention. The backbone tncs linked via rs232/diode matrix cables had
hidden alias's... so the only visible nodes to an end user in a "nodes
list" were those of the userport TNCs. By using 203, the next visible
hop would degrade to a quality of 181 (with the hidden port having a
quality of I think 192). The next visible hop after that if my memory
serves me well would be 164, and so on. The mathematics was so that the
8th visible hop to your own node would have a quality of 51, thus the
9th hop would be below the minqual of 50, and wouldn't be
shown/broadcasted or added.

> Once upon a time I had a Software 2000 NetROM manual that described a
> lot of the protocol.  I have no idea if the authors of the Linux NetROM
> code had access to that document or any other reference.  After years of
> watching it, even when I had access to a NetROM network with a backbone,
> NetROM seemed to fall apart after more than about three or four hops.

The NEDA system worked extremely well beyond 4 hops. They very carefully
studied it and when TheNet was replaced with X1J-4 we migrated over to
that. The neat thing about X1J-4 was that it did have a tiny IP router
in it... which was in a sense pointless because it had no IP daemons.
In the event of IP on RF though, you're better off w/o the added
protocol headers of NetRom and use vanilla ax25.

> All of this is a bit hazy in my memory.

Your memory is quite clear it seems :) Thanks for the trip down memory
lane! Brought me back to my old TheNet/BPQ days as well.
-- 
73 de Brian Rogers - N1URO
email: <n1uro@n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Delaware, all New England, 
and New Jersey.