[nos-bbs] ".bbs" appended on return addresses

Mon Jul 20 15:28:39 EDT 2020

I'm beating my head against this -- and Maiko is also noodling on it --
but I am getting nowhere.

The quick version of my question is "Does anyone know why return
addresses are sometimes ABC%DEF.bbs at GHI and have that ".bbs" in the
middle rather than being ABC%DEF at GHI. Responding to such a message (with
the ".bbs") does not work if it's going to a remote JNOS station -- the
message is silently dropped with no reason given ("FS -" response) and
the sender is not notified. (Responding to ABC%DEF at GHI does work.)

- - - - - - -

A friend and I have two JNOS BBS's operating here in San Francisco
(AA6AX and KJ6PTX) and want to pass messages back and forth.

When he addresses a message to me aa6ax at AA6AX his JNOS sends it out to
my JNOS on the radio (he has a rewrite rule and forward.bbs that take
care of that), but then when I open it, the return address is
kj6ptx%kj6ptx.bbs at AA6AX.

All well and good, _except_ for that ".bbs" in the middle, and we have
no idea where that came from. We believe it _should_ be
kj6ptx%kj6ptx at AA6AX instead. The JNOS log itself shows the correct
return address _without the .bbs_ in it. However, that's just the log.
Inside my JNOS "area" (aa6ax.ind) the message is from
kj6ptx%kj6ptx.bbs at AA6AX instead.

I also have rewrite and forward.bbs rules in place. My rewrite is:

*%*.bbs at AA6AX $1@$2 r

My understanding is that this rule (REGEX) looks for
anything-percent-anything-dotBBS at AA6AX and then rewrites it _without any
.bbs in the rewritten string_.

If I check within JNOS, the rewrite seems to correctly analyze.

jnos> rewrite kj6ptx%kj6ptx at AA6AX
to: kj6ptx_bbs

Note that this is _correct_. My rewrite and forward.bbs rules say that
messages to %KJ6PTX are to be queued in kj6ptx_bbs (underscore, not dot)
until sent.

When JNOS goes to send this message, however, it snags. JNOS at AA6AX
connects to JNOS at KJ6PTX and proposes a transfer, but the destination
address is KJ6PTX.BBS, and the JNOS at KJ6PTX rejects this ("FS -") for
reasons we don't understand, but anyway it is rejected. So that's the
issue...

