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.
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.
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.
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.
-- Mike, N1BEE