Attention Doctor,

The last netmail got through to the uplink but still no response so now an echomail to ASIAN_LINK with a nonconforming pktheader since the uplink cannot support a proper fts-0001.016 compliant pktheader ... or at least it couldn't before the latest breakage. Note that this echomail was sent with unbounded paragraphs so if this MSG finds it's way it can be scanned for planted linefeeds by noncompliant tossers along it's path.

End transmission.

... Newton's Little-known Seventh Law:
A bird in the hand is safer than one overhead.
--- GNU bash, version 4.4.19(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: jumpin' jack flash
By: Little Mikey to Doctor Flexy Jerkoff on Fri Apr 20 2018 10:14 pm

Attention Doctor,

The last netmail got through to the uplink but still no response so now an echomail to ASIAN_LINK with a nonconforming pktheader since the uplink cannot support a proper fts-0001.016 compliant pktheader ... or at least it couldn't before the latest breakage. Note that this echomail was sent with unbounded paragraphs so if this MSG finds it's way it can be scanned for planted linefeeds by noncompliant tossers along it's path.

End transmission.

Recieved here just now. A couple days in transit but it arrived.. :)

Ttyl :-),
Al


... The worst thing about censorship is ÛÛÛÛÛÛÛÛÛÛ.
--- SBBSecho 3.04-Linux
* Origin: The Rusty MailBox - Penticton, BC trmb.synchro.net (1:153/757)

Attention Alan,

Recieved here just now. A couple days in transit but it arrived..

Now this is REALLY confusing as the first two tests just got resent, and if you
are replying to the original test, then if the uplink cannot handle a regular fts-0001.016 compliant pktheader it should show up later without the first test
(the one you just replied to) as it will be a dupe in that pkt. Hopefully that
will tell the tale and eleviate the confusion.

Also I sent out a third test that if it doesn't show up here should confirm that the uplink in question indeed cnnot process fts-0001.016 compliant pktHeaders ... or whatever the kids are calling them these days.

For the record this reply is being sent to an uplink that CAN handle fts-0001.016 compliant pktHeaders as this reply should confirm.

End transmission.

... Gerrold's Laws of Infernal Dynamics:
1. An object in motion will always be headed in the wrong direction.
2. An object at rest will always be in the wrong place.
3. The energy required to change either one of the states will always be
more than you wish to expend, but never so much as to make the task
totally impossible.
--- GNU bash, version 4.4.19(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: jumpin' jack flash
By: Little Mikey to Alan Ianson on Mon Apr 23 2018 02:49 am

Now this is REALLY confusing as the first two tests just got resent, and if you are replying to the original test, then if the uplink cannot handle a regular fts-0001.016 compliant pktheader it should show up later without the first test (the one you just replied to) as it will be a dupe in that pkt. Hopefully that will tell the tale and eleviate the confusion.

I only see the one message here so if there were more than one transmissions I can only tell you that I replied to the one I received!

The one I replied to has a path of 153/7001 7715, and the message I am replying to now has a path of 153/7001 154/10 (and a few others).

Also I sent out a third test that if it doesn't show up here should confirm that the uplink in question indeed cnnot process fts-0001.016 compliant pktHeaders ... or whatever the kids are calling them these days.

For the record this reply is being sent to an uplink that CAN handle fts-0001.016 compliant pktHeaders as this reply should confirm.

Confirmed. sbbsecho logs pkt files received from 153/7715 as being type 2+. Is that different than fts-0001.016?

Ttyl :-),
Al


... It's not the money I want, it's the stuff.
--- SBBSecho 3.04-Linux
* Origin: The Rusty MailBox - Penticton, BC trmb.synchro.net (1:153/757)

Attention Alan,

I only see the one message here

Understood. A couple additional tests have been sent since your initial reply to alleviate confusion but they may end up causing greater numbers of 'senior moments' in this neck of the woods. :-/

Confirmed. sbbsecho logs pkt files received from 153/7715 as being
type 2+. Is that different than fts-0001.016?

