Subj : AmiBinkD 2026 To : All From : Gary McCulloch Date : Mon Aug 24 2026 07:17 am 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 (1:154/50) .