Hello!
> > 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.
Ok - this is the answer to my question.
... looked at the source (call.c, af_ax25.c) ... learnt a bit :-))
thank you.
perhaps I should have looked earlier ....
>
> 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).
hmm - yes - but you end up having two names for the same thing: the
interface name and the port. This at least confused me when I came across
linux ax25 two years ago.
> > 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...
Do they? At home where user==sysadmin they also use items like hda1, sdc3,
ippp0, tty7 I think.
> > 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
Well, it appears to me like reinventing the wheel. Why replicating
functionality when there is already a well known command for it?
I actually have seen users who used both ways 'just to be shure' ....
I tend to say: when there is only one way to accomplish things there is
less probability to make mistakes.
> > 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
perhaps. :-)
> 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
Yes I'm primarily thinking about them. Sure - if you present ax25 services to
remote users you probably want to give some information about your system.
> even people that use baycom, scc or soundmodem interfaces wouldn't need to
> use the interface name. Suggestions welcome.
When you intend to use tcp/ip, you will have to use the interface name anyway,
right? (route, ipchains ...)
> You missed only the whole idea of [ax|nr|rs]ports files...
hihi - at least I now have a clue what the motivation for it really is,
although I still don't like it.
> --
> --... Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ...--
> > According to Thorsten Kranzkowski: While burning my CPU.
>
> No!
>
> 1) The user makes an outgoing call using the _port_ name. 2) The 'call'
> (or whatever) application translates that to a callsign using the axports
> file and then 3) asks the kernel to make a connection through the port
> having that callsign as the hardware address.
ok - you are right.
how about an ioctl between socket() and connect() tho choose the interface?
That would also render the "funny extension" to ax25_bind() in af_ax25.c
obsolete.
> > > Now you have two interfaces with identical Hardwere addresses - which
> > > is perfectly ok for tcpip. But anything that uses axports (e.g. 'call') now
> > > gets confused because it cannot decide which interface to use. So it
> > > stops with an error message.
>
> No. As I already said it's the kernel that is very much confused at this
> point, not the utils. The utils just save you from the trouble by barfing
> early.
Is there any other place in the kernel except ax25_bind() where this would
cause trouble?
> Besides I'm not at all sure the kernel would be ok if the hardware
> addresses for other protocols were the same. And they won't be in general:
> no two ethernet cards in the world have the same hw address, ppp and slip
That's true. ( when you forget about those ethernat cards with software
settable hw address ...) You also dont't use layer2 (user-) connections or
layer2-digipeating though.
> (being point-to-point protocols) don't even have hw addresses and so on...
Anyway, thank you for replying.
73 Thorsten
--
| Thorsten Kranzkowski Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Mobile: ++49 161 7210230 Inet: [EMAIL PROTECTED] |
| Ampr: dl8bcu@db0nei.#nrw.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
