BinkD Success Story

AMBROSIA60-Portal  Fidonet Hauptseite


Nachdem DSL Ende März 2003 bei mir zu Hause gelegt worden ist, habe ich nach anfänglichem Versuchen schnell eine HTTP-BBS aufzubauen, das Handtuch geschmissen und mich zunächst anderen Projekten gewidmet, u.a. die Aktivierung von BinkD auf meinem NT-Rechner

BinkD Quellen

Ein passendes BinkD Paket für Win32 habe ich schnell gefunden. FileBases durchsuchen oder Google-Search. BinkD Download Seiten gibt es reichlich ... ;-)
Für mich unter Win32 habe ich das Paket binkd094.zip gefunden, dass allerdings keine Binaries enthielt. Das passende Binarie habe ich unter binkd-0.9.4-crc-win32.zip bei Volker Imre gefunden.
Ein weiterer Link für Binaries unterschiedlichster Betriebssysteme ist zu finden unter:
http://www.physcip.uni-stuttgart.de/tobi/binkd/precomp/

Update 14.8.05 v0.9.6
http://ambrosia60.goip.de/files/div27/i-util/BINKD096.ZIP - BinkD v0.9.6 Sources
http://ambrosia60.goip.de/files/div27/i-util/BND32096.ZIP - BinkD v0.9.6 Win32 executable
http://ambrosia60.goip.de/files/div27/i-util/BNDMAN.ZIP - BinkD HTML manual

Update 14.8.05 v0.9.7
http://ambrosia60.goip.de/files/div27/i-util/BINKD097.ZIP - BinkD v0.9.7 Sources
http://ambrosia60.goip.de/files/div27/i-util/BND32097.ZIP - BinkD v0.9.7 Win32 executable

Update 14.8.05 v0.9.8
http://ambrosia60.goip.de/files/div27/i-util/BINKD098.ZIP - BinkD v0.9.8 Sources
ftp://cvs.happy.kiev.ua/pub/fidosoft/mailer/binkd/ - Release versions (by Pavel Gulchouck 2:463/68)
Versionen bis einschl. 0.99

Eine Anmerkung noch zu den Sources:
Die Sources sind ein wenig unübersichtlich. Die neueste Version aus obigem FTP Verzeichnis liefert eine Version 0.9.7 als letzte "stable version". In einigen anderen Quellen sind Hinweise auf eine Version 0.9.8, 0.9.9 und sogar auf Versionen 1.0x. Ein stable 0.9.9 Paket liefert aber keine Win32 msv Version .... ist die Version, die ich auf meinem System seit ca Juli 2007 einsetze.
Um auf der "sicheren" Seite zu bleiben, bleibe ich vorerst bei rev 0.9.7 ...



Update Binaries: 17.9.08 v1.0a-515
BinkD v1.0a-515 Win32 binary (Server Offline)
Versionen: OS/2 (v0.9.3 - v0.9.9a), Win32 (v0.9.3 - v1.0a-515), *NIX (v1.0-snapshot)
(incompatible with some other BinkD revisions)

Update Binaries: v0.9.9a (stable) (Win32, OS/2)
BinkD v0.9.9a (stable) (Win32,OS/2) (by Roman Trunov 2:5022/2, [24-06-2005])



Nachdem ich beide Pakete ausgepackt hatte, waren 2 Files wesentlich:

BinkD Grundkonfiguration

Die BinkD.CFG habe ich einmal von oben nach unten durchgearbeitet und hatte somit schon ein laufendes BinkD Outbound System .... Somit war die 1. Hürde geschafft. ;-)

Mittels DirectUpdate (DynamicIP Updater) hatte ich bereits 2 DNS Namen aktiviert: ambrosia60.dyndns.org und ambrosia60.goip.de. Meinem Hub habe ich dann einen Nodelist-Line Update-Request geschickt, er möge doch bitte die Änderung in die Nodelist übernehmen. Von beiden Addressen habe ich die "stabilere" gewählt:
,1120,ambrosia60.goip.de,Offenbach,Ulrich_Schroeter,49-69-83003542,9600,
                                              CM,XA,MO,X75,H16,V32T,VFC,V34,IBN,U,RPK,ENC
Am darauffolgenden Freitag war die Änderung dann in der Nodelist aktiv.

Meinen Linkpartnern habe ich eine Netmail zukommen lassen, sie möchten doch bitte ihre BinkD Line Einstellung für mein System überprüfen und ggf. einen Eintrag für ambrosia60.goip.de mit unserem Sessionpassword zu aktivieren.

