outbound zones longer than 3 hex chars

Hi

I've been trying to get binkd working with wwivnet, and ran across a problem. WWIVnet uses 20000 as a fake zone (and net) number to transfer wwivnet packets over binkp. (they use networkb, their own binkp implementation).

Binkd talks to networkb, and works well, except for a buffer overflow caused by 4e20 not fitting into 3 chars. Ideally wwivnet would be using a lower number for their fake zone to avoid this issue.

I've forked and patched binkd to work with this case, but am unsure if you are interested in the patch as I think it's really a wwivnet issue. (The outbound.4e20 isn't even used, as binkd just uses fileboxes to transfer the files)

Andrew

[streaps]

BSO (Binkley Style Outbound) only supports 3 hex chars (DOS 8.3 file names).

But binkd uses non-standard BSO, which omits the hex extension for the default zone of the network. Just use something like
domain wwivnet /ftn/outb/wwivnet 20000

Another workaround is Amiga Style Outbound, which can be enabled with
aso
in binkd.cfg

it seems to me that if binkd uses non-standard BSO anyway, then fixing the crash by allowing one extra character wouldn't hurt. It's not padding 3 character extensions, just not crashing when a longer extension is required.

[streaps]

I would argue that no hex extensions for non-primary domains is already bug*. The non-standard way should be no excuse to add other quirks.

Why not use an outbound format that natively supports 16-bit zones, like ASO? Or some longbox format as an alternative to BSO/ASO? As far as I understand binkd always uses BSO/ASO even if you enable support for filebox and/or brakebox.

That binkd crashes on zone numbers > 4095 is still a bug and a fix would be nice.

Only my opinion as a user, I cannot speak for the developers.

*you get the standard behaviour, if you configure an unused zone as the default zone, i.e.:
domain amiganet /ftn/outb/amiganet 1
instead of
domain amiganet /ftn/outb/amiganet 39

[streaps]

Interesting: I created a poll for 4096:1/1 and 20000:1/1 with binkd and I see the outbound folders fidonet.1000 and fidonet.4e20. Feature or bug?

On Wednesday, 2 June 2021 3:44:09 PM AEST streaps wrote: Interesting: I created a poll for 4096:1/1 and 20000:1/1 with binkd and I see the outbound folders `fidonet.1000` and `fidonet.4e20`. Feature or bug?

It is a sometimes, bug, it's a buffer overflow, but if you don't have anything in the memory after it, it won't crash.

[streaps]

Correction:

I think I remembered this part of FTS-5005:

Note that outbound areas for domains other than
your primary will ALWAYS have a zone extension, and that zone
extensions are always specified in Hexadecimal, up to .FFF (4095).

but 4 paragraphs above it says:

For supporting communications with systems from a different zone, a
number of directories are created with the same generic name chosen
for the default directory, plus a quasi extension equal to the zone
number expressed as 3 hexadecimal digits zero-padded on the left.
If the zone number > 4095 then 4 hexadecimal digits are used in
quasi extension. The last can be implemented only with a modern
OS.

So 4 character extensions are clearly allowed by the standard. Maybe just create a PR for your fix.

What would happen on old DOS systems that don't support long file names?