AmiBinkD v10.33 - and where it sits among the other Amiga mailers ------------------------------------------------------------------

AmiBinkD is a port of binkd to AmigaOS 3.x. It talks straight to bsdsocket.library - no ixemul, no ixnet - and runs on real 68k iron or
under emulation. BinkP/1.1, CRAM-MD5, works with any FTN-aware Amiga
BBS.

v10.33 is out. Before the release notes, a word about something that
has come up: AmiBinkD is not the only non-ixemul mailer for the Amiga,
and it was not the first. Worth setting out plainly who has done what,
because three different projects are getting talked about as if they
were the same thing.


WHAT IS ACTUALLY OUT THERE

AmiBinkd v9.02 (2014, X-TReMe BBS)
The original Amiga binkd, and the one people mean when they say
"the old AmiBinkd is buggy". Nothing to do with this project
beyond the name, which I kept because sysops already knew it.
In hindsight that has caused more confusion than it saved.

FidoBlitz (Stephen, v0.19 May 2026)
A native Amiga Binkp/1.1 mailer written in AmiBlitz3. NOT a port
of anything - it is a fresh implementation of the protocol. That
is a different kind of work from what I am doing, and a harder
one in some ways: everything binkd already solved has to be
solved again.

binkd 1.1a-115 noixemul (Ervras, Aminet June 2026)
pgul's binkd adapted to AmigaOS 3.2 without ixemul, built with
bebbo's gcc, requires 68020 or better. Ships extras I do not:
srifreq, process_tic, a nodelist compiler, decompress. His repo
dates from April 2026, so he got a non-ixemul binkd running on
the Amiga before I did. Credit where it is due.

AmiBinkD v10.x (this one)
Also pgul's binkd, also no ixemul. Two differences that matter:

* It builds for plain 68000. No 020 required, no FPU, soft-float
throughout. If you are running a stock A500 or A2000, this is
the one that will start.

* It is deliberately still binkd. 18 of binkd's 34 source files
are untouched, and protocol.c - the binkp engine, 3,769 lines
- carries exactly one Amiga-specific line. Where it does
deviate it is almost always to work around something broken in
the Amiga C library, not to change how binkd behaves.

Two people ported the same program independently without knowing it.
That is how it goes in a hobby this size. Use whichever fits your
machine.


WHAT v10.33 FIXES, AND WHY IT MATTERS TO EVERYONE HERE

For weeks this board had a rare, ugly fault: now and then a write meant
for one file turned up in another. A .bsy lock file was found holding a
line of log text. About 0.2% of log lines - rare enough to look like
cosmic rays, often enough to eventually corrupt something that matters.

Four theories were wrong before the right one. What settled it was a
test that hammered TWO files at once from several Processes. Every
earlier test used a single file and passed cleanly, because with one
file a mixed-up descriptor still resolves to that same file. Two files
and it reproduced in ten seconds: 92 of 1000 log lines lost, and lock
markers written into the log.

The cause is in libnix, not in binkd. Every descriptor comes from
___allocfd, which scans a shared global table for a free slot and grows
it with realloc(), reassigning the global pointer. Disassembling that
layer - open, close, write, read, lseek, fopen, fwrite - there is not
one Forbid/Permit, not one semaphore, nothing atomic anywhere in it.

That is fine for a normal Amiga program. It is not fine if you run more
than one Process, because on AmigaOS they share ONE address space. Two Processes calling open() at the same moment can both take the same
slot. The loser's descriptor now points at the winner's file.

READ THAT AGAIN IF YOU WRITE AMIGA SOFTWARE. It is not a binkd bug and
it is not mine. Anything multi-Process built against libnix has it,
including - I would guess, though I have not tested his build - the
other binkd port above.

v10.33 keeps the heaviest user out of that table. Log() opened and
closed the logfile for EVERY line; it now goes through dos.library
directly and never allocates a descriptor. 4,133 log lines over two
days including outbound transfers, zero corrupted. Lock files and
transfers still use the library's descriptors, so this is not a
complete fix - but those run at a tiny fraction of the frequency.


YOUR PEERS MAY HAVE YOU LOGGED UNDER THE WRONG VERSION

The version was hardcoded in three separate places: the startup line,
the shutdown line, and the VER string sent to every node you poll. Two
got updated over the years and one did not.

From v10.19 to v10.32 every node this system polled recorded it as
v10.19 - including under a release published two days ago. Nothing
local was wrong. Only the REMOTE's log showed it, which is why it went
fourteen versions without anyone noticing. Worth grepping your own
sources for duplicated version literals.


UPGRADING

On v10.23 or earlier: your outbound mail is not being delivered.
Every bundle goes out announced as 0 bytes - libnix13's fstat()
reports st_size as 0 while returning success. Sessions look
completely normal in your log. Fixed in v10.24.

On v10.19 to v10.32: see above, your peers have you as v10.19.

AmiBinkD10_33.lha is in the file area, and on GitHub at
github.com/SpitfireTN/AmiBinkD


Nothing ships until it has run on the board for a day or more. A fix
that has not survived a real night of traffic is a guess.

Reign of Fire BBS - call.rofbbs.com - telnet 6800 / ssh call@

* ACIS Member. AmigaNet ArakNet C=Net DescipleNet FidoNet PiNet RetroNet
* C-Net/5
* Origin: call.rofbbs.com : 6800 6400 8502 : 423-541-8271 : rofbbs.com (64:500/1)

