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)

SEEN-BY: 57/0 103/705 153/250 154/10 203/0 220/70 221/0 1 6 242 360 229/101 SEEN-BY: 229/426 230/0 240/5832 267/800 280/464 5003 5555 288/100 292/854 SEEN-BY: 310/31 317/3 320/219 340/1000 396/45 423/81 120 633/280 640/1138 SEEN-BY: 640/1321 1384 712/848 770/0 1 100 340 772/0 1 210 500 2452/250 SEEN-BY: 3634/12

SEEN-BY: 116/116 123/25 755 135/300 153/7715 154/10 3634/15 27 50 119 123/115 SEEN-BY: 300/4 123/180 299/6 123/126 200 222/2 250/1 240/1120 712/1321
SEEN-BY: 275/1000 3634/56 57 12 0 18/0 123/0 1/120

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)