Free Wireshark Training Course Online

Take a free Wireshark Jumpstart training class online at

Wednesday, December 1, 2010

Filtering OUT Traffic by IP Address - Aaargh!

Another interesting question was posed at this week - it brings up a topic that I cover in the Wireshark 201: Filtering course (check out the schedule to catch the next free seminar on this topic).

The Question from ActualRandy
I want to see results where neither the destination, nor the source are the specified address; here is my filter. ip.src != && ip.dst != To my surprise, it returns some results with the that IP, such as this one: 157 238.065591 ICMP Destination unreachable (Port unreachable) The destination on this result is clearly one the filter should have blocked. What's up?

The Quick Answer
Avoid the use of != when filtering OUT IP address traffic. Instead use this filter:

!ip.addr ==

The Long Answer
Sake Blok spent a bit more time explaining what was going on here. First of all - let's talk about the problem with a filter beginning with ip.src !==.

As you can see from the image above, Wireshark turned the display filter area yellow to indicate something is wrong. If you hover over the field a tooltip explains that the filter may not work as desired.

Here's the first issue with this type of filter. An IP header has two IP fields - the source IP address field and the destination IP address field. This filter looks in IP source address field first. If the field doesn't contain -yippie! The filter matches and will be displayed. If the IP destination address field contains the packet will be displayed as well. It's frustrating.

Here's a version of the chart contained in Chapter 9 of the Wireshark Network Analysis book:

Here's the second issue that ActualRandy hit - his filter displayed an ICMP packet. Sake explained this quite eloquently at Numerous ICMP packets are what I call "two-headed packets" - they contain two IP headers - the true IP header and another IP header in the ICMP portion of the packet.

Using the simple !ip.addr== addresses both issues and

works like a charm.



Wednesday, November 17, 2010

Window Updates Not From Microsoft

The topic of Window Update packets surfaced at recently.

'Is it normal to see tcp window update packet (tcp.analysis.flags as a filter) for EVERY get/post request from a client workstation on the same LAN?'

The answer is... maybe. First let's talk about the infamous Window Update designation in Wireshark.

As TCP data packets arrive, their data is placed in the TCP receive buffer space until an application pulls that data out. If the data is sluggish at pulling the data out, the TCP receive buffer size begins to decrease. This is seen in every ACK packet sent by the host that is receiving data.

Wireshark doesn't alert you to the shrinking TCP window size or any window size problems until a host gets down to a window size of zero. Then Wireshark screams that there is a Window Zero condition.

After an application picks up data from the TCP receive buffer there is more space available and the sender increases their window size field value. THIS is what triggers Wireshark to mark the packet as a Window Update packet. It's a good thing.

The Wireshark Expert Infos window Chats tab is where the Window Update notices are displayed. They've moved from the more alarming Warnings or even Notes section to this boring location.

How can you quickly find if you have Window Update packets in your trace file? Apply a display filter for expert.message=="Window update" (watch the capitalization here). It's a simple and elegant color filter.

If you have the Wireshark Network Analysis book, check out Chapter 13, Wireshark's Expert System, for a definition of all the TCP expert notifications.

Now waht about seeing a TCP Window Update packet for EVERY GET/POST request from a client workstation on the same LAN? Well - it simply means that the HTTP application is pulling the data out of at the time a GET/POST is issued. Is that a problem? Nope. Is it normal? Nope - but hey - it's not a Window Zero issue and there's still buffer space available!



Thursday, October 28, 2010

Extract Fields with Tshark

An interesting question appeared at this week – “How can I run Wireshark from the command line to open a file, and output a file containing only the UDP length of every DNS packet?”

It’s an interesting question because folks often overlook (a) capturing traffic with Tshark and (b) using the -T parameter to pull field information.

The answer was provided by skypemesm:

tshark -R 'dns' -r abc.pcap -T fields -e udp.length

-R “dns” - applies a DNS display filter to the trace file

-r abc.pcap - opens the abc.pcap file using Tshark

-T fields - indicates we are pulling a field contents (default format: text)

-e udp.length - tells Tshark to pull the value of the udp.length field

The results of this type of operation print on the screen.

What if you want to pull this information from a live capture?

Ok - you have to watch out here since Bug 2234 restricts us from using a display filter during a live capture in Tshark. Sigh. We'll use a capture filter instead.

tshark -T fields -e udp.length -f "port 53" > udplength.txt

In this case we are still pulling out the UDP length field values, but we've defined a capture filter for traffic to/from port 53 and piped the results to a text file.

What else can you do? Well - you can use the -a parameter to define an autostop condition or the -c parameter to define the numbe of packets to capture.

All Access Pass Members: The Tshark Command-Line Capture course is released on the new portal. I just added a section on the use of -T/-e parameters after writing this blog. You should have received an email with your login instructions. If you didn't - send an email to

Not an All Access Pass member? Jeepers - the price was just lowered so now is the time to sign up for one-year of online training at

Tuesday, October 12, 2010

Kindle Version Released!

Kindle! Kindle! Kindle!

I've received lots of emails/queries lately asking if the Wireshark Study Guide and Exam Prep Guide will be available in Kindle formats.

Well, the answer is no and yes and maybe.

Yes - the Wireshark Certification Official Exam Prep Guide is now available on the Kindle (click to view Amazon page) - don't forget to download the Answer Sheets (PDF) over at as well. We had to get this book into eBook format as the enclosed CD was really limiting international distribution capabilities. All the practice exam questions on the CD are in the Kindle version of the book so you're not losing anything except the quiz engine to practice with.

