Just moving this from fsx_gen to keep the tls chat away from the gen area..

I'm guessing you are still polling 24556 - which is a different host
(IPv4 nat going on). If you poll 24553, it should get you bbs.leenooks.net:

This below is the output of "openssl s_client -alpn binkp -connect bbs.leenooks.net:24556"


=== Cut ===
CONNECTED(00000003)
-+-
Certificate chain
0 s:C = ZZ, O = W7-1-1, CN = dev.bbs.leenooks.net
i:C = ZZ, O = W7-1-1, CN = dev.bbs.leenooks.net
-+-
Server certificate
-----BEGIN CERTIFICATE----- MIIC8zCCAhygAwIBAgIIRr20pRZFutAwDQYJKoZIhvcNAQELBQAwPTELMAkGA1UE BhMCWloxDzANBgNVBAoTBlc3LTEtMTEdMBsGA1UEAxMUZGV2LmJicy5sZWVub29r cy5uZXQwHhcNMTkxMDE1MDI0ODQ4WhcNMzUxMjE2MDAwMDAwWjA9MQswCQYDVQQG EwJaWjEPMA0GA1UEChMGVzctMS0xMR0wGwYDVQQDExRkZXYuYmJzLmxlZW5vb2tz Lm5ldDCB3zANBgkqhkiG9w0BAQEFAAOBzQAwgckCgcEApF2Kab+CRU31Ya89pOhx gs0l19i9jxDQj4coaq+VYhqJQt39Vq/4nTFvs+X0UCnHN5ZkxsgeKzcsDV34smxV 4rdXWVWrECLTtQgKjtB6dCCeJiOvf1OYoRstxOSrVhpQarwdR5mm9SG6Gi51DJ0f XSmMEaofjQoW6bNXTqKRKOn5khGCW8+uM1y9UJ3uJqEZkUWX5klEJ2BiJI8sCu3I i4U1flZSE4gHHPfi4BfSkIHM+nLVXP5Vd+kCuvkwkYULAgMBAAGjfDB6MB0GA1Ud DgQWBBSToOqUM+4IOG39v9wHRDkHLJp7DjAOBgNVHQ8BAf8EBAMCBaAwOwYDVR0R BDQwMoEac3lzb3BAZGV2LmJicy5sZWVub29rcy5uZXSCFGRldi5iYnMubGVlbm9v a3MubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADgcEAdOZE32FwzIck vrtvqv3wTPlhzQNdYGV39vzCp0Il3Rdq4/jkidC/Y1zhemI0qjxNLIwxRhxsY01c z+xdHr8jSp3uCuzg71LVX0Z/XcHsWdkkO+bCXzb0Kj9bYr0NXkZyqsiWEkfqnDX/ J431lsA7cXoA+RiqMTXxps13Grr6MDuun1zbWRU5o46Qq2nE/M7DMDMx3MMEqsaN uL9d39FdIvkx79+WWrsi++SbKl1pSUZzrThuzhqX5/YxTY7GPUbK
-----END CERTIFICATE-----
subject=C = ZZ, O = W7-1-1, CN = dev.bbs.leenooks.net

issuer=C = ZZ, O = W7-1-1, CN = dev.bbs.leenooks.net

-+-
No client certificate CA names sent
-+-
SSL handshake has read 1446 bytes and written 232 bytes
Verification error: unable to verify the first certificate
-+-
New, (NONE), Cipher is (NONE)
Server public key is 1536 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID: 694017AF44CE1C205E8774B57E267DC2
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1583230828
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: yes
-+-
=== Cut ===

Just FYI.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

Hello alter,

IPv4:24553 is alterant (my bbs 2/116) - if you polled it, it would be unsecure (since your not defined on it), and so you shouldnt get any packets.

Yes, that's what happens. Just an error that there is no such AKA.

IPv4:24556 is Hub 3 - I see you poll it and get a bunch of stuff just
fine - but yes the cert wont match the DNS name (alterant.leenooks.net
- which resolves to the IPv4 address).

I wonder if IPv4/IPv6 could be a problem. My linode has both and will try IPv6 first.

verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
Exactly what that means I don't know.

That is normal, since the cert is self signed - this is just telling
you that you cannot validate the certificate via a 3rd party (self signed).

Well, we are tansfering both ways with TLS I think? So that is good.

I have taken bbs.linooks.net out of my hosts file since it didn't provide any joy and am back to polling alterant.leenooks.net.

I've noticed when I poll you (just testing for the most part) that I pick up a bunch of PKTs. Are you not able to poll and connect to my node?

That's actually a good thing. I can poll hub 4 but get nothing currently. Hub 4
may need a killbusy, I'm not sure.

It still takes a couple minutes to get my prompt back when I poll your node. I don't know why that is and it's not a critical error. Just a PITA. This is logged after I poll your node..

