some little patches IMHO i think should be applied

From: sandr8 <sandr8(at)blu.it>
Date: Sun Jun 29 2003 - 11:04:46 EDT

now-it-should-compile-under-linux.diff is a little workaround to succesfully make libnet-1.1.1-RC-005 under linux... it was broken... please have a look an see if now it is still ok also for the other platforms... since only linux did use some variables in libnet_open_raw6, i choosed to declare them only for linux and not for any !(__WIN32__)... i think this should not break anything

libnet-no-inner-ip-bug-and-instead-more-sanity-checks.diff checks that in a non-advanced injection type you provide the right lower layer header. furthermore it eleminates a bug that did so that libnet never computed the checksum for inner ipv4 headers when the injection type was LIBNET_RAW4 and it deletes some lines related to the ipv6 checksum in libnet_build_ipv6()... in fact ipv6 doesn't have any checksum ;)

no-dump-bug.diff is a little workaround to avoid libnet crash every time it cannot recognize a protocol number and return it's name. this happens when you don't get any information about that protocol number... this is not very likely to happen on other platforms, but on Linux it seems to happen very often, even though the "missing" protocol is listed in /etc/protocols... anyway it's not getprotobynumber() which segfaults (as it was stated in Libnet-1.1.1-RC-005/docs/BUGS)... getprotobynumber() just fails silently returning a NULL and libnet didn't check for it...

legible-name2addr4-and-right-description-in-list-of-functions.diff changes the description of libnet_get_ipaddr4(), libnet_get_ipaddr6(), libnet_get_ipaddr6... it also changes some comments in source code and replaces a ntohl() with a htonl(m)... this was not a bug, but IMHO it's really misleading... it is much better to always use the right function, for reader's sake... it was really hard for me to make out what these function actually did before completely ignoring descriptions and comments and convincing myself that ntohl() did work there because perfectly equivalent htonl()... the code worked it did what it should do but both the description, the comments and the call to ntohl() said it did the opposite and reading the whole code it appeared a complete nonsense.

cheers
sandr8)

---

To unsubscribe, e-mail: libnet-unsubscribe@securityfocus.com For additional commands, e-mail: libnet-help@securityfocus.com Received on Sun Jun 29 11:18:55 2003