There is no such thing as type 2, type 2+ or any other type of pktHeader in fts-0001.016. Like the Highlander, there can be only one, and it definetly isn't a type 2+ header which makes sbbsecho fts-0001.016 non-compliant ... not to mention the excess linefeeds in the body of the message ... or the obviously
corrupted MSGID, not that it has anything to do with fts-0001.016. :::wink, wink, knudge, knudge, say no more:::

End transmission.

... Preudhomme's Law of Window Cleaning: It's on the other side.
--- GNU bash, version 4.4.19(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: jumpin' jack flash
By: Little Mikey to Alan Ianson on Mon Apr 23 2018 04:34 am

There is no such thing as type 2, type 2+ or any other type of pktHeader in fts-0001.016. Like the Highlander, there can be only one, and it definetly isn't a type 2+ header which makes sbbsecho fts-0001.016 non-compliant ... not to mention the excess linefeeds in the body of the message ... or the obviously corrupted MSGID, not that it has anything to do with fts-0001.016. :::wink, wink, knudge, knudge, say no more:::

sbbsecho will create what it calls type 2 (Stone Age!) FTS-0001.16 packets although it defaults to type 2+ (4D address support) FSC-0048.02 packets. There is also type 2e and 2.2 to choose from.

I don't think I have received anything other than 2+ packets so I don't know what would happen if I tried to toss one.

Ttyl :-),
Al


... Do you like me for my brain, or my BAUD?
--- SBBSecho 3.04-Linux
* Origin: The Rusty MailBox - Penticton, BC trmb.synchro.net (1:153/757)

Hey Alan!

I thought I'd switch back to myself for replies and leave the "Little Mikey" ones for testing if and when needed. I think I've confused myself enough for awhile and I don't seem to be gaining any insight.

it defaults to type 2+ (4D address support)

Understood. I believe it was around the turn of the century when I noticed they were becoming the majority and a few years later that the standardized pktheader was becoming unsupported by the majority of nodes. Not sure if the sysops of those nodes were actually aware of the change in many cases. If the only reason for the change was to support 4D addressing it appears not to have worked as far as creating additional usage of fidonet echomail. I played around with it for a number of years and wasn't all that fond of it, other than
it beat offline messaging especially the QWK format.

