On 09-05-18 21:35, deon wrote to All <=-
It appears as if the packet has the wrong source address in it.
According to the MBSE debug log:
+ 05-Sep-2018 15:09:23 mbfido[280] Execute: /usr/bin/unzip -o -j -L fffd0000.we0
+ 05-Sep-2018 15:09:23 mbfido[280] Packet : 03171718.pkt type 2+
+ 05-Sep-2018 15:09:23 mbfido[280] From : 21:65535/116.1 to
21:2/116 + 05-Sep-2018 15:09:23 mbfido[280] Dated : 05-10-2018
05:07:28 + 05-Sep-2018 15:09:23 mbfido[280] Program : Unknown 0xfefe
0.0 + 05-Sep-2018 15:09:23 mbfido[280] Netmail from "Deon George of 21:2/116.1" to "deon of 21:2/116"
If you look at the second line, the packet has a source address of 21:65535/116.1 (when it is configured in Mystic has 21:2/116.1). So
while this netmail came into MBSE - if it was an echomail, it would
have been rejected with "Node 21:65535... not connected to area ...".
So, I'm confident this is an issue with Mystic and not with MBSE - next step would be to find a tool to read the pkt before MBSE takes it, but wanted to check if anybody used Mystic as a point?
I do have my Mystic BBS as a point in Fidonet (didn't want to bother getting a node for access to one echo) off my Synchronet BBS. I haven't seen any issues with addressing, and I'm sure the Fido gods would have complained if I did have such issues. I've been running this configuration for a year or so with no issues.
I do have my Mystic BBS as a point in Fidonet (didn't want to bother getting a
node for access to one echo) off my Synchronet BBS. I haven't seen any issues
with addressing, and I'm sure the Fido gods would have complained if I did have
I'm part of 3 networks (fido, fsx, pinet) and each, the packet as
opened in mbse is x:65535/n.1 - so I'm confident its not finger
trouble.
On 09-05-18 19:11, Bucko wrote to Vk3jed <=-
And I do the opposite, I run Mystic as the main node and point my SynchroNet.. Works great.. No issues at all. Except idiot (oops) I
mean operator error on my part..
On 09-06-18 14:33, deon wrote to Vk3jed <=-
Vk3jed wrote to deon:
I do have my Mystic BBS as a point in Fidonet (didn't want to bother getting a
node for access to one echo) off my Synchronet BBS. I haven't seen any issues
with addressing, and I'm sure the Fido gods would have complained if I did have
Hmm.. Is this on your *Pi?
I'm part of 3 networks (fido, fsx, pinet) and each, the packet as
opened in mbse is x:65535/n.1 - so I'm confident its not finger
trouble.
Looks like I'll spin up a test mystic and play (docker makes that easy
;)
I do have my Mystic BBS as a point in Fidonet (didn't want to bother getting a
node for access to one echo) off my Synchronet BBS. I haven't seen any issues
with addressing, and I'm sure the Fido gods would have complained if I did have
such issues. I've been running this configuration for a year or so with
no
issues.
od -A x -t x1z < [x].pkt
Might be a good idea to capture a packet and see if the net field is actually what MBSE thinks it is. Mystic is pretty well tested on ARM, and
I would be surprised if it's creating dodgy packets.
apam wrote to deon:
Might be a good idea to capture a packet and see if the net field i actually what MBSE thinks it is. Mystic is pretty well tested on AR
I would be surprised if it's creating dodgy packets.
I did, and the source net is incorrect set to 0xffff... :(
I knew I'd seen this come up before, I just couldn't remember what it was lol. Perhaps you could try and switch to type 2 packets and see if MBSE
can handle that?
Do you mean tell Mystic to use type 2 packets? There is no way to do
that as far as I can tell...
I'm confused though. In the logs MBSE reports it as a 2+ packet, but
then why is it pulling the source net (origNet) from the wrong field.
It should use the auxNet field right?
apam wrote to deon:
I knew I'd seen this come up before, I just couldn't remember what itwas
lol. Perhaps you could try and switch to type 2 packets and see if MBSE can handle that?
On 09-06-18 22:44, deon wrote to Vk3jed <=-
Hmm.. looks to me to be a Mystic issue - I guess with my setup?
Hmm.. looks to me to be a Mystic issue - I guess with my setup?
Interesting. :) Will have to check at some stage, system is down right now, just doing a full SD backup, so I have an up to date OS image, when
I replace the SD card, which is now a routine procedure to ensure the system stays more or less up. Should be back up in 30 mins. :)
On 09-07-18 11:10, Deon George wrote to Vk3jed <=-
Actually, I worked it out, and it isnt a Mystic issue - but an MBSE
issue.
I tracked down the FTSC document about mail pkts, and while Mystic was correctly setting a source network as 65535, because it was coming from
a point, MBSE was not looking in the alternative place for the correct source network address (and Mystic was storing it there correctly).
I've made Andrew (prime developer) aware, and it will make it in
1.0.7.8, but until then I have a patch if needed.
1.0.7.8, but until then I have a patch if needed.
Cool, good to help people sqush bugs. :)
On 09-07-18 11:53, Deon George wrote to Vk3jed <=-
On 09/07/18, Vk3jed said the following...
1.0.7.8, but until then I have a patch if needed.
Cool, good to help people sqush bugs. :)
Andrew just released 1.0.7.8 - so I've built both a debian DEB and
docker image if anybody is interested...
On 09-07-18 11:10, Deon George wrote to Vk3jed <=-
Actually, I worked it out, and it isnt a Mystic issue - but an MBSE issue.
Yeah saw that in later messages. :)
I tracked down the FTSC document about mail pkts, and while Mystic was correctly setting a source network as 65535, because it was coming from a point, MBSE was not looking in the alternative place for the correct source network address (and Mystic was storing it there correctly).
Yeah I would have been surprised if it was a Mystic bug, because I've never seen the issue, and I've been using Mystic as a point.
I've made Andrew (prime developer) aware, and it will make it in 1.0.7.8, but until then I have a patch if needed.
Cool, good to help people sqush bugs. :)
On 09-07-18 19:45, Digital Man wrote to Vk3jed <=-
There are two conflicting definitions of the so-called "2+" packet
definition in FTSC documents (FSC-39 and FSC-48), so I've dubbed the FSC-39 format as "2e" (and support both 2+ and 2e in SBBSecho) and published the details here: http://wiki.synchro.net/ref:fidonet_packets
There are two conflicting definitions of the so-called "2+" packet definition in FTSC documents (FSC-39 and FSC-48), so I've dubbed the FSC-39 format as "2e" (and support both 2+ and 2e in SBBSecho) and published the details here: http://wiki.synchro.net/ref:fidonet_packets
Maybe that'll help,
On 09/07/18, Digital Man said the following...
There are two conflicting definitions of the so-called "2+" packet definition in FTSC documents (FSC-39 and FSC-48), so I've dubbed the FSC-39 format as "2e" (and support both 2+ and 2e in SBBSecho) and published the details here: http://wiki.synchro.net/ref:fidonet_packets
Maybe that'll help,
Ahh, that explains a lot, thank you.
I dont understand the purpose of the auxnet field - and why the original orignet field cannot be used for all these different versions of packets. I'm curious what was being solved by adding an auxnet field.
Strictly Type-2 packet parsers would ignore the origPoint field of the packet header (it was just a portion of the reserved/fill area). So if
the originator was a point (say, for example, 1:2/3.4), a strictly
Type-2 packet parser would think the packet originator was actually
1:2/3 (the "boss node") and this could cause problems ...
On 09/08/18, Digital Man said the following...
Strictly Type-2 packet parsers would ignore the origPoint field of the packet header (it was just a portion of the reserved/fill area). So if the originator was a point (say, for example, 1:2/3.4), a strictly Type-2 packet parser would think the packet originator was actually 1:2/3 (the "boss node") and this could cause problems ...
Ahh, ok, I get it now.
So are there any thoughts to releasing an updated spec - say one that now handles 5D packets with a hope that the (appearingly active) BBS community change over to it? Then all this fudging would go away right?
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 31 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 245:55:11 |
| Calls: | 2,090 |
| Calls today: | 1 |
| Files: | 11,140 |
| Messages: | 948,901 |