14:01 [8258] session closed, quitting...
14:03 [8258] rc=(8259)=0
14:03 [8257] rc=(8258)=0
14:03 [8257] the queue is empty, quitting...

I don't get that 2 minute delay when polling other binkd or mystic nodes. We do
get a successful session, I just don't understand what binkd is waiting/hoping
for after the session.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

Re: binkd ssl
By: Al to alter ego on Tue Mar 03 2020 02:06 pm

Well, we are tansfering both ways with TLS I think? So that is good.

Yes, I think so too...

I have taken bbs.linooks.net out of my hosts file since it didn't provide any joy and am back to polling alterant.leenooks.net.

Good - it was just to test if that cert name was causing your 2 min delay - and
if it was, there was work to do on my side. Sounds like it is not related (I didnt think it would be...)

I've noticed when I poll you (just testing for the most part) that I pick up a bunch of PKTs. Are you not able to poll and connect to my node?

Yes, I'm trying to get binkit to poll out - it doesnt seem to be doing it unless I manually touch binkit.now. Havent figured out why yet.

(While writing this, I had a brain wave, and hopefully found why binkit.now wasnt being triggered.)

I am also juggling, because Taurus is also serving the same outbound for EMSI and other binkp systems. I think they can work together (lock files, etc), just
need to do some more testing to be sure.

I'm thinking of (and wanting to) splitting that out anyway, so all EMSI is done
on its own host. Playing with ifcico (then Hub 3 can go on the pi) but Spectre
doesnt play well with it.

It still takes a couple minutes to get my prompt back when I poll your node. I don't know why that is and it's not a critical error. Just a PITA. This is logged after I poll your node..

Hmm..

14:01 [8258] session closed, quitting...
14:03 [8258] rc=(8259)=0
14:03 [8257] rc=(8258)=0
14:03 [8257] the queue is empty, quitting...

My side looks like this:
3/4 09:01:33a 1344 BINKPS connection accepted from: 172.105.21.200 port 46006
3/4 09:01:33a 1344 BINKPS BinkIT/2.28 invoked with options:
3/4 09:01:33a 1344 BINKPS JSBinkP/1.122 inbound connection from 172.105.21.200:46006
3/4 09:01:34a 1344 BINKPS Peer version: binkd/1.1a-101/Linux binkp/1.1
3/4 09:01:34a 1344 BINKPS Will encrypt session.
3/4 09:01:34a 1344 BINKPS Remote addresses: 1:153/757@fidonet 1:153/0@fidonet 21:4/106@fsxnet 32:1/5@gamenet
3/4 09:01:34a 1344 BINKPS Inbound session for: 21:4/106@fsxnet
3/4 09:01:34a 1344 BINKPS CRAM-MD5 password match for 21:4/106@fsxnet
3/4 09:01:34a 1344 BINKPS outbox file: /MAILER/BOX/00150004.06A\5e5ed0a7.pkt
3/4 09:01:34a 1344 BINKPS outbox file: /MAILER/BOX/00150004.06A\5e5ed161.pkt
3/4 09:01:34a 1344 BINKPS outbox file: /MAILER/BOX/00150004.06A\5e5ed196.pkt
3/4 09:01:34a 1344 BINKPS outbox file: /MAILER/BOX/00150004.06A\5e5ed295.pkt
3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed0a7.pkt (1.5KB)
3/4 09:01:34a 1344 BINKPS Sent file: /MAILER/BOX/00150004.06A\5e5ed0a7.pkt (1.5KB)
3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed161.pkt (1.7KB)
3/4 09:01:34a 1344 BINKPS Sent file: /MAILER/BOX/00150004.06A\5e5ed161.pkt (1.7KB)
3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed196.pkt (1.4KB)
3/4 09:01:34a 1344 BINKPS Sent file: /MAILER/BOX/00150004.06A\5e5ed196.pkt (1.4KB)
3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed295.pkt (2.0KB)
3/4 09:01:34a 1344 BINKPS Sent file: /MAILER/BOX/00150004.06A\5e5ed295.pkt (2.0KB)
3/4 09:01:34a 1344 BINKPS We got an M_EOB, but there are still 4 files pending M_GOT
3/4 09:03:35a 1344 BINKPS Timed out receiving first byte of packet header!
3/4 09:03:35a 1344 BINKPS Deleted file: /MAILER/BOX/00150004.06A\5e5ed0a7.pkt
3/4 09:03:35a 1344 BINKPS Deleted file: /MAILER/BOX/00150004.06A\5e5ed161.pkt
3/4 09:03:35a 1344 BINKPS Deleted file: /MAILER/BOX/00150004.06A\5e5ed196.pkt
3/4 09:03:35a 1344 BINKPS Deleted file: /MAILER/BOX/00150004.06A\5e5ed295.pkt
3/4 09:03:35a 1344 BINKPS service thread terminated (0 clients remain, 0 total, 172 served)