Wed Jul  8 12:04:26 2020 - vhf sent:
KISS: Port 0 Data
AX25: AA6AX-1->KJ6PTX-1 I NR=1 NS=0 pid=Text
0000  00 96 94 6c a0 a8 b0 e2 82 82 6c 82 b0 40 63 20  ...l (0b..l.0 at c
0010  f0 5b 4a 4e 4f 53 2d 32 2e 30 6d 2d 42 31 46 48  p[JNOS-2.0m-B1FH
0020  49 4d 24 5d 0d 46 41 20 50 20 41 41 36 41 58 20  IM$].FA P AA6AX
0030  4b 4a 36 50 54 58 2e 42 42 53 20 4b 4a 36 50 54  KJ6PTX.BBS KJ6PT
0040  58 20 31 35 39 33 5f 41 41 36 41 58 20 34 30 35  X 1593_AA6AX 405
0050  0d 46 3e 0d                                      .F>.

Wed Jul  8 12:04:30 2020 - vhf recv:
KISS: Port 0 Data
AX25: KJ6PTX-1->AA6AX-1 I NR=1 NS=1 pid=Text
0000  00 82 82 6c 82 b0 40 e2 96 94 6c a0 a8 b0 63 22  ...l.0 at b..l (0c"
0010  f0 46 53 20 2d 0d                                pFS -.

First of all, am I understanding this correctly? Should I be able to
just "reply" to kj6ptx%kj6ptx.bbs at AA6AX and have the rewrite rule route
it correctly? Obviously it handles the overall message using my rewrite
and forward.bbs rules, but does nothing to the "To:" inside the message,
which retains the .bbs in it, which presumably is why it won't transfer
properly.

Second, is it possible that the JNOS on the receiving end should be
smarter and understand that "KJ6PTX.BBS" is in fact its own name?

For the record, I have tried modifying these settings:

bulletin return on|OFF
bulletin check on|OFF

which supposedly tells JNOS whether to pay attention to "R:" information
in bulletin routing, yet it makes no difference in how these incoming
messages are being handled. I still get the "%" format and the ".bbs" in
the return address.

This does not happen to return addresses to non-JNOS stations. They are
as expected and do not have this "%" nonsense in them. This is JNOS
being fussy with other JNOS systems. Or JNOS being fussy with "R:" headers?

—Sky

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Sky" (Jim Schuyler)
—Amateur Radio AA6AX
http://aa6ax.us/

On 7/16/20 7:23 PM, Sky wrote:
> Answers inline. If this isn't appropriate for this list, let me know.
> —Sky/aa6ax
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "Sky" (Jim Schuyler)
> —Amateur Radio AA6AX
> http://aa6ax.us/
>
> On 7/16/20 5:11 PM, Bill Vodall wrote:
>> )
>>
>>> On Wed, Jul 15, 2020 at 11:31 AM Sky <sky at aa6ax.us> wrote:
>> Hello Sky and the NOSBBS world...
>>
>> Mesh continues to bring back the fun of packet - I know - the tunnel's
>> are cheating a bit but hey - with NPR and LORA coming soon we'll have
>> new tech that fills that missing 1 to 10 mile coverage at a useable
>> speed.
>>
>> Yesterday as a zero pi day big time.  I went from zero to three in a
>> couple hours.  Having prepurchased the essentials worked out well.
>> The USB-Micro to 3 regular USB ports  (and one with Ethernet) made it
>> easy to hook up the keyboard and mouse to get running.
>>
>> The middle pi zero was a bit of an impediment.  Worked on getting it
>> associated with the local WIFI for a hour before I noticed the missing
>> W (as in Wifi Wireless) on the circuit board.  Plugged in the hub with
>> Ethernet and it came right up.
>>
>> The associate at the end of the tunnel set up another PI for me this
>> morning.  Since then I've compiled JNOS and delivered it over the
>> tunnel so it's running at the remote site.   Thus leaving only the
>> minor task of configuring JNOS.  If only I had a nickel for every
>> config change...
>>
>> Lot's of history with JNOS and many historical config files but since
>> I'm starting fresh I'll take the packaged jnos installer for a test
>> ride.
>>
>> (Hey Maiko - there's still a couple references to the jnosinstaller in
>> the Makefile...)
>>
>> There isn't much happening on the MESH world - that's about to change
>> when JNOS gets running.  Specially the web pages and even MRTG stats.
>>  LINBPQ has more web interaction - but it's even harder to get going
>> than JNOS.  I'll take it for a mesh test drive soon.
>>> Hey, Bill ——
>>> Compile was 100% easy.
>> Yes - copied the config.h.default - removed a couple defines not
>> needed for a pure IP environement and removed the two jnosinstalls.
>>
>>> My JNOS appears at 192.168.2.2 on the Pi via the tunnel set up in autoexec.nos. So I can access any services there that are listening. Is this what you're asking?
>> I'm expecting these jnos instances will use another 10. address on the
>> mesh.   Kinda like the old 44 net days.  That was my original
>> question.  With 'real' linux the TUN interface allows connecting JNOS
>> (like a virtual machine) to the hosting Linux.   Is that how you set
>> up your 192.168.2.2 interface.
> My 192.168.2.2 is configured in the autoexec.nos file. That's all I
> know. –Sky
>>> I use home-built Python add-ons to knit my JNOS into other capabilities like email. I use regular email app (Claws Mail) to send and receive thru JNOS (like using Outpost PMM, but without the need to run Windows). There are a few glitches that are getting worked out, but basically this works really, really smoothly.
>> That's where I hope this leads.   It'll provide a locally hosted email
>> system I can access with Thunderbird or alpine - I think Alpine is the
>> client these days. I left ELM at the y2k and still miss it.  NNTP
>> newsgroups, CONVER chat and the whole works - handled on a relatively
>> safe relatively quiet VPN'ish 10. net.
> Precisely. This stuff should be easy enough for regular folk to use it.
> I'm tired of going into an emergency simulation and taking 2 hours to
> fiddle with parameters before the packet station can be up and running. —Sky
>>> See https://SFWEM.NET/
>> Are you hooked on the big AREDN test tunnel with around 600 stations?
>>  Right now I want both - the big tunnel worldwide and a nice quiet
>> local net with friends.  I picked up a Mikrotiq hAP (
>> https://amzn.to/3h80O1P ) for a full time tunnel server.   I may get a
>> second one so I can be on both networks.
> SFWEM.NET is local with about 60 nodes. Tunnels are a problem as they
> add too many nodes. —Sky
>>> —Sky
>>> —Amateur Radio AA6AX
>>> http://aa6ax.us/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20200720/9c622721/attachment.html>