No - the Study Guide (800-pager) is not available in Kindle format... yet. After reviewing a slew of technical books in Kindle format it has become abundantly clear that some books just look like garbage on the Kindle. The formatting is limited enough to make some images unreadable and tables a complete nightmare. Ok, ok... some limitations are mostly evident on the itty bitty Kindle (can we call it a Kindlette?). We purchased the big Kindle for the office to play around a bit more with the formatting and I ordered an iPad (just for research purposes, of course) - so this leads me to...

Maybe - If we can survive the Kindle conversion nightmare that we've been living in for the past two weeks and tackle the hundreds of pages of reformatting required, then perhaps the Study Guide will make it to an eBook format. A simple look at the Mastering Windows Server 2008 Kindle edition by Mark Minasi really turned me off the idea of putting the Study Guide on the Kindle. It should be sold with a magnifying glass! Even if you enlarge the font, the graphic image is unreadable - granted, this was viewed on my Kindlette.

Thanks to all of you who have offered ideas and assistance on getting the Exam Prep Guide through Amazon's formatting and the MobiCreator product. If you have additional ideas or feedback, send them into us at

Remember to check out the Wireshark Certified Network Analyst program at!



Tuesday, October 5, 2010


Unless you've been living under a rock (or playing the new Halo non-stop), you likely have heard of the FBI nabbing 100+ in a global cybercrime ring.

