Mv> I was not harping on D'Bridge, I was trying to pinpoint the source of the Mv> problem by elimination. The inner workings of D'Bridge have always been Mv> treaetd as if they are state secrets. So I had to work on a minimum of Mv> knowledge.
That is a slight exageration.
D'Bridge is exactly as Kees describes. It generates an outbound-queue in a base-36 format. This is how it was made to work "here" and still does ...
DBUTIL moves everything for a specific client into a dedicated directory, in this case 2:250/1
c: cd c:\db dbutil move 2:250/1 C:\DB\BINKD\22501
Deleting a trailing FLO-line
c: cd c:\db\binkd\22501 del ????????.flo
Check if there is content in that directory
c: cd c:\db\binkd\22501 dir /a-d/b 2>nul >nul if errorlevel 1 goto end
Unpack possible packed content into pkt-files
c: cd c:\db\binkd\22501 call c:\db\bat\unpack.bat
Create FLO-file of whatever content is in the dedicated directory and let BINKD do its thing zith it ...
c: cd c:\db\binkd\22501 d:\soupgate\genflow 250 1 copy ????????.flo c:\binkd\outbound
:end
You know how to read a batch file.
Mv> The way it looks now, is that the version of binkd that Ward used was the Mv> exception. Despite the fact that it showed the IPv6 compile option was Mv> used, it would not do IPv6. So replacing it was NOT useless in tracing Mv> the problem.