Perhaps somebody knows what's going on between 01:34 and 03:35 - it seems I'm waiting on you to send me something?
...deon


... Distrust your first impressions; they are invariably too favorable.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Hello alter,

Yes, I'm trying to get binkit to poll out - it doesnt seem to be doing
it unless I manually touch binkit.now. Havent figured out why yet.

By default Sync (BinkIT) is looking for and acting on the binkout.now semaphore. The binkpoll.now semaphore can also be used for polling nodes from time to time that have BinkpPoll = true in sbbsecho.ini.

I am also juggling, because Taurus is also serving the same outbound
for EMSI and other binkp systems. I think they can work together (lock files, etc), just need to do some more testing to be sure.

I hope so.. :)

Perhaps somebody knows what's going on between 01:34 and 03:35 - it
seems I'm waiting on you to send me something?

I've seen that, something about M_EOB, but I don't know what is happening there
so really can't comment on it. I wonder if both Sync and Binkd are having a bit of trouble communicating?

I wish a had better input on that but I am stumped.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On Wed, 4 Mar 2020 10:08:23 +1100
"alter ego -> Al" <[email protected]> wrote:

3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed0a7.pkt (1.5KB)
3/4 09:01:34a 1344 BINKPS Sent
file: /MAILER/BOX/00150004.06A\5e5ed0a7.pkt (1.5KB)
3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed161.pkt (1.7KB)
3/4 09:01:34a 1344 BINKPS Sent
file: /MAILER/BOX/00150004.06A\5e5ed161.pkt (1.7KB)
3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed196.pkt (1.4KB)
3/4 09:01:34a 1344 BINKPS Sent
file: /MAILER/BOX/00150004.06A\5e5ed196.pkt (1.4KB)
3/4 09:01:34a 1344 BINKPS Sending file: /MAILER/BOX/00150004.06A\5e5ed295.pkt (2.0KB)
3/4 09:01:34a 1344 BINKPS Sent
file: /MAILER/BOX/00150004.06A\5e5ed295.pkt (2.0KB)
3/4 09:01:34a 1344 BINKPS We got an M_EOB, but there are still 4 files pending M_GOT
3/4 09:03:35a 1344 BINKPS Timed out receiving first byte of
packet header!

Perhaps somebody knows what's going on between 01:34 and 03:35 - it
seems I'm waiting on you to send me something?

M_EOB: End-of-Batch. M_EOB command must be transmitted after all the files have
been sent.

M_GOT: File acknowledgement, that MUST be transmitted upon receiving of the last data frame for current file.

This is a weird error, especially because Al is receiving the files. It only happens over TLS?

---
* Origin: � (21:1/151)

Re: binkd ssl
By: Oli to alter ego on Wed Mar 04 2020 08:42 am

3/4 09:01:34a 1344 BINKPS We got an M_EOB, but there are still 4
files pending M_GOT

M_EOB: End-of-Batch. M_EOB command must be transmitted after all the files have been sent.
M_GOT: File acknowledgement, that MUST be transmitted upon receiving of the last data frame for current file.

So who is sending the M_EOB out so sequence? It would seem Mystic, given I was sending files "and still had 4 left"?

This is a weird error, especially because Al is receiving the files. It only happens over TLS?

I would say no - I've noticed this before - but on Hub 3 binkit isnt doing normal binkp (taurus is). I might look at changing that...
...deon


... Spaceballs: The Tagline
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On Wed, 4 Mar 2020 20:21:20 +1100
"alter ego -> Oli" <[email protected]> wrote:

Re: binkd ssl
By: Oli to alter ego on Wed Mar 04 2020 08:42 am

3/4 09:01:34a 1344 BINKPS We got an M_EOB, but there are
still 4 files pending M_GOT

M_EOB: End-of-Batch. M_EOB command must be transmitted after
all the files have been sent.
M_GOT: File acknowledgement, that MUST be transmitted upon
receiving of the last data frame for current file.

So who is sending the M_EOB out so sequence? It would seem Mystic,
given I was sending files "and still had 4 left"?

AFAIK Al uses binkd (log format looks like binkd too).

The M_EOB was sent when binkd had no more files to sent, looks correct to me. Then binkit was waiting for the M_GOT for the files it sent. Question is: didn't binkd sent the M_GOT commands or didn't binkit recognize them? It would need a tcpdump (or any log of the data sent over the wire) to see what went wrong.

This is a weird error, especially because Al is receiving the
files. It only happens over TLS?

I would say no - I've noticed this before - but on Hub 3 binkit isnt
doing normal binkp (taurus is). I might look at changing that...

That would be nice. Taurus' binkp is really slow ...

---
* Origin: � (21:1/151)