If like probably the majority of users/sysops we had no option but to
use ifconfig statements, there would be less of us, At least the current
ports files make configuring a port straight forward, and less likely to
fail. I did'nt realise that the ax25-utils were subject to the German
purity law !
73 's richard
In message <[EMAIL PROTECTED]>,
Tomi Manninen <[EMAIL PROTECTED]> writes
>On Sun, 9 May 1999, Thorsten Kranzkowski wrote:
>
>> I have a fundamental question about this:
>> For what purpose do we have the 'axports' file? What is the reason for
>> which I have to bind a 'port' to a 'callsign' ?
>>
>> why don't we just use the interface name?
>
>Because the kernel doesn't. When you want to make a connection using the
>kernel AX.25, NET/ROM or ROSE layers (using the normal socket(), bind(),
>listen(), accept(), connect() etc. system calls), you have to use the
>interface hardware address ie. the "callsign bound to the port" to
>distinguish between the ports. Only when you configure things related
>directly to the interface itself (eg. the ip-address), you use the
>interface name.
>
>The whole idea of axports is to have an abstraction layer on top of these
>things so that the user would have to know only the port name (which you
>can BTW freely choose, unlike kernel interface names).
>
>> I think all the information in axports is superfluous:
>> name: that's what I want to get rid of
>
>Well good for you. But I think my users much prefer using a port name like
>"1" or "2m" or "9k6" over a kernel interface name like "bcfxzyq2" or
>whatever they happen to be called...
>
>> callsign: set with ifconfig (on the interface name ....:-) )
>
>Yes you can set it with ifconfig. The idea is that you wouldn't have to.
>Kissattach for example does all this for you. Also note that although you
>can use ifconfig, it often isn't quite "safe". The kernel interface name
>is often assigned dynamically and you can never really know for sure what
>the name is. This becomes even more important in a multiport system.
>
>> speed: set with sethdlc (also on the interface name)
>> paclen: set in /proc/sys/net/ax25/bcsf0/maximum_packet_length
>> ----- also the interface name
>> window: set in /proc/sys/net/ax25/bcsf0/standard_window_size
>
>Ditto.
>
>> description: well, _very_ important when you have only one interface .....
>> and if you have more than one you should know what you are
>> doing.
>
>Aren't you a bit narrow in your thinking? What about a multiport multiuser
>node site? Like ours that has five radio ports, an axip port and a couple
>of internal loopback ports. Sure anyone using our system knows exactly
>what they are doing... NOT.
>
>> Disadvantages of axports usage:
>> - axutils stop working when you assign the same call to two or more
>> interfaces
>
>Axutils stops working only as an early warning because if you do that,
>it's the _kernel_ that gets _very_ confused.
>
>> - users get _very_ confused about when to use a 'port'-identifier(axports) and
>> when the 'interface'-identifier(kernel)
>
>Users never need to use anything but the port name. Sysops should know
>what they are doing. If we are talking about an end-user that is both at
>the same time, we should probably just extend the idea of axports so that
>even people that use baycom, scc or soundmodem interfaces wouldn't need to
>use the interface name. Suggestions welcome.
>
>> By the way - one should drop "-i inetaddr" and "-m mtu" from nrattach and
>> rsattach - that's ifconfig functionality.
>
>Why should they be dropped? What harm is done having them there? In my
>opinion we should on the contrary have options for netmask and broadcast
>address too. Or preferably have all that information in the files.
>
>> What do you think about this?
>> What did I miss? Where am I wrong?
>
>You missed only the whole idea of [ax|nr|rs]ports files...
>
--
richard bown
