If you look closely and don’t blink you can see an AirPcap NX and Wireshark in a recent Today Show segment.
Reader Ro sent in the following pictures:
See the complete set at Flickr. The shark-with-a-tube-of-frosting frightens and confuses me.
An old-school method of debugging TCP-based services is to use telnet:
$ telnet www.wireshark.org 80 Trying 184.108.40.206... Connected to www.wireshark.org. Escape character is '^]'. HEAD / HTTP/1.0 Host: www.wireshark.org HTTP/1.1 200 OK Date: Fri, 16 Oct 2009 19:31:47 GMT Server: Apache Accept-Ranges: bytes Cache-Control: max-age=3600 Vary: Accept-Encoding X-Slogan: Be good. You never know who's running Wireshark nearby. Content-Length: 9628 Connection: close Content-Type: text/html Connection closed by foreign host.
It’s like giving your web server a big ol’ hug.
Most telnet clients do something very clever here. If you connect to a port other than 23 (or whatever getservbyname returns when you feed it “telnet”) they will disable telnet protocol negotiation and switch to line mode. This gives you a raw, line-based connection which is just the thing you need to interact with an HTTP, POP, IMAP, FTP, or NNTP server.
Adding SSL and IPv6 to the mix complicates things. I’m in the process of making Wireshark’s public-facing services available over IPv6. It would be helpful to be able to test connectivity to each service before adding its corresponding AAAA record. Standard telnet clients support 6, but not SSL. OpenSSL’s s_client command speaks SSL, but not over IPv6 (not on my systems, at least):
$ openssl s_client -connect '[2607:f0d0:2001:e:1::123]:443' getservbyname failure for f0d0:2001:e:1::123]:443
$ openssl s_client -connect ipv6.wireshark.org:443 gethostbyname failure connect:errno=110
Luckily Fyodor released Nmap 5 a while back. Nmap 5 includes ncat, which lets you connect over SSL+IPv6. It is now my new favorite service-poking utility.
$ ncat -6 --ssl -v 2607:f0d0:2001:e:1::123 443 Ncat version 5.00 ( http://nmap.org/ncat ) SSL connection to 2607:f0d0:2001:e:1::123:443. bugs.wireshark.org SHA-1 fingerprint: F6BA 2EE9 DEEF 74D3 B4B0 86D7 F5DB 6237 FF7F 896A HEAD /bugzilla/ HTTP/1.0 Host: bugs.wireshark.org HTTP/1.1 200 OK Date: Fri, 16 Oct 2009 20:26:23 GMT Server: Apache Vary: Accept-Encoding Connection: close Content-Type: text/html; charset=UTF-8
On many Linux distributions you can also use telnet-ssl:
telnet-ssl -z ssl 2607:f0d0:2001:e:1::123 443
Q: What does IPv4 exhaustion mean? Can’t you give IPv4 some Red Bull?
A: As everyone knows, the Internet was constructed by Theodore Roosevelt in 1895 using an old-growth forest and a thousand buffalo hides. He created a giant “pool” to hold all of the Internet’s numbers. While quite large for its time, the pool is much too small to handle the demands of today’s Internet.
Q: When will the pool run out?
A: In about eight and a half minutes.
Q: What will happen then?
A: The entire Internet will grind to a halt. It will shudder comically as it does so.
Q: But how will I get to Twitter? I gotta have my tweets.
A: In recognition of its role as the most important web site ever, the final IP address will be reserved for Twitter. In order to get there you will have to defeat an opponent in a cage match. You will get to choose between a crowd shouting “Two packets enter! One packet leaves!” or the Star Trek fight theme.
Q: Can’t I have something cool like Eye of the Tiger or that one Van Halen song that sounds like a motivational poster?
A: No. Not nerdy enough.
Q: I don’t want to fight a nerd in a cage. Is there another way to get my tweets?
A: No. Gotta battle a nerd.
Q: Well, what?
A: You could use IPv6.
Q: What’s IPv6?
A: It’s a newer, better Internet created by Matthew Broderick’s character in War Games in 1983. Its number pool is huge. The addresses should last for dozens of months at the very least.
Q: How do I use IPv6?
A: You have to have a modern computer. You also have to have an ISP that supports IPv6 or create a tunnel.
Q: OK. Tunnel’s all ready to go. Can I have my tweets now?
Q: Why not?
A: Twitter doesn’t use IPv6.
A couple of questions have come up on the wireshark-users mailing list recently about using capture filters for MPLS and VLANs. Each user was having the same problem yet these are different network technologies — what do they have to do with each other?
The answer is offsets.
Let’s take an up-close and personal look at the capture filter “ip src host 10.16.32.48”. We can do this by running tcpdump -d, which takes a filter, compiles it, and dumps out the result. The dump of our filter looks like this:
(000) ldh  (001) jeq #0x800 jt 2 jf 5 (002) ld  (003) jeq #0xa102030 jt 4 jf 5 (004) ret #96 (005) ret #0
If this makes no sense don’t worry. You just need to know that the first two lines look for the IP ethertype (0x800) starting at byte 12 and the next two lines look for the IP address 10.16.32.48 (0xa102030) starting at byte 26. This is the minimum amount of checking required for that capture filter if you’re running IP over Ethernet.
What happens if you’re using 802.1q? Continue reading
I made a video that shows you how to create a Windows shortcut that starts capturing immediately.
In a previous post I proposed the terms “indoor plumbing” for native IPv6 access and “outdoor plumbing” for tunneled IPv6. I think terminology like this is important. It’s short, clear, and implies an easy-to-visualize hierarchy where anything less than native routing involves uncomfortable exposure to the elements and woodland creatures.
Which leads us to those poor souls with IPv4-only networks.
“Y-you mean to say that you don’t have any modern plumbing at all? (snork) BWAHAHAHAHAHA!”
We could use something similar for unsecured wireless connections.