Hi,

I'm new to MBSE - I've been playing with it for the last few days, and today I finally set it up as my "mail hub". I was a Sysop 25+ years ago (like many I learning), so I'm enjoying getting (back) into this community.

I started BBSing 2 weeks ago and have also a Mystic up and running.

Today, I changed my Mystic to be a point for the networks I'm connected with (Fido, FSX ...) with MBSE being the dot zero. While I havent fully tested everything, it appears that netmail is working fine (at least to my hub anyway).

What I'm having trouble with is echomail. I think the problem is with Mystic, but wanted ask here for a second opinion. Incoming netmail is being sent to my hub, however, when the hub opens the packet the source looks like below, and thus it is being tossed into bad mail because of the wrong source address:

+ 05-Sep-2018 16:10:48 mbfido[363] Execute: /usr/bin/unzip -o -j -L fec50000.we3
+ 05-Sep-2018 16:10:48 mbfido[363] Packet : 031ce02f.pkt type 2+
+ 05-Sep-2018 16:10:48 mbfido[363] From : 314:65535/180.1 to 314:314/180
+ 05-Sep-2018 16:10:48 mbfido[363] Dated : 05-10-2018 06:10:40
+ 05-Sep-2018 16:10:48 mbfido[363] Program : Unknown 0xfefe 0.0
+ 05-Sep-2018 16:10:48 mbfido[363] Node 314:65535/180.1 not connected to area PIN_ADMIN

The From address is definately set as 314:314/180.1 - however all my AKAs (in Mystic) are shown as x:65535/x.1 (where x is fidonet and fsxnet as well).

If I read the log correctly, does this mean Mystic is writing the wrong source address?

BTW: I'm running this all on a Pi in Docker - so I dont think that should be part of the problem. (My containers are available if anybody is interested.) I also built MBSE as a Debian deb (for both Pi and X86) if that helps. I probably
have some suggestions to improve the build process for "packaging" if that is of interest as well... (Although my experience of Debian is new, historically I've always used CentOS - but debian does make a small docker image :).

...deon



Greetings, Deon George

... A dirty book is rarely dusty.

--- MBSE BBS v1.0.7.6 (GNU/Linux-ARM)
* Origin: Chinwag | MBSE in Docker on Pi (3:633/509)

Hello Deon!

Thursday September 06 2018 01:08, you wrote to All:

What I'm having trouble with is echomail. I think the problem is with Mystic, but wanted ask here for a second opinion. Incoming netmail is
being sent to my hub, however, when the hub opens the packet the
source looks like below, and thus it is being tossed into bad mail
because of the wrong source address:

+ 05-Sep-2018 16:10:48 mbfido[363] Execute: /usr/bin/unzip -o -j -L fec50000.we3
+ 05-Sep-2018 16:10:48 mbfido[363] Packet : 031ce02f.pkt type 2+
+ 05-Sep-2018 16:10:48 mbfido[363] From : 314:65535/180.1 to
314:314/180 + 05-Sep-2018 16:10:48 mbfido[363] Dated : 05-10-2018 06:10:40 + 05-Sep-2018 16:10:48 mbfido[363] Program : Unknown 0xfefe
0.0 + 05-Sep-2018 16:10:48 mbfido[363] Node 314:65535/180.1 not
connected to area PIN_ADMIN

The From address is definately set as 314:314/180.1 - however all my
AKAs (in Mystic) are shown as x:65535/x.1 (where x is fidonet and
fsxnet as well).

If I read the log correctly, does this mean Mystic is writing the
wrong source address?

Yes that is exactly what looks to be the problem.
You have not correctly set up the correct addresses
Check what is your systems address in Mystic and if it is being passed to all echo and file areas as a 'From'.

Next is the addresses used on both correct as above shows 314:314 but your message to mbse sent from 3:633 (509) so just what is your address?

Needless to say 314: is not a valid Fidonet network address locator.


If you have not yet got a NODELIST entry for your system/s I suggest you do so as mbse could get confused by an invalid address how ever all that said that is
not the main problem which is that Mystic is not correctly set up.

Using a dummy address for this example with 314:314/n Mbse should be set up as
the primary system addresses of 3:314/n

The Mystic address as 3:314/n.1 if using it as a point with all uplink address for echos and files as per mbse (3:314/n). Mbse must have the downlink for Mystic system as 3:314/n.1 and also mbse must be set up with system address 3:314/n.

Mbse should be set up to autocreate new areas for echos per the docs and likewise if files are coming in ditto but here using FILEGATE.ZXX as the file list stored in the correct directory which get updated when ever a new one comes in from your (mbse) uplink.

In my case and normally it is ~/var/arealists and this is created using the file magic processing.

I.e., in 10.4
A. Copy file FILEGATE.ZXX
1. Magic Copy File
2. Filemask FILEGATE.ZXX
3. Active Yes
4. Deleted No
5. Area FG_WORF
6. To path /home/mbse/var/arealists
7. Compile No

Again in 10.4
B. Execute file FILEGATE.ZXX
1. Magic Execute
2. Filemask FILEGATE.ZXX
3. Active Yes
4. Deleted No
5. Area FG_WORF
6. Command dos2unix /home/mbse/var/arealists/FILEGATE.ZXX
7. Compile No


Note that the for above paths I use /home/mbse instead of /opt/mbse as I could boot to other distros or versions and I like to minimise my work.

This you can do when building mbse by the usage of configure prefix=path

where mine is --prefix=/home

Hope it helps,


Vince

--- Mageia Linux v6/Mbse v1.0.7.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hey Vince,

Vince Coen wrote to Deon George:

You have not correctly set up the correct addresses

Actually I have though. This example is for the 314 network (pinet) that I am connected to. My Mystic IS set for 314:314/180.1, but packets sent to MBSE (which is 314:314/180) appear to be from 314:65535/180.1.

The same is true for Fidonet Mystic IS configured for 3:633/509.1, but MBSE sees the from as 3:65535/509.1

I'm joining micronet, and I have Mystic as a Node 618:510/10, and MBSE as the Host 618/510/1 - and the from packets in this case are correct.

I do have nodelists installled, and a mbout n ... correctly shows my point one and my point zero.

For this Pinet Echo, the echo already exists in MBSE and my point 1 is already subscribed to it (netmail messages work - even though they too also report as From n:65535/x.1 in the PKT log).

Is there a PKT tool that I can use to break out and dump the packets to confirm
Mystic is sending them with the wrong From address, or if that is not
wrong, then it would point to an MBSE setup issue somewhere?

In my case and normally it is ~/var/arealists and this is created using the file magic processing.
...

Thanks for this, I was wondering how to do this part :)

