@climber-girl noticed a case where a pshtt scan failed because no traffic was returned. The most likely culprit is that the NAT gateway through which all the Lambda traffic is passing is being overly taxed and dropping connections. To resolve this, I reduced the concurrency of the pshtt and sslyze scans by twenty percent.
Note that the trustymail concurrency has already been reduced in #35 in order to alleviate a different issue, and hence there is no need to reduce it here.
💠Motivation and Context
The dropped connections are resulting in incorrect pshtt scan results.
🧪 Testing
There is no way to test except to perform a full production scan using the new concurrency parameters and see if the problem persists. That will happen this weekend.
🚥 Types of Changes
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (causes existing functionality to change)
✅ Checklist
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
🗣 Description
@climber-girl noticed a case where a pshtt scan failed because no traffic was returned. The most likely culprit is that the NAT gateway through which all the Lambda traffic is passing is being overly taxed and dropping connections. To resolve this, I reduced the concurrency of the pshtt and sslyze scans by twenty percent.
Note that the trustymail concurrency has already been reduced in #35 in order to alleviate a different issue, and hence there is no need to reduce it here.
💠Motivation and Context
The dropped connections are resulting in incorrect pshtt scan results.
🧪 Testing
There is no way to test except to perform a full production scan using the new concurrency parameters and see if the problem persists. That will happen this weekend.
🚥 Types of Changes
✅ Checklist