Hello, Dmitry!
Friday June 27 2025 03:15, from Dmitry Protasoff -> Alexey Khromov:
Опубликован релиз Binkleyforce 0.26.1
BinkleyForce is an FTN (FidoNet) mailer originally developed in the late 1990s by Alexander Belkin. Over time, the project has been maintained via multiple repositories:
SourceForge: The project "binkleyforce" on SourceForge (maintained by users ugenk and vpooh) was active until 2015
https://sourceforge.net/projects/binkforce/ The last update on SourceForge was April 27, 2015, after which development moved elsewhere.
GitHub (zotrix): A GitHub repository under user zotrix appears to have continued development after SourceForge. This repository contains tags up to version 0.23 (Dec 2011)
https://github.com/fidosoft , but commit activity likely continued beyond that (the repository had ~197 commits). In 2016, the FIDOSOFT organization forked zotrix's repo, indicating that the zotrix repo was considered the main line at least up to that point. However, the zotrix repository itself has not advertised newer releases (no tags for 0.24+ on GitHub).
FIDOSOFT Fork: The FIDOSOFT GitHub organization forked the zotrix repo in 2016. This fork did not see further public commits after November 2, 2016, suggesting it was either for archival or packaging purposes. It does not contain the most recent changes.
Current (ZX Gitea) Repository: In recent years, development has been led by Alexey Khromov (FidoNet 2:5030/723), who maintains the project on a self-hosted Gitea instance (prj.zxalexis.ru). This is now the most up-to-date source. For example, the BinkleyForce 0.26.1 release (announced April 2025) is available on that Gitea site
https://wfido.ru/m/RU.FIDONET.DIGEST/2:6035/3.1+67fcc2bd Ongoing updates (e.g. version 0.27) have been mentioned in FidoNet forums as well, confirming that active development continues under Alexey's stewardship.
А вот такой патчик примешь? Очень удобно, когда пишутся те же самые
имена девайсов, которые у меня выдаются модемам через udev и прописаны
в mgetty:
The patch under review modifies the function answ_system() in sess_answ.c to improve how the program determines the "line name" (state.linename) for the current session. In the existing code, when BinkleyForce is answering a call on a modem, it sets state.linename based on the terminal device of standard input (file descriptor 0). Specifically, if STDIN is a TTY, it uses ttyname(0) (the path of the TTY device) and passes that to port_get_name() to get a simplified port name; if STDIN is not a TTY (e.g. a network connection), it defaults to "tcpip". For inbound TCP/IP (BinkP) connections invoked via inetd, it similarly sets state.linename = "tcpip" and marks the state as network (state.inet = TRUE)
. This patch introduces an additional check before using ttyname(0): it looks for the environment variable DEVICE (which is set by mgetty when it spawns an external program for an incoming call). If DEVICE is present and non-empty, the patched code uses its value as the device path, in place of ttyname(0). In other words: If the environment variable DEVICE is set (e.g. /dev/modem1), use port_get_name(env_device) to derive the line name.
If DEVICE is not set or is empty, fall back to the original behavior (use ttyname(0) if available, or "tcpip" if not a TTY).
The motivation for this change is to preserve user-friendly device naming in logs and status messages. Many system administrators create udev rules to assign custom symlink names to modem devices (e.g. /dev/modem1 instead of a kernel default like /dev/ttyUSB0). They also configure mgetty to use these names. Mgetty, when invoking BinkleyForce upon an incoming call, provides the device name via the DEVICE environment variable (documented as "the full name of the tty device" that the call came in on).
Without the patch, BinkleyForce would ignore this and use the canonical device path from ttyname(0), which might be the underlying device (e.g. ttyUSB0) rather than the symlink (modem1). This leads to logs and internal identifiers using the less intuitive name. In short, the patch ensures that BinkleyForce will log and refer to the line using the same device name configured in mgetty (and via udev), which improves clarity for the user. The author of the patch noted it is "very convenient when the same device names are written that are given to modems via udev and are in mgetty," aligning with this rationale.
When BinkleyForce is invoked by mgetty for an inbound modem call, getenv("DEVICE") will return a string (for example, "\/dev\/modem1"). The code will then call port_get_name(env_device). We can infer that port_get_name() likely extracts a consistent name from the device path (possibly returning the basename or a sanitized port identifier). Thus, if env_device is "/dev/modem1", state.linename might become "modem1". This is exactly the desired outcome - the program will use the human-friendly alias.
If for some reason DEVICE is not set, or the program was not invoked via mgetty, the code falls back to the previous logic: if file descriptor 0 is a TTY, use its ttyname (e.g. "/dev/ttyUSB0") to get a name (likely "ttyUSB0"); if not, use "tcpip". This means the patch does not change behavior for scenarios like pure TCP/IP operation or other launch methods.
Why this fix matters: BinkleyForce uses state.linename to label the session and manage logging. Notably, when opening the session log file, it uses the line name as part of the filename extension.
For example, without the patch an incoming call on /dev/ttyUSB0 might always log to LOG_FILE_SESSION.ttyUSB0. With the patch, if the admin's udev/mgetty calls that same device /dev/modem1, BinkleyForce will log to LOG_FILE_SESSION.modem1 instead. This makes it much easier for an operator to identify logs per physical modem, especially if multiple modems are in use with custom names. Furthermore, BinkleyForce already uses environment variables from mgetty for other call-related information. In the same function, after setting up linename, the code checks for CALLER_ID and CONNECT in the environment to record caller ID and connect strings. The patch follows this established pattern by also checking DEVICE - it's a natural extension of how BinkleyForce integrates with mgetty's provided data.
---
* Origin: ChatGPT can make mistakes. Check important info. (2:5015/46)