...deon


Greetings, Deon George

... "640K ought to be enough for anybody." Bill Gates '81

--- MBSE BBS v1.0.7.6 (GNU/Linux-ARM)
* Origin: Chinwag | MBSE in Docker on Pi (3:633/509)

On 2018 Sep 06 06:56:18, you wrote to Vince Coen:

Actually I have though. This example is for the 314 network (pinet) that I am connected to. My Mystic IS set for 314:314/180.1, but packets sent to MBSE (which is 314:314/180) appear to be from 314:65535/180.1.

The same is true for Fidonet Mystic IS configured for 3:633/509.1, but

MBSE

sees the from as 3:65535/509.1

which PKT format are you sending from your mystic point to MBSE? it must be type 2+ or type 2.2 for point and/or domain support...

type 2.2 is the only one that allows for the 5D domain name in the PKT header...

type 2+ has certain fields, originzone and destinatiozone, that are duplicated but must be set a certain way when a point system is involved... the originnet and destinationnet fields are handled differently in this case... you problem description appears to show that MBSE is not properly reading the type 2+ PKTs from your point system...

easy solution? switch your mystic back to a full node... you can still keep your MBSE as a mail hub...

hard solution? fix MBSE's PKT handling code to properly handle Type 2+ PKTs from point systems... there is a paper written by one of the Synchronet guys, Stephen Hurd, that contains a lot of details about PKTs and how to handle them... this information about Type 2+ PKT handling is definitely detailed in that paper... i do not recall if the final version was presented to the FTSC for publishing, if the FTSC accepted it, or if the FTSC did actually publish it... i do recall that someone on the FTSC did make a move to get the paper presented to the FTSC but i do not recall that outcome of that, either...


[TIME PASSES]


i was able to go back through my mail archive and find some posts about the above document... draft 4 is available at http://bbsdev.net/fsp/FSP-1040.txt and i think it is the last draft... the details i speak of above are found in the notes portion of the document's section "3. Type 2+ Packet"... the first paragraph in that notes section explains why net 65535 is being seen in these PKTs and how to properly handle it...


)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... This is your train. This is your train with Botchmann. Any questions?
---
* Origin: (1:3634/12.73)

Re: Hi
By: mark lewis to Deon George on Thu Sep 06 2018 10:48 am

