Subj : oxp locks up, again To : Martin Foster From : August Abolins Date : Mon Feb 10 2020 22:48:00 Hello Martin! ** 09.02.20 - 11:36, Martin Foster wrote to August Abolins: AA>> Which leads me to the security/bug/weakeness. AA>> ..then anyone could arbitrarily send me a nodelist, and its AA>> presence can screw up oxp (just like the presence of the old AA>> nodelist/diffs that I still had in there did). MF>It wasn't the presence of the old nodlists/diffs that was causing the MF>problem :) Correct. The main problem was having a Z1 nodelist and using a Z2 diff update file. But the only way I managed to clear the lock up was to delete the latent nodelist/nodediff files I still had in the incoming /FILES directory. MF>..The only files it takes action on are nodediffs/pointdiffs and if MF>any of them are out of sequence, it just ignores them. It was still taking action on the NODEDIFF that was in /FILES, even though I had cleared out the nodelist config tables. The /FIDO directory was empty! The following settings marked "<==THIS" were probably enabled: +- Configure Node/Pointlist ------------------------+ | | | List name NODELIST.### Number 038 | | | | Format of list Nodelist ? | | Zone/Address | | | | Update file NODEDIFF.### | | Update archive NODEDIFF.Z## | | | | Process by | | | | [x] Use internal nodelist processor |<==THIS | [x] Delete update after processing | +- Fido Options ---------------------------------+ Ý Ý Ý Int. dial prefix 00 Ý Ý Nat. dial prefix 0 Ý Ý Your dialing code 49-631 Ý Ý Ý Ý [x] Import nodelist updates automatically Ý<==THIS Ý [ ] Delete empty messages Ý Ý [x] Automatic TIC file processing Ý<==THIS? Is it the presence of a .TIC file in /FILES that can trigger the "action" too? Maybe I am worried over nothing since OXP probably takes a more secure process (ie acting on files only received from my Boss system via the TIC information) before it acts on just anything that looks like a diff file in the /FILES directory. ../|ug --- OpenXP 5.0.43 * Origin: ....................... (2:221/1.58) .