Same problem here, but with 224.*.*.* .
Oviously, some clients send bogous IPs. Therefore, we should ignore 0.*.*.*, 127.*.*.* and [224-255].*.*.*, optionally (for bigger LANs the next adresses may make sense) also 192.168.*.*, 172.[16-31].*.* and/or 10.*.*.*.

An option to ignore search results from these adresses would also be nice.

ObInfo:
255.255.255.255: subnet-local broadcast, non-routable, no TCP.
224-: broadcast, reserved and experimental, partially no TCP.
127.*.*.*: test range, .0.0.1 is loopback test
0.*.*.*: some boot protocol
0.0.0.0: unspecified adress

10.*.*.*, 172.[16-31].*.*, 192.168.*.*: site-local adresses, not routable (at least it sould not be) on the internet. You're free to use them in your LAN. If you have one of those and connect to the internet, you are firewalled (even if you use port forwarding).
See "push request" from the readme for additional infos.
(HINT: select "never send push request", except for large LANs with local gnutella server.)

Delaying/retrying on network unreachable is not a bad trick if you wait for a temporarx connection problem, but there should be a timeout.

BTW: There should be an option to automatically use the reflected IP.