#7972 closed defect (fixed)
tcptraceroute/libnet11 fails under 10.4.5 on Intel platform
Reported by: | dsinn@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.2 |
Keywords: | Cc: | markd@… | |
Port: | libnet11 |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
tcptraceroute reports a failure when attempting to trace to a site:
fatman:~ dsinn$ sudo tcptraceroute www.seanet.com 80 Selected device en1, address 192.168.42.241, port 59746 for outgoing packets Tracing the path to www.seanet.com (64.38.166.88) on TCP port 80, 30 hops max libnet_write failed? Attempted to write 40 bytes, only wrote -1
This occurs via both en0 and en1.
Both libnet11 and tcptraceroute build fine:
fatman:~ dsinn$ sudo port install libnet11 ---> Fetching libnet11 ---> Attempting to fetch libnet-1.1.2.1.tar.gz from http://www.packetfactory.net/libnet/dist/ ---> Attempting to fetch libnet-1.1.2.1.tar.gz from http://distfiles-od.opendarwin.org/ ---> Verifying checksum(s) for libnet11 ---> Extracting libnet11 ---> Configuring libnet11 ---> Building libnet11 with target all ---> Staging libnet11 into destroot ---> Packaging tgz archive for libnet11 1.1.2.1_0 ---> Installing libnet11 1.1.2.1_0 ---> Activating libnet11 1.1.2.1_0 ---> Cleaning libnet11 fatman:~ dsinn$ sudo port install tcptraceroute ---> Fetching tcptraceroute ---> Attempting to fetch tcptraceroute-1.5beta4.tar.gz from http://michael.toren.net/code/tcptraceroute/ ---> Verifying checksum(s) for tcptraceroute ---> Extracting tcptraceroute ---> Configuring tcptraceroute ---> Building tcptraceroute with target all ---> Staging tcptraceroute into destroot ---> Packaging tgz archive for tcptraceroute 1.5beta4_0 ---> Installing tcptraceroute 1.5beta4_0 ---> Activating tcptraceroute 1.5beta4_0 ---> Cleaning tcptraceroute
I have no other installed port's that rely on libnet11, so I am unable to test if it is tcptraceroute or libnet11 that is failing. The system is a MacBookPro running 10.4.5.
Attachments (3)
Change History (16)
comment:1 Changed 18 years ago by markd@…
Cc: | markd@… added |
---|
comment:2 Changed 18 years ago by dsinn@…
Rebuild to 1.5beta7 and still same results:
Selected device en1, address 192.168.42.17, port 55321 for outgoing packets Tracing the path to www.seanet.com (64.38.166.88) on TCP port 80 (http), 30 hops max libnet_write failed? Attempted to write 40 bytes, only wrote -1
Is there a good chance that the bug is with the libnet and not tcptraceroute?
comment:3 Changed 18 years ago by markd@…
(In reply to comment #2)
Is there a good chance that the bug is with the libnet and not tcptraceroute?
That is entirely possible. But I don't have enough knowledge here to help. If you wanted to try a newer version of libnet11, 1.1.3-RC-01 is out there. Just edit your libnet11 portfile and replace 1.2.1.1 with 1.1.3-RC-01 and replace the checksum with 5212616485265e33564bbbb12ab5ccd0 and reinstall. I don't have an Intel box to test with. If it is suspected that the problem is libnet11 (and 1.1.3 doesn't fix it) then the developers could be contacted.
comment:4 Changed 18 years ago by shadow@…
configure.in in libnet needs a hunk patched in something like
i?86-*-*darwin*) AC_DEFINE(LIBNET_BSDISH_OS) AC_DEFINE(LIBNET_BSD_BYTE_SWAP) LIBNET_CONFIG_DEFINES="-DLIBNET_BSDISH_OS -DLIBNET_BSD_BYTE_SWAP" ;;
autoconf reran to regenerate configure,
And all will be well
comment:5 Changed 18 years ago by markd@…
So if someone with an MacTel box could create ${portpath}/libnet11/files, download the attached patch into it, and add the following keywords to the portfile and install the port the fix can be verified.
patchfiles patch-configure.in use_autoconf yes
comment:6 Changed 18 years ago by dsinn@…
tcptraceroute still fails with the same error message after applying the configure.in patch for libnet11 on my MacIntel under 10.4.6
comment:7 Changed 18 years ago by dsinn@…
tcptraceroute is now working with libnet11 being fixed, but not via the suggested patch and additions to the Portfile. I am not very well versed with exactly operations of port, so it is quite possible that I erred in the suggested additions.
The "configure.in" file was in the files directory and the two commands were added to the portfile, but when I verified the Makefile, it did not have the additional directives in the LIBNET_CONFIG_DEFINES line.
I then manually edited the "configure.in" file and put additional lines from the patch in as a replacement for the existing "*darwin*" case terms. I then re-ran "autoconf" and "configure --prefix=/opt/local". The newly created Makefile did have the new directives.
Finished the build of libnet11 and tcptraceroute and verified that it now works correctly.
comment:8 Changed 18 years ago by markd@…
Looks like that patch was not correct. I attached a new one to be put into Portfilepath/files. Below are the changes to make to the Portfile. If someone can test it on an Intel Mac we can send it upstream for inclusion in the next version of libnet.
--- Portfile.org 2006-08-27 02:26:11.000000000 -0700 +++ Portfile 2006-08-27 02:34:52.000000000 -0700 @@ -26,8 +26,10 @@ master_sites ${homepage}dist/ distname libnet-${version} checksums md5 be845c41170d72c7db524f3411b50256 +patchfiles patch-configure.in worksrcdir libnet +use_autoconf yes platform darwin 6 { depends_build path:/usr/include/netinet/ip_var.h:netinet-headers
Changed 18 years ago by markd@…
Attachment: | patch-configure.2.in added |
---|
Patch for libnet11's configure.in
Changed 18 years ago by markd@…
Attachment: | patch-configure.3.in added |
---|
Patch for libnet11's configure.in
comment:9 Changed 18 years ago by markd@…
attachments.isobsolete: | 0 → 1 |
---|
comment:10 Changed 18 years ago by dsinn@…
The recommended patch does not work, but I've figured out why.
Please forgive me since I'm not a programmer, so I don't have my suggested changes in a normal patch... Anyone have a pointer to a quick lesson on using it? :)
The suggested patch doesn't work because the case statement doesn't have the details needed to match. The "configure.status" file pointed me at why:
s,@target@,i386-apple-darwin8.7.1,;t t s,@target_cpu@,i386,;t t s,@target_vendor@,apple,;t t s,@target_os@,darwin8.7.1,;t t
The case is comparing "target_os" which doesn't have CPU type as part of it.
So building off of the "solaris" case later in the original configure.in file from libnet, I added an additional case within the darwin section to check "target". I guess it is debatable if the case check should just check against 'target_cpu'...
*darwin*) AC_DEFINE(HAVE_SOCKADDR_SA_LEN) LIBNET_CONFIG_DEFINES="-DHAVE_SOCKADDR_SA_LEN" dnl dnl Check to see if x86 dnl case "$target" in i?86-*-*darwin*) AC_DEFINE(LIBNET_BSDISH_OS) AC_DEFINE(LIBNET_BSD_BYTE_SWAP) LIBNET_CONFIG_DEFINES="$LIBNET_CONFIG_DEFINES -DLIBNET_BSDISH_OS -DLIBNET_BSD_BYTE_SWAP" ;; *) ;; esac ;;
Not being really up on the use of case, I wasn't sure I needed the match all at the end but put it in anyways to be safe.
Finished building libnet11 and then tcptraceroute and everything worked.
Thanks!
comment:11 Changed 18 years ago by markd@…
Good job. Don't worry that you aren't a programmer, neither am I. But I don't have an Intel box to test with. To make a patch, all you do is copy the original so you have say configure.in.org and configure. Modify configure with your changes, then give this command:
diff -u configure.in.org configure.in >patch-configure.in
Now you've got a patchfile to put in ./files and list in the Portfile. That's it. Would you mind doing that since you have a box you can test it with? I thought you might be interested in the process anyway. I definitely want to pass this to the developers for inclusion in 1.1.3 so we don't have to always patch it.
comment:12 Changed 18 years ago by markd@…
Resolution: | → fixed |
---|---|
Status: | new → closed |
Committed the patch. Thanks!
comment:13 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Port: | libnet11 added |
tcptraceroute has been updated to 1.5beta7. It has no explicit Intel fixes listed in the changelog but please try it and see. If it still has a problem with Intel then it should be reported as a bug to the developer so they can fix it.