In den meisten Fällen ging das auch Problemlos. In einigen Fällen zeigte es sich aber, dass BinkD beim Aufbau der Test-Session Password Errors meldete...

Wie sich herausstellte, behandelt BinkD Sessionpasswords case-sensitive, unterscheidet also ob Passworte in Gross- oder Kleinbuchstaben geschrieben werden .... anders als bei den meisten regulären FTN-Mailern ....


BinkD Nodelist

Anders wie bei regulären FTN-Mailern, kann BinkD nicht auf eine Standard St.Louis-Format Fidonet Nodelist zugreifen, sondern benötigt ein spezielles Format in der die Einträge in etwa wie folgt gelistet sind:
Node <aka> <dns-host or ip[:port]>  -

   <aka>                   reguläre FTN-AKA i.e. 2:244/1120
   <dns-host or ip:port>   DNS-Name oder IP-Addresse, optional Port wenn nicht Standard 24554
   <->                     Steht für ein nicht vorhandenes Password
In der FileBase von meinem Uplink (RC24, Werner Blatt) habe ich in dem FileEcho I-BINKD eine BINKD-Nodes Nodeliste gefunden, die wohl auch ständig aktuallisiert wird.
Mittels Include Anweisung habe ich diese Nodeliste dann in die BINKD.CFG _vor_ den eigenen manuellen Link-Eintragungen eingebunden (nachfolgende Anweisungen überschreiben vorherige Anweisungen in der BINKD.CFG).
Somit konnte ich nun die meisten meiner Link-Partner als IP-Nodes identifizieren, da BinkD nun fortan beim Scanning entsprechende Nodes auflistete.
Beim Outbound Handling musste ich allerdings noch die regulären Binkley Modem- und ISDN-Lines ein wenig umkonfigurieren, so dass diese Lines ab sofort nicht mehr meine Link-Partner anwählten, sondern die Verbindung der BinkD Line überliessen.
Eine Konfiguration der Modemflag-Settings für das Nodelistflag IBN vor die entsprechenden Modemflags und ISDN Flags mit höherer Priorität schaffte hier Abhilfe: 
Fastlist Config:

[...]
TypeDef X75     32
TypeDef IBN     128


Binkley XE Modem Config:

BitType
Modemtrans 128     /   /IP         <-- Verhindert die ISDN-Anwahl wenn Node auch IBN Flag hat
ModemTrans 32   ATD/   /X75
ModemTrans 64      /   /UNK
Modemtrans 16      /   /MODEM
Jetzt waren die Grundvoraussetzungen geschaffen, dass die BinkD Line sich ähnlich der regulären FTN-Mailer verhielt - liegt Mail für ein System an, das unter der entsprechenden Nummer auch ein IBN Flag in der Nodelist gelistet hat, wird primär die IP-BinkD-Line zur Versendung des Pakets benutzt.


BinkD.TXT Nodelist Update

Die BINKD.TXT Nodelist kann entweder über das FileEcho I-BINKD (bei allen grösseren FileServer Systemen innerhalb R24) bezogen werden, oder man erstellt sich die Datei BINKD.TXT aus der jeweils aktuellen Raw-St.Louis-Nodelist selbst. Hierzu gibt es das PHP Script: BNLPHP12.ZIP BNLPHP12.ZIP (php script)
binkd_nodelister.php version 1.0 (PHP), (c) 2007-2012 by Ulrich Schroeter
Alternativ gibt es noch Perl und AWK Scripte:
nl2binkd.gz nl2binkd.gz (awk script)
nl2binkd v1.00, (c) 2012 by Markus Reschke
This script extracts nodes with binkd services from the standard Fidonet nodelist and creates a special nodelist for binkd.
bnlpl13.zip bnlpl13.zip (perl script)
binkd_nodelister.pl version 1.3
binkd nodelist tool converts St.Louis Nodelist to BinkD.TXT format
Perl Script - 14 Apr 2007, Copyright (c) 2007
by Jerry Schwartz and Write by Night, see also PHP port, GPL license


BinkD FileRequest

