On 2 Mar 1999, Jonathan NAYLOR wrote:
> The problem with users connecting to the NET/ROM callsign is that the
> NET/ROM doesn't know whether the person connecting is a user or another
> node, this is the reason why real NET/ROMs, BPQ, et al, don't generate
> any connect text in that case. The code could be making a mistake and
> upsetting the neighbouring node, potentially swapping "unknown command"
> messages with each other for ever. There is no such ambiguity with
> either a level 4 connect, or with a connection to the alias(es),
> A way around that would be when users connect to the node callsign on a
> frequency where you know that no NET/ROM links are going to take place,
> in that case it would be allowable to drop them into the node also.
There is also another way around the abovementioned problem and it has
been in use for years now on our system and many others. Also it has been
discussed on this list on several occations.
The trick is to take advantage of the fact that the first callsign in
/etc/ax25/nrports is used as the source callsign when netromd generates
broadcasts. Consequently when neighbouring nodes make interlink
connections to your station they always connect to that callsign.
Now the real trick: leave that _first_ callsign free of any services in
ax25d both for netrom and for ax25. Make it a "dummy netrom interface".
Then define a second netrom port with different (of course) call for your
node, a third for your bbs and so on. Now you can also configure ax25d to
answer to AX.25 connects to the second and third callsign with the correct
service (node and bbs respectively). The first callsign in nrports must
not appear anywhere else (like in ax25d.conf) but the second and third
can. With this setup you get behaviour like this when you connect to the
system:
With AX.25 (direct connect on a local frequency):
first callsign -> nothing (linux expects you to be a NET/ROM node
and start speaking "NETROM")
second callsign -> node
third callsign -> bbs
With NETROM (from a distant NET/ROM node):
first callsign -> connection refused / busy / whatever
second callsign -> node
third callsign -> bbs
I think this is the N+1:th time I try to describe how to do this but I'm
afraid it still won't make any sense to many people. Fortunately John
Ackermann has tried to explain it too so you can read his version and get
at least another version of this explanation... It's in
http://www.febo.com/packetnet/mvfma.html
--
--... Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ...--
