So, I sent him an email, asking if he could take a look at his logs, in hopes of tracking down where the problem might be. After sending it, I looked again at the logs, and now his system is authorizing with no problems...
I don't know if he made any changes on his end or not, as I haven't received a reply. I was just curious what would cause this type of a problem, and which end it may be from.
Are you talking about my node? :)
Do you mind doing some testing? If you could set the CRAM-MD5 setting
for my node to "No", then your mailer will use plain text passwords so
we can confirm the right password is being used by the mailer.
Also, try setting CRAM-MD5 to yes and forced and see if that makes any difference.
I have just done some brief testing from the hub to your system. While Mystic is set to Yes or Forced for CRAM-MD5, I get an Authorization failed error. If I set it to No, it connects with no problems.
I do have your node set to No for CRAM-MD5 now.
I do have your node set to No for CRAM-MD5 now.
We should leave it like that for now. When I see any updates for binkit I'll get you to test that again.
We should leave it like that for now. When I see any updates for
binkit I'll get you to test that again.
Sounds like a plan. :)
I've made a small change to my binkp.js as requested by Digital Man. Can you set my nodes CRAM-MD5 setting to yes and see what we get?
I've made a small change to my binkp.js as requested by Digital Man.
Can you set my nodes CRAM-MD5 setting to yes and see what we get?
Just tested it, and both Forced and Yes were successful! ;) I do have you set as Yes again.
I'll keep an eye on it for a few days, just to make sure there are no other issues.
Re: Re: fsxNet net 4 System
By: Black Panther to Al on Fri Mar 23 2018 05:50 pm
I've made a small change to my binkp.js as requested by Digital Man.
Can you set my nodes CRAM-MD5 setting to yes and see what we get?
Just tested it, and both Forced and Yes were successful! ;) I do have you set as Yes again.
Awsome good news. I'll pass it along.
I'll keep an eye on it for a few days, just to make sure there are no other issues.
I think the change I made disabled crypt support so we'll want to turn that back on but this does point to a solution I think.. :)
The only conceivable work-around would be to disable BinkP-encryption in BinkIT (for all incoming connections) and we don't want to do that. So hopefull this bug report makes it to g00r00 and it gets fixed rather soonish. :-)
Re: Re: fsxNet net 4 System
By: Digital Man to Al on Sat Mar 24 2018 12:40 am
The only conceivable work-around would be to disable BinkP-encryption BinkIT (for all incoming connections) and we don't want to do that. S hopefull this bug report makes it to g00r00 and it gets fixed rather soonish. :-)
I'll certainly provide what info I can if needed.
Now that Vertrauen is here (nice!) perhaps Avon can also provide those logs?
Re: Re: fsxNet net 4 System
By: Digital Man to Al on Sat Mar 24 2018 12:40 am
The only conceivable work-around would be to disable BinkP-encryption in BinkIT (for all incoming connections) and we don't want to do that. So hopefull this bug report makes it to g00r00 and it gets fixed rather soonish. :-)
I'll certainly provide what info I can if needed.
Black Panther: Do you have debug logs you can provide g00r00? I can re-enable the crypt option if needed to get info for g00r00 to look at.
Let me know.. I won't change anything til I hear from you.
Now that Vertrauen is here (nice!) perhaps Avon can also provide those logs?
Digital Man / Al - does this corroborate what you have been reporting? Sorry I have not been paying close attention to this issue.
Digital Man - for now I have set CRAM-MD5 to No for your node so I can CRASH traffic to you.
Please re-enable CRAM-MD5 authentication so we can test the work-around. :-)
On 03/24/18, Digital Man pondered and said...
Please re-enable CRAM-MD5 authentication so we can test the work-around. :-)
Done, next fidopoll to your node will again use CRAM-MD5
Cool, and the work-around worked:
Cool, and the work-around worked:
Oh, and all credit to Deuce (Stephen Hurd) - BinkIT really is his baby.
Cool, and the work-around worked:
3/24 03:08:16p 1880 BINKP Got M_PWD command args: CRAM-MD5-92da8ef4d0020127382277cc761b7006
3/24 03:08:16p 1880 BINKP Inbound session for: 21:1/100@fsxnet
3/24 03:08:16p 1880 BINKP CRAM-MD5 password mismatch for 21:1/100@fsxnet (expected: CRAM-MD5-9e937fe194f9c943b838e197e60974da, received: CRAM-MD5-92da8ef4d0020127382277cc761b7006)
3/24 03:08:16p 1880 BINKP Checking Mystic pass...
3/24 03:08:16p 1880 BINKP CRAM-MD5 password match for 21:1/100@fsxnet
But in the words of my dentist: you really should get that fixed. :-)
Black Panther: Do you have debug logs you can provide g00r00? I can re-enable the crypt option if needed to get info for g00r00 to look at.
Let me know.. I won't change anything til I hear from you.
DM, Does this work-around disable the CRYPT for all connections? If so, we might want to change it back, so there isn't any issues with other connections made by the node.
The work-around we have in the latest BinkIT revisions will accept both
a valid CRAM-MD5 response and when the Mystic-mailer is detected, also accept a response with a Mystic-miscalculated digest (as though there
were 3 extra 0-bytes appended to the challenge).
The CRAM-MD5 response that Mystic sent (as logged above) appears to have been calculated using the challenge value of: 472f50a45b5356f5f66ce7024da4351e000000 (3 0-bytes appended). Again, this problem doesn't happen if the OPT message sent from BinkIT excludes the "CRYPT" option.
We're testing a work-around in BinkIT for this flaw in Mystic's BinkP implementation, but that's hopefully just a temporary hack until there's
a widely deployed fix.
Unfortunately I have no capacity to test my fix right now. I am so behind and overwhelmed at work and with taking care of a sick family member, but I did put a new mis.exe and fidopoll.exe in the prealpha directory for Avon if he'd like to test the fix with any of the Synchronet systems.
Sorry for taking forever to address the issue.
Unfortunately I have no capacity to test my fix right now. I am so
behind and overwhelmed at work and with taking care of a sick family
member, but I did put a new mis.exe and fidopoll.exe in the prealpha directory for Avon if he'd like to test the fix with any of the
Synchronet systems.
I think the change I made disabled crypt support so we'll want to turn that back on but this does point to a solution I think.. :)
member, but I did put a new mis.exe and fidopoll.exe in the prealpha directory for Avon if he'd like to test the fix with any of the Synchronet systems.
I did upgrade the net 4 system. We'll be able to help test it out, as Al is polling from that system.
I have just upgraded the net 4 system to the updated version that g00r00 posted with a fix for this.
If you could turn crypt back 'on' on your end, we can test it out and see how everything works.
I did upgrade the net 4 system. We'll be able to help test it out, as A polling from that system.
It needs to be an outbound connection (from Mystic) for the test.
I have just upgraded the net 4 system to the updated version that g00 posted with a fix for this.
It looks good here. I am running all stock binkit/binkp.js now. Here's
the log..
member, but I did put a new mis.exe and fidopoll.exe in the prealpha directory for Avon if he'd like to test the fix with any of the
Synchronet systems.
Sorry for taking forever to address the issue.
I've fixed this issue up in Mystic's code as well...
Unfortunately I have no capacity to test my fix right now. I am so
behind and overwhelmed at work and with taking care of a sick family member, but I did put a new mis.exe and fidopoll.exe in the prealpha directory for Avon if he'd like to test the fix with any of the
Synchronet systems.
member, but I did put a new mis.exe and fidopoll.exe in the prealpha directory for Avon if he'd like to test the fix with any of the Synchronet systems.
I must be blind as I can't see this...
member, but I did put a new mis.exe and fidopoll.exe in the prealpha directory for Avon if he'd like to test the fix with any of the Synchronet systems.
I must be blind as I can't see this...
Sorry for taking forever to address the issue.
A day or two !=forever!
These things cannot be resolved until they are discovered.
I'll keep an eye on my inbound logs for a working CRAM-MD5 auth from
Avon.
I couldn't find the files when I went looking earlier but it sounds like Dan may have them so I'll contact him to see if I can work an update to 21:1/100 that way.
On 03/25/18, Digital Man pondered and said...
I'll keep an eye on my inbound logs for a working CRAM-MD5 auth from Avon.
Hi there.
OK have updated to the latest release from g00r00.
Okay, I've disabled the CRAM-MD5 auth work-around on my end (just now),
so if you could try again and let me know if it succesfully
authenticates, that'd be helpful.
Okay, I've disabled the CRAM-MD5 auth work-around on my end (just now),
so if you could try again and let me know if it succesfully
authenticates, that'd be helpful.
On 03/26/18, Digital Man pondered and said...
Okay, I've disabled the CRAM-MD5 auth work-around on my end (just now), so if you could try again and let me know if it succesfully authenticates, that'd be helpful.
No joy.
No joy.
Here's the logging..
Re: Re: Fixing Mystic Fidopoll <> BinkIT
By: Avon to Digital Man on Tue Mar 27 2018 12:49 pm
On 03/26/18, Digital Man pondered and said...
Okay, I've disabled the CRAM-MD5 auth work-around on my end (just now), so if you could try again and let me know if it succesfully authenticates, that'd be helpful.
No joy.
Okay, well that's good data for g00r00.
This is A39 Windows/32 Compiled 2018/03/12 12:49:30
I updated the M_OK response argument to indicate whether it's a regular authentication ('secure') or the special work-around auth ('mystic-work-around') - just temporarily while testing. So you can see from your side whether or not the work-around was used for the CRAMD-MD5 response authentication.
On 03/26/18, Digital Man pondered and said...
I updated the M_OK response argument to indicate whether it's a regular authentication ('secure') or the special work-around auth ('mystic-work-around') - just temporarily while testing. So you can see from your side whether or not the work-around was used for the CRAMD-MD5 response authentication.
Testing another version just now.
Check your logs for the poll below
[snip]
Mar 28 22:26:01 FIDOPOLL Version 1.12 A39 2018/03/26
Mar 28 22:26:01 Scanning 21:1/183
Mar 28 22:26:01 Queued 0 files (0 bytes) to 21:1/183
Mar 28 22:26:01 Polling BINKP node 21:1/183 by IPV4
Mar 28 22:26:01 Connecting to vert.synchro.net
Mar 28 22:26:02 Connected via IPV4
Mar 28 22:26:02 S: NUL SYS fsxHUB [fsxNet WHQ]
Mar 28 22:26:02 S: NUL ZYZ Paul Hayton
Mar 28 22:26:02 S: NUL VER Mystic/1.12A39 binkp/1.0
Mar 28 22:26:02 S: ADR 21:1/100@fsxnet 21:1/3@fsxnet 21:1/2@fsxnet 21:1/0@fsxnet 21:0/0@fsxnet...
Mar 28 22:26:03 C: NUL OPT CRAM-MD5-d51c67f4a5070bdda2e6f0b6c71288fd CRYPT
Mar 28 22:26:04 C: OK secure
[snip]
Hopefully it's fixed now :)
Has 1.12A39 already been publicly released? It'd be nice to key the work-around in BinkIT to the version number, but right now the fixed version is flying the same "VER" string as the problem versions.
No, not as yet Rob. The version I am testing is a pre-alpha and I'm
unsure when g00r00 will release A39. He may care to comment when he's about next but I know he's really buy.
No, not as yet Rob. The version I am testing is a pre-alpha and I'm unsure when g00r00 will release A39. He may care to comment when he's about next but I know he's really buy.
Its available for anyone to download and install, its just only on the
FTP site, so technically everyone does have the option to upgrade if
they wanted to!
The earliest there could be an official A39 would be after this weekend when the website is back up... assuming I can validate and fix (if
needed) whatever people are saying is wrong with Linux fidopoll.
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 2 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 118:01:29 |
| Calls: | 2,127 |
| Calls today: | 3 |
| Files: | 11,149 |
| D/L today: |
41 files (21,471K bytes) |
| Messages: | 950,885 |