We use Polycom SoundPoint IP phones here at the CACE Technologies World Domination Secret Lair. While troubleshooting a different problem recently I noticed that the phones do something funny. During the boot process they obtain an IP address via DHCP, similar to most PCs. A DHCP option tells the phones to fetch their configuration and firmware from an FTP server. The funny part is that some of the FTP transfers were failing even though the phones booted up just fine:
At packet 175 the phone starts to download sip.ld, the SIP firmware image. The transfer starts at packet 177, but the phone cuts the transfer short at packet 181. The phone then behaves as if nothing is wrong. What’s going on here? Continue reading
Wireshark 1.2 added a nifty welcome screen which lets you start capturing, load a capture file, get help, and lots of other things. At the very top of the screen we brag about our popularity.
You can change that message to anything you like.
Wireshark power user Joan Snelders sent in a couple of shark pictures:
The second byte in the IPv4 header (aka “those bits you’ve probably never, ever looked at”) is used for Differentiated Services, or DiffServ. It’s split into two parts: the 6 most significant bits define the DSCP (differentiated services code point) and the two least significant bits are for ECN (explicit congestion notification). You can use DSCP to divide your traffic into different classes. For example, Asterisk might use the following DiffServ value, which corresponds EF (Expedited Forwarding):
DSCP ECN 10111000
If your networking equipment is sufficiently aware, this traffic will receive preferential treatment.
You can filter these values pretty easily using the ip.dsfield.dscp display filter — just right-click on the DSCP field in the packet like so:
What if you need to use DSCP in a capture filter? Continue reading
You’ve just fired up Wireshark on your Windows Server 2003 or 2008 system and you’re not seeing nearly the amount of traffic you should. What’s happening?
The Windows Server 2003 Scalable Networking Pack introduced a feature called TCP Chimney Offload. Chimney offloading lets the OS networking stack hand off established TCP connections to the NIC for processing. This frees up the CPU, bus, and memory for other things and lets you scale up the number of connections you can handle. Hooray! Once the OS hands a connection off to the NIC, that traffic completely bypasses WinPcap and therefore doesn’t show up in Wireshark. You see the TCP connection setup and non-TCP traffic but no TCP data. Oops.
How do you fix the problem? It depends on your environment.
You can disable chimney offloading as described in KB 91222 (Server 2003) or KB 951037 (Server 2008). If you have a gigabit NIC you can probably get away with leaving it disabled. If you have a 10 gig NIC this might affect your performance. You can also SPAN or tap in and capture on an external machine, assuming you’re sufficiently equipped.
The big tech news this morning was a recently-discovered SMB2 vulnerability in Windows Vista, 2008, and 7. Laura Chappell created a Wireshark display filter for identifying offending traffic:
((smb.cmd == 0x72) && (smb.flags.response == 0)) && !(smb.pid.high == 0)
See the full report on her site for more information.
The ongoing effort to switch the entire planet over to IPv6 has a chicken-and-egg problem: there is little incentive to deploy it if no one else is using it. This is expected to change as IPv4 addresses become more scarce, but for the time being uptake is dismal (in the U.S. at least).
One easy way to measure IPv6 adoption is to see how many of Alexa’s top sites have AAAA records. Hurricane Electric and Lars Eggert do a good job of this. Following in their footsteps my own version of this data is shown below:
It shows IPv6 adoption in Alexa’s top 1000 sites along with the number of sites using Akamai. The number of IPv6 sites is pretty small but the number of “testing” sites is encouraging. See the notes below for a detailed explanation and breakdown.