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)