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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

File traffic is not like message traffic, you will only get new files when one
of the FDN hatches out new files. There was a new Binkd hatched for the OS/2 >version of binkd recently.

Is this hatched as an executable, or do you have to be able to compile it
on the OS/2 box?

I have been using IREX for this but the daemon mode eats a lot of resources
and slows the BBS down. Would like to try to get away from using it.

Mike


* SLMR 2.1a * Photons have mass? I didn't know they were Catholic...
--- SBBSecho 3.11-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)

Hello Dumas,

File traffic is not like message traffic, you will only get new files
when one of the FDN hatches out new files. There was a new Binkd
hatched for the OS/2 version of binkd recently.

Is this hatched as an executable, or do you have to be able to compile
it on the OS/2 box?

It is an OS/2 executible with a sample binkd.cfg and libbz2.dll.

It's requestable from here as BINKD104.ZIP. I don't have an OS/2 setup so I haven't tried it.

I have been using IREX for this but the daemon mode eats a lot of resources and slows the BBS down. Would like to try to get away from using it.

It's been a long time since I ran OS/2 but even then binkd was my mailer of choice. :)

That file arrived here in the GFD.FTN.MAIL area in the GFD (German File Distribution) FDN. There are many areas in that FDN for all types of files for OS/2 and is active.

That is a Fidonet FDN but it's not on the Filegate. If you (or anyone) would like to link for that (or other file/mail areas) we can do that.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: OS/2 version
By: Dumas Walker to ALAN IANSON on Sat May 02 2020 10:45:00

I have been using IREX for this but the daemon mode eats a lot of

resources

and slows the BBS down. Would like to try to get away from using it.

getting away from IREX is a GoodThing<tm> in any case... it isn't supported, has numerous documented bugs, and has some defect with its binkp1.1 support that other binkp mailers have to work around...


)\/(ark
--- SBBSecho 3.11-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

It is an OS/2 executible with a sample binkd.cfg and libbz2.dll.
It's requestable from here as BINKD104.ZIP. I don't have an OS/2 setup
so I haven't tried it.
That is a Fidonet FDN but it's not on the Filegate. If you (or anyone) would like to link for that (or other file/mail areas) we can do that.

I would like a link for it.

Thank you!

ACME BBS-Member of fsxNet/WWIVNet/SciNet/AmigaNet/VKRadio/FidoNet/MicroNet.

--- Mystic BBS v1.12 A46 2020/04/21 (Windows/32)
* Origin: ACME BBS-W.Coyote & D.Brown are our best users. (1:340/1000)

Hello mark,

On Saturday May 02 2020 19:23, you wrote to Dumas Walker:

getting away from IREX is a GoodThing<tm> in any case... it isn't supported, has numerous documented bugs, and has some defect with its binkp1.1 support that other binkp mailers have to work around...

Plus that it doesn't do IPv6 and in all likehood never will. Binkd supports IPv6 from version 1.00 up and for me that was the deciding factor in parting with Irex and converting my system from AMA to BSO now well over half a decade ago.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)