>
>
> Karl F. Larsen wrote in a message to Mike Bilow:
>
> KFL> I have not tested with any care but you can change the
> KFL> kernel defaults at anytime after the kernal has booted. 3
> KFL> days later will work...:-) But it has to be done because the
> KFL> kernel defaults are not very good. In particular the netrom
> KFL> "default_path_quality" should be 192 instead of 10. And
> KFL> since most of us live near netrom nodes and use them, the
> KFL> ax25 packet length should be 234, not 256.
>
> The defaults are defaults. If you don't like them, change them.
Thank you I have done so.
>
> The goal of the defaults is to cause as little damage to tbe public network as
> possible if some idiot just turns on netrom. With a default netrom quality of
> 10, the NODES broadcast will not falsely claim to be a useful route for any
> other node. The proper settings for netrom are highly variable from one region
> to another, and it is more important that all of the nodes in the same region
> agree than that some particular absolute value be used. If, for example, the
> regional convention was 128 for an adjacency and someone came up advertising
> 192, then all of the regional traffic would switch over to the "better" quality
> route. A few events like this will often motivate node operators to start
> locking all their routes manually and otherwise disabling most of the useful
> features in the netrom protocol in order to keep the network from periodically
> falling off its precariously balanced perch.
Believe it or not I own the technical manual sent out with the
Software 2000 Netrom chip I paid 65 (1988) dollars for. It had some
defaults for timers and things and the default initial quality was 192. I
wondered at the time why that value is used.
Now I know that you can cause packets to use the 9600 baud links,
rather than the 1200 baud accidental link, by giving the 9600 baud nodes
an initial quality one digit higher than the other. When the sun
disappears for 3 days and the solar powered 9600 baud path dies, the 1200
baud path begins working fast.
>
> One can level any number of very serious criticisms at netrom as a protocol.
> There are numerous implementations and these often interpret parts of the
> protocol in different ways. No one can agree upon a canonical implementation
> of netrom, and strange incompatibilities have to be worked out through reverse
> engineering. There are deadlock potentials, such as "CHOKE," written into the
> protocol itself.
>
Well the best in my opinion is that done by G8BPQ. His Switch in
DOS is just wonderful. Well, if terse, documentation and such, but if your
a packet bbs with several tnc's his stuff is simply the best.
It would be great if the Switch could be ported to Linux. The FBB
for Linux is now simply great. It runs with everything working and is
pretty. If a BPQ switch could be implemented above FBB like it is in DOS
it would be a better world...:-)
The current netrom in Linux is true to the definition of Netrom.
And it works well, but it lacks some of the bells and whistles of the BPQ
Switch.
> As for packet length, this is a vicious circle. Since there are (I think) 20
> bytes of overhead when encapsulating an AX.25 frame into a netrom frame, the
> largest payload is 236 bytes inside a 256-byte netrom frame. However, don't
> forget that netrom frames are also themselves always encapsulated inside AX.25
> frames. In effect, a netrom circuit operates by encapsulating AX.25 frames
> into netrom frames into AX.25 frames. The only way to stop the recursive (or,
> more properly, excursive) application of AX.25 packet length is to distinguish
> between encapsulated and unencapsulated frames, in which case the encapsulated
> maximum length would be directly computable from the unencapsulated maximum
> length minus some constant associated with the encapsulation type. It is a
> good idea to know exactly what it is that you are setting.
>
Simple test. Send a packet with 256 bytes of payload to a netrom
node. Watch the two packets exit that node. At 1200 baud it is obvious the
network is slowed down. Make the packets 234 bytes and watch things speed
up.
> -- Mike, N1BEE
>
>
>
Best wishes
- Karl F. Larsen, 3310 East Street, Las Cruces,NM (505) 524-3303 -