One additional tip (I'm not trying to be a pain in everyones behind here, just thinking out loud)
Since In *most* cases you can find the broadcast at .255, maybe you should make a small change to *first* try .255, and then do the scan if you get no response?
Hmmmmmm... Come to think of it, If nothing else: rather than counting up to 255, just count down from 255 - in most cases it will be an immediate match. On top of being more efficient, it would also make your code faster since there are less addresses to probe in most cases.
90%+ of the time you won't need to do your scan after all, it is only necesary to catch the exceptions.
you could even go as far as this, and probe the following IP's in order:
1) .255 (256 IP subnet)
2) .127 (128 IP subnet)
3) .63 and .191 (64 IP subnet)
4) .31, .95, .159, .223 (32 IP subnet)
5) .15, .47, .79, .111, .143, .175, .207, .239 (16 IP subnet)
6) .7, etc... (8 IP subnet)
Of course you can replace any of the above with the full scan, but since there aren't -that- many 'odd' broadcast IP's, if you probe the ones above first instead of brute-forcing the entire netblock you will find a match much faster, while keeping a relatively low profile on the network at the same time.
Of course your current example works as well, but you may want to consider the suggestion above as an improvement.
By the way, your multi-NIC code above does seem to work pretty well: it succesfuly determined the broadcast IP's on my real NIC, as well as two virtual (VMWare) ones.
Since In *most* cases you can find the broadcast at .255, maybe you should make a small change to *first* try .255, and then do the scan if you get no response?
Hmmmmmm... Come to think of it, If nothing else: rather than counting up to 255, just count down from 255 - in most cases it will be an immediate match. On top of being more efficient, it would also make your code faster since there are less addresses to probe in most cases.
90%+ of the time you won't need to do your scan after all, it is only necesary to catch the exceptions.
you could even go as far as this, and probe the following IP's in order:
1) .255 (256 IP subnet)
2) .127 (128 IP subnet)
3) .63 and .191 (64 IP subnet)
4) .31, .95, .159, .223 (32 IP subnet)
5) .15, .47, .79, .111, .143, .175, .207, .239 (16 IP subnet)
6) .7, etc... (8 IP subnet)
Of course you can replace any of the above with the full scan, but since there aren't -that- many 'odd' broadcast IP's, if you probe the ones above first instead of brute-forcing the entire netblock you will find a match much faster, while keeping a relatively low profile on the network at the same time.
Of course your current example works as well, but you may want to consider the suggestion above as an improvement.
By the way, your multi-NIC code above does seem to work pretty well: it succesfuly determined the broadcast IP's on my real NIC, as well as two virtual (VMWare) ones.