I sort of ran into this a while ago, in that I was not able to
troubleshoot things due to all the reasons that tcptraceroute exists.
Does the -P flag to the built in traceroute not suffice for you?
I have settled on mtr (sudo port install mtr) for my tracing needs, it
seems to be a much more visual and better way to research source and
destination packets.
For what it is worth, on a Intel MacBook:
tcptraceroute @1.5beta7_1 (active)
I was able to get it installed.
libpcap @1.0.0_0 (active)
libnet11 @1.1.4_0 (active)
Strange that tcptraceroute needs root to run...
mtr google.com
I got a full answers in 1.5 seconds or so.
I did get tcptraceroute to work:
http://www.pastie.org/722620
But, using your command:
sudo tcptraceroute -d mail.google.com 443
Looks common enough:
http://www.google.com/search?hl=en&source=hp&q=debug%3A+null+pointer+from+pcap_next%28%29&aq=f&oq=&aqi=
I suggest you take that issue to the tcptraceroute mailing list, it
does not look to be related to MacPorts.
Sorry I could not be of more help. Maybe mtr will work for you in the
meantime.
--
Scott * If you contact me off list replace talklists@ with scott@ *
On Nov 30, 2009, at 1:07 PM, Josh Bracken wrote:
Hi,
I'm getting nothing but "debug: null pointer from pcap_next()" after
upgrading to 10.6 and re-installing mac ports and subsequently
installing tcptraceroute. I then installed Mac Ports on a different
Mac that had shipped with 10.6 and had never had Mac Ports installed.
I get the same results on both macs. I have had zero success finding
any way to remediate this issue. I have found 2 possible causes for
this noted below:
1) on a platform where packet filtering is done in user mode rather
than the kernel, the kernel hands a buffer full of packets to libpcap
but none of them pass the filter;
2) on a platform that supports a read timeout that starts before any
packets arrive, and that causes the read/recvfrom/getmsg/whatever from
the kernel to return when the timeout expires even if no packets have
arrived, no packets arrive within the timeout interval.
My versions
--
libpcap 1.0.0
libnet 1.1.4
tcptraceroute 1.5beta7_1
Debug output from tcptraceroute to gmail
--
l-s-lock:~lock$ sudo tcptraceroute -d mail.google.com 443
debug: tcptraceroute 1.5beta7, i686-apple-darwin10.0.0
debug: Compiled with libpcap 1.0.0, libnet 1.1.4 (API 110)
debug: entering getinterfaces()
debug: ifreq buffer set to 32
debug: Successfully retrieved interface list
debug: Using HAVE_SOCKADDR_SA_LEN method for finding addresses.
debug: Discovered interface lo0 with address 24.3.0.0
debug: Ignoring AF_INET6 address on interface lo0
debug: Ignoring AF_INET6 address on interface lo0
debug: Discovered interface lo0 with address 127.0.0.1
debug: Ignoring down interface gif0
debug: Ignoring down interface stf0
debug: Discovered interface en0 with address 6.3.6.0
debug: Discovered interface en0 with address 10.2.5.10
debug: Discovered interface fw1 with address 144.3.8.0
debug: Discovered interface en1 with address 6.3.6.0
debug: leaving getinterfaces()
debug: Determined source address of 10.2.5.10 to reach 74.125.127.19
debug: entering finddev()
debug: finddev() returning en0
debug: Setting o_syn, in absence of either o_syn or o_ack
debug: debugoptions():
debug: TEXTSIZE: 1024SNAPLEN: 92 IPTOSBUFFERS: 12
debug: ALLOCATEID_CACHE: 512datalink: 1datalinkoffset: 14
debug: o_minttl: 1 o_maxttl: 30o_timeout: 3
debug: o_debug: 1 o_numeric: 0 o_pktlen: 0
debug: o_nqueries: 3o_dontfrag: 0 o_tos: 0
debug: o_forceport: 0 o_syn: 1 o_ack: 0
debug:o_ecn: 0o_nofilter: 0 o_nogetinterfaces: 0
debug: o_trackport: 0 datalinkname: ETHERNET device: en0
debug: o_noselect: 1o_dnat: 0 isn:
1044160097
Selected device en0, address 10.249.58.10, port 49938 for outgoing
packets
debug: pcap filter is:
(tcp and src host 74.125.127.19 and src port 443 and dst host
10.249.58.10)
or ((icmp[0] == 11 or icmp[0] == 3) and dst host 10.249.58.10)
Tracing the path to mail.google.com (74.125.127.19) on TCP port 443
(https), 30 hops max
debug: Generating a new batch of 512 IP ID's
debug: Sent probe 1 of 3 for hop 1, IP ID 62136, source port 49938,
SYN
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
debug: null pointer from pcap_next()
Can anyone with more understanding of libpcap elaborate on what
