• HPT

    From tassiebob@21:3/169 to All on Thu Jul 7 20:07:59 2022
    Hi All,

    HPT, and the other Husky tools...

    For those who are using them on Linux (intel), did you install pre-built binaries, or did you manage to build from sources?

    I'm trying the latter, but I'm clearly missing something.

    I've got the huskymak.cfg file updated and in the base directory as per the destructions, but when I jump into the smapi directory and run "make clean" (GNU make), it fails saying there's no target "clean".

    I'm loosely familiar with Makefiles, but I can't see how this build system they've got going picks up the variables defined in the huskymak.cfg file, or really how this build system works at all. Trying the old Makefiles (make -f makefile.lnx clean) just yields other, different, problems.

    I've currently got fidoconf, hpt, huskybse, huskylib, msged, and smapi unpacked into subdirectories of the base directory. All were git clones from the github repo (master branch, the others are prehistoric).

    I can't help thinking it shouldn't be this hard. Can anyone tell me what totally obvious thing I'm missing? :-)

    Cheers.

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)
  • From Alan Ianson@21:4/106 to tassiebob on Thu Jul 7 03:32:42 2022
    I can't help thinking it shouldn't be this hard. Can anyone tell me what totally obvious thing I'm missing? :-)

    I built a fresh husky a week ago following the instructions here..

    https://github.com/huskyproject/huskybse/blob/master/INSTALL.asciidoc

    They are using a new build system these days and you are right, it seems to be harder than it needs to be.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From tassiebob@21:3/169 to Alan Ianson on Thu Jul 7 20:44:12 2022
    I built a fresh husky a week ago following the instructions here..

    https://github.com/huskyproject/huskybse/blob/master/INSTALL.asciidoc

    Doh!

    So those instructions are different to what's in the "INSTALL" file, but the "doh!" bit is that line 4 of the INSTALL file says to read INSTALL.asciidoc.

    Let's see how it goes when I follow the right instructions...

    Thanks for the pointer - much appreciated!

    Cheers.

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)
  • From tassiebob@21:3/169 to Alan Ianson on Thu Jul 7 21:20:03 2022
    https://github.com/huskyproject/huskybse/blob/master/INSTALL.asciidoc

    Confirmed - read that version of the INSTALL doc and it builds fine. Doh!

    Thankyou!

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)
  • From deon@21:2/116 to tassiebob on Thu Jul 7 22:07:23 2022
    Re: HPT
    By: tassiebob to All on Thu Jul 07 2022 08:07 pm

    HPT, and the other Husky tools...

    For those who are using them on Linux (intel), did you install pre-built binaries, or did you manage to build from sources?

    So I run Hub 3 with binkd and hpt - all in a docker container.

    You are welcome to use that container - or look at my build (Dockerfile) here: https://dev.leenooks.net/bbs/fidohub

    The runner has the build output if that helps.


    ...δεσ∩
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From tassiebob@21:3/169 to deon on Fri Jul 8 13:40:45 2022
    So I run Hub 3 with binkd and hpt - all in a docker container.

    You are welcome to use that container - or look at my build (Dockerfile) here: https://dev.leenooks.net/bbs/fidohub

    The runner has the build output if that helps.

    I'll definitely take a look at that after work - I'll most likely run it natively, but there will be many useful pointers in the way you've got it all set up I'm sure.

    Cheers,
    Bob.

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)
  • From TassieBob@21:3/169 to tassiebob on Sun Jul 10 16:48:56 2022

    here: https://dev.leenooks.net/bbs/fidohub

    The runner has the build output if that helps.

    I'll definitely take a look at that after work - I'll most likely run it natively, but there will be many useful pointers in the way you've got it all set up I'm sure.

    binkd question...

    Sending a netmail to 1337:2/100, binkd tries to call 1337:2/100@fsxnet...

    I assume it's defaulting to fsxnet, since that's first listed in my binkd config file.

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    Presumably this is why it doesn't match the node line for 1337:2/100?

    node 21:3/100 -4 n3.z21.bbs.leenooks.net:24554 pass,pass,pass -
    node 1337:2/100 -4 n2.z1337.bbs.leenooks.net:24554 pass,pass,pass -

    I note that for Fidonet, I could specify a root-domain (binkp.net typically) on the node line and it'll do the FTN to hostname resolution that way. I haven't seen evidence of a root-domain I can use for fsxnet or tqwnet...

    I don't have the Perl nodelist stuff setup for binkd at the moment - is that the fix?

    Am I wrong in assuming I should be able to send netmail to a node listed in a node line without needing a binkp.net style lookup or nodelist?

    Clues most welcome :-)

    Cheers.

    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob BBS (21:3/169)
  • From Al@21:4/106 to TassieBob on Sun Jul 10 00:22:10 2022
    Sending a netmail to 1337:2/100, binkd tries to call 1337:2/100@fsxnet...

    It is the tosser that prepares the netmail to be sent, so I would look there and also check your golded.cfg (if you use that).

    I assume it's defaulting to fsxnet, since that's first listed in my binkd config file.

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337


    Those are 5D node lines. I am using 3D node lines in binkd.conf like this..

    domain fidonet /home/bbs/ftn/outbound 1 domain fsxnet /home/bbs/ftn/outbound 1

    Presumably this is why it doesn't match the node line for 1337:2/100?

    Actually that will work with binkd although you tosser needs to support 5D also.

    I note that for Fidonet, I could specify a root-domain (binkp.net typically) on the node line and it'll do the FTN to hostname resolution that way. I haven't seen evidence of a root-domain I can use for fsxnet or tqwnet...

    binkd will use binkp.net by default. There is another for fsxnet that Avon setup but I forget the details ATM.

    We'll have to ask him the details.

    I don't have the Perl nodelist stuff setup for binkd at the moment - is that the fix?

    No, perl doesn't come into this.

    Am I wrong in assuming I should be able to send netmail to a node listed in a node line without needing a binkp.net style lookup or nodelist?

    Yes, binkd will get node info from your node lines and use binkp.net otherwise if defnode is setup.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Zip@21:1/202 to TassieBob on Sun Jul 10 09:42:02 2022
    Hello TassieBob!

    On 10 Jul 2022, TassieBob said the following...

    node 21:3/100 -4 n3.z21.bbs.leenooks.net:24554 pass,pass,pass -
    node 1337:2/100 -4 n2.z1337.bbs.leenooks.net:24554 pass,pass,pass -

    Try changing this to 21:3/100@fsxnet and 1337:2/100@tqwnet, and also make sure to include the domain in your address lines if you haven't already, e.g.:

    address 21:3/169@fsxnet
    address 1337:2/<your node number>@tqwnet

    ...to see if that makes any difference, as one blurb in the config says that:

    # If the first address is specified as a 3D/4D address, its domain will be
    # taken from the domain defined in the first "domain" line. If more addresses
    # are specified as 3D/4D ones, their domain will be taken from the first
    # address.

    The last part there might be why it "borrows" the fsxnet domain for your additional addresses (1337:2/<your node number>).

    I note that for Fidonet, I could specify a root-domain (binkp.net typically) on the node line and it'll do the FTN to hostname resolution that way. I haven't seen evidence of a root-domain I can use for fsxnet or tqwnet...

    I have added "fsxnet.nz" to my config, although I see now that it doesn't seem to resolve my address:

    host n202.n1.z21.fsxnet.nz
    Host n202.n1.z21.fsxnet.nz not found: 3(NXDOMAIN)

    ...so maybe Avon will have to chime in on the details here. :)

    I don't have the Perl nodelist stuff setup for binkd at the moment - is that the fix?

    No, that should not be needed.

    Am I wrong in assuming I should be able to send netmail to a node listed in a node line without needing a binkp.net style lookup or nodelist?

    Yes, I think so.

    And if you want binkd to be able to send to any node (e.g. for crashmail), you would add something like:

    defnode *

    ...at the end. But this of course requires that the root domain has been set for each network so that it can resolve the FTN address to an IP number.

    Hope this helps!

    Best regards
    Zip

    --- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From TassieBob@21:3/169 to Al on Sun Jul 10 17:50:42 2022

    Hey Al,

    Sending a netmail to 1337:2/100, binkd tries to call
    1337:2/100@fsxnet...

    It is the tosser that prepares the netmail to be sent, so I would look there and also check your golded.cfg (if you use that).

    I'm not seeing any trace of '@fsxnet' in the .cut file in the outbound directory, and the source/destination zone/net/node look to be right. I looked here earlier and that's what led me to the conclusion it was probably binkd doing it..

    Presumably this is why it doesn't match the node line for 1337:2/100?

    Actually that will work with binkd although you tosser needs to support 5D also.

    I thought HPT did, but I may still have its config wrong...

    I note that for Fidonet, I could specify a root-domain (binkp.net
    typically) on the node line and it'll do the FTN to hostname resolution
    that way. I haven't seen evidence of a root-domain I can use for fsxnet
    or tqwnet...

    binkd will use binkp.net by default. There is another for fsxnet that Avon setup but I forget the details ATM.

    Ah - I had a quick poke around earlier and couldn't get anything obvious to resolve under fsxnet.nz. Hopefuly he'll chime in when he has a chance (I know he's off travelling at the moment).

    I don't have the Perl nodelist stuff setup for binkd at the moment - is
    that the fix?

    No, perl doesn't come into this.

    Sweet - I hate Perl... LoL.

    Am I wrong in assuming I should be able to send netmail to a node
    listed
    in a node line without needing a binkp.net style lookup or nodelist?

    Yes, binkd will get node info from your node lines and use binkp.net otherwise if defnode is setup.

    That's about what I thought.

    Thanks for the suggestions - I will indeed go back through my GoldED & HPT configurations, and do some comparisons between the packets that get generated for fsxnet vs those for tqwnet to see what, if any, obvious differences there are.

    Cheers.


    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob BBS (21:3/169)
  • From TassieBob@21:3/169 to Zip on Sun Jul 10 18:00:32 2022

    Hey Zip,

    node 21:3/100 -4 n3.z21.bbs.leenooks.net:24554 pass,pass,pass -
    node 1337:2/100 -4 n2.z1337.bbs.leenooks.net:24554 pass,pass,pass -

    Try changing this to 21:3/100@fsxnet and 1337:2/100@tqwnet, and also make sure to include the domain in your address lines if you haven't already, e.g.:

    address 21:3/169@fsxnet
    address 1337:2/<your node number>@tqwnet

    Tried that (but tried it again, just in case I pooched it up the first time). I didn't have any luck, but I'll do some more fiddling...

    ...to see if that makes any difference, as one blurb in the config
    says
    that:

    # If the first address is specified as a 3D/4D address, its domain will be # taken from the domain defined in the first "domain" line. If more addresses # are specified as 3D/4D ones, their domain will be taken from the first # address.

    The last part there might be why it "borrows" the fsxnet domain for your additional addresses (1337:2/<your node number>).

    Yeah, that's what made me try it originally.

    I have added "fsxnet.nz" to my config, although I see now that it
    doesn't
    seem to resolve my address:

    host n202.n1.z21.fsxnet.nz
    Host n202.n1.z21.fsxnet.nz not found: 3(NXDOMAIN)

    :-(

    Am I wrong in assuming I should be able to send netmail to a node
    listed in a node line without needing a binkp.net style lookup or
    nodelist?

    Yes, I think so.

    And if you want binkd to be able to send to any node (e.g. for crashmail), you would add something like:

    defnode *

    ...at the end. But this of course requires that the root domain has been set for each network so that it can resolve the FTN address to an IP number.

    I have defnode setup, but not the root-domain bit.

    Hope this helps!

    Has given me some pointers towards things to look at - muchly appreciated.

    Cheers,
    Bob.

    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob BBS (21:3/169)
  • From Al@21:4/106.1 to TassieBob on Sun Jul 10 01:44:33 2022
    Hello TassieBob,

    It is the tosser that prepares the netmail to be sent, so I would
    look there and also check your golded.cfg (if you use that).

    I'm not seeing any trace of '@fsxnet' in the .cut file in the outbound directory, and the source/destination zone/net/node look to be right.
    I looked here earlier and that's what led me to the conclusion it was probably binkd doing it..

    I don't see it either here. Mind you I setup hpt years ago when there was no 5D support. That may have changed now but I am not sure.

    I thought HPT did, but I may still have its config wrong...

    I don't think so but I have not looked into 5D support.

    Thanks for the suggestions - I will indeed go back through my GoldED &
    HPT configurations, and do some comparisons between the packets that
    get generated for fsxnet vs those for tqwnet to see what, if any,
    obvious differences there are.

    No worries. Hollar if you have issues or questions and we'll try to help you get things in order.

    Ttyl :-),
    Al

    ... This message has been UNIXized for your protection.
    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)
  • From Zip@21:1/202 to TassieBob on Sun Jul 10 11:35:30 2022
    Hello TassieBob!

    On 10 Jul 2022, TassieBob said the following...
    Tried that (but tried it again, just in case I pooched it up the first time). I didn't have any luck, but I'll do some more fiddling...

    OK!

    Has given me some pointers towards things to look at - muchly
    appreciated.

    You're very welcome! Hoping you'll be able to solve it.

    As a sidenote, when I think of it, my outbound has one primary subdirectory (fsxnet), and the others are adjacent to it:

    # NOTE: Specifying a matching (21 = 21) default zone will cause the outbound
    # directory to become /mnt/bbs/echomail/out/fsxnet in practice
    domain fsxnet /mnt/bbs/echomail/out/fsxnet 21 fsxnet.nz

    # NOTE: Specifying a non-matching (21 != 2) default zone will cause the
    # outbound directory to become /mnt/bbs/echomail/out/fidonet.002 in practice domain fidonet /mnt/bbs/echomail/out/fidonet 21 binkp.net

    (I'm in FidoNet zone 2.)

    So, I specify 21 as the default domain for all my FTN networks, and hence get .<number> suffixes to the outbound directory names for all but fsxNet.

    Of course, having a subdirectory for each network eases things for binkd, but I think your setup with one outbound with all in it (right?) *should* work as well. As 3D setups do exist (for older software), and binkd *should* be able to find out from the outgoing packet filenames which node is the recipient...

    Best regards
    Zip

    --- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From TassieBob@21:3/169 to Zip on Sun Jul 10 19:44:22 2022


    As a sidenote, when I think of it, my outbound has one primary subdirectory
    (fsxnet), and the others are adjacent to it:

    # NOTE: Specifying a matching (21 = 21) default zone will cause the outbound # directory to become /mnt/bbs/echomail/out/fsxnet in
    practice domain fsxnet /mnt/bbs/echomail/out/fsxnet 21 fsxnet.nz

    # NOTE: Specifying a non-matching (21 != 2) default zone will cause the
    # outbound directory to become /mnt/bbs/echomail/out/fidonet.002 in practice domain fidonet /mnt/bbs/echomail/out/fidonet 21 binkp.net

    When I was first cutting the config for binkd I did configure it this way but I couldn't find the required HPT directives to make HPT use the separate outbound directories. The documentation suggested it only supported Binkley-style outbound directories (so a base directory for the primary zone, and .xxx hex encoded subdirectories for other zones).

    So, I specify 21 as the default domain for all my FTN networks, and
    hence
    get .<number> suffixes to the outbound directory names for all but fsxNet.

    What I have now is both fsx & tqw using a common outbound path, with fsx using the path as-is (it's primary), and tqw using <path>.539/ (hex encoded 1337).

    Even though the outbound packets is in <path>.539/, binkd still thinks it needs to place an outbound call to 1337:2/100@fsxnet, which I have no node line for because, well, it should be 1337:2/100@tqwnet (which I do have a node line for).

    but I think your setup with one outbound with all in it (right?)

    Basically as described above, but for the avoidance of doubt/confusion:

    drwxrwxr-x 3 bbs bbs 4096 Jul 10 19:47 outbound <- fsxnet
    drwxr-xr-x 3 bbs bbs 4096 Jul 10 19:52 outbound.539 <- tqwnet

    With binkd configured:

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    I don't have any specific HPT config for this - it seems smart enough to put mail for my primary/first listed address in outbound, and for zone 1337 into outbound.539

    There was a comment earlier that maybe my GoldED config might be the issue, so I tried sending a zone 1337 netmail from Mystic and had the same result. Possible they're both wrong of course, but I'm leaning towards thinking they're both OK and the problem is with either HPT or binkd - the latter feels more likely from what I'm seeing...

    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob's BBS (21:3/169)
  • From Zip@21:1/202 to TassieBob on Sun Jul 10 12:48:16 2022
    Hello TassieBob!

    On 10 Jul 2022, TassieBob said the following...
    way but I couldn't find the required HPT directives to make HPT use the separate outbound directories. The documentation suggested it only supported Binkley-style outbound directories (so a base directory for
    the primary zone, and .xxx hex encoded subdirectories for other zones).

    OK! So no mention of domains (4D or even 5D) there?

    Even though the outbound packets is in <path>.539/, binkd still thinks
    it needs to place an outbound call to 1337:2/100@fsxnet, which I have no node line for because, well, it should be 1337:2/100@tqwnet (which I do have a node line for).

    Yep, sounds like binkd believes the "outbound.539" directory is for a different zone but for the same domain (fsxNet) then...

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    Still wondering a little about that 1337 there, as specifying it should make binkd believe that anything for zone 1337 shouldn't be placed in a directory named "outbound.1337", but rather in the directory named "outbound". Which would then collide with the fsxNet outbound (which also uses the "outbound" directory).

    Did you try changing this to:

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 21

    ...or even something more apparent like:

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 999

    ...just so that you get a non-match (21 != 1337 and 999 != 1337) for the default zone specified on the domain line, so that binkd knows to look for tqwnet things in the "outbound.1337" directory rather than in the "outbound" directory?

    The old documentation reference link I have for this would be:

    https://web.archive.org/web/20171117081757/http://old.vk.pp.ru/docs/binkd/index .htm#config.domain

    I believe this would be "Example 2".

    Sorry if you already tried that. :)
    This is interesting but intriguing stuff. :)

    Best regards
    Zip

    --- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From Zip@21:1/202 to TassieBob on Sun Jul 10 12:50:35 2022
    Hello again, TassieBob!

    On 10 Jul 2022, Zip said the following...
    Still wondering a little about that 1337 there, as specifying it should make binkd believe that anything for zone 1337 shouldn't be placed in a directory named "outbound.1337", but rather in the directory named

    (cut)

    ...just so that you get a non-match (21 != 1337 and 999 != 1337) for the default zone specified on the domain line, so that binkd knows to look
    for tqwnet things in the "outbound.1337" directory rather than in the

    Of course I meant "outbound.539" (the hex value of 1337) and not "outbound.1337". :-)

    Best regards
    Zip

    --- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From TassieBob@21:3/169 to Zip on Sun Jul 10 20:53:32 2022

    On 10 Jul 2022, TassieBob said the following...
    way but I couldn't find the required HPT directives to make HPT use
    the separate outbound directories. The documentation suggested it
    only supported Binkley-style outbound directories (so a base directory
    for the primary zone, and .xxx hex encoded subdirectories for other
    zones).

    OK! So no mention of domains (4D or even 5D) there?

    There's mention of 4D, and some mention of 5D (although with a warning that the domain name is not supported everywhere in the HPT config).

    Yep, sounds like binkd believes the "outbound.539" directory is for a different zone but for the same domain (fsxNet) then...

    Yeah, this appears to be the case. I'm just not sure why it's picking up the wrong domain.

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    Did you try changing this to:

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 21

    ...or even something more apparent like:

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 999

    I didn't, and I will, although I'd argue that's a pretty crappy/unintuitive way to have to configure it if that's what it needs to work. I suspect in doing so it'll not even realise outbound.539 is supposed to exist, and won't scan it.

    Update: Did this while I was typing the reply, and confirmed, binkd doesn't even look at outbound.539 when configured this way.

    default zone specified on the domain line, so that binkd knows to look
    for
    tqwnet things in the "outbound.1337" directory rather than in the "outbound" directory?

    ...and continuing on from above, I can't specify /home/bbs/ftn/outbound.539 as the outbound directory as binkd flags the directory extension as invalid and refuses to use the config (tried that bit earlier).

    The old documentation reference link I have for this would be: https://web.archive.org/web/20171117081757/http://old.vk.pp.ru/docs/bi nkd/index .htm#config.domain

    I believe this would be "Example 2".

    Will check that out in a sec.

    This is interesting but intriguing stuff. :)

    I'll bet it's going to end up something very simple. Maybe it's just me, but the documentation for these things seems to be sorely out of date in many cases. I remember the docco being much better in the late 80's :-)

    Thanks for the ongoing suggestions!


    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob's BBS (21:3/169)
  • From TassieBob@21:3/169 to TassieBob on Sun Jul 10 21:10:32 2022

    Update: Did this while I was typing the reply, and confirmed, binkd doesn't even look at outbound.539 when configured this way.

    OK, so I might have been a bit hasty there - it is scanning outbound.539 now.

    Might have made some progress - more testing to be done.


    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob's BBS (21:3/169)
  • From TassieBob@21:3/169 to Zip on Sun Jul 10 21:16:24 2022
    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    Still wondering a little about that 1337 there, as specifying it should make binkd believe that anything for zone 1337 shouldn't be placed in a directory named "outbound.1337", but rather in the directory named "outbound". Which would then collide with the fsxNet outbound (which also uses the "outbound" directory).

    Did you try changing this to:

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 21

    ...or even something more apparent like:

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 999

    ...just so that you get a non-match (21 != 1337 and 999 != 1337) for the default zone specified on the domain line, so that binkd knows to look for tqwnet things in the "outbound.1337" directory rather than in the "outbound" directory?

    OK, so I was too hasty.

    Good news is YOU NAILED IT! I can send netmail for both zones now.

    Using "the wrong" zone number on the subsequent entry is very unintuitive, and seems to go against the examples further down in the config file, but it absolutely works, and is totally in line with the info in that link you sent.

    THANKYOU!


    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob's BBS (21:3/169)
  • From deon@21:2/116 to TassieBob on Sun Jul 10 22:38:10 2022
    Re: HPT
    By: TassieBob to tassiebob on Sun Jul 10 2022 04:48 pm

    Sending a netmail to 1337:2/100, binkd tries to call 1337:2/100@fsxnet...

    I assume it's defaulting to fsxnet, since that's first listed in my binkd config file.

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    A trap that gets everybody :)

    The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound" represents.

    Its normal to use the same "outbound" for all your zones (/home/bbs/ftn/outbound) in your case, and the number on the end should be what it represents by default. If that is zone 21, then *every* domain line should have 21 for each different domain.

    This helps binkd determine which outbound to put "other zone" mail in.

    IE:

    having:

    domain fsxnet /home/bbs/ftn/outbound 21, and
    domain tqwnet /home/bbs/ftn/outbound 21

    Means:

    * /home/bbs/ftn/outbound is the path prefix for my outgoing mail
    * zone 21 mail will go it it directly
    * zone 1337 mail will go in it with the hex 539 appended (ie: /home/bbs/ftn/outbound.539

    Hope that makes sense :)


    ...δεσ∩
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From deon@21:2/116 to TassieBob on Sun Jul 10 22:45:42 2022
    Re: HPT
    By: deon to TassieBob on Sun Jul 10 2022 10:38 pm

    This helps binkd determine which outbound to put "other zone" mail in.

    Errr. "find", not "put"...


    ...δεσ∩
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From TassieBob@21:3/169 to deon on Sun Jul 10 22:58:44 2022
    I assume it's defaulting to fsxnet, since that's first listed in my
    binkd config file.

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    A trap that gets everybody :)

    Doh!

    The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound" represents.

    Yeah, and if I re-read the comment in the binkd config file with that in mind, it kind of, sort of, says that. I was thrown by the example further down that showed two different zone numbers :-(

    having:

    domain fsxnet /home/bbs/ftn/outbound 21, and
    domain tqwnet /home/bbs/ftn/outbound 21

    Means:

    * /home/bbs/ftn/outbound is the path prefix for my outgoing mail
    * zone 21 mail will go it it directly
    * zone 1337 mail will go in it with the hex 539 appended (ie: /home/bbs/ftn/outbound.539

    Hope that makes sense :)

    It does, but I still maintain the configuration is unintuitive :-)

    Cheers.


    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: TassieBob's BBS (21:3/169)
  • From Zip@21:1/202 to TassieBob on Sun Jul 10 15:08:58 2022
    Hello TassieBob!

    On 10 Jul 2022, TassieBob said the following...
    Good news is YOU NAILED IT! I can send netmail for both zones now.

    That's great news!

    Using "the wrong" zone number on the subsequent entry is very
    unintuitive, and seems to go against the examples further down in the

    Yes, I also think it is very counterintuitive...

    When I think about it, domains can probably simply be seen as yet another layer of addressing, allowing for different FTNs to use the same zone numbers without colliding. Or some kind of separation mechanism in general.

    Given that, the default domain of a "domain" keyword is really only valid in practice if the outbound directories -- with or without zone numbers -- have unique names, identifying the FTNs (the domains).

    So "Example 2" kind of nullifies one of the needs for domains in that respect...

    At least they could have some kind of "NULL" keyword if one doesn't want a "default domain" for a domain (meaning that it should always create .<zone number> suffixes on the outbound directories)...

    THANKYOU!

    You're very welcome! :-D

    It might also have been possible to add the "d" (direct) flavor to the node line, meaning that it should not send packets for that node through any other system. But in general that should not be needed; anything that should not be routed through another system should be marked as direct already by the tosser, by it (the tosser) assigning the flow files "*.d??" filenames. Which of course is common for flow files for polling ("*.dlo").

    Anyway, glad that you got it working! :)

    Best regards
    Zip

    --- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From deon@21:2/116 to TassieBob on Sun Jul 10 23:10:49 2022
    Re: HPT
    By: TassieBob to deon on Sun Jul 10 2022 10:58 pm

    It does, but I still maintain the configuration is unintuitive :-)

    It probably is!

    Ideally you only need to specify "the outbound" and assume its for the first aka, but it hasnt been coded that way :(


    ...δεσ∩
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Al@21:4/106 to TassieBob on Sun Jul 10 07:54:22 2022
    It does, but I still maintain the configuration is unintuitive :-)

    It is. There is a write up about all this in the Binkd FAQ but I think it gets forgotten about.. :)

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Oli@21:3/102 to deon on Sat Jul 23 08:25:40 2022
    deon wrote (2022-07-10):

    Re: HPT
    By: TassieBob to tassiebob on Sun Jul 10 2022 04:48 pm

    Sending a netmail to 1337:2/100, binkd tries to call
    1337:2/100@fsxnet...

    I assume it's defaulting to fsxnet, since that's first listed in my
    binkd config file.

    domain fsxnet /home/bbs/ftn/outbound 21
    domain tqwnet /home/bbs/ftn/outbound 1337

    A trap that gets everybody :)

    The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound" represents.

    Are your sure? If I create a poll for 21:3/100 binkd uses the zone number to figure out the domain.

    Its normal to use the same "outbound" for all your zones (/home/bbs/ftn/outbound) in your case, and the number on the end should
    be what it represents by default. If that is zone 21, then *every* domain line should have 21 for each different domain.

    Which is only a workaround and I saw weird things happening. binkd is a 5D mailer that doesn't implement 5D BSO correctly. It's just a mess.

    ---
    * Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (21:3/102)
  • From deon@21:2/116 to Oli on Sat Jul 23 21:50:18 2022
    Re: HPT
    By: Oli to deon on Sat Jul 23 2022 08:25 am

    The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound"
    represents.

    Are your sure? If I create a poll for 21:3/100 binkd uses the zone number to figure out the domain.

    Yes.

    If you have:

    domain fsxnet /home/bbs/ftn/outbound 21

    Binkd knows to find any outbound files in /home/bbs/ftn/outbound for that zone, named 00030064.*

    If you were sending to 22:3/100, then binkd would look in /home/bbs/ftn/outbound.016 named 00030064.*

    It actually makes sense to me why it was implemented this way, but it isnt an obvious conclusion for the newby.


    ...δεσ∩
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Oli@21:3/102 to deon on Sun Jul 24 19:56:36 2022
    deon wrote (2022-07-23):

    Re: HPT
    By: Oli to deon on Sat Jul 23 2022 08:25 am

    The number at the end (21 and 1337) is *not* the zone number for
    the domain, it is the zone number that this "outbound"
    represents.

    Are your sure? If I create a poll for 21:3/100 binkd uses the zone
    number to figure out the domain.

    Yes.

    If you have:

    domain fsxnet /home/bbs/ftn/outbound 21

    Binkd knows to find any outbound files in /home/bbs/ftn/outbound for that zone, named 00030064.*

    If you were sending to 22:3/100, then binkd would look in /home/bbs/ftn/outbound.016 named 00030064.*

    It actually makes sense to me why it was implemented this way, but it
    isnt an obvious conclusion for the newby.

    If binkd is configured for 4D, which means using the wrong zone number for all other domains, you might be right. In proper 5D setup it also defines the default domain for the zone number. Not only for files in the outbound, but also for addresses in the config files (address, node keyword).

    Let's say I have

    domain fidonet /ftn/fidonet 2
    domain dognet /ftn/dognet 6
    domain fleanet /ftn/fleanet 6

    address 2:...
    address 6:100/200
    node 6:100/232 ...
    node 6:50/40@fleanet ...

    binkd appends @dognet to all adresses that don't have a domain and start with the zone number "6:".

    "binkd -P 6:100/232" polls node 6:100/232@dognet and send the aka 6:100/200@dognet.
    "binkd -P 6:50/40" creates a poll for 6:50/40@dognet, but there would be no node to poll.
    "binkd -P 6:50/40@fleanet" polls 6:50/40@fleanet, but there is no AKA defined for the network.


    Yes. it is not wrong that

    the number at the end
    - is *not* (necessarily) the zone number for the domain
    - it is the zone number that the outbound (without extension) represents

    but

    - every zone number has also a default domain. Which is kind of the zone number for the domain in 5D, but not exactly.

    binkd somehow uses the domain in the configured AKAs too, to figure out the domain part. I don't know what has precedence over what. It's indeed a bit unintuitive.

    Btw, if you want to use standard conform 5D BSO, you also have to use the wrong zone number workaround. Something like:

    domain fidonet /ftn/fidonet 2
    domain fsxnet /ftn/fsxnet 2

    or

    domain fidonet /ftn/fidonet 2
    domain fsxnet /ftn/fsxnet 65535

    (binkd allows even bigger zone numbers than 2¹⁶ in the config)





    ---
    * Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (21:3/102)