Anyhow I am done testing for now and am not convinced I achieved anything in the process. I am starting to think it might have been better to let sleeping dogs lie. Oh well ... live and learn eh?

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.19(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 2018 Apr 22 21:24:30, you wrote to Little Mikey:

For the record this reply is being sent to an uplink that CAN handle
fts-0001.016 compliant pktHeaders as this reply should confirm.

Confirmed. sbbsecho logs pkt files received from 153/7715 as being
type 2+.

unfortunately, you can only see what PKTs your links send you... with echomail,
each link creates new PKTs as the echo messages are packed for others... so you
can't see what PKT format li'l mickey sent out unless you get one directly from
him...

Is that different than fts-0001.016?

yes, very...
FTS-0001 is PKT 2[.0]...
FSC-0039 is PKT 2+
FSC-0045 is PKT 2.2...
FSC-0048 refines FSC-0039 and clarifies some aspects...

2[.0] does not do points or domains...
2+ does not do domains...


==== Begin "READPKT.PAS" ====
program readpkt;

{
purpose:
to read the header information in FIDO .PKT files. this is to
help determine what information is in them.
}

[...]

type
bulkheader = array[0..57] of byte;
pkthead1 = record {Type 2+ FSC-0039/48}
orgnode : word;
dstnode : word;
year : integer;
month : integer;
day : integer;
hours : integer;
minutes : integer;
seconds : integer;
baud : integer;
pktver : integer;
orgnet : word;
dstnet : word;
prdcodl : byte;
pvmajor : byte;
password : array[0..7] of char;
qorgzone : integer;
qdstzone : integer;
auxnet : word;
capval : word;
prdcodh : byte;
pvminor : byte;
capword : word;
origzone : integer;
destzone : integer;
origpoint : integer;
destpoint : integer;
proddata : array[0..3] of char;
end;

pkthead2 = record {Type 2.0 FTS-0001}
orgnode : integer;
dstnode : integer;
year : integer;
month : integer;
day : integer;
hours : integer;
minutes : integer;
seconds : integer;
baud : integer;
pktver : integer;
orgnet : word;
dstnet : word;
prdcode : byte;
pvmajor : byte;
password : array[0..7] of char;
qorgzone : integer;
qdstzone : integer;
filler : array[0..19] of char;
end;

pkthead3 = record {Type 2.2 FSC-0045}
orignode : integer;
destnode : integer;
origpoint : integer;
destpoint : integer;
reserved : array[0..7] of char;
pktsubver : integer;
pktver : integer;
orignet : word;
destnet : word;
prdcod : byte;
prdrev : byte;
password : array[0..7] of char;
origzone : integer;
destzone : integer;
origdom : array[0..7] of char;
destdom : array[0..7] of char;
proddata : array[0..3] of char;
end;

[...]

var
bheader : bulkheader;
header1 : pkthead1 absolute bheader;
header2 : pkthead2 absolute bheader;
header3 : pkthead3 absolute bheader;

[...]
==== End "READPKT.PAS" ====

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Autocorrect has maid me say thongs I didn't Nintendo.
---
* Origin: (1:3634/12.73)

On 2018 Apr 23 04:34:30, you wrote to Alan Ianson:

Confirmed. sbbsecho logs pkt files received from 153/7715 as being
type 2+. Is that different than fts-0001.016?

There is no such thing as type 2, type 2+ or any other type of pktHeader

in

fts-0001.016.

really? type 2[.0] is definitely defined in there... Section F, subsection 1...

Like the Highlander, there can be only one, and it definetly isn't a
type 2+ header which makes sbbsecho fts-0001.016 non-compliant ...

1:153/7715 doesn't run sbbs or sbbsecho...

not to mention the excess linefeeds in the body of the message ...

and here we thought you were old-school... the old-school way is forced right-hand margins with CRLF on each line...

or the obviously corrupted MSGID,

sbbsecho's MSGID is not corrupt... it just doesn't match some template that some fidonet folks think it should...

not that it has anything to do with fts-0001.016. :::wink, wink,
knudge, knudge, say no more:::

true...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Blood is thicker than water - and much tastier.
---
* Origin: (1:3634/12.73)

Attention mark,

really? type 2[.0] is definitely defined in there...

Indeed. However no mention of any other type except type 1 which fts-0001.016 declares to be obsolete.

1:153/7715 doesn't run sbbs or sbbsecho...

The reply was to 1:153/757.

and here we thought you were old-school... the old-school way is
forced right-hand margins with CRLF on each line...

type 1? A reference would have been nice. As for CRLF, those are even more excessive than just a single LF. Old school only requires a single CR but then
again that depends on where one gets schooled and of course doesn't apply when speaking fts-0001.016. As for right-hand margins that requires even more wasted bytes in a packed message. They certainly aren't required for display if one considers inserting them at the start of each line, which of course is variable depending on the hardware the message(s) get written to.

sbbsecho's MSGID is not corrupt... it just doesn't match some
template that some fidonet folks think it should...

Reference? fts-0009.001 claims;

^AMSGID: origaddr serialno

where origaddr constitutes a valid return address for the originating network.
If indeed fts-0001.016 is to be considered the defacto standard for Fidonet messaging then the origaddr would be 1:153/757 in this case.

End transmission.

... Teslacle's Deviant to Fudd's Law:
Half of what goes in here must come out there.
--- GNU bash, version 4.4.19(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 2018 Apr 23 14:35:20, you wrote to me:

really? type 2[.0] is definitely defined in there...

Indeed. However no mention of any other type except type 1 which fts-0001.016 declares to be obsolete.

right... but the original statement said there was no packet types defined in the document...

1:153/7715 doesn't run sbbs or sbbsecho...

The reply was to 1:153/757.

that wasn't apparent...

and here we thought you were old-school... the old-school way is
forced right-hand margins with CRLF on each line...

type 1? A reference would have been nice.

the format of the packed messages doesn't have anything to do with the PKT type
;)

As for CRLF, those are even more excessive than just a single LF. Old school only requires a single CR but then again that depends on where
one gets schooled and of course doesn't apply when speaking
fts-0001.016.

i'm speaking of old-school programs that have been used in fidonet since forever...

As for right-hand margins that requires even more wasted bytes in a
packed message. They certainly aren't required for display if one considers inserting them at the start of each line, which of course is variable depending on the hardware the message(s) get written to.

at one time, the huge majority of messages being carried in fidonet had line terminators on every line... that's the "forced right margins" i speak of... in
recent times, we've seen them forced to less than 40 places because someone was
posting from a phone device... the majority of those messages from the heyday were posted via offline mail systems like QWK or bluewave... i'm not talking about what the specs call for... only what the programs are emitting... it took
until the '90s before forced EOLs were being dropped in a majority of FTN compliant software... we still see a lot of it, though... even your posts fail to take all of my 199 column screen width which they should if there're no forced right margins...

sbbsecho's MSGID is not corrupt... it just doesn't match some
template that some fidonet folks think it should...

Reference? fts-0009.001 claims;

sbbsecho does not claim to support fts-0009 so it does not apply...

^AMSGID: origaddr serialno

where origaddr constitutes a valid return address for the originating network. If indeed fts-0001.016 is to be considered the defacto standard for Fidonet messaging then the origaddr would be 1:153/757 in this case.

that depends on the definition of "valid return address for the originating network"... the data that sbbsecho puts in its msgid lines has enough detail to
take you back to the actual message base and specific message number... the standard FTN msgid can only get you to the node... besides, the node number is in the MSGID line from sbbsecho... we won't even mention that the spec doesn't say that there cannot be more data given in the origaddr part... nor will we mention that the MSGID is not supposed to be parsed or used for anything other than message linking and duplicate detection...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Gravity is the chief cause of airplane crashes.
---
* Origin: (1:3634/12.73)

Attention mark,

the format of the packed messages doesn't have anything to do
with the PKT type ;)

