[network_bandwidth_test] network scan can be overzealous causing script to freeze
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Checkbox |
Fix Released
|
High
|
Brendan Donegan | ||
Bug Description
While running the cert tests on a remote network, I discovered a problem with the network_
The script, while looking for targets, does an nmap ping sweep of the network the target ethernet device is attached to:
class PingScan(Command):
name = "nmap -n -sP"
argument_count = 1
def parse_lines(self, lines):
hosts = []
host_lines = []
# Skip header lines
for line in lines[1:]:
if line.startswith
return hosts
Ordinarily, this works just fine on a network with a standard class C subnet, which yields, at most, 256 possible IPs.
However, it does not scale well at all. When run on a network with a standard class B subnet, it attempts a ping sweep of 256*256 hosts, for a total of 65536 hosts.
Good example is this device found on a server I was recently testing in a remote lab:
eth0 Link encap:Ethernet HWaddr 80:c1:6e:63:80:c0
inet addr:155.208.98.66 Bcast:155.
--
eth7 Link encap:Ethernet HWaddr e8:39:35:00:55:4f
inet addr:155.208.98.46 Bcast:155.
That's two devices being tested, and each one would trigger an nmap scan of 65536 IPs each :( Needless to say, this caused nmap to freeze and I had to skip the test.
Related branches
- Zygmunt Krynicki (community): Approve
-
Diff: 36 lines (+2/-2)3 files modifieddata/client-cert.whitelist (+0/-1)
data/client-selftest.whitelist (+0/-1)
debian/changelog (+2/-0)
- Zygmunt Krynicki (community): Approve
-
Diff: 29 lines (+1/-10)2 files modifieddebian/changelog (+1/-0)
jobs/networking.txt.in (+0/-10)
- Daniel Manrique (community): Approve
-
Diff: 1477 lines (+506/-529) (has conflicts)1 file modifieddebian/changelog (+506/-529)
| Daniel Manrique (roadmr) wrote | #1 |
| Changed in checkbox: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| importance: | Medium → High |
| Daniel Manrique (roadmr) wrote | #2 |
| Changed in checkbox: | |
| status: | Triaged → In Progress |
| assignee: | nobody → Brendan Donegan (brendan-donegan) |
| Changed in checkbox: | |
| status: | In Progress → Fix Committed |
| Marc Tardif (cr3) wrote | #3 |
| Changed in checkbox: | |
| status: | Fix Committed → Fix Released |
OK, so the reason to do the nmap scan is to determine pingable ip addresses. Since this bug report is a testimony that this technique does not scale, we could potentially switch to other techniques; they won't be as thorough as brute-forcing every single IP in the range, but they can potentially yield reasonable results.
Sciri showed us a Fluke network diagnostics tool and what it does essentially is ping either the gateway or the DHCP server. Another possible technique is to send a broadcast ping to populate the ARP table and then take an IP from that. The internet_test script already contains code to do this, so it could potentially be reused.
A "best of both worlds" approach for network_
Also, tweaking nmap so it's faster (I see from the manpage that even with -sP it sends two or three probes per IP), or even using the "timeout" command to limit the time it takes to find hosts could make it more usable.
I'll set this as triaged so we can start working on it.