• Bad packets

    From Deon George@3:633/509 to All on Fri May 29 23:21:49 2020
    Howdy,

    I've noticed sometimes that hpt is packing the same packet to multiple destinations. On this particular occasion, the packet was sent to 2/116 which was rejected by Synchronet. Wondering if anybody has any ideas.

    Here is an exerpt from the log:

    1 20:04:45 Start
    1 20:04:45 Start tossing...
    7 20:04:45 pkt: /fido/mailer/in/b42e21b8.tos [21:3/101]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c00.pkt created for [21:1/100]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c01.pkt created for [21:2/100]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c02.pkt created for [21:4/100]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c03.pkt created for [21:2/116]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c04.pkt created for [21:3/102]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c05.pkt created for [21:3/104]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c06.pkt created for [21:3/103]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c07.pkt created for [21:3/105]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c08.pkt created for [21:3/999]
    M 20:04:46 pktFile /fido/mailer/out.tmp/d0de9c09.pkt created for [21:3/106] ...
    M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:3/104 via 21:3/104]
    7 20:04:46 Packing for 21:3/104 Ioram Sette, d0de9c05.pkt > ce84ee01.th0
    6 20:04:46 cmd: arj a -+ -e -y /fido/mailer/out.015/ce84ee01.th0 /fido/mailer/out.tmp/d0de9c05.pkt

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:3/102 via 21:3/102]
    7 20:04:46 Leave non-packed mail for 21:3/102 Oliver Thuns, d0de9c04.pkt

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:4/100 via 21:4/100]
    7 20:04:46 Packing for 21:4/100 Hub, d0de9c02.pkt > d0de9c03.fr0
    6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c03.fr0 /fido/mailer/out.tmp/d0de9c02.pkt

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:3/105 via 21:3/105]
    7 20:04:46 Packing for 21:3/105 Les Wade, d0de9c07.pkt > d0669506.fr0
    6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0669506.fr0 /fido/mailer/out.tmp/d0de9c07.pkt

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:2/116 via 21:2/116]
    7 20:04:46 Packing for 21:2/116 Alterant, d0de9c03.pkt > d0de9c04.fr0
    6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c04.fr0 /fido/mailer/out.tmp/d0de9c03.pkt

    Notice that the packet d0de9c03.fr0 is created for multiple destinations in the same invocation of toss. Is this right?

    ...ëîåï

    ... You've got to miss them to score sometimes.
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Michael Dukelsky@2:5020/1042 to Deon George on Fri May 29 18:46:42 2020
    Hello Deon,

    Friday May 29 2020, Deon George wrote to All:

    I've noticed sometimes that hpt is packing the same packet to multiple destinations.

    Did you run tparser?

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Alan Ianson@1:153/757 to Deon George on Fri May 29 13:40:38 2020
    Hello Deon,

    Notice that the packet d0de9c03.fr0 is created for multiple
    destinations in the same invocation of toss. Is this right?

    That would certainly be a problem but I have not seen that here.

    I just scanned out a message and I can see that each outbound bundle was created with a new filename, each incremented by 1.

    If a node has mail waiting in the outbound new mail will be added to it but new outbound bundles all have a new and unique filename.


    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Deon George on Fri May 29 14:08:28 2020
    Hello Deon,

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:3/104 via 21:3/104] 7 20:04:46 Packing for 21:3/104 Ioram Sette, d0de9c05.pkt > ce84ee01.th0 6 20:04:46 cmd: arj a -+ -e -y /fido/mailer/out.015/ce84ee01.th0 /fido/mailer/out.tmp/d0de9c05.pkt

    I suspect hpt was planning to create d0de9c03.fr0 for 21:3/104 but found an existing mail bundle to add mail to.

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:3/102 via 21:3/102] 7 20:04:46 Leave non-packed mail for 21:3/102 Oliver Thuns, d0de9c04.pkt

    I suspect hpt was also planning to create d0de9c03.fr0 for 21:3/102 but found mail was not to be packed for that node.

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:4/100 via 21:4/100] 7 20:04:46 Packing for 21:4/100 Hub,
    d0de9c02.pkt > d0de9c03.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c03.fr0 /fido/mailer/out.tmp/d0de9c02.pkt

    It looks like d0de9c03.fr0 was finaly used for mail to 21:4/100.

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:3/105 via 21:3/105] 7 20:04:46 Packing for 21:3/105 Les Wade, d0de9c07.pkt > d0669506.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0669506.fr0 /fido/mailer/out.tmp/d0de9c07.pkt

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:2/116 via 21:2/116] 7 20:04:46 Packing for 21:2/116 Alterant, d0de9c03.pkt > d0de9c04.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c04.fr0 /fido/mailer/out.tmp/d0de9c03.pkt

    It appears these 2 nodes both got mail added to d0de9c04.fr0?

    If that happened it seems to me one of those nodes would have received that bundle with both of those .pkt's and the other simply didn't get them at all.

    An investigation is in order here. If that logging is correct that looks like a problem.

    Notice that the packet d0de9c03.fr0 is created for multiple
    destinations in the same invocation of toss. Is this right?

    d0de9c03.fr0 went OK I think.. but d0de9c04.fr0 looks like a problem.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Deon George on Fri May 29 14:30:38 2020
    Hello Deon,

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:3/105 via 21:3/105] 7 20:04:46 Packing for 21:3/105 Les Wade, d0de9c07.pkt > d0669506.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0669506.fr0 /fido/mailer/out.tmp/d0de9c07.pkt

    Actually, this outbound mail went into d0669506.fr0. Probably an existing mail bundle waiting for that node.

    M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:2/116 via 21:2/116] 7 20:04:46 Packing for 21:2/116 Alterant, d0de9c03.pkt > d0de9c04.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c04.fr0 /fido/mailer/out.tmp/d0de9c03.pkt

    So d0de9c04.fr0 was used just for 21:2/116.

    No issues here.. :)

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Deon George@3:633/509 to Michael Dukelsky on Sat May 30 11:07:06 2020
    Re: Bad packets
    By: Michael Dukelsky to Deon George on Fri May 29 2020 06:46 pm

    Did you run tparser?

    I did, no errors if that's why you were asking...

    ...ëîåï

    ... Freedom of the press is limited to those who have one.
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Deon George@3:633/509 to Alan Ianson on Sat May 30 11:09:02 2020
    Re: Bad packets
    By: Alan Ianson to Deon George on Fri May 29 2020 01:40 pm

    Notice that the packet d0de9c03.fr0 is created for multiple
    destinations in the same invocation of toss. Is this right?
    That would certainly be a problem but I have not seen that here.

    I just scanned out a message and I can see that each outbound bundle was created with a new filename, each incremented by 1.

    Yeah, it doesnt happen all the time, it only happens sometimes.

    Originally I never bundled packets into an archive, but turned that on because I noticed the same packet for multiple destinations. That seemed to work OK, but I now see it happening with the archive...

    I'm certain something isnt right, but its not consistently re-producable... (that I've worked out yet anyway...)

    ...ëîåï

    ... Hell hath no fury like a bureaucrat scorned.
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alan Ianson@1:153/757 to Deon George on Fri May 29 22:11:52 2020
    Hello Deon,

    Originally I never bundled packets into an archive, but turned that on because I noticed the same packet for multiple destinations. That
    seemed to work OK, but I now see it happening with the archive...

    I have not seen that happen here and it's not something I'd like to see. Most of my links are using arcmail bundles but a few are raw pkt files.

    I'm certain something isnt right, but its not consistently re-producable... (that I've worked out yet anyway...)

    I'll have eyes on this since you bring it up and see what I can see. If it is something you can reproduce bring it up here. I can't fix it but others can if it proves to be an issue.. but I have not seen it.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Deon George@3:633/509 to Alan Ianson on Sun May 31 22:30:48 2020
    Re: Bad packets
    By: Alan Ianson to Deon George on Fri May 29 2020 10:11 pm

    I'm certain something isnt right, but its not consistently
    re-producable... (that I've worked out yet anyway...)

    OK, here is another example. I have a perl hook that responds to a test message post. Folks only saw the perl hook post, not the original from 3/110.

    3/110 sent a test message, which was sent to 10+ links, this is mine:

    1 02:31:37 Start tossing...
    7 02:31:37 pkt: /fido/mailer/in.tmp/b4373309.tos [21:3/110]
    E 02:31:38 Responding to test in [FSX_GEN].
    2 02:31:38 Reading dupes of FSX_GEN
    ...
    M 02:31:38 pktFile /fido/mailer/out.tmp/d28ac803.pkt created for [21:2/116] ...
    4 02:31:38 echo area FSX_GEN - 1 msgs
    ...
    M 02:31:38 packFile /fido/mailer/out.015/d28ac803.su0 created for [21:2/116 via 21:2/116]
    7 02:31:38 Packing for 21:2/116 Alterant, d28ac803.pkt > d28ac803.su0
    6 02:31:38 cmd: zip -9 -j -q /fido/mailer/out.015/d28ac803.su0 /fido/mailer/out.tmp/d28ac803.pkt
    ...

    (This is the original test message.), then:

    1 02:31:38 Start scanning...
    1 02:31:38 EchoTossLogFile not found -> Scanning all areas
    2 02:31:38 Reading dupes of FSX_GEN
    ...
    M 02:31:38 pktFile /fido/mailer/out.tmp/d28ac803.pkt created for [21:2/116] ...
    M 02:31:38 packFile /fido/mailer/out.015/d28ac80a.su0 created for [21:2/116 via 21:2/116]
    7 02:31:38 Packing for 21:2/116 Alterant, d28ac803.pkt > d28ac803.su0
    6 02:31:38 cmd: zip -9 -j -q /fido/mailer/out.015/d28ac803.su0 /fido/mailer/out.tmp/d28ac803.pkt
    ...
    D 02:31:38 exported: 1
    E 02:31:38 echo area FSX_GEN - 1 msgs

    Notice that packet d28ac803.pkt was used twice, and went into the same archive d28ac80a.su0 for the same node 2/116. I'm assuming the second pkt file overwrote the first one.

    hpt is invoked from a script that calls "hpt toss", then "hpt scan".

    Why is the same packet number between two different runs?

    ...ëîåï

    ... Want to have some fun? Walk into an antique shop and say, What's new?
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Wilfred van Velzen@2:280/464 to Deon George on Sun May 31 14:52:00 2020
    Hi Deon,

    On 2020-05-31 22:30:48, you wrote to Alan Ianson:

    1 02:31:37 Start tossing...
    ...
    M 02:31:38 pktFile /fido/mailer/out.tmp/d28ac803.pkt created for [21:2/116]
    ...

    (This is the original test message.), then:

    1 02:31:38 Start scanning...
    ...
    M 02:31:38 pktFile /fido/mailer/out.tmp/d28ac803.pkt created for [21:2/116]
    ...

    Notice that packet d28ac803.pkt was used twice, and went into the same archive d28ac80a.su0 for the same node 2/116. I'm assuming the second pkt file overwrote the first one.

    hpt is invoked from a script that calls "hpt toss", then "hpt scan".

    Why is the same packet number between two different runs?

    It's all taking place within the same second. Maybe the current time is used to create the filename?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Deon George@3:633/509 to Wilfred van Velzen on Mon Jun 1 07:33:13 2020
    Re: Re: Bad packets
    By: Wilfred van Velzen to Deon George on Sun May 31 2020 02:52 pm

    It's all taking place within the same second. Maybe the current time is used to create the filename?

    Not sure on that one - I guess I could look through the code.

    But anyway, I've added a sleep 1 between each one, and we'll see if that helps the situation...

    ...ëîåï

    ... Do what you will with this tagline, just don't bother me about it!
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alan Ianson@1:153/757 to Deon George on Sun May 31 18:44:32 2020
    Hello Deon,

    Notice that packet d28ac803.pkt was used twice, and went into the same archive d28ac80a.su0 for the same node 2/116. I'm assuming the second
    pkt file overwrote the first one.

    Yes, that would explain why we only saw the test bot's reply and not the original.

    hpt is invoked from a script that calls "hpt toss", then "hpt scan".

    Why is the same packet number between two different runs?

    That's the question. AFAIK I have seen all original posts and bot replies except one yesterday, I only saw the bot reply. Today I saw another pair, the origianl test message and the bot reply.

    Why did that happen and does it happen only sometimes?

    Perhaps it is a problem that this all happened in the same second in this case as Wilfred sugested.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Deon George on Sun May 31 18:51:20 2020
    Hello Deon,

    Why is the same packet number between two different runs?

    This is the question that needs to be answered. I'm going to send a test to the bot in a minute here. Can you show us the logging?

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Deon George@3:633/509 to Alan Ianson on Mon Jun 1 12:30:20 2020
    Re: Bad packets
    By: Alan Ianson to Deon George on Sun May 31 2020 06:44 pm

    That's the question. AFAIK I have seen all original posts and bot replies except one yesterday, I only saw the bot reply. Today I saw another pair, the origianl test message and the bot reply.
    Why did that happen and does it happen only sometimes?

    So I've actually notice it happen a few times - but I've only looked into it deeper this time.

    The question is, as you've stated "Why did it happen that time and not every time"... I guess a first approach would be to keep all packets that come in and then reply said packets, when we notice it happen again, and see if it happens a second tiem. Then when it's reproducable, we can debug it.

    ...ëîåï

    ... Ahh! Come on Gerard, just this one last little feature!
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Deon George@3:633/509 to Alan Ianson on Mon Jun 1 12:31:29 2020
    Re: Bad packets
    By: Alan Ianson to Deon George on Sun May 31 2020 06:51 pm

    This is the question that needs to be answered. I'm going to send a test to the bot in a minute here. Can you show us the logging?

    I can.

    I'm currently debugg with this:
    LogLevels 0-9,A-N,P-T,V-Y

    Anything else I should have?

    ...ëîåï

    ... I don't deserve this, but I have arthritis and I don't deserve that either --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Deon George@3:633/509 to Alan Ianson on Mon Jun 1 12:33:23 2020
    Re: Bad packets
    By: Alan Ianson to Deon George on Sun May 31 2020 06:51 pm

    Why is the same packet number between two different runs?
    This is the question that needs to be answered. I'm going to send a test to the bot in a minute here. Can you show us the logging?

    Also be aware, I've added a 1 second delay between hpt toss and hpt scan - in case time is involved when deciding the packet name. (I havent looked through the code to see if it is...)

    ...ëîåï

    ... I installed a skylight in my apartment... the people who live above me are furious!
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alan Ianson@1:153/757 to Deon George on Sun May 31 22:06:08 2020
    Hello Deon,

    Also be aware, I've added a 1 second delay between hpt toss and hpt
    scan - in case time is involved when deciding the packet name. (I
    havent looked through the code to see if it is...)

    I said this an another area but for completeness I'll say it here too.

    I would take thast delay out so we can get a good look at what is happening here, and act on it if necessary.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Deon George on Sun May 31 22:07:58 2020
    Hello Deon,


    I'm currently debugg with this:
    LogLevels 0-9,A-N,P-T,V-Y

    Anything else I should have?

    I think that will cover it. My own logging is turned down a bit but when looking for the cause of an issue it's good to have telling logs and I think that'll do it.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Michael Dukelsky@2:5020/1042 to Deon George on Mon Jun 1 13:12:44 2020
    Hello Deon,

    Monday June 01 2020, Deon George wrote to Alan Ianson:

    Also be aware, I've added a 1 second delay between hpt toss and hpt
    scan - in case time is involved when deciding the packet name. (I
    havent looked through the code to see if it is...)

    It is not in the code, it is in your configuration. If there is no "bundleNameStyle" in your configuration or it is set "bundleNameStyle timeStamp", then a bundle name is created from current time. It is better to use "bundleNameStyle addrsCRC32Always".

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Deon George@3:633/509 to Michael Dukelsky on Mon Jun 1 20:41:09 2020
    Re: Bad packets
    By: Michael Dukelsky to Deon George on Mon Jun 01 2020 01:12 pm

    It is not in the code, it is in your configuration. If there is no "bundleNameStyle" in your configuration or it is set "bundleNameStyle timeStamp", then a bundle name is created from current time. It is better to use "bundleNameStyle addrsCRC32Always".

    Thank you.

    I wasnt aware of that parimeter, so no I didnt have it. tparser showed: BundleNameStyle: undefined (timeStamp)

    So I've changed it.

    ...ëîåï

    ... I profoundly believe it takes a lot of practice to become a moral slob.
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Tommi Koivula@2:221/360 to Michael Dukelsky on Mon Jun 1 14:50:08 2020
    On 01.06.2020 13:12, Michael Dukelsky : Deon George :

    Monday June 01 2020, Deon George wrote to Alan Ianson:

    DG> Also be aware, I've added a 1 second delay between hpt toss and hpt
    DG> scan - in case time is involved when deciding the packet name. (I
    DG> havent looked through the code to see if it is...)

    It is not in the code, it is in your configuration. If there is no "bundleNameStyle" in your configuration or it is set "bundleNameStyle timeStamp", then a bundle name is created from current time. It is
    better to use "bundleNameStyle addrsCRC32Always".
    But that parameter does not affect the names of created .PKT's, or does it?

    'Tommi

    --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:77.0) Gecko/20100101 Thunderbird/77.0
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Michael Dukelsky@2:5020/1042 to Tommi Koivula on Mon Jun 1 16:17:54 2020
    Hello Tommi,

    Monday June 01 2020, Tommi Koivula wrote to Michael Dukelsky:

    DG> Also be aware, I've added a 1 second delay between hpt toss
    and hpt
    DG> scan - in case time is involved when deciding the packet name.
    (I
    DG> havent looked through the code to see if it is...)

    It is not in the code, it is in your configuration. If there is no
    "bundleNameStyle" in your configuration or it is set
    "bundleNameStyle timeStamp", then a bundle name is created from
    current time. It is better to use "bundleNameStyle
    addrsCRC32Always".
    But that parameter does not affect the names of created .PKT's, or
    does it?

    No, it does not.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Kai Richter@2:240/77 to Michael Dukelsky on Tue Jun 2 12:48:28 2020
    Hello Michael!

    01 Jun 20, Michael Dukelsky wrote to Deon George:

    "bundleNameStyle" in your configuration or it is set "bundleNameStyle timeStamp", then a bundle name is created from current time. It is
    better to use "bundleNameStyle addrsCRC32Always".

    What is the reason for the timestamp default then?

    Isn't there the next workaround to count up the extension? *.su0 bundles are going to be followed by *.su1 bundles. So timestamp should be safe?

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Deon George on Tue Jun 2 13:20:18 2020
    Hello Deon!

    31 May 20, Deon George wrote to Alan Ianson:

    02:31:38 cmd: zip -9 -j -q /fido/mailer/out.015/d28ac803.su0

    If you want to see what your packer really does adjust the pack/unpack configuration lines in the husky config. I think it's -q that should be replaced by the verbose switch.

    I don't know if the zip output can be redirected with >> to a seperate logfile in the same pack config line or if that is necessary.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Michael Dukelsky@2:5020/1042 to Kai Richter on Tue Jun 2 19:12:56 2020
    Hello Kai,

    Tuesday June 02 2020, Kai Richter wrote to Michael Dukelsky:

    "bundleNameStyle" in your configuration or it is set
    "bundleNameStyle timeStamp", then a bundle name is created from
    current time. It is better to use "bundleNameStyle
    addrsCRC32Always".

    What is the reason for the timestamp default then?

    Isn't there the next workaround to count up the extension? *.su0
    bundles are going to be followed by *.su1 bundles. So timestamp should
    be safe?

    Since there was a suspiáion of a bug when the default bundleNameStyle is used, I proposed using a different bundleNameStyle. I use addrsCRC32Always therefore I suggested this style.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Deon George@3:633/509 to Michael Dukelsky on Wed Jun 3 09:33:59 2020
    Re: Bad packets
    By: Michael Dukelsky to Kai Richter on Tue Jun 02 2020 07:12 pm

    Since there was a suspiáion of a bug when the default bundleNameStyle is used, I proposed using a different bundleNameStyle. I use addrsCRC32Always therefore I suggested this style.

    Mmm, OK, this probably wont fix the problem I was experiencing.

    We noticed that a hpt toss and hpt scan ran within the same second - and generated the same PKT for a node. So when that packet was added to the bundle, the first PKT was relaced with the second one.

    I havent looked through the code, but what determines the PKT name for a node? Is it time based? If so, then I just need to make sure there is a 1s delay between invocations of hpt - I'm assuming that should address it?

    ...ëîåï

    ... Democracy is the art of running the circus from the monkey cage.
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Tommi Koivula@2:221/1 to Deon George on Wed Jun 3 11:47:12 2020
    Hi Deon.

    03 Jun 20 09:33:58, you wrote to Michael Dukelsky:

    Re: Bad packets
    By: Michael Dukelsky to Kai Richter on Tue Jun 02 2020 07:12 pm

    Since there was a suspißion of a bug when the default
    bundleNameStyle is used, I proposed using a different
    bundleNameStyle. I use addrsCRC32Always therefore I suggested
    this style.

    Mmm, OK, this probably wont fix the problem I was experiencing.

    Correct.

    We noticed that a hpt toss and hpt scan ran within the same second -
    and generated the same PKT for a node. So when that packet was added
    to the bundle, the first PKT was relaced with the second one.

    I havent looked through the code, but what determines the PKT name
    for a node? Is it time based? If so, then I just need to make sure
    there is a 1s delay between invocations of hpt - I'm assuming that
    should address it?

    To make sure there is just one hpt running at the time, do you have something like this in your fidoconfig?

    LockFile \bbs\husky\lock
    AdvisoryLock 30

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/1)
  • From Deon George@3:633/509 to Tommi Koivula on Wed Jun 3 21:39:41 2020
    Re: Bad packets
    By: Tommi Koivula to Deon George on Wed Jun 03 2020 11:47 am

    To make sure there is just one hpt running at the time, do you have something like this in your fidoconfig?
    LockFile \bbs\husky\lock
    AdvisoryLock 30

    I do only have 1 hpt running at a time. Its launched by a script that tests for a semafore that a previous invocation would create on start and delete at the end.

    I had a look at my config:

    LockFile: /var/lock/lock
    AdvisoryLock: off

    I might just turn this on anyway, but it in theory should be redundant (I think?)

    ...ëîåï

    ... File not found, I'll load something *I* think is interesting.
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Tommi Koivula@2:221/0 to Deon George on Wed Jun 3 15:37:22 2020
    Hello, Deon George.
    On 03/06/2020 21.39 you wrote:

    To make sure there is just one hpt running at the time, do you have
    something like this in your fidoconfig?
    LockFile \bbs\husky\lock
    AdvisoryLock 30
    I do only have 1 hpt running at a time. Its launched by a script that tests for a semafore that a previous invocation would create on start and delete at the end.
    I had a look at my config:
    LockFile: /var/lock/lock
    AdvisoryLock: off
    I might just turn this on anyway, but it in theory should be redundant (I think?)

    It doesnt harm if you turn it on. :)

    ..deltepssigmn
    .. File not found, I'll load something *I* think is interesting.

    --
    Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/0)
  • From Michael Dukelsky@2:5020/1042 to Deon George on Wed Jun 3 17:20:46 2020
    Hello Deon,

    Wednesday June 03 2020, Tommi Koivula wrote to Deon George:

    To make sure there is just one hpt running at the time, do you
    have something like this in your fidoconfig? LockFile
    \bbs\husky\lock AdvisoryLock 30
    I do only have 1 hpt running at a time. Its launched by a script
    that tests for a semafore that a previous invocation would create
    on start and delete at the end. I had a look at my config:
    LockFile: /var/lock/lock
    AdvisoryLock: off
    I might just turn this on anyway, but it in theory should be
    redundant (I think?)
    It doesnt harm if you turn it on. :)

    And to turn it on you should put there a positive integer, not "on".

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Deon George@3:633/509 to Michael Dukelsky on Thu Jun 4 08:59:29 2020
    Re: Bad packets
    By: Michael Dukelsky to Deon George on Wed Jun 03 2020 05:20 pm

    And to turn it on you should put there a positive integer, not "on".

    Yup, I noticed that - thanks :)

    Now back to my original reason for this thread - it seems that in some scenarios that the same PKT name is created for a node, and I have seen it a couple of times using hpt toss and hpt scan.

    I see it more prevelently when I set up downlinks without archive bundles.

    Before I create an environment to get some debugging, just wondering if this has been seen before? Or if there is a known config issue or use-case that could cause it?

    ...ëîåï

    ... A seeming ignorance is often a most necessary part of worldly knowledge. --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Kai Richter@2:240/77 to Deon George on Wed Jun 3 14:01:40 2020
    Hello Deon!

    03 Jun 20, Deon George wrote to Tommi Koivula:

    LockFile \bbs\husky\lock

    I had a look at my config:
    LockFile: /var/lock/lock

    I can't help with the current problem (i think a "sleep 1" between the toss and scan run wouldn't help) but i recommend to be more verbose with the lock file name.

    If you see a "lock" file you have no idea what it locks. If you see a "husky.lock" file you would know it's the one to delete if there is trouble with husky. Usually you need those help after years of normal operation and when you forgot what your configuration does.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Michael Dukelsky@2:5020/1042 to Deon George on Thu Jun 4 18:17:12 2020
    Hello Deon,

    Thursday June 04 2020, Deon George wrote to Michael Dukelsky:

    Now back to my original reason for this thread - it seems that in some scenarios that the same PKT name is created for a node, and I have
    seen it a couple of times using hpt toss and hpt scan.

    I see it more prevelently when I set up downlinks without archive
    bundles.

    Looks like most of the people use archive bundles, so the other code branch may be more buggy.

    Before I create an environment to get some debugging, just wondering
    if this has been seen before? Or if there is a known config issue or use-case that could cause it?

    Not that I know of.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Tommi Koivula@2:221/360 to Deon George on Thu Jun 4 19:54:10 2020
    On 03.06.2020 14:39, Deon George : Tommi Koivula :

    To make sure there is just one hpt running at the time, do you have something like this in your fidoconfig?
    LockFile \bbs\husky\lock
    AdvisoryLock 30

    I do only have 1 hpt running at a time. Its launched by a script that
    tests for a semafore that a previous invocation would create on start
    and delete at the end.

    Just one more idea... You say you run "hpt toss" and "hpt scan" at the same second. Would it make any difference if you run "hpt toss scan" instead of two separate commands?

    'Tommi

    ---
    * Origin: rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Deon George@3:633/509 to Tommi Koivula on Fri Jun 5 07:37:54 2020
    Re: Re: Bad packets
    By: Tommi Koivula to Deon George on Thu Jun 04 2020 07:54 pm

    Hi Tommi,

    Just one more idea... You say you run "hpt toss" and "hpt scan" at the same second. Would it make any difference if you run "hpt toss scan" instead of two separate commands?

    Well, the reason I run it separately is that between "hpt toss" and "hpt scan", I'm running "htick scan" (in case a tossed message was to filefix). (Then after all of that I'm running "hpt pack".)

    Perhaps there is a better approach to doing this?

    ...ëîåï

    ... In every revolution, there's one man with a vision. Kirk, stardate unknown --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)