-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timenator stuck at 50%, only using first payload #4
Comments
Ran into the same thing, came here to see if others had similar problems. Since this is posted back in September, I might just start debugging and look for a solution. I rely on this plugin for the standard deviation results 😬 |
Found my problem, if the response doesn't have the field content-length, the rowData list can't get populated because the variable content_length never gets instantiated. The fix is simple, add a content_length variable and set it to 0: Before
After:
|
Ran into the same problem, would be great if somebody could merge the patch above... |
@ret2src @ustayready thank you for the fox. If you submit a pull request, I’ll accept it (if I still can since I no longer work at F-Secure) |
Timeinator has been working flawlessy a few weeks ago, but is now showing an unexpected behaviour: Each run gets stuck at exactly 50% progress.
Logger++ reveals that requests are being properly sent by the extension, yet only for the very first payload. Subsequent payloads are being ignored. The intended timing analysis is hence impossible.
Observed this behaviour on different OS's, e.g. Win 10 and MacOS. Currently on Burp Pro v2022.8.2.
Let me know if I can help with more debug info to track this down.
The text was updated successfully, but these errors were encountered: