Subj : pkt viewer
To   : Alan Ianson
From : mark lewis
Date : Tue May 24 2016 12:31 pm


23 May 16 15:52, you wrote to me:

ml>> my tool says that it is a type 2+ PKT...

AI> That's good to know.. we were uncertain but James had thought so. That pkt
AI> does toss OK but mystic logs that it comes from 1:65535/757 but it's
really
AI> 1:153/757.1.

that's because he's not looking at the proper field for the net address...
there are two originating network fields in the type 2+ format... one must look
in the second field based on certain data aspects of other fields used... i
forget the details but Stephen Hurd (aka Deuce) of Synchronet BBS fame has
written a proposal (FSP-1040 IIRC) and posted it to the FTSC_PUBLIC area... his
proposal covers the PKTs and explains a lot of details... his document is based
on Type 2 (FTSC-0001) and how the others are different from it... my tool, for
instance, works slightly backwards from his proposal in that it assumes a PKT
is a Type 2+ format... if certain specific values are 0 (zero) and the ""baud""
is 2 then we have a Type 2.2 (FSC-0045) PKT... if any of those values are
wrong, we look at the capability word... if it is 0 (zero), then we have a Type
2 (FTSC-0001) PKT... otherwise if the capability word is 1 (one) and the baud
is not 2 we have a Type 2+ (FSC-0039) PKT...

AI> If I add a password to that pkt Mystic says invalid password and
AI> doesn't toss it. Do you have any idea why that would happen? Something
AI> seems just a bit off but I don't know what.

because the net address is 65535 instead of 153... if the originating system is
a point system. the orignet field is set to 65535 and the actual originating
net is found in the auxnet field... i think this was done because of the
pointnet stuff that uses a fake net number to create 3D pointnets instead of
having an actual 4D point number in the address... this was all back when there
wasn't any 4D capable stuff to hold the point address so they slid things left
a tad... i'm kinda leaning to the idea that pointnets started back when FTN
addresses were only 2D so there wasn't anywhere to store a point number
anyway...

eg:
1:153/715.0   ==  1:10295/0
1:153/715.5   ==  1:10295/5
1:153/715.12  ==  1:10295/12
1:153/715.20  ==  1:10295/20
1:153/715.42  ==  1:10295/42

like net numbers, pointnet numbers were assigned following some formula... i'm
not real sure but i think that any net address 10000 or higher was a pointnet
and the point number became the node number as seen above... note that i used
1:153/715 because i know that Dallas still does pointnet stuffs and it was easy
enough to find one of his entries in my logs for a valid pointnet address... so
in 2D format, 153/715 became 10295 in the pointnet format...

AI> There have also been problems with pkt files from/to daydream, they
AI> seem more problematic but I have not seen any of those.

AI> Can I pick your brain for a minute? O:-)

it might be messy...

AI> What pkt type are there in use today? I have heard of Type-2, 2+ and
AI> 2.2. Is that it or are there more?

the type 2 family is all there is in use... Type 2 aka Type 2.0 (FTS-0001),
Type 2+ (FSC-0039 and FSC-0048) and Type 2.2 (FSC-0045)... Type 2+ may be
problematic as there's the plain FSC-0039 form and then there's the modified
one that adds FSC-0048 for additional validation checking that it is a Type 2+
PKT... this was done because of various incompatible Type 3 proposals that
never went anywhere... there is/was also a Type 10 packet proposal but it also
never went anywhere...

here's the notes portion of section 3 of stephen's section proposal... this is
just the one part that covers the origNet and auxNet fields...

===== snip =====
 Notes:
 auxNet
   If origNet is 65535 (0xffff), indicates that the originator is a
   point, and the originating network can be found in this field.
   Some old software may not follow this convention, so the network
   number may be found in either of the two fields.  When parsing a
   Type 2+ packet, if origNet is 65535, the software MUST use the
   value from the auxNet field.  When creating a packet, if the
   originating system is a point, it SHOULD set origNet to 65535 and
   put the net number in this field.  In the case where the originating
   net is 65535 (As recommended by Policy 4), it SHOULD be placed in
   both origNet and auxNet.
===== snip =====

)\/(ark

Always Mount a Scratch Monkey

... It's no secret a man's conscience can sometimes be a pest.
---
* Origin:  (1:3634/12.73)