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!