AnsweredAssumed Answered

Problem in Pagination Logic of Host List Detection API v2

Question asked by Guy Yehuda on Jan 9, 2018
Latest reply on Jan 10, 2018 by Jeff Leggett

We’ve encountered an issue with the Pagination Logic in Host List Detection API v2 (resource /api/2.0/fo/asset/host/vm/detection/ with parameter action=list).

When working with no truncation (i.e. truncation_limit is 0, or a value larger than hosts amount in the network), we get X hosts back in one batch as expected.

When using truncation limit of Y, where Y < X , some hosts are skipped between the batches. The issue reproduces for most truncation limits we try.

After examination, we’ve found out that the problem is with the id_min in the URL returned in the WARNING tag.

Instead of supplying id_min which is [last returned host id + 1], Qualys tries to supply the exact id of the next host, but skips other hosts along the way for some reason.



A concrete example:

When running w/o truncation limit, we get 1461 hosts.

We ran it with truncation limit of 370, in order to get 4 batches back.

Results of the first batch are 370 hosts: ids 304576-5649612 as expected.

Next host ID should have been 5649650, but the id_min produced in the warning tag by Qualys is 5649894, i.e. skipping 2 hosts: 5649650 & 5649882.

Then, next id_min produced by Qualys in the warning at the end of the next batch is 39990011 instead of 39422787, causing 27 other hosts to be skipped.

All in all, 29 hosts out of 1461 were skipped.

In order to solve this issue, we had to inject the [last returned host id + 1] instead of the wrong id_min supplied by Qualys, instead of using the URL Qualys supply in the warning tag .

Thanks in advance,
Guy Yehuda