tcptraceroute 1.5b7 on Snow Leopard

[Scott Haneda]

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: 1024        SNAPLEN: 92     IPTOSBUFFERS: 12
> debug: ALLOCATEID_CACHE: 512        datalink: 1    datalinkoffset: 14
> debug:         o_minttl: 1          o_maxttl: 30        o_timeout: 3
> debug:          o_debug: 1         o_numeric: 0          o_pktlen: 0
> debug:       o_nqueries: 3        o_dontfrag: 0             o_tos: 0
> debug:      o_forceport: 0             o_syn: 1             o_ack: 0
> debug:            o_ecn: 0        o_nofilter: 0 o_nogetinterfaces: 0
> debug:      o_trackport: 0      datalinkname: ETHERNET     device: en0
> debug:       o_noselect: 1            o_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 the
> problem is and if there is a possible fix?
>
> Thanks,
> Lance
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users