Date: Tue, 14 May 2019 12:20:40 +0200 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: ZTEX: timeouts and optimizing? Hi Vincent, On Tue, May 14, 2019 at 12:37:38AM +0200, Vincent wrote: > I'm playing with john and some ZTEX boards. Some unexpected errors are shown > once in a while: > > <cracking starts> > .. > SN <removed>: Timeout. > Found 1 device(s) ZTEX 1.15y > SN: <removed> productId: 10.15.0.0 "inouttraffic JtR 1.8.x" busnum:1 > devnum:36 > .. > <cracking continues> Yes, this can happen once in a while, and it hurts the average speed as the timed-out device remains unused for a while. If this is infrequent enough, you could just accept it. BTW, to automatically remove SNs from JtR output, you can list them in the [List.ZTEX:Devices] section in john.conf. Then they'll be replaced with device numbers in JtR output, and also you'll be able to refer to devices by number in the "--devices" option. > Some questions: > - Are there user settings that might fix this (e.g. frequency)? For some hash types you need to adjust TargetSetting or TargetRounds in the corresponding john.conf sections, to match the loaded hashes' iteration counts. JtR warns you when this is needed. Lowering the frequency could help, but in another message you already say it didn't help you. Lowering the frequency too much could actually trigger timeouts in some cases. Excluding specific boards that are most problematic for specific hash types could also help, if you have many boards. You can use the "--devices" option to do this without having to physically disconnect or power off any boards. As you say, all of them work fine for bcrypt-ztex, so you wouldn't want to permanently disconnect any. Sometimes also replacing USB cables or hubs helps. This is unlikely to help in your case since you say bcrypt-ztex works reliably for you, but it's still possible that this will help because USB traffic patterns vary between hash types (and bcrypt-ztex commonly uses relatively little bandwidth), so some might expose a problem that others don't. On a related note, use of "--mask" (maybe along with other cracking modes) reduces USB traffic, so might help hide USB-related problems too. It's also useful to observe how the timeouts/errors are distributed between different FPGA numbers on each board. If they're similarly common for all 4 FPGAs, this would suggest a USB problem. If some FPGAs exhibit errors far more frequently than others, this would suggest that our specific design just doesn't work reliably on those specific chips (at least at the specific frequency). > - Are guesses lost as the result of the time-outs? Some processing is lost (whatever the board managed to do just before it got into a wrong state and timed out), but it's then redone, so everything crackable in that session is supposed to be cracked anyway. If anything that should doesn't get cracked, that's not because of timeouts, but rather because of potential undetected errors. > - What's a good way to determine the maximum speed of individual boards? > - If clocked too high, will a board just hang of will guesses be wrong? We're testing with many same-salt hashes, where many (or even all) of the attempted candidate passwords are expected to crack some hash. Then we make sure that everything actually does get cracked. Sometimes too high a frequency primarily results in timeouts. Sometimes a moderately too high frequency may first result in a small percentage of missed cracks, but no timeouts. Sometimes it's a mix of both. You can see such examples in some postings by me and by Royce. I hope this helps, and thank you for giving this functionality a try. If you don't mind, could you please share some statistics with us - how many boards out of how many you have exhibit these timeout problems for which hash types, their iteration count settings, hash and salt counts? Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.