Discussion:
1.0 or 1.1?
(too old to reply)
Michiel van der Vlist
2014-03-18 18:27:50 UTC
Permalink
Hello Vince,

From the log:

D:\FIDO\BINKD>binkd -p -P250/1 binkd.cfg
22:27 [1616] BEGIN standalone, binkd/1.1a-49/Win32 -p -P250/1 binkd.cfg
22:27 [1616] creating a poll for 2:250/***@fidonet (`d' flavour)
22:27 [1616] clientmgr started
+ 22:27 [5984] call to 2:250/***@fidonet
22:27 [5984] trying f1.n250.z2.binkp.net [81.179.6.57]...
22:27 [5984] connected
+ 22:27 [5984] outgoing session with 81.179.6.57
- 22:27 [5984] OPT CRAM-MD5-fe0546a08517088d26b5e79a357f1f1a
+ 22:27 [5984] Remote requests MD mode
- 22:27 [5984] SYS Air Applewood BBS
- 22:27 [5984] ZYZ Vince Coen
- 22:27 [5984] LOC Roydon, Essex, UK
- 22:27 [5984] NDL CM,XA,IBN
- 22:27 [5984] TIME Tue, 18 Mar 2014 21:27:06 +0000
- 22:27 [5984] VER mbcico/1.0.1/GNU/Linux-x86_64 binkp/1.1
- 22:27 [5984] PHN applewood.dtdns.net
- 22:27 [5984] OPM Air Applewood BBS Linux System
+ 22:27 [5984] addr: 2:250/***@fidonet
+ 22:27 [5984] addr: 2:25/***@fidonet
+ 22:27 [5984] addr: 2:250/***@fidonet
- 22:27 [5984] OPT EXTCMD GZ BZ2 PLZ
+ 22:27 [5984] Remote supports EXTCMD mode
- 22:27 [5984] TRF 0 0
+ 22:27 [5984] Remote has 0b of mail and 0b of files for us
+ 22:27 [5984] done (to 2:250/***@fidonet, OK, S/R: 0/0 (0/0 bytes))
22:27 [5984] session closed, quitting...
22:27 [1616] the queue is empty, quitting...

Did you put me back on 1.1?


Cheers, Michiel
Vince Coen
2014-03-18 19:22:49 UTC
Permalink
Hello Michiel!
Post by Michiel van der Vlist
Hello Vince,
Did you put me back on 1.1?
Nope but you are not in my lists as I had to rebuild the system after having a
wee mishap with the bbs directory due to mount a 3Tb drive that looked like
the
primary HDD. Now thats not a problem unless you have /opt/mbse linked to
/home/mbse on both and I wanted to copy the content from one HDD to the other
but desided to delete the target before doing cp.

This deleted them all.

I have now rebuilt it using a 2 year old backup, just time and 2 years of new
files, it happens.

Did you get my msg where this issue is discused?

It explains the issues that will arise by fixing it.


Vince
Michiel van der Vlist
2014-03-20 20:25:29 UTC
Permalink
Hello Vince,

On Tuesday March 18 2014 23:22, you wrote to me:

VC> Nope but you are not in my lists as I had to rebuild the system after
VC> having a wee mishap with the bbs directory due to mount a 3Tb drive
VC> that looked like the primary HDD. Now thats not a problem unless you
VC> have /opt/mbse linked to /home/mbse on both and I wanted to copy the
VC> content from one HDD to the other but desided to delete the target
VC> before doing cp.

VC> This deleted them all.

Ok, shit happens.

VC> I have now rebuilt it using a 2 year old backup, just time and 2 years
VC> of new files, it happens.

VC> Did you get my msg where this issue is discused?

VC> It explains the issues that will arise by fixing it.

I am afraid I did not get it. Could you repost it please?


Cheers, Michiel
Vince Coen
2014-03-23 09:59:07 UTC
Permalink
Hello Michiel!

21 Mar 14 00:25, you wrote to me:

VC>> Nope but you are not in my lists as I had to rebuild the system
VC>> after having a wee mishap with the bbs directory due to mount a
VC>> 3Tb drive that looked like the primary HDD. Now thats not a
VC>> problem unless you have /opt/mbse linked to /home/mbse on both
VC>> and I wanted to copy the content from one HDD to the other but
VC>> desided to delete the target before doing cp.

VC>> This deleted them all.
Post by Michiel van der Vlist
Ok, shit happens.
VC>> I have now rebuilt it using a 2 year old backup, just time and 2
VC>> years of new files, it happens.

VC>> Did you get my msg where this issue is discused?

VC>> It explains the issues that will arise by fixing it.
Post by Michiel van der Vlist
I am afraid I did not get it. Could you repost it please?
I cannot find it so,

The reporting reflects the setting for a specific node setup within the
uplinks mbse
system.

If the node is in fact using a later version e.g, 1.1 then the node must
advise the
uplink to remove the v1.0 setting as it can cause problems.

Changing the code:

1. Yes the mbcico code can be changed to ignore the nodes setting if calling
system
is in fact using v1.1 as against the node setting of v1.0 BUT it does assume
the the
uplink sysop will upgrade the mbse s/w and the fact that you reporting him/her
using
0.95.13 etc is unlikely, as the date history of the various versions of mbse
are:

0.95.12 22-May 2011
0.95.13 8-Aug-2011
0.95.14 1-Dec-2011
0.95.15 26-Dec-2012
1.00.00 Dec-2013 (approx)
1.00.1 Dec-2013 (approx)
1.00.2 14-Mar-2014 Not yet issued as under test & subject to more changes
such as ..

2. Changing the code as in (1) may affect valid connections using binkd type
links.

3. A sysop using a older version is showing that s/he is not in a rush or has
the time
to upgrade. Of course if they do not respond to the request it does not help
:(

4. Another option is to allow the downlink to change the setting themselves.
Not sure how to implement other than via a areafix,filemgr %BINKD=OFF etc
request, but
it also will need the uplink to upgrade ....


All in all, the best bet is just ask the sysop in question to remove the binkd
1.0
flag for the specific node address.


Vince
Michiel van der Vlist
2014-03-27 20:48:38 UTC
Permalink
Hello Vince,

On Sunday March 23 2014 13:59, you wrote to me:

VC> The reporting reflects the setting for a specific node setup within
VC> the uplinks mbse system.

Last time we checked it reported 1.1 to me while it was actually set to 1.0 for
me...

VC> If the node is in fact using a later version e.g, 1.1 then the node
VC> must advise the uplink to remove the v1.0 setting as it can cause
VC> problems.

Of course. But that requires that the sysop can be contacted. Which may be
problematic under some circumstances.

VC> Changing the code:

VC> 1. Yes the mbcico code can be changed to ignore the nodes setting if
VC> calling system is in fact using v1.1 as against the node setting of

That is not what I requested. What I requested is that when it is forced to 1.0
that it actually reports 1.0. That is what I requested, no more, no less.

VC> 2. Changing the code as in (1) may affect valid connections using
VC> binkd type links.

Yes. So it is not a good idea.

VC> 3. A sysop using a older version is showing that s/he is not in a rush
VC> or has the time to upgrade. Of course if they do not respond to the
VC> request it does not help :(

Indeed. That is why I requested the binkd team for an option to downgrade my
side to 1.0 in case of the problem encountered.

VC> 4. Another option is to allow the downlink to change the setting
VC> themselves. Not sure how to implement other than via a areafix,filemgr
VC> %BINKD=OFF etc request, but it also will need the uplink to upgrade
VC> ....

I don't think that is a good idea. It will probably cause new problems which
may lead to a request from the other side for an option to overrule it...

VC> All in all, the best bet is just ask the sysop in question to remove
VC> the binkd 1.0 flag for the specific node address.

Sure. But still think mbcico reporting 1.1 to a node when it is forced into
1.0 mode for that node is an error. I think that should be corrected
irrespective of other considerations.


Cheers, Michiel
Vince Coen
2014-03-29 13:07:51 UTC
Permalink
Hello Michiel!
Post by Michiel van der Vlist
Sure. But still think mbcico reporting 1.1 to a node when it is
forced into 1.0 mode for that node is an error. I think that should be
corrected irrespective of other considerations.
I will re-look at the code and see what the heck it is doing as I thought it
was reporting correctly but I do suffer from memory lapses but will look at it
later today.

Again ....

To check that if system is set to 1.0 it must report that mode to sender.

It is looking like it gets the senders version before issuing its own which in
any event is wrong ...


Vince
Vince Coen
2014-03-29 14:31:57 UTC
Permalink
* Carbon copied to Michiel van der Vlist

Hello Michiel!
Post by Michiel van der Vlist
Sure. But still think mbcico reporting 1.1 to a node when it is
forced into 1.0 mode for that node is an error. I think that should be
corrected irrespective of other considerations.
Looking at the code at start of session:

-----------------------------
if (((Loaded && nodes.NoBinkp11) || bp.buggyIrex) && (bp.Major == 1) &&
(bp.Minor != 0)) {
Syslog('+', "Binkp: forcing downgrade to binkp/1.0 protocol");
bp.Major = 1;
bp.Minor = 0;
}
-----------------------------

Which is saying if binkp is set to v1.0 OR node is set to v1.0 system is
forcing 1.0 protocol = 1.0


Here which is where we send system info to remote we do :

-------------------------------
/*
* Send system info to remote
*/
int binkp_banner(int originate)
{
time_t t;
int rc;
rc = binkp_send_command(MM_NUL,"SYS %s", CFG.bbs_name);
if (!rc)
rc = binkp_send_command(MM_NUL,"ZYZ %s", CFG.sysop_name);
if (!rc)
rc = binkp_send_command(MM_NUL,"LOC %s", CFG.location);
if (!rc)
rc = binkp_send_command(MM_NUL,"NDL %s", CFG.IP_Flags);
t = time(NULL);
if (!rc)
rc = binkp_send_command(MM_NUL,"TIME %s", rfcdate(t));
if (!rc) {
if (nodes.NoBinkp11 || bp.buggyIrex)
rc = binkp_send_command(MM_NUL,"VER mbcico/%s/%s-%s %s/%s", VERSION,
OsName(), OsCPU(), PRTCLNAME, PRTCLOLD);
else
rc = binkp_send_command(MM_NUL,"VER mbcico/%s/%s-%s %s/%s", VERSION,
OsName(), OsCPU(), PRTCLNAME, PRTCLVER);
-------------------------------

So if binkp flag set to 1.0 we send 1.0.

This is correct the only crack in the oinment is if bink is send <1.0
e.g., 0.95 in which case it is defaulting to v1.1 as it only tests for 1.0.

I am assuming here that versions below 1.0 do in fact send 1.0.

I do have a problem I think is that I was not seeing any reporting of this in
the logs BUT I may well not have had full debugging set to on when we tried
this earlier in the month so it looks like we have to repeat the tests setting
you up as a node here and with binkp v1.1 negative (forcing 1.0) when you poll
me in two tests: 1. with binkd v1.1 and 2. with binkd v1.0.

I will now set this up with your node addr and full debugging so please poll
me.



Vince
Michiel van der Vlist
2014-03-29 19:23:03 UTC
Permalink
Hello Vince,

On Saturday March 29 2014 18:31, you wrote to me:

VC> I will now set this up with your node addr and full debugging so
VC> please poll me.


29 Mar 22:19:34 [7012] BEGIN standalone, binkd/1.1a-49/Win32 -p -P250/1
binkd.cfg
29 Mar 22:19:34 [7012] creating a poll for 2:250/***@fidonet (`d' flavour)
29 Mar 22:19:34 [7012] clientmgr started
+ 29 Mar 22:19:34 [6336] call to 2:250/***@fidonet
29 Mar 22:19:34 [6336] trying f1.n250.z2.binkp.net [81.179.6.57]...
29 Mar 22:19:34 [6336] connected
+ 29 Mar 22:19:34 [6336] outgoing session with 81.179.6.57
? 29 Mar 22:19:34 [6336] recv: connection closed by foreign host
+ 29 Mar 22:19:34 [6336] done (to 2:250/***@fidonet, failed, S/R: 0/0 (0/0
bytes))
29 Mar 22:19:34 [6336] session closed, quitting...
29 Mar 22:19:35 [7012] the queue is empty, quitting...


?????


Cheers, Michiel
Vince Coen
2014-03-29 20:35:45 UTC
Permalink
* Originally in BINKD

Hello Michiel!
Post by Michiel van der Vlist
Hello Vince,
VC>> I will now set this up with your node addr and full debugging so
VC>> please poll me.
Post by Michiel van der Vlist
29 Mar 22:19:34 [7012] BEGIN standalone, binkd/1.1a-49/Win32 -p
-P250/1 binkd.cfg 29 Mar 22:19:34 [7012] creating a poll for
29 Mar 22:19:34 [6336] trying f1.n250.z2.binkp.net [81.179.6.57]...
29 Mar 22:19:34 [6336] connected
+ 29 Mar 22:19:34 [6336] outgoing session with 81.179.6.57
? 29 Mar 22:19:34 [6336] recv: connection closed by foreign host
(0/0 bytes)) 29 Mar 22:19:34 [6336] session closed, quitting... 29 Mar
22:19:35 [7012] the queue is empty, quitting...
?????
These are from my logs:

--------------------------
29-Mar-2014 19:17:40 mbcico[3504] MBCICO v1.0.2
29-Mar-2014 19:17:40 mbcico[3504] Cmd: mbcico f5555.n280.z2.fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] Options: Call WaZOO EMSI Freqs Zmodem
ZedZapHydra PLZ GZ/BZ2 NoNR
+ 29-Mar-2014 19:17:40 mbcico[3504] Calling 2:280/***@fidonet (Blijf Tonijn,
phone (null))
+ 29-Mar-2014 19:17:40 mbcico[3504] Open TCP connection to
"fido.vlist.eu:24554"
+ 29-Mar-2014 19:17:40 mbcico[3504] Trying IPv4 83.82.233.201 port 24554
+ 29-Mar-2014 19:17:40 mbcico[3504] Established IBN/TCP IPv4 connection with
83.82.233.201, port 24554
+ 29-Mar-2014 19:17:40 mbcico[3504] GeoIP location: Netherlands, NL EU
+ 29-Mar-2014 19:17:40 mbcico[3504] Start outbound Binkp session with
2:280/5555
@fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] Binkp: start session
+ 29-Mar-2014 19:17:40 mbcico[3504] Binkp: node 2:280/***@fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] Options :
CRAM-MD5-397fce50ba666c5094d36421df3c22ee
+ 29-Mar-2014 19:17:40 mbcico[3504] System : Blijf Tonijn
+ 29-Mar-2014 19:17:40 mbcico[3504] Sysop : Michiel van der Vlist
+ 29-Mar-2014 19:17:40 mbcico[3504] Location: Driebergen, NL
+ 29-Mar-2014 19:17:40 mbcico[3504] Flags :
CM,MO,IBN:fido.vlist.eu,U,RPK,NPK,ENC,NC
+ 29-Mar-2014 19:17:40 mbcico[3504] Time : Sat, 29 Mar 2014 20:17:27 +0100
+ 29-Mar-2014 19:17:40 mbcico[3504] Uses : binkd/1.1a-49/Win32 binkp/1.1
+ 29-Mar-2014 19:17:40 mbcico[3504] address : 2:280/***@fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] address : 2:2/***@fifonet
+ 29-Mar-2014 19:17:40 mbcico[3504] address : 2:28/***@fidonet
+ 29-Mar-2014 19:17:41 mbcico[3504] Options : EXTCMD
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: EXTCMD is active
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: MD5 unprotected session
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: forcing downgrade to binkp/1.0
protocol
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: mail 2761, files 0 bytes
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: send
"/home/mbse/var/bso/outbound/011815b3.cut" as "4754c9ce.pkt"
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: size 2761 bytes, dated Mar 29
19:17:17, comp No
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: OK 2761 bytes sent in 0.001 seconds
(2696.289 Kb/s)
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: M_GOT
"4754c9ce.pkt 2761 1396120637"
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: remote GOT "4754c9ce.pkt"
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: session finished, rc=0
+ 29-Mar-2014 19:17:43 mbcico[3504] Closing TCP connection, connected 3.00s
+ 29-Mar-2014 19:17:43 mbcico[3504] Call to 2:280/***@fidonet successful
(rc=0)
+ 29-Mar-2014 19:17:43 mbcico[3504] Sent 2761 bytes, received 0 bytes, avg
2761
cps
+ 29-Mar-2014 19:17:43 mbcico[3504] Connected 3.00s
29-Mar-2014 19:17:43 mbcico[3504] MBCICO finished in 3.00s
--------------------------

I have NO other log records for your system or for any log transactions for
that time frame (21:19 UTC or even 22:19) eg:

------------------------
+ 29-Mar-2014 20:39:24 mbcico[13096] Connected 3.00s
29-Mar-2014 20:39:24 mbcico[13096] MBCICO finished in 4.00s
29-Mar-2014 22:00:01 mbfido[22019]
29-Mar-2014 22:00:01 mbfido[22019] MBFIDO v1.0.2
29-Mar-2014 22:00:01 mbfido[22019] Cmd: mbfido ne -q

.................. heavy debug records for above last line then:

+ 29-Mar-2014 22:00:34 mbcico[22082] Connected 3.00s
29-Mar-2014 22:00:34 mbcico[22082] MBCICO finished in 4.00s
29-Mar-2014 23:43:51 mbfido[858]
29-Mar-2014 23:43:51 mbfido[858] MBFIDO v1.0.2
29-Mar-2014 23:43:51 mbfido[858] Cmd: mbfido to
------------------------

The first block was when I sent you a message direct and if you look at the
block within:

---------------------------
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: EXTCMD is active
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: MD5 unprotected session
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: forcing downgrade to binkp/1.0
protocol
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: mail 2761, files 0 bytes
---------------------------

and this is from my debug log for the entire connection (it is long):

--------------------------
29-Mar-2014 19:17:40 mbcico[3504] MBCICO v1.0.2
29-Mar-2014 19:17:40 mbcico[3504] Cmd: mbcico f5555.n280.z2.fidonet
s 29-Mar-2014 19:17:40 mbcico[3504] rdoptions node Michiel van der Vlist
2:280/5
***@fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] Options: Call WaZOO EMSI Freqs Zmodem
ZedZap
Hydra PLZ GZ/BZ2 NoNR
? 29-Mar-2014 19:17:40 mbtask[11607] TCP/IP session registered (3504), now 1
ses
sions
s 29-Mar-2014 19:17:40 mbcico[3504] Inbound set to
"/home/mbse/var/inbound/tmp.2
.280.5555.0"
+ 29-Mar-2014 19:17:40 mbcico[3504] Calling 2:280/***@fidonet (Blijf Tonijn,
ph
one (null))
+ 29-Mar-2014 19:17:40 mbcico[3504] Open TCP connection to
"fido.vlist.eu:24554"
+ 29-Mar-2014 19:17:40 mbcico[3504] Trying IPv4 83.82.233.201 port 24554
+ 29-Mar-2014 19:17:40 mbcico[3504] Established IBN/TCP IPv4 connection with
83.
82.233.201, port 24554
s 29-Mar-2014 19:17:40 mbcico[3504] IPv4 TCP connection: len=16, port=24554,
add
r=83.82.233.201
+ 29-Mar-2014 19:17:40 mbcico[3504] GeoIP location: Netherlands, NL EU
+ 29-Mar-2014 19:17:40 mbcico[3504] Start outbound Binkp session with
2:280/5555
@fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] Binkp: start session
s 29-Mar-2014 19:17:40 mbcico[3504] SM (orgbinkp): Start => ConnInit
s 29-Mar-2014 19:17:40 mbcico[3504] SM (orgbinkp): ConnInit => WaitConn
+ 29-Mar-2014 19:17:40 mbcico[3504] Binkp: node 2:280/***@fidonet
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL SYS Air Applewood BBS
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL ZYZ Vince Coen
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL LOC Roydon, Essex, UK
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL NDL CM,XA,IBN
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL TIME Sat, 29 Mar 2014
19:17:40 +0000
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL VER
mbcico/1.0.2/GNU/Linux-x86_64 binkp/1.0
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL PHN applewood.dtdns.net
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL OPM Air Applewood BBS
Linux System
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: binkp_send_comp_opts(TRUE) NRwe=Can
NRthey=Can
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_NUL OPT EXTCMD GZ BZ2 PLZ
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_ADR 2:250/***@fidonet
2:25/***@fidonet 2:250/***@fidonet
s 29-Mar-2014 19:17:40 mbcico[3504] SM (orgbinkp): WaitConn => WaitAddr
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL OPT
CRAM-MD5-397fce50ba666c5094d36421df3c22ee
+ 29-Mar-2014 19:17:40 mbcico[3504] Options :
CRAM-MD5-397fce50ba666c5094d36421df3c22ee
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL SYS Blijf Tonijn
+ 29-Mar-2014 19:17:40 mbcico[3504] System : Blijf Tonijn
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL ZYZ Michiel van der
Vlist
+ 29-Mar-2014 19:17:40 mbcico[3504] Sysop : Michiel van der Vlist
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL LOC Driebergen, NL
+ 29-Mar-2014 19:17:40 mbcico[3504] Location: Driebergen, NL
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL NDL
CM,MO,IBN:fido.vlist.eu,U,RPK,NPK,ENC,NC
+ 29-Mar-2014 19:17:40 mbcico[3504] Flags :
CM,MO,IBN:fido.vlist.eu,U,RPK,NPK,ENC,NC
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL TIME Sat, 29 Mar 2014
20:17:27 +0100
+ 29-Mar-2014 19:17:40 mbcico[3504] Time : Sat, 29 Mar 2014 20:17:27 +0100
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL VER binkd/1.1a-49/Win32
binkp/1.1
+ 29-Mar-2014 19:17:40 mbcico[3504] Uses : binkd/1.1a-49/Win32 binkp/1.1
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL 2:280/***@fidonet
2:2/***@fifonet 2:28/***@fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] address : 2:280/***@fidonet
+ 29-Mar-2014 19:17:40 mbcico[3504] address : 2:2/***@fifonet
+ 29-Mar-2014 19:17:40 mbcico[3504] address : 2:28/***@fidonet
s 29-Mar-2014 19:17:40 mbcico[3504] SM (orgbinkp): WaitAddr => SendPasswd
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: send M_PWD
CRAM-MD5-89aeacd2c28706313938a839a81ba42e
s 29-Mar-2014 19:17:40 mbcico[3504] SM (orgbinkp): SendPasswd => AuthRemote
s 29-Mar-2014 19:17:40 mbcico[3504] SM (orgbinkp): AuthRemote => IfSecure
s 29-Mar-2014 19:17:40 mbcico[3504] SM (orgbinkp): IfSecure => WaitOk
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: rcvd M_NUL OPT EXTCMD
+ 29-Mar-2014 19:17:41 mbcico[3504] Options : EXTCMD
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: remote wants EXTCMD mode
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: EXTCMD they=Want we=Want
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: EXTCMD is active
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: BZ2 they=Can we=Want
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: GZ they=Can we=Want
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: PLZ they=Can we=Want
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: NR they=Can we=Can
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: rcvd M_NUL non-secure
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: M_OK "non-secure"
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: MD5 unprotected session
s 29-Mar-2014 19:17:41 mbcico[3504] SM (orgbinkp): WaitOk => Opts
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: EXTCMD they=Act. we=Act.
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: BZ2 they=Can we=Want
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: GZ they=Can we=Want
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: PLZ they=Can we=Want
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: NR they=Can we=Can
s 29-Mar-2014 19:17:41 mbcico[3504] SM (orgbinkp): Opts => Success
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: forcing downgrade to binkp/1.0
protocol
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: last session was 0
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: rcvd M_EOB
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: receiver RxWaitF
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp/1.0 mode and got M_EOB, goto RxEOB
t 29-Mar-2014 19:17:41 mbcico[3504] tty_waitputget: timeout=300
b 29-Mar-2014 19:17:41 mbcico[3504] Creating filelist
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: mail 2761, files 0 bytes
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: send M_NUL TRF 2761 0
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: send
"/home/mbse/var/bso/outbound/011815b3.cut" as "4754c9ce.pkt"
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: size 2761 bytes, dated Mar 29
19:17:17, comp No
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: send M_FILE 4754c9ce.pkt 2761
1396120637 0
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: send data (2761)
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: OK 2761 bytes sent in 0.001 seconds
(2696.289 Kb/s)
t 29-Mar-2014 19:17:41 mbcico[3504] tty_waitputget: timeout=300
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: send M_EOB
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: 1 pending files on queue
t 29-Mar-2014 19:17:41 mbcico[3504] tty_waitputget: timeout=300

Lots of duplicate messages for the above last two lines and then:

b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: rcvd M_GOT 4754c9ce.pkt 2761
1396120637
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: receiver RxEOB
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: add message M_GOT 4754c9ce.pkt 2761
1396120637
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: Process The Messages Queue Start
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: M_GOT "4754c9ce.pkt 2761
1396120637"
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: remote GOT "4754c9ce.pkt"
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: binkp/1.0 session seems complete
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: binkp_clear_filelist(0)
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: session finished, rc=0
s 29-Mar-2014 19:17:43 mbcico[3504] Closing temp inbound after a good session
s 29-Mar-2014 19:17:43 mbcico[3504] inbound_close(): /home/mbse/var/inbound
locked
s 29-Mar-2014 19:17:43 mbcico[3504] inbound_close(): /home/mbse/var/inbound
unlocked
s 29-Mar-2014 19:17:43 mbcico[3504] inbound_close(): removed
/home/mbse/var/inbound/tmp.2.280.5555.0/tmp
s 29-Mar-2014 19:17:43 mbcico[3504] inbound_close(): removed
/home/mbse/var/inbound/tmp.2.280.5555.0
+ 29-Mar-2014 19:17:43 mbcico[3504] Closing TCP connection, connected 3.00s
+ 29-Mar-2014 19:17:43 mbcico[3504] Call to 2:280/***@fidonet successful
(rc=0)
+ 29-Mar-2014 19:17:43 mbcico[3504] Sent 2761 bytes, received 0 bytes, avg
2761
cps
m 29-Mar-2014 19:17:43 mbtask[11607] MIB set mailer 6,0,2,1,1,4,0;
m 29-Mar-2014 19:17:43 mbtask[11607] MIB mailer: rcvd=23765029 sent=24171406
in=60742 out=207347 sec=191049 unsec=55039 bad=22001 ftsc=0 yoohoo=308
emsi=168
binkp=248865 freq=3
+ 29-Mar-2014 19:17:43 mbcico[3504] Connected 3.00s
29-Mar-2014 19:17:43 mbcico[3504] MBCICO finished in 3.00s
--------------------------

The lines to note are:

++++++++++++++++++++++
+ 29-Mar-2014 19:17:40 mbcico[3504] Time : Sat, 29 Mar 2014 20:17:27 +0100
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL VER binkd/1.1a-49/Win32
binkp/1.1
+ 29-Mar-2014 19:17:40 mbcico[3504] Uses : binkd/1.1a-49/Win32 binkp/1.1
b 29-Mar-2014 19:17:40 mbcico[3504] Binkp: rcvd M_NUL 2:280/***@fidonet
2:2/***@fifonet 2:28/***@fidonet
++++++++++++++++++++++


Shows that you are v1.1 but will force v1.0 see these lines but specifically
line 3:

++++++++++++++++++++++++
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: NR they=Can we=Can
s 29-Mar-2014 19:17:41 mbcico[3504] SM (orgbinkp): Opts => Success
+ 29-Mar-2014 19:17:41 mbcico[3504] Binkp: forcing downgrade to binkp/1.0
protocol
b 29-Mar-2014 19:17:41 mbcico[3504] Binkp: last session was 0
++++++++++++++++++++++++



Not sure what happened when you polled me but please try again.

After which I must thurn debug off as I am getting a heck of a lot of logging:

Vince
mark lewis
2014-03-29 16:27:57 UTC
Permalink
On Sat, 29 Mar 2014, Michiel van der Vlist wrote to Vince Coen:

VC> I will now set this up with your node addr and full debugging so
VC> please poll me.


MvdV> 29 Mar 22:19:34 [7012] BEGIN standalone, binkd/1.1a-49/Win32 -p
MvdV> -P250/1 binkd.cfg
MvdV> 29 Mar 22:19:34 [7012] creating a poll for 2:250/***@fidonet (`d'
MvdV> flavour) 29 Mar 22:19:34 [7012] clientmgr started
MvdV> + 29 Mar 22:19:34 [6336] call to 2:250/***@fidonet
MvdV> 29 Mar 22:19:34 [6336] trying f1.n250.z2.binkp.net
MvdV> [81.179.6.57]... 29 Mar 22:19:34 [6336] connected
MvdV> + 29 Mar 22:19:34 [6336] outgoing session with 81.179.6.57
MvdV> ? 29 Mar 22:19:34 [6336] recv: connection closed by foreign host
MvdV> + 29 Mar 22:19:34 [6336] done (to 2:250/***@fidonet, failed, S/R:
MvdV> 0/0 (0/0 bytes)) 29 Mar 22:19:34 [6336] session closed,
MvdV> quitting...
MvdV> 29 Mar 22:19:35 [7012] the queue is empty, quitting...

that looks suspiciously like what you were seeing before with those other nodes
running the older version of mbcico...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin
Vince Coen
2014-03-30 00:08:23 UTC
Permalink
Hello mark!
VC>> I will now set this up with your node addr and full debugging so
VC>> please poll me.


MvdV>> 29 Mar 22:19:34 [7012] BEGIN standalone, binkd/1.1a-49/Win32
MvdV>> -p -P250/1 binkd.cfg
MvdV>> 29 Mar 22:19:34 [7012] creating a poll for 2:250/***@fidonet
MvdV>> (`d' flavour) 29 Mar 22:19:34 [7012] clientmgr started + 29
MvdV>> Mar 22:19:34 [6336] call to 2:250/***@fidonet
MvdV>> 29 Mar 22:19:34 [6336] trying f1.n250.z2.binkp.net
MvdV>> [81.179.6.57]... 29 Mar 22:19:34 [6336] connected
MvdV>> + 29 Mar 22:19:34 [6336] outgoing session with 81.179.6.57
MvdV>> ? 29 Mar 22:19:34 [6336] recv: connection closed by foreign
MvdV>> host + 29 Mar 22:19:34 [6336] done (to 2:250/***@fidonet, failed,
MvdV>> S/R: 0/0 (0/0 bytes)) 29 Mar 22:19:34 [6336] session closed,
MvdV>> quitting...
MvdV>> 29 Mar 22:19:35 [7012] the queue is empty, quitting...
Post by mark lewis
that looks suspiciously like what you were seeing before with those
other nodes running the older version of mbcico...
There is no details of a poll from him at these or any other time except the
one when I polled him and that applies in all log files: system, debug &
mbtask.

I can only assume that the router rejected it or the system did (I noticed
there was some very minor unidentified traffic to proftpd) around that time
but not enough to reject it because of volume.

I cannot see the log for the router as it has rolled off the top due to
torrent
traffic.

Vince
Michiel van der Vlist
2014-03-30 11:01:11 UTC
Permalink
Hello Vince,

On Sunday March 30 2014 04:08, you wrote to mark lewis:

VC> There is no details of a poll from him at these or any other time
VC> except the one when I polled him and that applies in all log files:
VC> system, debug & mbtask.

VC> I can only assume that the router rejected it or the system did (I
VC> noticed there was some very minor unidentified traffic to proftpd)
VC> around that time but not enough to reject it because of volume.

VC> I cannot see the log for the router as it has rolled off the top due
VC> to torrent traffic.

I am still unable to connect to you, still the same error. I will poll you at
16:00 UTC or shortly thereafter, so you can have a look at the logs.


Cheers, Michiel

Loading...