which PKT format are you sending from your mystic point to MBSE? it must be type 2+ or type 2.2 for point and/or domain support...

I don't think Mystic operators have a choice about which PKT type their node generates. According to my sbbsecho.log the PKT type I receive from my Mystic links is type 2e.

Ttyl :-),
Al


... Disclaimer: Advice void where prohibitted by common sense!
--- SBBSecho 3.06-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

mark lewis wrote to Deon George:

which PKT format are you sending from your mystic point to MBSE? it must be type 2+ or type 2.2 for point and/or domain support...

type 2.2 is the only one that allows for the 5D domain name in the PKT header...

I've done some research and cant see anything authoritative that it does. But MBSE does report this in the logs:

+ 06-Sep-2018 23:58:35 mbfido[1186] Packet : 03e04a78.pkt type 2+
+ 06-Sep-2018 23:58:35 mbfido[1186] From : 3:65535/509.1 to 3:633/509
+ 06-Sep-2018 23:58:35 mbfido[1186] Dated : 06-10-2018 13:58:27
+ 06-Sep-2018 23:58:35 mbfido[1186] Program : Unknown 0xfefe 0.0

Thats an indicator that it is a 2+ packet right? So does that mean my MBSE is not handling it correctly? I recall somewhere a config about 4d packets, need to look for that, perhaps that is the problem?

i was able to go back through my mail archive and find some posts about the above document... draft 4 is available at http://bbsdev.net/fsp/FSP-1040.txt and i think it is the last draft... the details i speak of above are found in the notes portion of the document's section "3. Type 2+ Packet"... the first paragraph in that notes section explains why net 65535 is being seen in these PKTs and how to properly handle it...

Awesome, I'll take a look.

Thanks...


Greetings, Deon George

... "640K ought to be enough for anybody." Bill Gates '81

--- MBSE BBS v1.0.7.6 (GNU/Linux-ARM)
* Origin: Chinwag | MBSE in Docker on Pi (3:633/509)

On 2018 Sep 06 11:55:32, you wrote to me:

which PKT format are you sending from your mystic point to MBSE? it
must be type 2+ or type 2.2 for point and/or domain support...

I don't think Mystic operators have a choice about which PKT type
their node generates. According to my sbbsecho.log the PKT type I
receive from my Mystic links is type 2e.

i think Type 2e is sbbsecho's indicator of FSC-0039 which is the first half of Type 2+... the document i pointed to as well as the synchronet wiki, IIR what i
read recently, should explain it better... that being mainly that the "2+" term was introduced with FSC-0048 which expanded on and clarified FSC-0039... FSC-0039 says it is an extension of Type 2...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... That's stronger than a garlic milkshake.
---
* Origin: (1:3634/12.73)

On 2018 Sep 07 09:32:44, you wrote to me:

Thats an indicator that it is a 2+ packet right?

yes...

So does that mean my MBSE is not handling it correctly?

i see only that it is reporting and apparently using the 65535 net address field and not pulling the true net address from the secondary field... i'm curious to see what others of the MBSE community have to say... something tells
me this is a known problem that is being worked on but i do not know what the status of that work is... i think andrew was working in this area...

I recall somewhere a config about 4d packets, need to look for that, perhaps that is the problem?

i do not know... i have not (yet) installed and played with MBSE...

i was able to go back through my mail archive and find some posts
about the above document... draft 4 is available at
http://bbsdev.net/fsp/FSP-1040.txt and i think it is the last
draft... the details i speak of above are found in the notes portion
of the document's section "3. Type 2+ Packet"... the first paragraph
in that notes section explains why net 65535 is being seen in these
PKTs and how to properly handle it...

Awesome, I'll take a look.

Thanks...

you are welcome...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... while [ true ] ; do story ; done
---
* Origin: (1:3634/12.73)

mark lewis wrote to Deon George:

i see only that it is reporting and apparently using the 65535 net address field and not pulling the true net address from the secondary field... i'm curious to see what others of the MBSE community have to say... something tells me this is a known problem that is being worked on but i do not know what the status of that work is... i think andrew was working in this area...

So I think I found it - and IMHO a bug.

I looked at lib/getheader.c, and and in getheader() I dont see where it handles
auxNet if origNet = 0xffff.

As per http://bbsdev.net/fsp/FSP-1040.txt, it states

When parsing a
Type 2+ packet, if origNet is 65535, the software MUST use the
value from the auxNet field.

So I put in this