Jetzt komme ich zu den langwierigeren Konfigurations Problemen.
Da BinkD selbst keine direkte FReq. Unterstützung eingebaut hat, muss man sich eines FileRequestProzessors bedienen der mittels eines BinkD "EXEC" Aufrufs nach dem SRIF Standard aufgerufen werden kann.
Da ich Allfix in meinem FTN-System für die FileEcho Unterstützung eingebaut habe und Allfix in der Version 5.13 auch einen eingebauten FReq.Prozessor besitzt, lag es nahe Allfix dafür heranzuziehen.
Für Win32 bin ich davon ausgegangen, dass eine Win32 Version benötigt wird. Also Allfix/Universal. Also Allfix/Universal ausgepackt, Setup aufgerufen. Freq.Prozessor Einstellungen konfiguriert.
In BINKD.CFG eine entsprechende Zeile:
  exec "!e:\\bink\\line.22\\freq.cmd *S" *.req
eingetragen und die FREQ.CMD entsprechend erstellt: 
[Inhalt FREQ.CMD]
q:
cd\allfix
SET ALLFIX=Q:\Allfix
allfix Rp -SRIF %1
Beim Freq. wurde zwar die *.REQ Datei erkannt und der Exec Aufruf gezündet, aber eine Antwort-Datei *.RSP wurde nicht erstellt ...
Mittels Echo Debug Zeilen war ersichtlich, dass Allfix/Universal zwar gestartet wurde, aber Allfix/Universal ausser der Aufrufzeile nichts ins Allfix.Log schrieb ...
Nachdem ich nun mit meinem Uplink 'zig Versuche unternommen hatte den Freq. zum Laufen zu bekommen, hatte ich dann einen manuellen Aufruf mit einer SRIF-Datei, die ich unter Novell aus dem Binkley-Outbound (!) wiederhergestellt hatte
h:\bink\out\out\00f40457.srf
durchgeführt. Und siehe da, Allfix/Universal erwartete einen Tastendruck, weil ich für Allfix/Universal noch keinen Key hatte ... ;-(
Key - geht doch einfach - einfach unter www.allfix.com einen Allfix/Universal generieren lassen ...
DENKST'E
Für WWW.ALLFIX.COM existieren keine IP-Addressen mehr ... ;-(
Die Domain ALLFIX.COM ist zwar noch registriert, aber sämtliche DNS-records sind entfernt ... ;-(
Weder eMail noch HTTP Zugang sind Online ... Also war's nichts mit Registrierung ....

OK. Nicht verzagen ...
Der Versuch mit der entsprechenden DOS Version führte zum gewünschten Ergebnis ...
Anschliessende Online-Test-Frequest-Versuche mit der DOS Version lieferten jeweils die gewünschten Files ....

Hint: Um Allfix einen schnelleren Zugriff auf die FileBase zu ermöglichen, sollte man statt nur der Liste der für den Freq. unterstützten Verzeichnisse ein Fixutil Index durchführen.
Der entsprechende Befehl für den Aufruf zur Indexerstellung während der regulären Fileverarbeitung lautet:

fixutil CompileRequestIdx

Hint2: die Domain ALLFIX.COM ist Offline. Bob Seaborn (1:140/12) hat aber noch einen Mirror der Allfix WebSite unter http://www.nwstar.com/allfix am Laufen. Jeddoch funktionierten bei mir die Menüs nicht und auch ist keine Registrierung möglich ... ;-(

[Update 19.9.08]
www.allfix.com wird nach 139.142.226.133 aufgelöst, aber die Seite bleibt leer ... :(

Registrierungs Link (aus den Sources des NWSTAR.COM links):
REGISTRATION SITES

In der Zwischenzeit arbeite ich mit dem Filerequest-Processor: VIREQ/32

 VIREQW13.ZIP Size: 76459 Date: 2004-04-16 Time: 01:05:00
VIREQ/32 V0.13 Filerequestprozessor fuer Windows -Arbeitet mit SRIF gemaess FSC-0086.001 -Benoetigt keine Filebase, auch keine FILES.BBS (c) 1998-2001 by Volker Imre Win32 version by Michael Haase

Da aber diese Version unter Win32 beim CDP Function Request ein Problem aufweist, habe ich mir selbst ein VIREQ Derivat (VIREQCLP) zusammengebastelt, dass nun im Einsatz ist.
Für die Filebase Index Erstellung benutze ich VIIDX32.EXE aus obigem Paket.

 VIRQCL10.ZIP Size: 126899 Date: 2012-12-30 Time: 12:00:00
ViReq/Clp v1.00 DOS, OS/2 and Win32 DOS shells Freq processor. -Arbeitet mit SRIF gemaess FSC-0086.001 -Benoetigt keine Filebase -Benoetigt keine FILES.BBS (c) 1998-2001 by Volker Imre; Win32 version by Michael Haase; (2012) DOS/OS2/Win32 version by Ulrich Schroeter


Die modifizierte Aufruf Batch für BinkD (CDP-Node aware):
[Inhalt FREV.CMD]
q:
cd\allfix
copy e:\bink\line.22\binkd.cfg e:\bink\line.22\sik_cfg\binkd.cfg
copy %1 e:\bink\cdp\dbg
rem allfix Rp -SRIF %1
rem q:\allfix\vireq32.exe %1
q:\allfix\VIREQCLP.EXE %1
e:

BinkD DynamicIP Alternativen

Wie weiter oben beschrieben hatte ich mit dem Produkt DirectUpdate angefangen.
Nachdem BinkD lief, ich auf der Kiste auch Webserver aktiviert hatte, musste ich immer wieder feststellen, dass sich die IP-Addresse in Abständen von teilweise 10 min. regelmässig änderte ;-(
Teilweise änderte sich die IP gerade dann, wenn kurz zuvor die letzte Änderung an die DNS-Server weitergereicht wurden. So entstanden immer wieder "Löcher" von Nicht-Erreichbarkeit, über den ganzen Tag hinweg. Das wollte ich nicht stehen lassen.
Da ich direkten Zugriff auf einen W2K-DNS-Server im Internet habe, der Dynamic IP Änderungen rein theoretisch bearbeiten könnte versuchte ich mich zunächst damit DirectUpdate auf einen "Generic W2K" Update einzurichten. Die angeforderten Parameter überforderten mich aber, so dass ich diesen Versuch sehr schnell fallen liess.
Von anderer Seite erhielt ich den Tip bei "dnsalias.net" mal zu schauen ... Die hätten die 10 min. Sperre nicht, die z.Bsp. Dyndns.Org und Dnsalias.Net haben ...
Also Anmeldung bei "dnsalias.net" und laut Client Liste, Unterstützung des DirectUpdate's Aktivierung von "dnsalias.net" unter DirectUpdate. Aber, was ich auch konfigurierte, ein Update kam nicht zustande .... ;-(
Das war 2003. Nach der Exkursion via Gnudip und fidosoft.de, letzteres wurde 2005 gekapert, landete ich doch wieder DirectUpdate und Dnsalias.net.


[Da Deaktivierung von Perl, gilt die gesamte nachfolgende Sektion nicht mehr]

Bei "dnsalias.net" stiess ich dann auf GNUDip ... ein Perlscript getriebener Client für Win32. Auch gibt es Clients für OS/2 und Linux ... ;-)
Also Reaktivierung bei "dnsalias.net" Installation des Win32 GNUDip Clients ...
Nun hatte der GNUDip Client es aber auch in sich ...
Der erste Perlaufruf (config.bat) lieferte einen GPF ;-(
Der zweite Aufruf führte dann zur interaktiven Konfiguration.
Der manuelle Aufruf von gdipc.bat lieferte aber nur eine Parameterliste ...
Also Parameter gesichtet, welche benötigt werden könnten. Der Parameter -g lieferte als Description: Client is behind a gateway. Genau das ist bei mir der Fall ... aber keinen Hinweis darauf, was es genau damit auf sich hat ...
Im weiteren Verlauf der Tests stiess ich auf den Aufrufparameter -g sendport:recvport ] aber wieder kein Hinweis was es nun mit den Ports auf sich hat ...
In dem File CLIENTS.HTML das im Win32 Archiv enthalten war fand ich ganz am Ende nachfolgenden Hinweis: 
"You must configure the NAT box to redirect some external UDP port to a UDP port on the
internal machine running the client. You provide these port numbers to the client using
the -g option.  This option will also cause the client to request the GnuDIP server to
send the external address of the NAT device (which the server sees as the other end of
the client connection)  back in the reply to the update request."
Damit hatte ich nun einen Bezug, dass das Problem ein Firewall-Problem war. Der Hinweis auf den UDP Port "sagte" mir was. In der Firewall-Konfiguration lassen sich TCP oder UDP Ports von Extern nach Intern "mappen". Die Protocol Infoseite auf dnsalias.net http://www.dnsalias.net/html/protocol.html liefert dann wiederum einen Hinweis auf den Standard Port der normalerweise dafür benutzt wird: Port 3495
Nachdem ich im Firewall die Translation "Orig UDP Port 3495 Reciving UDP Port 3496" aktiviert hatte, meldete der GNUDip Client erstmals einen Update der aktuellen IP Addresse beim DNS-Server ... ;-)
Da der Perlscript bislang noch durch manuellen Aufruf in einer DOS-Box gestartet wurde, verfiel ich auf die Idee, diesen Dienst zu einem Service umzustellen. Im NT4 Resource-Kit gibt es ein Tool SRVANY mit dem man beliebige Programme als Dienst einrichten kann. Als Application Parameter kann man so ein Script starten, das letztendlich auch den GNUDip Client startet.
Ein Problem bleibt aber noch: Stoppt man nun diesen Service bleibt das Perlscript weiterhin aktiv!
Eine Modifikation des Perlscripts in der Loop-Schleife zusätzlich nach einem Semaphore-File Ausschau zu halten, und wenn das Semaphore-File existiert die Loop zu beenden, löste das Problem.
Nun konnte der Service mittels eines weiteren Scripts StopServ.CMD gestoppt werden und der Perlscript nach endlicher Zeit auch beendet werden:
GNUDIPS.CMD   (modifizierte GNUDIP.BAT für NT4 Service)

zusätzlich    (relativ am Anfang des Scripts bei den Variablendeklarationen)
my $semap = 'C:/gdipc/gdipcs.txt';

in der Schleife:
# repeat forever ...
while (1) {

   . . .

     # wait before spawning again
  Win32::Sleep($wait);

  # kill previous interation if still running
  $process->Kill(255);


zusätzlicher Block  (hier wird die Semaphore-Datei überprüft, bei Vorhandensein Loop-Exit ...)

  if (open(SEMAP,"$semap")) {
    close(SEMAP);
    exit;
  } else {
    close(SEMAP);
  }
Die Datei StopServ.CMD enthält nachfolgende Zeilen: 
NET STOP GNUDIP                         Stoppt Service <Servicename> unter NT4
echo.>>C:\GDIPC\gdipcs.txt              Semaphore-Datei zum Beenden des Perlscripts anlegen

Beim NT4 Reboot würde nun aber die Semaphore-Datei "stehen" bleiben ... Aus diesem Grund muss der Service-Start auch mit einer Prozedur gestartet werden. Hier die Prozedur für den Start des GNUDip Services:
SERVICE.CMD 
c:
cd\gdipc
if not exist gdipcs.txt goto skipd
del gdipcs.txt
:skipd
gdipcs.cmd -f I:\.GnuDIP2.txt -g 3495:3496 -d 60 -l i:\logfiles\gdipc.log -w 1
exit
Der Parameter -d 60 bewirkt nun, dass der Client jede Minute eine Überprüfung der IP Addresse durchführt und ggf. die Addresse beim DNS Server updatet. Nachdem dieser Script eingerichtet und gestartet wurde ändert sich die IP Addresse nurmehr 1x täglich ... ;-)
Success.

[GNUDIP ersetzt durch DynamicUpdate]


BINKD Links
BinkD Documentations
BinkD FAQ
BinkD man page
BinkD binaries (Link 1) (binkd.grumbler.org)
BinkD binaries (Link 2) (www.dreamlandbbs.com R50) (Server Offline)
BinkD User Guide (incl. complete Cfg description)

Eingesetzte Software (Updated Dec 2012)

FTN-System unter einem Windows 2000 Server
Maximus FileBase (DOS), Background Maintenance auf einem DOS-PC
Windows 2000 Server
Apache 2.0.45, PHP 4.x (Win32)
BinkD v0.9.7 (Win32) (older version)
BinkD v0.9.9 (Win32) (older version)
BinkD v1.0a-515 (Win32) (newest version)
BinkD v0.9.9a (stable) (Win32,OS/2) (by Roman Trunov 2:5022/2, [24-06-2005])
(binkd_nodelister.pl v1.0 (Perlscript), (c) 2002 by Jerry Schwartz and Write by Night)
BNLPHP10.ZIP binkd_nodelister.php version 1.0 (PHP), (c) 2007 by Ulrich Schroeter
VIREQCLP/16 Filerequest-Processor VIREQ/32 (c) 1998-2001 by Volker Imre, Derivat (c) 2012 by U.Schroeter
DirectUpdate v4 Win32, Dynamic IP DNS-Update, Shareware

Ulrich Schroeter, Mai 2003
Updated: Mai 2008
Updated: Januar 2012
Updated: December 2012
© 2003-2024 by Ulrich Schroeter   03742