You'll notice mention of Zeus. Zeus is financial malware - in essence, it listens to your online banking sessions and sends them to scumbag server (SS). Now if you do a little research, you'll find that Zeus is currently listed as the #1 botnet by some folks (
Trusteer). Many virus detection tools miss Zeus altogether. (I'm not surprised by that at all - I have a kitchen strainer that does a better job than some of the VDS options out there.).

You could watch the conversation information and do some GeoIP mapping in Wireshark, but that might not be the best option (Gasp! Did I really say that? Yes.) Check out BotHunter (from my old employer, SRI International - yup - I was a waitress in the Executive Dining Room at the time when my peers were taking Latin and World History in their senior year of high school - another story for
another time).

BotHunter basically monitors conversations with an awareness of your trusted network (you define that during the setup) while using Snort's event generation engine to report suspect behavior. It's an interesting tool to play with - in addition, check out to view the BotHunter Internet Monitor page. BotHunter automatically grabs the latest C&C server list, malware DNS list, Russian Business Network address space and malicious backdoor/control ports from the SRI repository. The BotHunter repository service enables your "fielded BotHunter" to report infection profiles anonymously.

It's an interesting and FREE product to help you battle bot-infected hosts. If you haven't had a chance to analyze the traffic to/from a bot-infected host - check out the sec-sickclient.pcap file over in the trace files available at

Interesting Links:

Remember to check out the Wireshark Certified Network Analyst program



p.s. Thanks to everyone who suggested "back fixes" - it's healing nicely so far.

Wednesday, September 29, 2010

Blogging through Muscle "Sapams"

After 5 days of working up every excuse possible to avoid the dreaded doctor, I finally caved in when I dropped an AirPcap adapter and couldn't pick it up - yup - I'd ripped up my back somehow. The pain was incredible - just imagine - no monitor mode capability, no 802.11 headers, no multi-channel aggregation... it was a nightmare.

My doc prescribed numerous meds including one to take "as needed for muscle sapam." After receiving the obligatory lecture on "don't drive or operate heavy equipment with these medicines" (does a Cisco Nexus box count?), I whimpered home and told my family I would be "a little loopy" this weekend. If I hadn't already taken some of these medications, I would have immediately raced my two teens to the doctor for treatment for eye-rolling - it's a strange and erratic affliction that plagues so many teens.

I figured the perfect time to start working on this week's blog would be while cozying up on the couch waiting for the pain to subside with these new meds. This morning, however, I reviewed the numerous medically-induced blogs I whipped out while semi-comotose this past weekend.

I realize one thing now - DON'T MEDICATE AND BLOG.

Here are the titles of a few of the blogs I'd spewed out while numb.

* Should Pot be Legalized in Farmville? Since I'm from California and the issue of legalizing pot is almost recommended Kindergarten fare, I wondered about adding pot farms in Farmville. What would the reaction be? If met with heavy opposition perhaps Hempville would be more open
to the issue.

* Put Audio Triggers into Wireshark - I did skulk around a bit on, but had such a tough time typing Wiershark and TPCIP... almost hit "Submit" on an idea to add audio to the Expert Infos Composite function. Imagine importing the "Star Trek Audio Set" and hearing "Damn it, Jim... I'm just a doctor" each time a packet was lost or "Live long and prosper" for each retransmission. There's a loose reference to my old "Amazon Rain Forest" exercise I used with a NetScanTools Pro class...

* Intel - Do the Right Thing - Add an "A" to McAfee. This blog was rather short - simply suggesting that Intel's first move after acquiring McAfee should be to add that friggin' "a" to make it MacAfee - we all pronounce it that way already - c'mon - think of your customers here. There was a bit of a side-ramble regarding their Vegas conference in October featuring Bill
Clinton and some crazy off-beat reference to strip clubs too.

Well... perhaps you can tell I'm not off the meds yet - my mind is wandering ... and I hope it comes back sometime.

So I apologize now if you've asked me a technical question, reached out for advice or pinged me with a thought... I've been busy controlling my "muscle sapams".

Remember to check out the Wireshark Certified Network Analyst program at!



Wednesday, September 22, 2010 is Here!

It's not a forum... it's a Q&A site!

Last week Gerald announced on his blog. The site is based on OSQA (an open source Q&A solution).

I've been playing around on and it's pretty interesting to read the variety of questions that have been posted. Just what I need - something else to keep me awake at night! Sigh.

Go Ahead - Ask a Question
You can read the Q&A FAQ ("sweet baby corn cob?"), but here's the basic flow for using

1. Sign up for a free account at
2. Click "ask a question." Be as clear and complete with your question. If someone doesn't understand or wants more facts, they can comment on your question.
3. You can add details by commenting on your own question as well.
4. When your question gets answered you will receive an email notification (this is a setting you can change in Users > User Tools > Autosubscribe me to).
5. Now here's the important part -
a. If the answer solved the issue, mark it "answered."
b. If someone asks for more information, please comment to provide it.

Marking questions answered ensures that only truly unanswered questions show up when you click the Unanswered tab.

Do We Need Those Stinkin' Badges?
Click on the Badges tab to see the various badges you can earn (and how many times they have been awarded since the launch of by being an active, contributing member.

Pick Up Some Great Tips
By reading through some of the questions/answers at, you can learn:

* How to create an offset filter for Ethernet packets
* How to display all TCP connections with SYN packets
* The cause of SMB STATUS_ACCESS_DENIED packets
* How checksum errors can become a red herring in troubleshooting

I remember the old CompuServe NetWire days - it's fun to get active online again.

See you there!

Remember to check out the Wireshark Certified Network Analyst program at!



Wednesday, September 15, 2010

Troubleshooting with Coloring Rules

Wireshark contains an Expert system (click that colored button in the lower left corner on the status bar) which highlights packets of concern. There are so many network issues that are not detected with the Expert system, however. Consider creating a custom profile that contains a set of "butt ugly" coloring rules to call your attention to highlight potential performance issues.

Some of my favorite troubleshooting coloring rules look for protocol anomalies, error responses and high delta times. Other coloring rules focus on packets that may hint at (or scream about) security issues.

Here's a list of some of the coloring rules I will cover in the October 19th webinar:

* High delta times in displayed packets: When you filter on a conversation, look for sudden increases in delta times, but watch out for moments when user intervention is required to send the next packets - users are slow.

* 4 NOPs in the TCP Options Area: I've covered this over at the Wireshark Tips page - you just never want to see this one.

* HTTP Error Codes: Any HTTP response code higher than 299 indicates either a client error or server error.

* Small TCP Window Size Values: Even if the Window Size field isn't at 0, a low value can totally stop a data transfer process. Wireshark's Expert won't catch packets with a Window size of 50 - it will just catch a Window Size of 0.

In the webinar we will also talk about using "butt uglies" - colors that you detest - to call attention to the performance problems indicated in a trace file.

It will be a full webinar (with a maximum of 1,000 seats), so register early and arrive early to the session. The recorded version will only be available to the All Access Pass members.

Remember to check out the Wireshark Certified Network Analyst program at!



Tuesday, September 7, 2010

Analyzing HUGE Packets - TSO/LRO

Recently I received a trace file from a customer having performance problems. One of the issues in the trace file was a series of packets with large length values such as 32,885 or 35,094 or 61,557.

I've been seeing this characteristic more and more often when analyzing trace files.

This is not a situation of jumbo frames.

This is a situation called TCP Segmentation Offload (or TSO)/Large Receive Offload (LRO).

TSO/LRO are hardware functions. A host with TSO-enabled hardware sends TCP data to the NIC without segmenting the data in software. The NIC will perform TCP segmentation. NICs supporting LRO receive packets and reassemble them before passing the data on to the local software.

When Wireshark is loaded and capturing on a system that performs TSO/LRO, Wireshark may show you these really large frames - it's not lying - that is the size of the frame before segmentation has occurred (in the case of outbound packets handled with TSO) or after reassembly has occurred (in the case of inbound packets handled with LRO).

If you want to see the packets as they actually look when traversing the network - capture them at a location along the path using a FDX tap or port spanning/monitoring. The frames should then be the standard size.

Remember to check out the Wireshark Certified Network Analyst program at!



Thursday, September 2, 2010

Hiding Columns in the New Wireshark 1.4.0!

Wireshark version 1.4.0 download -
Wireshark Certified Network Analyst -
Wireshark Network Analysis Study Guide -
Wireshark Certification Exam Prep Guide -

Register for the free Wireshark 201 Filtering Webinar on September 8, 10am-11am PDT -

This week we had over 800 people register for the free Wireshark 101 Jumpstart
online course. You can download the handouts and review the topics covered.

During the webinar I focused on some of the cool new features of Wireshark
version 1.4.0. One of my favorite new features - Apply As Column - has even
gotten better than it was in the release candidate versions!

At Sharfest 2010, I was showing the new Apply As feature to the audience. Gerald
Combs, creator of Wireshark, was in that audience.

Simply right click on a field in a packet and choose Apply As to add that field as a
column in the Packet List pane. My favorite fields to add are:

* TCP Window Size field
* TCP Sequence Number field
* TCP Acknowledgment Number field
* IP Time to Live field
* 802.11 Channel/Frequency field (from a RadioTap or PPI header)

During that presentation I mentioned how fabulous it would be if I could
temporarily hide one of the new columns then quickly enable it again later.

Try it Yourself

Step 1
Download and extract all the book supplements (available online at

Step 2
In Wireshark version 1.4.0, open the trace file called http-download-bad.pcap. This trace file contains the traffic of someone connecting to a web server and downloading a file. The performance stinks.

Step 3
Expand the TCP header in packet #1 and right-click on the Window Size field (near the
end of the TCP header). Select Apply As Column. Your new Window Size column
appears in the Packet List pane.

Step 4
Right click on the new Window Size column and select Rename Column Title... - change
the name to WinSize.

Step 5
Now click the new WinSize column twice to see the Window Size field values lowest to highest - do you see the "Window Zero" condition in the trace file? What is the IP address of the host that states it has no receive buffer space (indicated by a Window Size of 0)? Yup - that would be the problem with the file download process!

Step 6
Let's say you don't always want to see that column though. Simply right click on the WinSize column heading and select Hide Column. When you want to see it again, just right click on any column heading and select Displayed Columns. Sweet!

Thanks Gerald and the Wireshark development team! This is a great addition!


Thursday, August 19, 2010

Official Exam Prep Guide Hits Amazon!

Visit to see sample pages.
Visit the
Amazon Marketplace page to purchase.

It's been a busy time teaching webinars covering the Wireshark Certified Network
Analyst Exam and then the Exam Prep Guide being released (earlier than
expected) on Amazon.

Watch the recorded Wireshark Certified Network Analyst video at

The new Exam Prep Guide is designed to help you evaluate your readiness to
take the Wireshark Certified Network Analyst (WCNA) Exam.

Thanks to all of our reviewers and good luck to all of you who have registered to
take the Exam at!

Laura Chappell
More information and to download the Exam Information Pack, visit

Wednesday, August 11, 2010

Wireshark Certification Exam is Released!

Download the Exam Information Pack
Download the Step-by-Step Registration Information Pack.

Register - Free webinar: Become a Wireshark Certified Network Analyst

I am thrilled to announce that the Wireshark Certified Network Analyst Exam is
NOW AVAILABLE ! The Exam is available globally in a proctored format through
Kryterion. Currently the Exam is only available in English.

The Wireshark Certification Exam was designed to confirm
individual competencies in using Wireshark to locate the
cause of network problems (poor performance or security-
related) and confirm your knowledge of TCP/IP network
communications in general.

The Exam is based on the thirty-three areas of study defined in the Exam Focus
and Content section of this document. The four primary areas covered in this
Exam are:

  • Wireshark Functionality
  • TCP/IP Network Communications
  • Network Troubleshooting
  • Network Security

To earn the Wireshark Certified Network Analyst status, you must pass a single
exam—the WCNA-100x Exam (version 100.1 is the current version).

Register for the Exam
The Wireshark Certified Network Analyst Exam is available at hundreds of testing
centers around the world. You can take your Exam at a KRYTERION High-stake
Online Secure Testing (HOST) location near you. To locate a local testing center,

The Wireshark Certified Network Analyst Exam is a closed-book Exam consisting
of 100 questions. The Exam time limit is 2 hours (120 minutes). Exam questions
are in true/false or multiple choice format (there is only one correct answer for
each multiple choice question). Many of the questions include a Wireshark
screen image.

Exam Pricing
The Wireshark Certified Network Analyst Exam cost is USD 299. The Wireshark
Certified Network Analyst Exam Practice Exam (online) cost is USD 29.

Pass/Fail Grading
The Wireshark Certified Network Analyst Exam is graded on a pass/fail basis.
Passing scores are set by using statistical analysis. At the completion of the
Exam, Candidates receive a score report along with a score breakout by Exam

How to Register for Your Exam
Register for the proctored Wireshark Certified Network Analyst Exam online at

Step-by-step Exam Registration instructions and complete Exam Preparation
recommendations are available at

The Official Exam Prep Guide will be on Amazon around August 23rd - learn more

Thanks to all of you who have been so patient as we rewrote, redesigned and
redeveloped the Exam. We are excited to see Wireshark become more popular
each month and hope the Wireshark Certified Network Analyst designation
becomes a de facto certification for all IT professionals.

Laura Chappell
More information and to download the Exam Information Pack, visit

Wednesday, July 21, 2010

Wireshark Exam Prep Guide in Final Editing!

Update: The book has gone to the printers. We expect it to be available on
Amazon around August 23rd. For more information, visit

Yes - this blog has been quiet for a bit - I've been putting in an unreal amount of
time prepping the Wireshark Certified Network Analyst Exam and the new
Wireshark Certified Network Analyst Official Exam Prep Guide (shown above).

After writing the Wireshark Network Analysis: Official Wireshark Certified Network
Analyst Study Guide, we had talked about building a prep guide to provide a feel
for the questions on the Exam.

The result is a 202-page Exam Prep Guide that covers over 300 questions in the
book and over 300 questions in both timed and untimed exam format on the
accompanying CD.

The Exam is about ready to release - both the Exam and Exam Prep Guide
should be announced on the same day (get ready). Measure and validate your
analysis skills using the Exam Prep Guide and taking the Wireshark Certified
Network Analyst Exam!

More information on the Exam release and requirements will be coming up over

For more information on the Wireshark Certified Network
Analyst Official Exam Prep Guide, visit

Are you ready? Check out the Exam Prep questions below:

Note: If doesn't have the Wireshark Network Analysis book in stock,
check out our Amazon Marketplace page.

The MAC name resolution process resolves the first 3 bytes of the
MAC address to the OUI value contained in Wireshark’s manuf file.

__ True
__ False

The first two packets of a single TCP handshake process can be
used to determine the long term average round trip latency time
between hosts.

__ True
__ False

The display filter tcp.analysis.flags shows all packets that
have the TCP Reset bit set to 1.

__ True
__ False

ICMP Destination Unreachable messages sent in response to an
FTP connection attempt indicate the FTP port is likely firewalled.

__ True
__ False

Which TCP setting must be enabled in order to use the
tcp.analysis.flags display filter?

__ A. Try Heuristic Subdissectors First
__ B. Analyze TCP Sequence Numbers
__ C. Allow Subdissector to Reassemble TCP Streams
__ D. Window Scaling and Relative Sequence Numbers

Which Calc value is best suited to graphing the IO rate using
__ A. SUM(*)
__ B. MIN(*)
__ C. LOAD(*)
__ D. MAX(*)

Enjoy life... one bit at a time.


Answers: True (that's the purpose of the manuf file), False (you need more than
just a single SYN, SYN/ACK to figure out the long-term average RTT), False (this
filter shows packets marked as retransmissions, window zero, checksum errors,
etc. - not TCP reset packets), True (if the port were open, we'd see a SYN/ACK, if it
were closed we'd see a RST - an ICMP response indicates a likely firewall
fantastic Wireshark display filter), A (you want to count up all the TCP data - not
just know the minimum or maximum values for the time period - the LOAD(*) is
used for time values).

Wednesday, June 2, 2010

Google's Secure Search... Not So Secure?

Watch two new videos examining Google searches using HTTP and HTTPS - now
available at Note that the trace files used in the
video are in the download section of that site.

As a follow-up to last week's "Peeking at Google's Secure Search Beta Traffic"
blog, I did a bit more poking around in the secure search traffic after getting this
question via Twitter.

Here are the steps seen in the trace file called google-https-
cachedlink_plus_sitelink.pcap over at the
download page.

1. Access
2. Search for "hacking cisco ip phones"
3. Click on the cached link for one result (a blog page)
4. Click on one of the links on that blog page

In analyzing the traffic, I noticed the following:

  • It takes 3 TLS/SSL connections just to load the Google secure search
  • When I clicked on the cached link I connected to Google's web cache site
    ( CNAME
  • My original search terms were contained in clear text in the GET query to
    Google's cache server.
  • My original search terms were also contained in the packets generated to
    the Symantec secure browsing server.
  • When I clicked one of the links on the cached page, I connected to the
    target website and provided my referral information (including my search

This is NOT secure searching if you click a cached link in
Google's "secure" search beta.

Heck - apply the display filter http.request.method == "GET" && frame
contains "hacking"
and see how many times my search term showed up in
the traffic.

So... what's the point of Google's secure search? Google states the following:

"With Google search over SSL, you can have an end-to-end encrypted search
solution between your computer and Google. This secured channel helps protect
your search terms and your search results pages from being intercepted by a
third party. This provides you with a more secure and private search experience."

Wow - that's as misleading as my son saying his homework is "mostly finished."
Am I not a third-party? Maybe a bit of clarity is warranted here, Googlites!

Google - I suggest you kill the cached link feature on your secure search page.
Otherwise you aren't offering any secrecy to unsuspecting folks who might click
on those links.

Enjoy life... one bit at a time!


Tuesday, May 25, 2010

Peeking at Google's Secure Search Beta Traffic

Watch the new video comparing Google searches using HTTP and HTTPS -
now available at Note that the two trace files
used in the video are in the download section of that site.

If you haven't been following Google lately, you might have missed their "secure
search" announcement. It's HTTPS-based, but don't think you're totally secure
from prying eyes when you web browse (also see Chapter 23 of the Wireshark
Network Analysis book for details on HTTPS analysis).

Secure Search Doesn't Hide Target Browsing
Just because your Google search process is running with HTTPS and is
encrypted, this doesn't mean that when you click that link your browsing
session that follows is encrypted. Some chatter last week indicated that
Google's "secure search" somehow protected you more than it really does.
Sure, your browsing session is encrypted, but the minute you click on an HTTP
link, I can read the DNS query issued (if any) and the HTTP session to the target

Yes, Removing the Referrer Data will Screw up Analytics
One "side effect" of Google's secure search option is that when you click on the
target link from the Google's secure search page, the referrer information is not
sent to the target - they can't tell from whence you came. Oh, boy - this really is
going to mess up the analytics.

Analytics-hounds are going to freak out on this one!

Get an All Access Pass at
here and check out the video detailing the two Google
search processes.

Enjoy life... one bit at a time!


Sunday, May 2, 2010

Talking Tech with RunAs Radio

Last week I had the chance to talk with Richard Campbell and Greg Hughes of
RunAs Radio. You can listen

Don't know about RunAs Radio?
RunAs Radio started back in 2007 and offers weekly radio shows primarily for a
Microsoft-centric audience. My episode #160! I got interested in RunAs Radio
when I learned that Andy Malone had been interviewed recently on RunAs Radio
(I'm on a Cloud Computing panel with Andy at TechEd next month).

Grey Hair, Fire Extinguishers, Needles in a Haystack, Vegas and More
Although the session started with a reference to my ever-increasing grey hairs
and the need for a fire extinguisher in the kitchen, Richard pushed towards the
issues related to wireless analysis. "It's been abused so much."

We chatted about "jacked up access points" and saturation of the WLAN
environment in a Vegas casino.

Cool Topics/Presenters
Visit the RunAs Radio archives to check out the other 159 programs. Here are
some that I really enjoyed listening to.

  • Doug Toombs - free tools - although he missed Wireshark for some
    unknown reason - at least he got Nmap in there. Listen here.
  • Nick Simons - he's the guy that killed Clippy - Nick talks about some free
    tools for IT pros. I know you all love free tools! Listen here.
  • Steve Riley - now over at Amazon's Cloud Computing division - it's
    always interesting to listen to Steve. Listen here.

Go check out the podcasts at RunAs Radio and enjoy life... one bit at a time!


The "Death of" Series

I've been having a great time working on some really lousy networks! You too?! What a coincidence!

As conference season approaches (June), I've just finished writing up my draft presentations. I'll be starting a series of presentations inspired by the Dexter series on Showtime. As we've run through the entire season just recently, the
images of death were first and foremost on my mind when I started sketching out these presentations.

DEATH OF A NETWORK: Identify the Hidden Cause of Lousy Network Performance
I'm going to have fun with this one! This is my "finger pointing" session and I have some major pointing to do! I'm not going to sugar coat some of the more recent causes of pathetic performance and I'll be showing the trace files used
to nail down who's really killing the network.

DEATH OF SECURITY: Breached Hosts/Stolen Data/IP Espionage
A long conversation with a buddy at a 3-letter agency gave me some ideas of what to share in this session. We'll talk some recent case stuff before looking at suspicious traffic and have a heart-to-heart about the methods in which your
network security may fail you.

It's not all death and doom though. I added some "ugly network" humor in there. In fact I'm going to have difficulty keeping a straight face as I walk through the traffic of a certain hip phone that exudes attitude on the network. Hmmm.... who could that be?

I'll be recording these "Death of" presentations for our All Access Pass members, so get a membership if you want to
catch these new presentations without heading to a conference.

Of course, I won't be serving wine or beer, but you'll probably remember the information better that way!

Enjoy life... one bit at a time!


Wednesday, April 28, 2010

When Wireshark Gets Confused...

SIP/VoIP call setup is covered in Chapter 27 of
Wireshark Network Analysis.]

I was scrambling around in preparation for a VoIP training session recently
when I opened a new VoIP trace file that depicted a simple call set up routine
followed by the actual call.

Strangely, Wireshark had an issue identifying one side of the SIP connection -
as you can see in the graphic above. Wireshark dissected one-half of the
conversation as FF (Foundation Fieldbus) traffic.

What in the world is going on here?

Wireshark defines the protocol column value based on the highest layer of
decode that it can apply to the packet. In this case, Wireshark found something
in these packets to indicate the traffic was Foundation Fieldbus packets.

I compared the packets defined as "FF" to the packets correctly interpreted as

Aha! The port number fields tell the story. In the UDP header, packets that
contained the source port of 1089 are dissected as Foundation Fieldbus. Ok -
let's just skip past the fact that the sender in Frame 2 above is not responding
to the correct port number defined in Frame 1.

My focus was on getting Wireshark to dissect the packets marked Foundation
Fieldbus as SIP packets. I certainly don't want to alter the preferences of
Wireshark so that all packets containing source port 1089 are dissected as SIP
packets (as they likely are just ephemeral ports and not SIP at all).

The quick solution is to right click on the packets dissected as Foundation
Fieldbus and select Decode As. Selecting SIP as the desired dissection and
applying this to the trace file fixed the problem quickly. Wireshark now
dissected source port 1089 as SIP. Clicking the "Show Current" button in the
Decode As window displays all manually altered dissection configurations.

It's not often that I have to apply Wireshark's Decode As function - typically I hit
companies using non-standard port numbers for applications for various
understandable and just plain whacky reasons).

It's a great feature to know - just in case you hit a strange dissection.

Enjoy life...
in the Netherlands... one bit at a time!


Tuesday, April 20, 2010

Europe Welcomes Wireshark University

On May 31st, the first Wireshark University course opens in the Netherlands!
The Core 1 course registration is now open with our first European partner,
SCOS. For information, visit

You do not want to miss this event!

This course teaches you how to capture wired and wireless traffic and interpret
the most common TCP/IP communications including IP, ICMP, UDP, TCP,
DNS, ARP, DHCP, HTTP and email traffic.

Register online today at
For more information, email

In addition, SCOS is a European distributor of the new Wireshark Network
Analysis book ( There should be copies of the book
available at the training to help you prepare for the upcoming Wireshark
Certified Network Analyst Exam (due Q2/2010). For more information on the
Exam, visit
Wireshark University.

Betty DuBois, Lead Wireshark University Instructor, will be presenting this 5-day
event focusing on the key capabilities of Wireshark, the world's most popular
network analyzer, and TCP/IP communications analysis.

Special thanks to Matt Hamburg of SCOS for hosting this very special event.

Enjoy life...
in the Netherlands... one bit at a time!


Wednesday, April 14, 2010

Baseline Today!

In one of the early book reviews, Marcos Christodonte II states “I’m a firm
believer in baselining network traffic. In this section, Wireshark Network
Analysis details the importance of baselining and the types of traffic to focus on.
Like other sections, this section also provides screenshots, showing how to
analyze traffic and packet statistics.” [Read the full review

Every IT professional should take baselining seriously. It’s not difficult to do and
will save you time, money, frustration and possibly your job when all hell breaks
loose on the network.

Baselines define your network’s vital signs when it is healthy. Baselines are
used to define not only the basic traffic flows of an application or process – they
also help define the number of connections required by a process, the type of
connection, the port numbers, interdependencies with other hosts, typical round
trip times, average packet per second rates, average load time and more.

Chapter 28 includes my baseline checklists - listing the traffic you should be
capturing and what you should be looking for when characterizing "normal"

For example, if you want to create a baseline of your login/logout sequences,
consider the following questions:

  • What discovery process takes place during login?
  • What server does the client connect to?
  • What are the processes seen during login?
  • How many packets does a typical login require?
  • Are there any login dependencies?

When someone complains about a slow login process, compare the current
ugly login to the baseline you created.

  • Are there any large gaps in time?
  • Are there any Expert Info notifications?
  • Do you see the same number of conversations as in your baseline?
  • Do you see the same number of endpoints as in your baseline?
  • Do you see the same protocols as in your baseline?
  • Do you see the same number of packets as in your baseline?
  • Do you see the same dependencies as in your baseline?
  • Did the name resolutions process match your baseline?

You don't have to know everything about every packet and protocol in use. Use
the ugly trace and the baseline trace to identify large gaps in time, large
differences in packets, unusual error responses. All of this enables you to point
the finger at the problem.

Remember - in a finger-pointing world, the only finger
that counts is the network analyst's finger!

So… schedule some time to create your baselines now – before you need

Enjoy life... one bit at a time!


Tuesday, April 6, 2010

HELP! I've Been Tooned

If you went to BrainShare 2010 and watched the Monday or Thursday keynotes,
they were preceded by two short behind-the-scenes videos. In each video a
domineering packet geekess prepares systems for the show while "Fred"
(likely the user from hell) sweats it out through last-minute stress.

Yup - the geekess was my voice and a toon of me (although my boobs are
smaller as I told the project coordinator, Russ Dastrup, after seeing the initial
animation images).

Russ asked me to prepare a script of some of the geeky things that I might say
- if you're an old-timer, you might have caught the reference to Compsurf
(remember those good old days?). There was also a reference to Wireshark in

Chris Miller supplied the voice talent for Geeko and Fred - from what I heard at
the recording studio, Chris is a pretty famous voice talent (Geppetto in Shrek is
listed as one of his credits - cool!). Those voices were recorded before mine. I
meandered into Soundtek Studios here in Campbell, California for my voice-
overs. When I walked in I was spending more time looking at their recording
equipment (they are a Mac shop) than the instruments (although I did consider
playing a little tambourine).

It was ironic when they had network problems (an unplugged Ethernet cable)
before we started. The technician, Pat, was speaking another language most of
the time - "too hot" "too out there" "more eeeee". At one point he told me to be
"less orgasmic" when I was trying to add some energy to my voice (I'd been up
almost all night working book edits and I was in dire need of a triple espresso).

At the keynote a few people said "Hey! That's Laura!" and they were right. Ya just
never know where I'll show up.

Enjoy life... one bit at a time!


Sunday, March 28, 2010

Six Wireshark Network Analysis Video Supplements are Ready!

Coffee and a Quickie offers a quick glimpse at some of the topics discussed in the Wireshark Network Analysis book.Yesterday I added another video focusing on using pre-made profile elements. The videos are all over at

The book is now on Amazon - they are ramping up stock, so be patient!

Conference Season Heating Up
We're working on calendars this week as the conference abstract and presentation deadlines loom. So far, I am planning on being at the following conferences:

  • Microsoft TechEd
  • Sharkfest 2010
  • HP TechForum (preshow seminar)
  • HTCIA International

We are looking at running some Wireshark Bootcamps. These will be 3-day intense Wireshark hands-on courses focused on the objectives defined for the Wireshark Certified Network Analyst exam. The objectives are listed at the front of each chapter of the Wireshark Network Analysis book.

Don't Forget - there are lots of resources over at the website - don't forget to download the trace files and other supplements.

Enjoy life... one bit at a time.


Wednesday, March 3, 2010

Wireshark Network Analysis has Left the Building

What shall I do with myself this morning? Hmmm... I already cleaned off my desk of all remnants of the book writing/editing process. I drafted up the book website (that will be home to the trace files and book supplements).Instinctively I launch Wireshark - heading out to get the latest development release at Ooooh... we're now on version 1.3.4 SVN (subversion) 32095.

Wireshark was a moving target while I wrote the book and we're releasing the book with features you won't even see if you don't load the development version or wait until v1.4 comes out.

I've been examining each feature and working on descriptions and scenarios to depict the out-of-order packets (which are sometimes retransmissions), retransmissions vs. fast retransmissions, duplicate ACKs (and what triggers them)

  • HTTPS decryption methods including the long and error prone key entry in the preferences section and the best TCP preference settings to view and filter on the SSL/TLS handshake
  • step-by-step procedures for application analysis methods to determine if an application affected network browsing performance (I analyzed Aptimize Website Accelerator running on Microsoft's Sharepoint website) - graphing methods to illustrate the effect of this tuning product
  • building a table to show WLAN capture options - when do you want promiscuous mode enabled/disabled and what can you "see" without monitor mode capability
  • diagramming networks with NAT/PAT devices, firewalls, layer 2 switches, MPLS configurations and more - all in an effort to explain how these devices affect the traffic
  • maintaining my new feature checklist to ensure I covered the new Packet List pane, fabulous load times, ignore packets feature, Apply as Column feature, etc.
  • keeping a master list of all the hot capture, display and color filters I've built to catch and vividly show the traffic that really explains what's going on
  • inventorying all the book trace files that are referenced in the Practice What You've Learned section of each chapter - that was an undertaking!

It's been a lot of work - puff, puff - but strangely enticing. Each morning I had a list of features I would focus on that day. Each day I was able to marvel at Wireshark's capabilities. Each day I created charts and graphs of amazing network problems.

Oh... gotta go... that new development version of Wireshark is calling!


Wednesday, February 10, 2010

Organic Software Visualization puts Wireshark Development in a New Light

Check out Don't worry... I'll wait right here until you return...

This is by far one of the coolest videos I've seen in a long time. Created by Loris Degioanni (creator of WinPcap), this video visually represents the Wireshark development process from its inception using a tool called code_swarm.

The video shows an organic information visualization (a term coined by Ben Fry) which "eschews traditional data confinement in space and lets the elements play together in free form and unpredictable ways."

The result is stunning!

Visit for more information on code_swarm and to see the visualizations for the following projects:

Additional project videos can be found at

You can see when specific areas of a project are HOT. For example, in Wireshark's code_swarm there are moments when everyone is focused on the dissectors (shown in light blue) - the image radiates a halo of light blue as
dissector code is checked in (like stars flying in). At other times, feverish work was being done on the GTK (Graphical Toolkit) to make Wireshark more user friendly.

Release files are indicated in red. Sudden red bursts can be seen when version is released. A legend in the upper left corner helps the viewer understand what parts of the project are most active at any time. Names flash when that
developer checks in code. The histogram at the bottom of the screen indicates the size and time of commits to the project.

In June 2006 all hell breaks loose when Wireshark is born of Ethereal. The histogram goes wild with commits and you can see all the work being done to change the name to Wireshark - in the manuals, in the dissectors, in the plugins
- everywhere.

I showed the various code_swarm videos to my kids when they came home from school today. Their first reaction - "Whoa... that's cool!" Second reaction from my son - "Do you think they have something like that for WoW?" Sigh....

Their final reaction really hit me (after living on 3 hours sleep a night trying to finish the Wireshark Network Analysis book and try to catch the features and capabilities of this celestial moving target) - "It looks like the project is a black hole sucking in the life around it."

Good observation.


Tuesday, January 19, 2010

Haiti: High and Low Tech Rescue

It's heartbreaking to see the loss of life in Haiti right now, especially the children. One image from haunts me – a 1 month old child held in the arms of a rescuer (image #12 at

Cellular communications has had a tremendous role in this disaster – from victims text messaging for assistance to families finding each other. It underscores the importance of shoring up cellular networks in preparation for

Google updated their satellite imagery to show amazing before and after images of the devastation - Click on one of the images to zoom in as close as you can.

At, image #32 at displays SearchCam, a victim location device that offers tremendous ability in looking in confined spaces. You can watch a video about SearchCam technology at

The other impressive group in these disasters is always the canine units: Irish and Spanish rescuers, Germany’s International Search and Rescue (ISAR) group, Canadian Search and Disaster Dog Association, California's National
Disaster Search Dog Foundation (SDF), and many others.

These dogs react differently to survivors and victims – if a survivor is found, the dogs bark loudly; if a victim is found, they scratch at the rubble. For all of our high technology, they still amaze us. Nearly 70 hours after the quake, Hunter (a Border Collie from SDF) found two young girls trapped under 4 feet of concrete.

Our thanks to the many military, civilian and canine heroes helping the victims and families who have been devastated by this quake.

Please donate to your favorite relief charity today.


Wednesday, January 13, 2010

Google vs. China

Posted: 2010-01-13 09:19:54
Call for Case Studies at left!

In essence, Google discovered a security breach with the following
  • the attack was not just against Google - at least 20 other large
    companies worldwide have been targeted
  • the target appeared to be Gmail accounts of Chinese human rights
  • other Gmail accounts of human rights activists have been breached

Imagine if Google decides to pull because of the human rights
violations persistently perpetrated by the Chinese government! Whoa!

For a while now I've been saying... the only way to run a secure network in China
is to... not run a network in China.

The Chinese government has their paws over every bit of data at their whim. If
you are a Chinese dissident, they are listening. If you are a foreign company with
intellectual property (IP) to steal, they are listening.

I applaud Richard Bejtlich at for focusing on China
(read his October 22, 2009 blog and follow him religiously) and loved his
prediction of a cloud-based security incident. Did you read my "cloud concerns"
article at as well?

So -- is your company gong to jump to cloud computing? Are you going to open
up that China office and try to set up a 'secure connection to the US?' (best of
luck there - just wait for the knock on your door asking you to install a tap for
government snooping).

The Chinese government is totally out of control. It will be interesting to see the
details emerge. I am certain the CG will respond with some shrug and a sly grin.
They realize the value and economical nature of cyber-espionage and they don't
give a damn who they step on.

Ok... yeah - this hit a nerve.

Have you looked at your traffic today?

The image above shows the traffic to/from a host in our lab that was hacked.
Notice the interesting target? Have you set up GeoIP in Wireshark yet?

C'mon - check out the setup/use video over at
to-Track-IP-Address-Locations-in-Wireshark-video.aspx - use Firefox as your
default browser to save yourself some troublshooting time.

(GeoIP was the topic of the last Wireshark Weekly Tip - sign up at www. to get an email each week with a new tip.)

Ok... now to go throw out some "Made in China" junk around here!

Enjoy life one bit at a time!

p.s. Thanks to everyone who is submitting case studies for the book! I am
reviewing them, categorizing them, responding with questions (if I have some)
and moving right along in reading them - some really great ones! I'm also
interested in those 'newbie tips' so keep 'em coming in - see the link at left to
submit your case study!