if (capword & 0x0001) {

if (f->net == 65535) {
Syslog('+', "Point Packet : %d to %d", f->net, t->net);
f->net = buffer[0x26] + (buffer[0x27] << 8);
Syslog('+', "Net Changed : %d to %d", f->net, t->net);
}

And my packet was accepted by my node:

07-Sep-2018 11:34:22 mbfido[147] MBFIDO v1.0.7.6
07-Sep-2018 11:34:22 mbfido[147] Cmd: mbfido toss
+ 07-Sep-2018 11:34:22 mbfido[147] Pass: toss netmail (/opt/mbse/data/inbound) + 07-Sep-2018 11:34:22 mbfido[147] Point Packet : 65535 to 633
+ 07-Sep-2018 11:34:22 mbfido[147] Net Changed : 633 to 633
+ 07-Sep-2018 11:34:22 mbfido[147] Packet 2+ : 3 to 3
+ 07-Sep-2018 11:34:22 mbfido[147] Packet : 0433cb8c.pkt type 2+
+ 07-Sep-2018 11:34:22 mbfido[147] From : 3:633/509.1 to 3:633/509
+ 07-Sep-2018 11:34:22 mbfido[147] Dated : 07-10-2018 01:23:53
+ 07-Sep-2018 11:34:22 mbfido[147] Program : Unknown 0xfefe 0.0

I havent check if this point handling is handled anywhere else though - but could this be a fix? Is sharing that here enough for it to be reviewed?

BTW: It seems the sourceforge code repositoriy is back level (1.0.7.3) - whereas the download zip file is 1.0.7.6?

...deon


Greetings, Deon George

... "Luke... Luke... Use the MOUSE, Luke" - Obi Wan Gates

--- MBSE BBS v1.0.7.6 (GNU/Linux-ARM)
* Origin: Chinwag | MBSE in Docker on Pi (3:633/509)

Hello Deon!

07 Sep 18 11:46, you wrote to mark lewis:

So I think I found it - and IMHO a bug.

I looked at lib/getheader.c, and and in getheader() I dont see where
it handles auxNet if origNet = 0xffff.

It currently doesn't. I'll be fixing this very shortly.

I havent check if this point handling is handled anywhere else though
- but could this be a fix? Is sharing that here enough for it to be reviewed?

As the primary maintainer of late, I can assure you it's already being reviewed.

BTW: It seems the sourceforge code repositoriy is back level (1.0.7.3)
- whereas the download zip file is 1.0.7.6?

The git repository on SourceForge needs to be updated; the Hg (Mercurial) repository should be current (1.0.7.7 ATM) -- I will bring it up to date when I commit your fix.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

On 09/07/18, Andrew Leary said the following...

The git repository on SourceForge needs to be updated; the Hg
(Mercurial) repository should be current (1.0.7.7 ATM) -- I will bring
it up to date when I commit your fix.

Great! Do you announce here when you do that?

How do you get to the Mercurial repository? I dont know Mercurial (I do know git), but I am curious to see what's changed since 1.0.7.6.

...deon

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Chinwag | MysticBBS in Docker! (3:633/509.1)

On 09/07/18, Andrew Leary said the following...

As the primary maintainer of late, I can assure you it's already being reviewed.

I thought I would ask - any chance the makefiles can be updated to support $DESTDIR? So that anybody who wants to package it up (like I do to make a
DEB), dont need to apply a patch ;)

No big deal, but thought it would be a benefit to more, and shouldnt impact anybody who dont build packages.

I'd also like to recommend that the binaries be changed to be 500 not 700 (ie: they shouldnt be writable) as well...

...deon

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Chinwag | MysticBBS in Docker! (3:633/509.1)

Hello Deon!

07 Sep 18 06:45, you wrote to me:

Great! Do you announce here when you do that?

I haven't always in the past, but it certainly won't hurt anything.

How do you get to the Mercurial repository? I dont know Mercurial (I
do know git), but I am curious to see what's changed since 1.0.7.6.

1.0.7.7 added support for DORINFO1.DEF doors. 1.0.7.8 will fix your incoming point packet issue.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Deon!

07 Sep 18 07:00, you wrote to me:

I thought I would ask - any chance the makefiles can be updated to
support $DESTDIR? So that anybody who wants to package it up (like I
do to make a DEB), dont need to apply a patch ;)

I'll look into that before the next major release.

No big deal, but thought it would be a benefit to more, and shouldnt impact anybody who dont build packages.

I'd also like to recommend that the binaries be changed to be 500 not
700 (ie: they shouldnt be writable) as well...

Good point; there's no reason that they need to be writable. Added to my list.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)