Within the fido config utility (echocfg) when entering a 4D address (NNN:NNN/NNN.0) the address is written in 3D format, i.e. with the point (0) removed. This works fine for most uses cases, however if an inbound .tic file uses a 4D address, then tickit.js will not match the Pw entry and TicFilePwd entry, and the following error occurs:
Configured TicFilePwd is empty, but TIC file has a password, node: 39:13/0.0
Suggested fix, within tickit.js as well as trying to match NNN:NNN/NNN also try NNN:NNN/NNN.0 in case 4D format is used in a .tic file.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
It would be helpful to have log lines before and after the error, not just the error. It looks like there's a weird hack to check passwords twice in some cases.
yeah, that "weird hack" is to make it work with domains because i couldn't figure out the C/C++ code right to handle 3D/4D and 3D/4D+domain properly... initial attempts worked but were shot down for a reason i don't recall so i punted and just did the dual lookup in tickit... the attempts might have been due to adding more logging but it has been too long to remember that part clearly...
I've imported the file for now, by editing the sbbsecho.ini file and adding the .0 point, however any further edits with echocfg restore the address back to a 3D address.
Also if 4D was added to echocfg, then I would imagine I would need to add every linked address twice, firstly in 3D format them 4D format, to cater for both types in .tic files.
yeah, the C/C++ code should already be handling the .0 internally... i haven't been in the code in a couple of years, though... haven't even switched to git from cvs yet :(
but, x:y/z.1 and similar should work properly... i'm thinking that it is specifically .0 that may be being missed for some reason...
as the guy that added a lot to tickit and spent time in this particular area, i can say that tickit specifically does two rounds through the addresses in sbbsecho.ini looking for a remote system's password... the first loop is without the 5D domain and the second loop adds the 5D domain... it should be finding them in 4D or 5D mode...
i really wanted to fix up the C/C++ code so that an address lookup would automatically work with either 4D or 5D FTN addresses but my C/C++ is woefully ugh...
i'm just trying to understand how it missed the address... you only added the .0 in sbbsecho.ini?
FWIW: FTN addressing is weird...
fidonet started with only the node number aka 1D...
then it added nets y/z for 2D...
then points and zones both came about the same time... address representation may or may not be done with the zone so x:y/z and y/z.d are both 3D... when the zone is left off, your default zone is assumed...
x:y/s.d is probably best known as 4D...
finally @domain was added and then you have x:y/z@domain (5D) and y/z.d@domain (4D)...
so you can see that there are two 3D and 4D representations in FTN software but few support the @domain format... my original work on tickit was was partly to further true 5D in sbbs as well as enhancing tickit to work properly in a HUB configuration...
I'm assuming that tickit.js sees something like NNN:NNN/NNN.0 in the tic file, then searches sbbsecho.ini for a matching address, which it won't find, as the address is in 3D format - NNN:NNN/NNN
So I've received the next nodelist from my hub and it went through ok, and I haven't tried the fix DigitalMan provided as I wanted to see it fail first before applying the latest code. Also my hub upgraded their system last weekend so this might explain why I don't have 4D problems this week. I will post another note on here if I spot the same problem again in future.