This year at Sharkfest I offered a special capture file challenge I called “The Megalodon Challenge”. Other than the “normal” challenges you could find at The Reef it was not limited to the size of 100MB, and the solution cannot be reduced to a couple of words or numbers. After Sharkfest I was asked if I could put up the challenge so that people that haven’t been at the conference (or didn’t know about the challenge) could give it a shot. So here it is.
“Jasper, do you have a minute?”
I think that is the one sentence that I heard most at Sharkfest 2015, which is the annual Wireshark developer and user conference. Which makes it the most interesting place to be for anyone doing network analysis, for business or fun/hobby (yes, those exist). People asking me for a minute involved Wireshark core developers, other speakers, and of course Sharkfest attendees.
Sharkfest 2015 is coming up fast (22 days, 12 hours to go when typing this), and so I spend the morning hours of my Saturday for preparation of materials for my three talks. Since that also involves adding features and fixing bugs in TraceWrangler (which I also need for the large demo part of my FIRST presentation the week before Sharkfest) it is a slow process. So let’s waste a little additional time on a blog post 🙂
Tracewrangler was always supporting IPv6 from the start (even though without extension headers except fragmentation), but last weekend I realized that I could improve the sanitization feature due to something that is missing compared to IPv4: subnet masks. This may sound funny, but in fact the missing subnet masks help.
Last week Uwe, one of the instructors of the Wireshark class I created for FastLane, gave me a call in the evening. He was teaching a 5 day class in Hamburg at the time, and had had a student ask about a peculiar problem with frame/packet timestamps. I remembered that I had read something about this issue before, so I told him I’d investigate. And in the end, it looked like a good topic for a blog post, so here it is. It also means that I can point Uwe at this post instead of writing a lengthy email. Hm, wait… so now I write a blog post that is even longer?! Nevermind. Let’s go.
My previous post was about one of multiple false positives a network analyst needs to keep an eye out for to avoid writing down findings in a report that weren’t really there. So when I looked at my Sharkfest traces to see what other topic I could write this post about I realized that I have already “burned” two of the other false positives in earlier posts. Well, the good thing is you don’t have to wait and can read about them right away (if you haven’t already).
The TCP expert of Wireshark is doing a pretty good job at pinpointing problems, helping analysts to find the packets where things go wrong. Unfortunately, there are some things that can throw the expert off pretty badly, which can fool inexperienced analysts in believing that there are big problems on the network. I did a talk about some of those problems at Sharkfest 2013 called “Top 5 False Positives”, and this post will be about on of them: Duplicate packets.
Every now and then most analysts run into a troubleshooting situations where they need to capture the same packets at different locations in the network. Some reasons for such multi-point captures include
- having to determine if packets get delayed at some point in the network (this would be one of the few cases where “it IS the network”)
- checking if there is packet loss, checksum errors (which is basically leading to packet loss, too) or any unwanted packet modification “on the way”
- determining if all conversations look the same on both (or more) capture locations
If you spent enough time using Wireshark or any other network analysis tool, you’ll sooner or later be able to even read bare hex dumps of packets, at least partially (it’s a little bit like Neo seeing the Matrix). So maybe you run across a text dump of a packet like this one:
0000 00 0d b9 21 95 18 c8 60 00 16 7c cc 08 00 45 00 ...!...`..|...E. 0010 00 34 6b 8a 40 00 80 06 00 00 c0 a8 7c 64 51 d1 .4k.@.......|dQ. 0020 b3 45 c4 60 00 50 19 00 52 e7 00 00 00 00 80 02 .E.`.P..R....... 0030 20 00 42 4a 00 00 02 04 05 b4 01 03 03 02 01 01 .BJ............ 0040 04 02