Following up on Chuck's questions about the apparent call/SSID used by
Linux AX.25:
When a station has established a connection to any Linux AX.25 service
that I'm aware of, including node, FBB, and the CLX cluster software,
the FROM callsign matches the callsign used to establish the
connection, so I believe that meets your criteria for "manifest."
It'll save a bit of confusion to mention now that the low-level Linux
networking components, like NetROM network layer configuration, are
completely separate from the programs that users interact with. For
example, the "node" program provides a G8BPQ-like front end for user
interface. "node" is launched by a daemon program called ax25d, which
listens on all the AX.25 ports. When it sees an incoming connect
request it matches the FROM and TO callsigns, as well as the port, to
values in a configuration file and launches the appropriate application.
So, when you connect to W8APR-1 or BBROOK on 145.61 at my station,
ax25d sees that request and knows that any connection to that callsign
is intended for the node program, so it launches that program, passing
to it the TO and FROM callsigns of the incoming connect request. node
than takes over the connection, using those callsigns. Most
applications launch in this way, though some (like FBB) listen to the
AX.25 ports directly rather than via ax25d. What's key is that the
combination of ax25d and the program's own coding defines what
callsigns are used, so there's tremendous flexibility in configuration.
The call/SSID combinations assigned to the hardware ports have nothing
to do with it, and they can be totally different, or even dummy calls.
Moving on to the NetROM subsystem... When the Linux NetROM system
sends its node table, the FROM call is the call/SSID assigned to the
first NetROM port defined in the system. That may or may not make the
user access call/SSID "manifest" but it will identify the port used for
layer 2 NetROM-to-NetROM connects. (It may help to explain that the
Linux "node" program that provides the BPQ-like user interface isn't an
integral part of the NetROM subsystem -- it's a stanalone program that
is configured separately. Its call/SSID don't have anything to do with
what's defined for the NetROM ports.)
Note that to make the NetROM user interaction similar to what BPQ users
expect, you ordinarily configure two or more NetROM ports, each with
its own alias and call/ssid combination. One is a "system"
alias/call/ssid that can be hidden with a "#" character and is only
used for NetROM-to-NetROM connections, while the others are used for
user interaction. At W8APR, #MVFMA:W8APR-14 is the system node,
BBROOK:W8APR-1 conencts you to the "node" front end, and MVFMA:W8APR-0
provides access to the FBB software. All these appear in neighboring
node tables. (My web page explains the details of setting this up.)
If the NetROM system and applications are set up properly, users could
do an AX.25 connection to, for example, FBB, using the call/SSID that
appears in the "MVFMA:W8APR-0" entry of the NetROM nodes list -- it
will respond to both that alias and call/SSID via AX.25, or to the
MVFMA node via NetROM. However, you don't *have* to do it that way, so
there's no guarantees.
The only other traffic I can think of where a passer-by would pick up a
callsign/SSID is from some sort of beacon. As you've already seen, FBB
sends its mail beacon using the call/ssid that it responds to.
By itself, the node program doesn't generate any beacons or status
messages to let a passer-by know that it's there. However, there's a
separate "beacon" program that allows you to send one or more beacons
on whatever ports you want, using whatever FROM and TO callsigns you
want. With that tool, you can make the call/SSID of whatever services
you like visible.
I hope this helps.
73,
John
> Hi, John:
>
> No. I am not asking that if Joe Packet uses a TNC2 and attempts to connect to
> W8APR-1,
> that a station will respond using a CALLSIGN-SSID of W8APR-1. It would have to.
> If I use a TNC2 and transmit connect requests to W8APR-1, it will not accept a
> <UA>
> from any other CALLSIGN-SSID. I think it would return a <DM> to any other
> CALLSIGN-SSID's <UA> frame.
>
> What I am asking is:
> How does a network neighbor pbbs sysop know what CALLSIGN-SSID
> to try to AX.25 forward?
>
> (I know how to do a AX.25 connect to a NETROM, THENET, BPQ, MSYS node
> by looking at its neighbor's node list. In the case of MSYS or a BPQ/BBS
> I know what CALLSIGN-SSID & ALIAS-SSID to use to establish an AX.25
> circuit with the BBS.)
>
> Does Joe Packet see AX.25 packets transmitted by W8APR-1?
>
> Does the callsign-ssid assigned to the linux node transmit AX.25 frames using the
> callsign-ssid
> that is accepting AX.25 connects?
>
> Does the callsign-ssid assigned to the linux bbs transmit AX.25 frames using the
> callsign-ssid
> that is accepting AX.25 connects?
>
> If I monitored your 145.61 MHz port with a TNC2 would the callsign-ssid you used
> to transmit
> AX.25 frames (MyHEARD) be the same callsign-ssid that would accept AX.25 connects?
>
> If I monitored your NETWORK port with a THENET, NETROM, BPQ, MSYS node,
> would it be manifest what callsign-ssid to use to establish an AX.25 circuit with
> your node?
> Would it be manifest what callsign-ssid to use to establish an AX.25 circuit with
> your bbs?
>
> Without the person who configured the linux node telling me
> and by only monitoring or checking a node list,
> how do I know what CALLSIGN-SSID to use to establish an AX.25 circuit to a linux
> node?
> how do I know what CALLSIGN-SSID to use to establish an AX.25 circuit to a linux
> bbs?
>
> I am assuming that by looking at a node list, that I will see only the
> CALLSIGN-SSIDs that
> are accepting node level circuit requests and not AX.25 connect requests.
>
> Does the default configuration of linux node transmit (an ID frame?) in AX.25
> using the
> callsign-ssid that is accepting AX.25 circuits?
>
> Is it manifest to the user?
>
> Is it manifest to the neighbor pBBS sysop?
>
> I think we are about 6 miles apart. I've dialed in 145.61 MHz and will check
> my heard list and node list in a few minutes to see if I can figure out what
> CALLSIGN-SSID would be accepting AX.25 circuits.
>
> Result after about one hour:
> The only CALLSIGN-SSID heard was W8APR-0.
> (OBTW, you have mail.)
>
> If you hadn't told me, I'd never have known that a node W8APR-1 was
> available for an AX.25 circuit on that channel.
>
> Thanks, again.
> Chuck nc8q
>
>
> John Ackermann wrote:
>
> > > Hi, John:
> > >
> > > Thanks.
> > >
> > > I think that you are answering my question (1.) with a 'yes', but I am not
> > > sure.
> > >
> > > I've read all my new mail today and see no answer regarding making
> > > the 'AX.25 accepting CALLSIGN-SSID' manifest.
> > >
> > > I think an ALIAS-* can be configured though and this should be good enough.
> > >
> > > 73, Chuck
> >
> > Chuck, I think what you're asking is whether the call/SSID that's used
> > as the destination address for inbound packets is used as the source
> > address for outbound packets in that same connection. I would need to
> > do some monitoring to be sure, but I believe that the answer is "yes,
> > probably". I believe that most of the Linux AX.25 tools and
> > applications will reflect the address used to establish the connection
> > as the apparent "FROM" address in the return packets.
> >
> > I say "probably" because an application can assign a "FROM" address at
> > will if it wants to, so there's no system-wide guarantee what every
> > conceivable application might due. (As an aside, at least one version
> > of the "call" program that you use to establish an outgoing
> > plain-old-packet keyboard session allows you to specify the FROM
> > callsign in the command syntax.
> >
> > If you want to check for yourself, you can connect to W8APR-0, W8APR-1,
> > MVFMA, or BBROOK on 156.61 (I think you're close enough to me to reach
> > directly) and see what the FROM/TO callsigns are. W8APR-0 and MVFMA
> > connect to the FBB software, while W8APR-1 and BBROOK are used for the
> > node software. The hardware address of the 145.61 port is actually
> > W8APR-13, and I don't think you'll see many packets with that FROM
> > address.
> >
> > 73,
> > John
> > --
> > John Ackermann N8UR
> > Dayton, Ohio, USA
> > [EMAIL PROTECTED] -- http://www.febo.com
> >
> > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > Version: 2.6.3a
> >
> > mQBtAzgI9hgAAAEDAMiMQDZTVVuVIS0AscJ0Wy63oK4+Q5xvtxbX/ZoG1qCOuYDI
> > Fph4/RqL9vVEItWBy6ISk+zbkATzPgy84nrI7+GBtld4F9DoHWARQXjC1I8cFZjY
> > TSe16ffqO/ba1ukLnQAFEbQlSm9obiBSLiBBY2tlcm1hbm4gTjhVUiA8anJhQGZl
> > Ym8uY29tPokAdQMFEDgI9hjqO/ba1ukLnQEBtYIC/AxJ2RqT0/9TqY8JGEkPx2sw
> > +W5Z6Tu4UI654t9diGdCcIEPjOG1qUvwH2Xop0Yj9QGoM4NnHIw6qUSN5VH7hHKA
> > bGnpuTxinuW/gKaI3bt2MC8QZZq0gy2de26907lE2A==
> > =UHWl
> > -----END PGP PUBLIC KEY BLOCK-----
--
John Ackermann N8UR
Dayton, Ohio, USA
[EMAIL PROTECTED] -- http://www.febo.com
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3a
mQBtAzgI9hgAAAEDAMiMQDZTVVuVIS0AscJ0Wy63oK4+Q5xvtxbX/ZoG1qCOuYDI
Fph4/RqL9vVEItWBy6ISk+zbkATzPgy84nrI7+GBtld4F9DoHWARQXjC1I8cFZjY
TSe16ffqO/ba1ukLnQAFEbQlSm9obiBSLiBBY2tlcm1hbm4gTjhVUiA8anJhQGZl
Ym8uY29tPokAdQMFEDgI9hjqO/ba1ukLnQEBtYIC/AxJ2RqT0/9TqY8JGEkPx2sw
+W5Z6Tu4UI654t9diGdCcIEPjOG1qUvwH2Xop0Yj9QGoM4NnHIw6qUSN5VH7hHKA
bGnpuTxinuW/gKaI3bt2MC8QZZq0gy2de26907lE2A==
=UHWl
-----END PGP PUBLIC KEY BLOCK-----