True, but if the pktheader is rejected because the link cannot handle a certain
pktheader type then the formatting of the packed message(s) becomes irrelevant.

Speaking for 1:153/7001 the issue has been resolved despite any misgivings and regrets it has caused anyone, especially the nodelisted sysop of 1:153/7001. He did state that he would end up regretting this and that prediction has proved itself to be 100% accurate.

Again thank you for your kind attention in this most sensitive matter.

End transmission.

... Anthony's Law of Force: Don't force it, get a larger hammer.
--- GNU bash, version 4.4.19(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 2018 Apr 25 16:33:40, you wrote to me:

the format of the packed messages doesn't have anything to do with
the PKT type ;)

True, but if the pktheader is rejected because the link cannot handle
a certain pktheader type then the formatting of the packed message(s) becomes irrelevant.

true BUT there really isn't any reason for PKTs to be rejected... their headers
are all the same size and the "2" part of the PKT header which indicates the PKT is a type 2 or Type 2 variant is in the same place in all of them... one could simply determine if the PKT is a Type 2 variant and then skip the header entirely to process the messages themselves since they carry most all of the necessary data anyway... those that do not have certain needed data can be sidelined for the operator to deal with...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Brains are such offal food.
---
* Origin: (1:3634/12.73)

Attention mark,

there really isn't any reason for PKTs to be rejected

Doesn't really matter whether or not there is a good reason if indeed they are being rejected.

one could simply determine if the PKT is a Type 2 variant and
then skip the header entirely

The entire pktheader is ignored here. There is absolutely nothing there that is of any consequence.

those that do not have certain needed data can be sidelined for
the operator to deal with...

Understood. Near as can be determined here is that the entire pktheader as well as the first 14 bytes of the msgheader can be safely sent to the bitbucket
as completely useless data to both humans and machines. Unfortunetly the same
cannot be said for links.

End transmission.

... Newton's Little-known Seventh Law:
A bird in the hand is safer than one overhead.
--- GNU bash, version 4.4.19(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)