[nos-bbs] ".bbs" appended on return addresses
Sky
sky at aa6ax.us
Mon Jul 20 18:35:26 EDT 2020
More info.
JNOS manual says
*bulletin return [on | OFF]*
Displays or sets how a message's return address is obtained. If ON,
the return address is obtained from the last R: header line when
available. If OFF, sender%forwarding.bbs at mycall is used. Note that
for the mailbox SR (send-reply) command to work, the system's
rewrite file must be capable of handling the '%' symbol. A
recommended rewrite rule is: *%*@YOURCALL* $1@$2 r
Note that I have it OFF normally. However, if I turn bulletin-return ON
I get return addresses of the form AA6AX@ (nothing after the 'at') which
clearly doesn't work either. So that's not going to be a complete solution.
I'm fully willing to admit that this might be caused by having two JNOS
stations talking to each other, but I think that should be possible.
Most of the time my station talks to ARY-based BBS's, and messages go
flying around with no problem. And our two JNOS-based stations can talk
to the other BBS's and exchange messages just fine. It only fails when
they talk to each other directly.
—Sky
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Sky" (Jim Schuyler)
—Amateur Radio AA6AX
http://aa6ax.us/
On 7/20/20 12:28 PM, Sky via nos-bbs wrote:
>
> 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/
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/nos-bbs_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20200720/29cbf1bf/attachment-0001.html>
More information about the nos-bbs
mailing list