• binkd error

    From Tony Langdon@3:633/410 to All on Wed Jul 3 14:40:22 2019
    I've been running binkd fairly successfully for 2.5 years on this system, and for the most part, it's been flawless. However, on polling one particular uplink, I've started getting a strange error, which is not giving me a lot of clues.

    This only happens with one particular uplink, as far as I can tell, and because the error appears to refer to DNS lookups, I've tried things like hardcoding entries in my hosts file, and even using the raw IP:PORT in binkd.conf.
    Anyway, this is the error I get:


    03 Jul 14:27:02 [16069] started client #1, id=16166
    03 Jul 14:27:02 [16166] created /sbbs/binkd/fsxnet.015/00010064.csy
    + 03 Jul 14:27:02 [16166] call to 21:1/100@fsxnet
    + 03 Jul 14:27:02 [16166] getaddrinfo failed: Servname not supported for ai_socktype (-8)
    + 03 Jul 14:27:02 [16166] holding 21:1/100@fsxnet (2019/07/03 14:37:02)
    03 Jul 14:27:02 [16166] unlinked `/sbbs/binkd/fsxnet.015/00010064.csy'
    03 Jul 14:27:02 [16166] bsy_remove_all: done
    03 Jul 14:27:02 [16069] rc(16166)=0

    I'm not sure what "Servname not supported for..." means. Google was very vague on this, and why it's only appeared in the last month or so is baffling me. Looking up the offending hostname in DNS manually using nslookup and friends works fine.

    This is the version I'm running.

    01 Jan 17:30:14 [20916] BEGIN, binkd/1.0.4/Linux -P 3:633/280 binkd.conf
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Richard Menedetter@2:310/31 to Tony Langdon on Wed Jul 3 09:20:00 2019
    Hi Tony!

    03 Jul 2019 14:40, from Tony Langdon -> All:

    + 03 Jul 14:27:02 [16166] getaddrinfo failed: Servname not supported
    for ai_socktype (-8)

    Indeed strange ... ai_socktype should be TCP/UDP:
    ai_socktype
    This field specifies the preferred socket type, for example SOCK_STREAM or SOCK_DGRAM. Specifying 0 in this field indicates that socket addresses of any type can be returned by getaddrinfo().

    I do not think it has something to do with BinkD.
    It is just an error that your OS (Linux?) reports back to BinkD.
    The question is why ... to be honest I have no clue.
    Easiest would be to hardcode an IPv4 address ... that should work by eliminating the DNS query.

    If you want to get to the bottom of this you could use ltrace to trace what calls are done, and take a look what is in the call that fails.

    It could also be an IPv4/IPv6 issue maybe??

    Keep us informed ...

    CU, Ricsi

    ... Channel your imagination into ever-soaring levels of paranoia.
    --- GoldED+/LNX
    * Origin: My wife's other car is a broom! (2:310/31)
  • From Tony Langdon@3:633/410 to Richard Menedetter on Wed Jul 3 18:24:00 2019
    On 07-03-19 09:20, Richard Menedetter wrote to Tony Langdon <=-

    + 03 Jul 14:27:02 [16166] getaddrinfo failed: Servname not supported
    for ai_socktype (-8)

    Indeed strange ... ai_socktype should be TCP/UDP:
    ai_socktype
    This field specifies the preferred socket type, for example SOCK_STREAM
    or SOCK_DGRAM. Specifying 0 in this field indicates that socket
    addresses of any type can be returned by getaddrinfo().

    OK.

    I do not think it has something to do with BinkD.
    It is just an error that your OS (Linux?) reports back to BinkD.
    The question is why ... to be honest I have no clue.
    Easiest would be to hardcode an IPv4 address ... that should work by eliminating the DNS query.

    Tried that, still getting the error.

    If you want to get to the bottom of this you could use ltrace to trace what calls are done, and take a look what is in the call that fails.

    Hmm, not a tool I'm familiar with. :(

    It could also be an IPv4/IPv6 issue maybe??

    Maybe, though I've been fully native IPv4/IPv6 capable for 8 years, and the really weird part is everything worked until recently, and there's nothing I recall changing. It also only affects one uplink, the rest poll fine.


    ... Apathy Error: Strike any key...or none, for that matter.
    === MultiMail/Win v0.51
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Kees van Eeten@2:280/5003.4 to Tony Langdon on Wed Jul 3 12:31:46 2019
    Hello Tony!

    03 Jul 19 14:40, you wrote to All:

    This only happens with one particular uplink, as far as I can tell, and because the error appears to refer to DNS lookups, I've tried things like hardcoding entries in my hosts file, and even using the raw IP:PORT in binkd.conf. Anyway, this is the error I get:


    03 Jul 14:27:02 [16069] started client #1, id=16166
    03 Jul 14:27:02 [16166] created /sbbs/binkd/fsxnet.015/00010064.csy
    + 03 Jul 14:27:02 [16166] call to 21:1/100@fsxnet
    + 03 Jul 14:27:02 [16166] getaddrinfo failed: Servname not supported for ai_socktype (-8)

    I tried 3:633/410 and 3:633/280 and got IPv6 connections on both.
    You are however calling 21:1/100@fsxnet. I have no way to check what
    is in your binkd.conf for that node,

    I expect Servname to be the service port (eg 24554) and the socket type
    either for ipv4 or ipv6.

    I tried 3:633/280 with an arbitrary port number, that resulted in
    connection refused.

    + 03 Jul 14:27:02 [16166] holding 21:1/100@fsxnet (2019/07/03
    14:37:02)
    03 Jul 14:27:02 [16166] unlinked `/sbbs/binkd/fsxnet.015/00010064.csy'
    03 Jul 14:27:02 [16166] bsy_remove_all: done
    03 Jul 14:27:02 [16069] rc(16166)=0

    I'm not sure what "Servname not supported for..." means. Google was very vague on this, and why it's only appeared in the last month or so is baffling me. Looking up the offending hostname in DNS manually using nslookup and friends works fine.

    This is the version I'm running.

    01 Jan 17:30:14 [20916] BEGIN, binkd/1.0.4/Linux -P 3:633/280 binkd.conf

    O.K. that is your local system, not the server for 3:633/410
    It could use an upgrade on the version of Binkd.

    Why does it say: "call to 21:1/100@fsxnet", when you are polling 3:633/410

    Sorry, just more questions and no answers to your problem.

    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au
    (3:633/410)

    Kees

    --- GoldED+/LNX 1.1.5--b20180707
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Wilfred van Velzen@2:280/464 to Tony Langdon on Wed Jul 3 12:12:26 2019
    Hi Tony,

    On 2019-07-03 18:24:00, you wrote to Richard Menedetter:

    It also only affects one uplink, the rest poll fine.

    What's the hostname of the problem uplink?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tony Langdon@3:633/410 to Kees van Eeten on Wed Jul 3 22:00:00 2019
    On 07-03-19 12:31, Kees van Eeten wrote to Tony Langdon <=-

    I tried 3:633/410 and 3:633/280 and got IPv6 connections on both.
    You are however calling 21:1/100@fsxnet. I have no way to check what
    is in your binkd.conf for that node,

    Yeah, 3:633/280 is my Fidonet uplink, and I'm having no issues there. The other address is me. ;)

    I expect Servname to be the service port (eg 24554) and the socket
    type
    either for ipv4 or ipv6.

    Only difference is 21:1/100 uses port 24556.

    I tried 3:633/280 with an arbitrary port number, that resulted in
    connection refused.

    This is the version I'm running.

    01 Jan 17:30:14 [20916] BEGIN, binkd/1.0.4/Linux -P 3:633/280 binkd.conf

    O.K. that is your local system, not the server for 3:633/410
    It could use an upgrade on the version of Binkd.

    Same thing. :)

    Why does it say: "call to 21:1/100@fsxnet", when you are polling 3:633/410

    Not taken from the same part of the log, that's all. :)
    * Origin: As for me, all I know is that, I know nothing.
    (2:280/5003.4)

    ... I'm so hungry, I could eat a... Wait! Come back, @FN@!
    === MultiMail/Win v0.51
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Tony Langdon@3:633/410 to Wilfred van Velzen on Wed Jul 3 22:03:00 2019
    On 07-03-19 12:12, Wilfred van Velzen wrote to Tony Langdon <=-

    Hi Tony,

    On 2019-07-03 18:24:00, you wrote to Richard Menedetter:

    It also only affects one uplink, the rest poll fine.

    What's the hostname of the problem uplink?

    agency.bbs.nz:24556


    ... Everybody should believe in something - I believe I'll have a beer
    === MultiMail/Win v0.51
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Wilfred van Velzen@2:280/464 to Tony Langdon on Thu Jul 4 09:25:03 2019
    Hi Tony,

    On 2019-07-03 22:03:00, you wrote to me:

    What's the hostname of the problem uplink?

    agency.bbs.nz:24556

    I created a fake node in my binkd config to be able to make a poll:

    04 Jul 09:21:27 [24676] BEGIN, binkd/1.1a-95/Linux -p -P 999:999/999 /home/fido/etc/binkd.conf
    ? 04 Jul 09:21:27 [24676] Cannot find domain for zone 999, assuming 'fidonet'
    04 Jul 09:21:27 [24676] creating a poll for 999:999/999@fidonet (`d' flavour)
    04 Jul 09:21:27 [24676] clientmgr started
    + 04 Jul 09:21:27 [24677] call to 999:999/999@fidonet
    04 Jul 09:21:27 [24678] 999:999/999@TestNet busy, skipping
    04 Jul 09:21:27 [24676] rc(24678)=0
    + 04 Jul 09:21:28 [24677] getaddrinfo failed: Name or service not known (-2)
    04 Jul 09:21:28 [24676] rc(24677)=0
    04 Jul 09:21:28 [24676] the queue is empty, quitting...
    + 04 Jul 09:21:29 [24680] call to 999:999/999@TestNet
    04 Jul 09:21:29 [24680] trying agency.bbs.nz [2001:470:d:123::50]:24556...
    04 Jul 09:21:30 [24680] connected
    + 04 Jul 09:21:30 [24680] outgoing session with agency.bbs.nz:24556 [2001:470:d:123::50]
    - 04 Jul 09:21:32 [24680] OPT CRAM-MD5-34fac41297577203a092a5e56776c69f
    + 04 Jul 09:21:32 [24680] Remote requests MD mode
    - 04 Jul 09:21:32 [24680] SYS fsxHUB Risa [NET1]
    - 04 Jul 09:21:32 [24680] ZYZ Avon
    - 04 Jul 09:21:32 [24680] TIME Thu, 04 Jul 2019 19:21:25 1200
    - 04 Jul 09:21:32 [24680] VER Mystic/1.12A43 binkp/1.0
    - 04 Jul 09:21:32 [24680] BUILD 2019/03/03 01:35:01 Windows/32
    + 04 Jul 09:21:32 [24680] addr: 21:1/100@fsxnet (n/a or busy)
    + 04 Jul 09:21:32 [24680] addr: 21:1/3@fsxnet (n/a or busy)
    + 04 Jul 09:21:32 [24680] addr: 21:1/2@fsxnet (n/a or busy)
    + 04 Jul 09:21:32 [24680] addr: 21:1/0@fsxnet (n/a or busy)
    + 04 Jul 09:21:32 [24680] addr: 21:0/0@fsxnet (n/a or busy)
    ? 04 Jul 09:21:32 [24680] no AKAs in common domains or all AKAs are busy
    + 04 Jul 09:21:32 [24680] done (to 999:999/999@TestNet, failed, S/R: 0/0 (0/0 bytes))
    04 Jul 09:21:32 [24680] session closed, quitting...

    Interestingly at first I get the same response. But after that it just works, and keeps on working...?


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tony Langdon@3:633/410 to Wilfred van Velzen on Thu Jul 4 20:24:00 2019
    On 07-04-19 09:25, Wilfred van Velzen wrote to Tony Langdon <=-

    Interestingly at first I get the same response. But after that it just works, and keeps on working...?

    Strange.


    ... And on the 8th day God said, "Murphy, you're in charge."
    === MultiMail/Win v0.51
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Richard Menedetter@2:310/31 to Tony Langdon on Thu Jul 4 15:09:22 2019
    Hi Tony!

    03 Jul 2019 18:24, from Tony Langdon -> Richard Menedetter:

    If you want to get to the bottom of this you could use ltrace to
    trace what calls are done, and take a look what is in the call
    that fails.
    Hmm, not a tool I'm familiar with. :(

    It just outputs all library calls that the binary does.

    Try "ltrace date" and you see the library calls date makes.
    You also see the options and result codes.

    CU, Ricsi

    ... Microwave ovens: consolation prize in our struggle to understand physics. --- GoldED+/LNX
    * Origin: Put on your seatbelt ... I want to try something new. (2:310/31)
  • From Richard Menedetter@2:310/31 to Tony Langdon on Thu Jul 4 15:16:46 2019
    Hi Tony!

    03 Jul 2019 22:03, from Tony Langdon -> Wilfred van Velzen:

    What's the hostname of the problem uplink?
    agency.bbs.nz:24556

    I have no issues at all connecting to Paul:
    + 15:16 [22774] call to 3:770/1@fidonet
    15:16 [22774] trying agency.bbs.nz [2001:470:d:123::50]...
    15:16 [22774] connected
    + 15:16 [22774] outgoing session with agency.bbs.nz:24554 [2001:470:d:123::50]

    Why Port 24556???

    CU, Ricsi

    ... There's a dead fly swimming in my soup! Nonsense dead flies can't swim!
    --- GoldED+/LNX
    * Origin: We grow because we struggle, learn and overcome. (2:310/31)
  • From Wilfred van Velzen@2:280/464 to Richard Menedetter on Thu Jul 4 15:24:44 2019
    Hi Richard,

    On 2019-07-04 15:16:46, you wrote to Tony Langdon:

    What's the hostname of the problem uplink?
    agency.bbs.nz:24556

    I have no issues at all connecting to Paul:
    + 15:16 [22774] call to 3:770/1@fidonet
    15:16 [22774] trying agency.bbs.nz [2001:470:d:123::50]...
    15:16 [22774] connected
    + 15:16 [22774] outgoing session with agency.bbs.nz:24554 [2001:470:d:123::50]

    Why Port 24556???

    There's a different system on that port, and that's where Tony had the problem...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From mark lewis@1:3634/12.73 to Richard Menedetter on Thu Jul 4 13:14:54 2019

    On 2019 Jul 04 15:16:46, you wrote to Tony Langdon:

    What's the hostname of the problem uplink?
    agency.bbs.nz:24556

    I have no issues at all connecting to Paul:
    + 15:16 [22774] call to 3:770/1@fidonet
    15:16 [22774] trying agency.bbs.nz [2001:470:d:123::50]...
    15:16 [22774] connected
    + 15:16 [22774] outgoing session with agency.bbs.nz:24554 [2001:470:d:123::50]

    Why Port 24556???

    because there's more than one system running on the same IP and if you don't use the right port, you won't be talking to the proper system when you poll... you cannot forward a port to more than one internal IP...

    )\/(ark

    And to this end they built themselves a stupendous super-computer which was
    so amazingly intelligent that even before its data banks had been connected
    up it had started from "I think therefore I am" and got as far as deducing
    the existence of rice pudding and income tax before anyone managed to turn
    it off.
    ... Marketers are shameless and whorelike and borderline insane.
    ---
    * Origin: (1:3634/12.73)
  • From Dan Cross@3:770/100 to Tony Langdon on Thu Jan 30 06:12:25 2020
    On 03 Jul 2019 at 02:40p, Tony Langdon pondered and said...

    I've been running binkd fairly successfully for 2.5 years on this
    system, and for the most part, it's been flawless. However, on polling one particular uplink, I've started getting a strange error, which is
    not giving me a lot of clues.

    I ran into this today. The root cause is a use-after-free bug in
    binkd; this bug has been present since sometime in 2001 according
    to the git history. Most people probably won't notice it unless
    your system's malloc() is aggressive about poisoning memory returned
    by free().

    I've sent a pull request to fix it upstream. https://github.com/pgul/binkd/pull/16

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Tony Langdon@3:633/410 to Dan Cross on Thu Jan 30 11:07:00 2020
    On 01-30-20 06:12, Dan Cross wrote to Tony Langdon <=-

    I ran into this today. The root cause is a use-after-free bug in
    binkd; this bug has been present since sometime in 2001 according
    to the git history. Most people probably won't notice it unless
    your system's malloc() is aggressive about poisoning memory returned
    by free().

    Ahh, OK. Good find by the looks of it.

    I've sent a pull request to fix it upstream. https://github.com/pgul/binkd/pull/16

    Hopefully I can get hold of the fixed source. I've had to take a number of measures like restricting callouts to the affected node to IPv4 only, and also hardcoding the IPv4 IP in the node entry, because DNS lookups were also problematic for the affected node..

    A second link running over ZeroTier started showing similar issues recently, but switching that link to connect directly across the open Internet was enough to get that link working.

    It's odd that it only affects some links.

    My system is a fairly busy Pi that's running 2 BBSs, which may explain why malloc() is being a bit aggressive. :)


    ... Cut my pizza into six pieces please. I can't eat eight.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Dan Cross@3:770/100 to Tony Langdon on Thu Jan 30 15:55:06 2020
    On 30 Jan 2020 at 11:07a, Tony Langdon pondered and said...

    I've sent a pull request to fix it upstream. https://github.com/pgul/binkd/pull/16

    Hopefully I can get hold of the fixed source. I've had to take a number of measures like restricting callouts to the affected node to IPv4 only, and also hardcoding the IPv4 IP in the node entry, because DNS lookups were also problematic for the affected node..

    With luck, the upstream maintainer will address the pull request quickly, either by applying my patches or coming up with another fix. If you need
    this quickly, however, you could clone my fork (https://github.com/fat-dragon/binkd.git) and build from source.

    A second link running over ZeroTier started showing similar issues recently, but switching that link to connect directly across the open Internet was enough to get that link working.

    It's odd that it only affects some links.

    The code path with the use-after-free was dependent on the source of
    the information. If you used the default port, the pointer in question
    would end up pointing to memory that wasn't free()'d; if you used a non-standard port in your configuration file (e.g., `agency.bbs.bz:24556`), you'd tickle the bug; hence why it doesn't show up everyhwere.

    My system is a fairly busy Pi that's running 2 BBSs, which may explain
    why malloc() is being a bit aggressive. :)

    A memory-intensive workload will likely put pressure on the operating
    system's virtual memory subsystem (note, VM in the general sense, not
    specific to e.g. swap space), but is unlikely to significantly affect
    malloc(). While some malloc() implementations do go to pains to work
    with the VM system to return memory to the OS under pressure, this is necessarily on a page boundary and it's likely other short strings had
    been allocated on that same page (at least, this was what I observed
    on my system).

    Rather the aggressiveness I mentioned with respect to free()'d memory
    has to do with the malloc() implementation writing garbage into the
    free()'d region of memory, precisely to detect these sorts of
    use-after-free issues.

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alexander Kruglikov@2:5053/58 to Dan Cross on Thu Jan 30 10:24:48 2020
    Good ${greeting_time}, Dan!

    30 Jan 20 06:12, you wrote to Tony Langdon:

    I've sent a pull request to fix it upstream. https://github.com/pgul/binkd/pull/16

    Yippee! I cloned binkd from your forked repo, compiled - and everything works! Thank you very much again here again! =))

    With best regards, Alexander.

    --- "GoldED+/LNX 1.1.5-b20180707" ---
    * Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58)
  • From Tony Langdon@3:633/410 to Dan Cross on Thu Jan 30 21:17:00 2020
    On 01-30-20 15:55, Dan Cross wrote to Tony Langdon <=-

    With luck, the upstream maintainer will address the pull request
    quickly, either by applying my patches or coming up with another fix.
    If you need this quickly, however, you could clone my fork (https://github.com/fat-dragon/binkd.git) and build from source.

    Building from source is not an issue, mine is built from source anyway. :)

    The code path with the use-after-free was dependent on the source of
    the information. If you used the default port, the pointer in question would end up pointing to memory that wasn't free()'d; if you used a non-standard port in your configuration file (e.g., `agency.bbs.bz:24556`), you'd tickle the bug; hence why it doesn't show
    up everyhwere.

    Interesting, and the FSX hub does use a non standard port, from memory. Reducing path latency to a minimum seems to help.

    Rather the aggressiveness I mentioned with respect to free()'d memory
    has to do with the malloc() implementation writing garbage into the free()'d region of memory, precisely to detect these sorts of use-after-free issues.

    That, I don't know. :)


    ... Back Up My Hard Drive? I Can't Find The Reverse Switch!
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Dan Cross@3:770/100 to Alexander Kruglikov on Fri Jan 31 03:21:42 2020
    On 30 Jan 2020 at 10:24a, Alexander Kruglikov pondered and said...

    Yippee! I cloned binkd from your forked repo, compiled - and everything works! Thank you very much again here again! =))

    Sure thing. Just FYI, that pgul merged that PR into the master repo,
    so I recommend going back to that....

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alexander Kruglikov@2:5053/58 to Dan Cross on Thu Jan 30 21:41:20 2020
    Good ${greeting_time}, Dan!

    *** Answering a msg posted in area CarbonArea.

    31 Jan 20 03:21, you wrote to me:

    Yippee! I cloned binkd from your forked repo, compiled - and
    everything works! Thank you very much again here again! =))
    Sure thing. Just FYI, that pgul merged that PR into the master repo,
    so I recommend going back to that....

    Yes, I've already compile and tested version from the main repository.
    But thank you all the same!

    With best regards, Alexander.

    --- "GoldED+/LNX 1.1.5-b20180707" ---
    * Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58)
  • From Max Vasilyev@2:5057/77 to Dan Cross on Thu Jan 30 22:36:24 2020
    Hello Dan!

    30 Jan 20 06:12, you wrote to Tony Langdon:

    I've sent a pull request to fix it upstream. https://github.com/pgul/binkd/pull/16
    binkd/win9x won't compile anymore

    binkd type : msvc, binkd9x, static
    output dir : bin\msvc-binkd9x-static
    binkd exe : binkd9x-static.exe -----------------------------------------------------------
    Compiling:
    client.c
    client.c(224) : error C2039: 'ss_family' : is not a member of 'sockaddr_in'
    \MSVC6\VC98\INCLUDE\winsock.h(309) : see declaration of 'sockaddr_in'

    WBR, Max. piwamoto!»¿ßѼ-¡ÑΓ
    --- ߬πτáε »« FleetStreet'π :-(((
    * Origin: Personal Reality (2:5057/77)
  • From Tommi Koivula@2:221/0.1 to Dan Cross on Thu Jan 30 20:01:30 2020
    Hi Dan.

    30 Jan 20 22:36:24, Max Vasilyev wrote to you:

    I've sent a pull request to fix it upstream.
    https://github.com/pgul/binkd/pull/16

    binkd/win9x won't compile anymore

    binkd type : msvc, binkd9x, static
    output dir : bin\msvc-binkd9x-static
    binkd exe : binkd9x-static.exe -----------------------------------------------------------
    Compiling:
    client.c
    client.c(224) : error C2039: 'ss_family' : is not a member of
    'sockaddr_in'
    \MSVC6\VC98\INCLUDE\winsock.h(309) : see declaration of
    'sockaddr_in'

    And OS/2:

    === Cut ===
    Compiling binkd.c...
    Compiling readcfg.c...
    Compiling tools.c...
    Compiling ftnaddr.c...
    Compiling ftnq.c...
    Compiling client.c...
    client.c: In function `clientmgr':
    client.c:224: error: structure has no member named `ss_family'
    make.exe: *** [client.o] Error 1
    === Cut ===

    :(

    'Tommi

    ---
    * Origin: Point One, Le Gros-Theil, France (2:221/0.1)
  • From Dan Cross@3:770/100 to Max Vasilyev on Fri Jan 31 08:09:35 2020
    On 30 Jan 2020 at 10:36p, Max Vasilyev pondered and said...

    Hello Dan!

    30 Jan 20 06:12, you wrote to Tony Langdon:

    I've sent a pull request to fix it upstream. https://github.com/pgul/binkd/pull/16
    binkd/win9x won't compile anymore

    binkd type : msvc, binkd9x, static
    output dir : bin\msvc-binkd9x-static
    binkd exe : binkd9x-static.exe -----------------------------------------------------------
    Compiling:
    client.c
    client.c(224) : error C2039: 'ss_family' : is not a member of 'sockaddr_in' \MSVC6\VC98\INCLUDE\winsock.h(309) : see declaration of 'sockaddr_in'

    Sorry, I can't assist with win9x; that is very old and I'm not
    in a position to support it. However, I think I see a relatively
    simple fix. https://github.com/pgul/binkd/pull/17 may fix it,
    specifically the 'Defines for people using ancient systems',
    commit hash c90a4dd if you want to try patching and rebuilding.

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Dan Cross@3:770/100 to Tommi Koivula on Fri Jan 31 08:10:56 2020
    On 30 Jan 2020 at 08:01p, Tommi Koivula pondered and said...

    And OS/2:

    Please try commit c90a4dd in https://github.com/pgul/binkd/pull/17;
    that might address the issue. Like win9x, I'm not in a position to
    support OS/2, either, but the fix should be the same.

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Tommi Koivula@2:221/6 to Dan Cross on Fri Jan 31 09:29:02 2020
    Hi Dan.

    31 Jan 20 08:10, you wrote to me:

    On 30 Jan 2020 at 08:01p, Tommi Koivula pondered and said...

    And OS/2:

    Please try commit c90a4dd in https://github.com/pgul/binkd/pull/17;

    I will, but not today. ;)

    'Tommi

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: nntps://news.fidonet.fi (2:221/6)
  • From Torsten Bamberg@2:240/5832 to Dan Cross on Sat Feb 1 12:15:31 2020
    Hallo Dan!

    31.01.2020 08:10, Dan Cross schrieb an Tommi Koivula:

    And OS/2:
    Please try commit c90a4dd in https://github.com/pgul/binkd/pull/17;
    that might address the issue. Like win9x, I'm not in a position to support OS/2, either, but the fix should be the same.
    Well, something doesn't fit.
    I used the current binkd sources from cvs.


    =##= Anfang "_comp.txt" =##=
    Build Makefile.dep...
    Compiling binkd.c...
    Compiling readcfg.c...
    Compiling tools.c...
    Compiling ftnaddr.c...
    Compiling ftnq.c...
    Compiling client.c...
    client.c: In function `clientmgr':
    client.c:224: error: structure has no member named `ss_family'
    make: *** [client.o] Error 1
    =##= Ende "_comp.txt" =##=


    =##= Anfang "_gcc.txt" =##=
    Reading specs from E:/GCC/gcc3/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5/specs Configured with: D:/CODING/LIBC/0.6/src/gcc/configure --enable-clh --enable-threads=os2 --enable-shared=libgcc,bfd,opcodes --enable-nls --without-included-gettext --with-local-prefix=D:/CODING/LIBC/0.6/TOOLS/x86.os2/gcc/staged --prefix=/gcc --with-gnu-as --disable-libgcj --enable-languages=c,c++
    Thread model: os2
    gcc version 3.3.5 (Bird Build 2014-10-26 18:53 (csd6))
    =##= Ende "_gcc.txt" =##=


    Bye/2 Torsten

    ... MAILBOX01: up 7d 12h 20m load: 37 proc, 132 threads (tbup1.1)
    --- GoldED+ 1.1.5-19
    * Origin: DatenBahn BBS Hamburg (2:240/5832)
  • From Tommi Koivula@2:221/0.1 to Dan Cross on Sat Feb 1 13:33:48 2020
    Hi Dan.

    31 Jan 20 08:10:56, you wrote to me:

    On 30 Jan 2020 at 08:01p, Tommi Koivula pondered and said...

    And OS/2:

    Please try commit c90a4dd in https://github.com/pgul/binkd/pull/17;

    Compiling binkd.c...
    Compiling readcfg.c...
    Compiling tools.c...
    Compiling ftnaddr.c...
    Compiling ftnq.c...
    Compiling client.c...
    client.c: In function `clientmgr':
    client.c:224: error: structure has no member named `sa_family'
    make.exe: *** [client.o] Error 1

    that might address the issue.

    Nope.

    'Tommi

    ---
    * Origin: Point One, Le Gros-Theil, France (2:221/0.1)
  • From Dan Cross@3:770/100 to Torsten Bamberg on Sun Feb 2 02:33:54 2020
    On 01 Feb 2020 at 12:15p, Torsten Bamberg pondered and said...

    Hallo Dan!

    And OS/2:
    Please try commit c90a4dd in https://github.com/pgul/binkd/pull/17; that might address the issue. Like win9x, I'm not in a position to support OS/2, either, but the fix should be the same.
    Well, something doesn't fit.
    I used the current binkd sources from cvs.

    Yes, my pull request hasn't made it to CVS yet. :-/

    --- Mystic BBS v1.12 A44 2020/01/31 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Dan Cross@3:770/100 to Tommi Koivula on Sun Feb 2 02:40:50 2020
    On 01 Feb 2020 at 01:33p, Tommi Koivula pondered and said...

    Compiling client.c...
    client.c: In function `clientmgr':
    client.c:224: error: structure has no member named `sa_family'
    make.exe: *** [client.o] Error 1

    I'm sorry, I really have no idea. That's been the name of the
    structure member since at least BSD 4.1c, ca 1982.

    My guess is that your system actually names the structure member
    something else, and then #define's `sa_family` to whatever that
    non-standard name is. My workaround is to `#define ss_family sa_family`,
    but that preprocessor substitution probably happens after all of
    the renaming the system libraries do.

    One can play games with casts. For example, if you change line
    224 of client.c to read something like:

    ((struct sockaddr *)(&invalidAddreses[0]))->sa_family = AF_INET;

    It may compile. I haven't tested that, though.

    --- Mystic BBS v1.12 A44 2020/01/31 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Torsten Bamberg@2:240/5832 to Dan Cross on Sat Feb 1 23:36:31 2020
    Hallo Dan!

    02.02.2020 02:33, Dan Cross schrieb an Torsten Bamberg:

    Yes, my pull request hasn't made it to CVS yet. :-/
    I patched manually, but:


    Build Makefile.dep...
    Compiling binkd.c...
    Compiling readcfg.c...
    Compiling tools.c...
    Compiling ftnaddr.c...
    Compiling ftnq.c...
    Compiling client.c...
    client.c: In function `clientmgr':
    client.c:224: error: structure has no member named `sa_family'
    make: *** [client.o] Error 1

    Bye/2 Torsten

    ... MAILBOX01: up 7d 21h 27m load: 36 proc, 131 threads (tbup1.1)
    --- GoldED+ 1.1.5-19
    * Origin: DatenBahn BBS Hamburg (2:240/5832)
  • From Dan Cross@3:770/100 to Torsten Bamberg on Sun Feb 2 18:23:41 2020
    On 01 Feb 2020 at 11:36p, Torsten Bamberg pondered and said...

    client.c: In function `clientmgr':
    client.c:224: error: structure has no member named `sa_family'

    This is the same issue the other fellow had; the same solution I
    offered to him might help?

    --- Mystic BBS v1.12 A44 2020/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Tommi Koivula@2:221/0.1 to Torsten Bamberg on Wed Feb 5 20:24:26 2020
    Hi Torsten.

    02 Feb 20 18:23:40, Dan Cross wrote to you:

    On 01 Feb 2020 at 11:36p, Torsten Bamberg pondered and said...

    client.c: In function `clientmgr':
    client.c:224: error: structure has no member named `sa_family'

    This is the same issue the other fellow had; the same solution I
    offered to him might help?

    The other fellow just pulled https://github.com/fat-dragon/binkd.git and it compiled fine with gcc 3.3.5.

    === Cut ===
    Binkd 1.1a-101 (Feb 5 2020 21:20:33/OS2)
    Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm, amiga_4d_outbound, bwlim.
    Facilities: fts5004 rfc2553emu
    === Cut ===

    'Tommi

    ---
    * Origin: Point One, Le Gros-Theil, France (2:221/0.1)
  • From Dan Cross@3:770/100 to Tommi Koivula on Thu Feb 6 15:06:32 2020
    On 05 Feb 2020 at 08:24p, Tommi Koivula pondered and said...

    The other fellow just pulled https://github.com/fat-dragon/binkd.git and it compiled fine with gcc 3.3.5.

    Ah, wonderful to hear. Thanks, other fellow. :-) (Sorry, I blanked on
    your name when replying to the first gentleman.)

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Torsten Bamberg@2:240/5832 to Dan Cross on Thu Feb 6 18:51:28 2020
    Hallo Dan!

    06.02.2020 15:06, Dan Cross schrieb an Tommi Koivula:

    The other fellow just pulled
    https://github.com/fat-dragon/binkd.git and it compiled fine with
    gcc 3.3.5.
    Ah, wonderful to hear. Thanks, other fellow. :-) (Sorry, I blanked
    on your name when replying to the first gentleman.)
    Jep, this repo does work with gcc3/emx.

    binkd.exe -vv says:

    =##= Anfang "binkd.txt" =##=
    Binkd 1.1a-101 (Feb 5 2020 23:42:15/OS2)
    Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm, amiga_4d_outbound, bwlim.
    Facilities: fts5004 rfc2553emu
    =##= Ende "binkd.txt" =##=

    Thanks Dan! :-)

    Bye/2 Torsten

    ... MAILBOX01: up 3d 0h 22m load: 37 proc, 131 threads (tbup1.1)
    --- GoldED+ 1.1.5-19
    * Origin: DatenBahn BBS Hamburg (2:240/5832)
  • From Tommi Koivula@2:221/0.1 to Dan Cross on Thu Feb 6 19:22:46 2020
    Hi Dan.

    06 Feb 20 15:06:32, you wrote to me:

    On 05 Feb 2020 at 08:24p, Tommi Koivula pondered and said...

    The other fellow just pulled https://github.com/fat-dragon/binkd.git and
    it compiled fine with gcc 3.3.5.

    Ah, wonderful to hear. Thanks, other fellow. :-)

    +1 :)

    'Tommi

    ---
    * Origin: Point One, Le Gros-Theil, France (2:221/0.1)
  • From Torsten Bamberg@2:240/5832 to Tommi Koivula on Sat Feb 8 01:38:54 2020
    Hallo Tommi!

    06.02.2020 19:22, Tommi Koivula schrieb an Dan Cross:

    https://github.com/fat-dragon/binkd.git and it compiled fine
    with gcc 3.3.5.
    Ah, wonderful to hear. Thanks, other fellow. :-)
    +1 :)
    Same here. Binkd runs now like a charm.
    Thanks Dan. +1

    'Tommi
    Bye/2 Torsten

    ... MAILBOX01: up 4d 6h 25m load: 34 proc, 128 threads (tbup1.1)
    --- GoldED+ 1.1.5-19
    * Origin: DatenBahn BBS Hamburg (2:240/5832)
  • From Max Vasilyev@2:5057/77 to Dan Cross on Sat Feb 8 14:07:22 2020
    Hello Dan!

    06 Feb 20 15:06, you wrote to Tommi Koivula:

    https://github.com/fat-dragon/binkd.git and it compiled fine with
    gcc 3.3.5.
    Ah, wonderful to hear. Thanks, other fellow. :-)
    Some words about your patch.

    #ifndef sockaddr_storage
    #define sockaddr_storage sockaddr_in
    #endif

    You don't need to add #ifndef here. There is no sockaddr_storage defined, if you have an old compiler without HAVE_GETADDRINFO/HAVE_GETADDRINFO.

    #ifdef AF_INET6
    invalidAddresses[1].ss_family = AF_INET6;
    #endif

    It works with old gcc, but not with MSVC6.
    I suggest to change it to #ifdef _SS_MAXSIZE.

    WBR, Max. piwamoto!»¿ßѼ-¡ÑΓ
    --- ߬πτáε »« FleetStreet'π :-(((
    * Origin: Personal Reality (2:5057/77)
  • From Dan Cross@3:770/100 to Max Vasilyev on Sun Feb 9 01:52:52 2020
    On 08 Feb 2020 at 02:07p, Max Vasilyev pondered and said...

    Some words about your patch.

    Please put these comments on github. The BBS interface is bad
    for code commentary.

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Tommi Koivula@2:221/0.1 to Torsten Bamberg on Sat Feb 8 16:45:34 2020
    Hi Torsten.

    08 Feb 20 01:38:54, you wrote to me:

    Hallo Tommi!

    06.02.2020 19:22, Tommi Koivula schrieb an Dan Cross:

    https://github.com/fat-dragon/binkd.git and it compiled fine
    with gcc 3.3.5.
    Ah, wonderful to hear. Thanks, other fellow. :-)
    +1 :)

    Same here. Binkd runs now like a charm.

    I did not put it in operation yet, I'll wait for the "official" version to appear in cvs.

    And I have no problems with -99 either. :)

    'Tommi

    ---
    * Origin: Point One, Le Gros-Theil, France (2:221/0.1)
  • From Jason Bock@2:280/464 to Tommi Koivula on Tue Feb 11 12:46:52 2020
    SEEN-BY: 57/0 103/705 153/250 154/10 203/0 220/70 221/0 229/101 426 240/5832 SEEN-BY: 267/800 280/464 5003 5555 288/100 292/854 310/31 317/3 340/1000 SEEN-BY: 396/45 423/120 712/848 770/0 1 100 340 772/0 1 210 500 2452/250
  • From Oli@2:280/464.47 to Jason Bock on Wed Feb 12 09:54:52 2020
    11 Feb 20 12:46, you wrote to Tommi Koivula:

    @TID: Mystic BBS 1.12 A43
    ^^^
    people are still using this buggy mess of a tosser? ;)

    @MSGID: 1:267/310@fidonet5E42A22F
    ^^^^
    space missing?

    @REPLY: 2:221/0.1 5e3ed84c
    @PID: Legacy/X Alpha-5

    Something is missing. There is not even an Origin line. Did Legacy/X create an empty message or was the content lost somewhere on the path?

    SEEN-BY: 57/0 103/705 153/250 154/10 203/0 220/70 221/0 229/101 426
    240/5832
    SEEN-BY: 267/800 280/464 5003 5555 288/100 292/854 310/31 317/3 340/1000 SEEN-BY: 396/45 423/120 712/848 770/0 1 100 340 772/0 1 210 500 2452/250 @PATH: 267/310 800 770/1 280/464 464.47
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: kakistocracy (2:280/464.47)
  • From Björn Felten@2:203/2 to Oli on Wed Feb 12 13:50:12 2020
    Something is missing. There is not even an Origin line.

    ACK that. And there was far more errors.

    Path: JamNNTPd!not-for-mail
    From: "Jason Bock -> Tommi Koivula" <0:0/0>
    X-Comment-To: Tommi Koivula
    Newsgroups: BINKD
    Subject: binkd error
    Date: Tue, 11 Feb 2020 11:46:52 GMT
    Message-ID: <466$BINKD@JamNNTPd>
    X-JAM-From: Jason Bock <0:0/0>
    X-JAM-To: Tommi Koivula
    X-JAM-FTSKLUDGE: TID: Mystic BBS 1.12 A43
    X-JAM-MSGID: 1:267/310@fidonet5E42A22F
    X-JAM-REPLYID: 2:221/0.1 5e3ed84c
    X-JAM-PID: Legacy/X Alpha-5
    X-JAM-SEENBY2D: 57/0 103/705 153/250 154/10 201/0 203/0 2 124 220/70 221/0 1 229/101
    X-JAM-SEENBY2D: 229/426 230/0 240/5832 267/800 280/464 5003 5555 288/100 292/854
    X-JAM-SEENBY2D: 310/31 317/3 320/219 340/1000 396/45 423/120 712/848 770/0 1 100 340
    X-JAM-SEENBY2D: 772/0 1 210 500 2452/250
    X-JAM-PATH2D: 267/310 800 770/1 280/464 203/0 2
    X-JAM-Attributes: Sent TypeEcho
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit





    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)