AmiBinkD v10.34 - correct identification, correct clock ------------------------------------------------------------------

AmiBinkD is a port of binkd to AmigaOS 3.x. It talks straight to bsdsocket.library - no ixemul, no ixnet - and runs on real 68k iron or
under emulation. BinkP/1.1, CRAM-MD5, works with any FTN-aware Amiga
BBS.

v10.34 is a small release with no protocol or transfer changes. It
fixes two things AmiBinkD has been telling you wrong since the
beginning, both of them visible to every node it talks to.


IT NOW SAYS WHAT IT IS AND WHAT IT RUNS ON

Every mailer identifies itself during the handshake. Here is what
arrives at my board from elsewhere:

binkd/1.1a-115/Linux binkp/1.1
Mystic/1.12A49 binkp/1.0

Mailer, version, operating system, then protocol. Through v10.33
AmiBinkD sent this:

AmiBinkD v10.33-binkp/1.1

No operating system named, a space where the convention uses a slash,
and the protocol token stuck on with a hyphen. binkd's own parser
searches for "binkp/" so it always worked, but a stricter one could
read "v10.33-binkp/1.1" as a single token, and nothing told the
remote sysop what the mailer was running on.

It now sends:

AmiBinkD/10.34/Amiga binkp/1.1

Every other mailer reports its platform. There is no good reason an
Amiga should be the one that stays quiet about it.

Related: the version number now has ONE definition in the source.
v10.33 had already collapsed three hardcoded copies into one after a
drift left the handshake reporting v10.19 for fourteen releases. This
finishes that job.


IT NOW KNOWS WHAT TIME ZONE IT IS IN

The handshake also carries your local time and UTC offset. AmiBinkD
was sending the right wall-clock time with "+0000" attached - telling
every node it polled that it sat on the Greenwich meridian, wherever
in the world it actually was. Anyone computing my real UTC time from
that was four hours out.

binkd normally works the offset out by comparing gmtime() against
localtime(). That cannot work here. AmigaOS has no timezone database,
and the C runtime's localtime() is literally gmtime(t - __timezone)
with __timezone never set - I disassembled it to be sure. The two
agree exactly, so the difference comes out as zero. It was never a configuration mistake; the generic method simply cannot work on this
platform.

AmiBinkD now asks locale.library, which is where AmigaOS actually
keeps the answer - the zone you set in Prefs/Locale, the same value
every other localised program reads. Nothing to configure, and it is
correct in any country.

Two things to know:

If your offset still shows +0000, open Prefs/Locale, set your time
zone, and press SAVE (not Use - Use only writes to ENV:, which is
RAM). An Amiga that has never saved Locale prefs reports a GMT
offset of zero, and AmiBinkD cannot tell that apart from a system
genuinely running on GMT.

Daylight saving is manual. AmigaOS has no concept of it anywhere -
loc_Flags is documented "always 0 for now" and the autodocs never
mention it. Locale holds STANDARD time, so in a summer-time region
the reported offset is an hour out for half the year. Either pick
the zone entry one hour off during summer, or set "tzoff" in your
config, which overrides Locale entirely - "tzoff -4h" here in
summer, "-5h" in winter. The second is tidier; it leaves the
system-wide Locale setting alone for everything else on the machine.


ABOUT IPv6 - SO NOBODY IS MISLED

AmiBinkD is IPv4 only, and I want to be plain about it rather than
let it be discovered.

This is not a missing build option. The AmigaOS TCP/IP API has no
IPv6 in it at all. Roadshow's sys/socket.h - the official AmigaOS 3.2 networking headers - defines 26 address families, ending at AF_SIP 24
and AF_MAX 26. There is no AF_INET6, no sockaddr_in6, no in6_addr
anywhere in the netinclude tree. AmiTCP and Miami are IPv4 only as
well. Upstream binkd speaks IPv6 on the PC because the host stack
hands it AF_INET6 sockets; the Amiga has none to hand over, so every
IPv6 branch in binkd's sources compiles out on this platform.

There is no Amiga TCP stack you could swap in to change this.

If you want IPv6 callers to reach your board, put a small v6-to-v4
relay in front of the BinkP port on a machine that does have IPv6 -
the host, if you run under emulation, or a router or second box in
front of real hardware. One socat process is enough:

socat TCP6-LISTEN:24554,ipv6only=1,fork,reuseaddr TCP4:127.0.0.1:24554

Verified here: an IPv6 caller completes the full BinkP greeting and
session through it. One caveat - the relay is what connects to
AmiBinkD, so your log records IPv6 callers as coming from 127.0.0.1.
Do not use address-based node restrictions on a port reached that
way. CRAM-MD5 password authentication is unaffected and remains the
real access control. Run the relay with logging on (socat's -d -d) if
you want the real peer address recorded somewhere.


UPGRADING

Drop in the new binary. No config changes are required and nothing
in the protocol or transfer path changed - if v10.33 was working for
you, v10.34 behaves identically on the wire apart from the two
strings above.

The one thing worth doing afterwards is checking your own greeting,
since that is what this release is about. Prefs/Locale first if your
offset reads +0000.

Reign of Fire BBS - rofbbs.com - call.rofbbs.com

* ACIS Member. AmigaNet ArakNet C=Net DescipleNet FidoNet PiNet RetroNet
* C-Net/5
* Origin: call.rofbbs.com : 6800 6400 8502 : 423-541-8271 : rofbbs.com (64:500/1)