Analysis on The Official Wireshark Blog

Detecting Heartbleed Traffic

Wed, 09 Apr 2014 23:02:49 +0000

The big news in the tech industry this week is The Heartbleed Bug, a vulnerability that affects a large portion of secure web sites on the Internet. I updated the Wireshark and WinPcap web sites on Monday (along with reissuing and revoking certificates) shortly after OS patches were released.

Our web sites are protected going forward, but what about the past? We have a Shark appliance in our environment but that leads to a challenge. We had about 350 GB of HTTPS on our network on Monday alone. This is just slightly too large to load into Wireshark.

Fortunately one of my coworkers (P.J. Malloy) came up with a BPF filter that matches Heartbleed traffic:

http://www.riverbed.com/blogs/Retroactively-detecting-a-prior-Heartbleed-exploitation-from-stored-packets-using-a-BPF-expression.html

Applying this filter directly on the Shark appliance gave me a much smaller number of packets which I could easily analyze in Wireshark. So far I haven’t found anything suspicious.

Troubleshooting the hidden dangers of TCP’s Nagle algorithm and delayed acknowledgement

Fri, 11 Jan 2013 23:58:10 +0000

As we all know, TCP/IP is a great protocol suite. However, there are times when it can become the bottleneck. This is especially true if you use TCP/IP for real time transactions where small data sizes are the norm (think financial institutions). In this session, I’ll show you why Nagle algorithm and delayed acknowledgement was developed. But more importantly, I’ll highlight the unintended consequences when the two features interact – badly – with each other. After watching this session, you will be able to spot the hidden dangers of using TCP/IP for real time transactions. Enjoy, and as always, I would really appreciate your feedback and suggestions. Here is the video:

http://www.youtube.com/watch?v=2CMueBcQNtk&feature=share&list=PL18B4C1339C54900A

And as always, any and all feedback and suggestion are welcome. Thank you and Enjoy!

Hansang Bae

Comments 🔗

Comment by credible58 on 2013-01-13 23:57:32 +0000 🔗

Great video, Hansang.

Comment by Hansang Bae on 2013-01-14 12:53:06 +0000 🔗

@credible58, thank you! If you have any ideas for future sessions, by all means, please let me know.

Comment by Jasper Bongertz on 2013-01-21 06:46:43 +0000 🔗

Nice presentation, Hansang, as usual. The only thing that I might have added to the slides would haven been an animation of what would be different without the push flags.

Comment by Hansang Bae on 2013-01-21 07:17:54 +0000 🔗

Ah, good point. I removed some popup hints, quizzes etc. because youtube doesn’t support it. That would have been a good one, especially since I talk about it on the PPT. BTW, I just spent an hour anonymizing an upcoming CIFS troubleshooting scenario. What a pain that was! 🙂

Comment by Andrew on 2013-01-23 12:52:27 +0000 🔗

Great presentation, you gave a very clear explanation of the rules on the message sequence chart that made understanding the actual packet trace easy. I also like that you made the packet trace available.

I’m left with one question though, why does packet #7 in the trace get to go immediately? This packet is only 226 bytes long so isn’t an MSS and there is unacknowledged data in flight (the bytes in #4, #5 and #6) so even though the Push bit is set in #7 my read of the Nagle rules on your slide #4 is that the only way #7 can be sent is if the Nagle override timeout expired? Yet the time between packet #7 and #6 is 16us which means the override timer cannot have expired. I’m presumably missing something though?

Comment by Hansang Bae on 2013-01-24 16:20:17 +0000 🔗

Andrew,
Give me a day or two. I’m on the road and will be back this weekend. I will reply when I’m back in the office. thanks

Comment by Hansang Bae on 2013-01-29 13:06:52 +0000 🔗

Andrew,
I’m glad you picked up on it. There are other small nuances in this trace that I didn’t get into . I didn’t delve into them just yet because this was more of an intro. 20/20 hindsight, I think it might have been better to tackle the bread and butter “nagle/delayed-ack” case first. But I’m very happy that you picked up on the fact that 10.10.10.10 probably has Nagle turned off. Another user Aaron also contacted me about packet #7! So I’m very happy that you guys are picking up on the small nuances of protocol analysis!

There are other oddities in the trace, and I may come back to it after a few more sessions.

Comment by Hai Wanxue on 2013-01-30 01:28:40 +0000 🔗

Great session.
I wrote something about TCP Nagle algorithm and Delayed ACK before in Chinese.
http://wenku.baidu.com/view/fbfda71aa300a6c30c229f99.html

Comment by Hansang Bae on 2013-01-30 08:00:45 +0000 🔗

Hai,
Thanks. Please feel free to download the presentation and pcap files and use it to your heart’s content! I see your presentation was much more thorough, was it for a class you were teaching? I can’t read it (if it was Korean, I could! 🙂 ) but I see enough TCP related acronyms to get the feel of it.

Thanks,

Hansang

Comment by Hai Wanxue on 2013-01-30 18:49:59 +0000 🔗

Hansang,
I am working at one company for technology consultant.
Writing it only as case because I often encountered them at work.
Thanks.

Comment by Anonymous Coward on 2013-02-05 17:33:39 +0000 🔗

These retransmissions are killing me!

Comment by Hansang Bae on 2013-02-05 21:23:25 +0000 🔗

That’s pretty funny, K! 🙂 Sorry folks, that’s a little insider joke!

Comment by jaspreet on 2013-02-19 23:18:53 +0000 🔗

Very very knowledgeable video. thanks for all the efforts taken to create this good stuff!

Comment by Hansang Bae on 2013-02-20 08:20:40 +0000 🔗

It’s my pleasure jaspreet! Glad you found it useful.

thnx

Hansang

Comment by krishnayeddula on 2013-03-06 19:34:11 +0000 🔗

Superb Video. It does nothing but enhances the Zeal to learn. That bus example was simple yet powerful.

Hansang,
People are thirsty here.Some more please.

Comment by Hansang Bae on 2013-03-09 18:33:37 +0000 🔗

@krishnayeddula, @Cyril, @Beulah, @Money..
Thank you. Another video will be coming out shortly. I’m glad that my passion for protocol analysis is coming through! 🙂

Antivirus Outbreak

Mon, 09 Aug 2010 18:00:49 +0000

Wednesday, August 4, 8:00 AM 🔗

We receive a phone call from someone complaining about “Wireshark Antivirus”. I take the call. The person on the other end isn’t able to provide many details other than that a program named “Wireshark Antivirus” is displaying some a shield and directing him to the cacetech.com web site.

This is new. We’ve been on the receiving end of a few false positives in the past but this is new. Some jackass is using our name do do harm.

This will not end well.

August 4, Morning 🔗

I start searching using Google and Bing, looking for other reports or any details. This is my job for the rest of the day.

So far our only exposure is through reports from other people. A forum post mentions “Wireshark Antivirus.exe”. I ask for screen shots so I can at least put an image online but don’t received any.

The calls continue, but are mercifully few. I add news items to www.wireshark.org and www.cacetech.com and send an email to wireshark-users and wireshark-dev.

This will not end well.

August 4, Afternoon 🔗

Two discussions pop up on Yahoo! Answers. This is a reputation-based Q&A site. Someone posts erroneous information but I can’t correct it. How do you get enough reputation to be helpful in an emergency?

At around 2:00 PM posts start showing up with recommendations for cleaning up the trojan.

Thursday, August 5 🔗

We get our first angry letter! Threats and foul language and everything!

More calls come in. Most AV software has been updated to catch the code if it hadn’t already done so.

This will not end well.

Friday, August 6 🔗

The reports and calls taper off.

By this time several blog entries and news articles have covered the malware. I add them to the news items on the Wireshark and CACE web sites.

This will not end well.

Saturday, August 7 🔗

More cussing and threats via email. Someone managed to find our contact information on the CACE web site, but completely missed the “Wireshark Antivirus” Malware news banner at the top of the home page.

This will not end well.

Monday, August 9 🔗

The crap-storm continues. We’re trying to help as best we can.

Tuesday, August 10 🔗

Yahoo! Answers deleted one of my comments because it was flagged as spam. Thanks Yahoo! You guys are swell!

Lessons: 🔗

Communicate. Luckily its victims were visiting www.cacetech.com, so we could pass along updates in near real time. Google and Bing helped track down users posting questions to online forums. I responded to each question with any information I had at the time.

People don’t run AV software. Seriously — you should at least be running something like MS Security Essentials by now.

Even cake is dangerous. One of the infections apparently happened while looking for pictures of cake on Flickr.

Comments 🔗

Comment by James Wylie on 2010-08-09 13:58:08 +0000 🔗

Gents,

I’ve had two customers in the past few weeks with virus infections from an app called Wireshark Antivirus. This was strange becuase I used your app a few years back. Took me a minute to realize that it was you guys and that some bonehead was using your name to exploit with bad character your company.

How can I help –

Mr Wylie

Comment by Gerald Combs on 2010-08-09 18:11:19 +0000 🔗

@James It sounds like you’re helping already.

Comment by mary chang on 2010-08-09 20:35:21 +0000 🔗

hello,
something calling itself WIRESHARK ANTIVIRUS installed itself on my computer & seems to insist on a subscription of some sort. I wonder if your program can uninstall it? I have notified CONSUMER FRAUD REPORTING.ORG. Many thanks for any help!
MARY CHANG.

Comment by Lee Anne Farnham on 2010-08-09 21:19:22 +0000 🔗

How do I get rid of this sharkware virus? It tagged on to my computer this morning when I was taking a look at wedding anouncement web sites.

I will also send an email to consumer fraud reporting.org.

Comment by Gerald Combs on 2010-08-09 21:31:07 +0000 🔗

Mary & Lee Anne,

There are a links with removal instructions at http://www.wireshark.org/news/20100804.html . Googling for “wireshark antivirus” (WITH quotes) turns up a lot more information about removing the trojan. I don’t have any way of testing them here and so can’t recommend any particular one.

Comment by belensaurus on 2010-08-12 22:48:11 +0000 🔗

i got the wireshark thingy and i managed to get rid of it,
download thee Malwarebytes’ Anti-Malware program and it will actually get rid of it
the wireshark program thingy wont let the program pop out but all you have to do it press the alt+ctrl+delete keys together and youll get the windows task manager pc lick on the wireshark and end the task then once the malwarebites program pops out do a quick scan and once the scan is finished remove the threats and your done your computer will restart and your computer will be ok go on malwarebites again and delete the threats and your done

Comment by Matt on 2010-08-13 10:50:08 +0000 🔗

The MalwareBytes solution seems to have eliminated the bug itself. However, further investigation has revealed that my browser is hijacked. I do not know if this was part of the Wireshark Antivirus bug or some prior threat I missed, but Googling “Malwarebytes” and following any of the links redirects me to off-the-wall websites that I’m sure are attempting to add more malicious garbage to my machine. I highly promote MalwareBytes, but be very careful attempting to download it. You may want to DL it from the comfort of another (uninfected) machine, and copy the installer to your infected machine. Also, you may need other solutions besides MBAM if your browser has been hijacked as mine has.

Comment by margy on 2010-08-13 11:37:00 +0000 🔗

how to do you know if your browser’s been hijacked? I have this Wireshark AV thing and can’t open apps to download anything to get rid of it. Had just downloaded MalwareBytes the night before…then got this. Can’t open MB to even scan

Comment by Gerald Combs on 2010-08-13 12:15:07 +0000 🔗

@margy According to a Malwarebytes forum post you can rename mbam.exe to something else:

http://forums.malwarebytes.org/index.php?s=bf5375540445801cd46624397aa2918a&showtopic=59850&pid=297318&st=0&#entry297318

Comment by brian on 2010-08-13 17:36:36 +0000 🔗

For those of you having issues running malwarebytes or other removal tool, your best bet is to boot in Safe Mode prior to executing anything. To enter safe mode, simply pres F8 while your computer is in BIOS prior to windows start up.

Comment by mary chang on 2010-08-13 19:15:13 +0000 🔗

Success to report! Our computer guru has solved all my problems, cleaned the whole system, besides identifying & removing that fake program. I intend to forward the fake’s name to Fraud Prevention authorities. If anybody wants to know, I can share my guru’s name — he has a huge reputation in our counties.

Comment by Curt on 2010-08-19 23:24:47 +0000 🔗

Is there a chance to monitor ports on unmanaged switches and the NIC´s of the machines attached to these ports?
I am experiencing ports to be hung up by machines in a way that they are not reachable anymore. The switch seems to be physically well but traffic to these ports is impossible.

Comment by James Eighmey on 2010-08-21 10:16:47 +0000 🔗

If you are a newbie to system security. You can run clamav portable or stinger to remove wireshark anti-virus. here are the links to both. McAfee Stinger – http://vil.nai.com/vil/stinger/ ClamAV Portable – http://portableapps.com/apps/utilities/clamwin_portable Your best bet is to run these from a flashdrive or memory card, and download them from a clean system.

Comment by Jamie on 2010-08-23 16:20:38 +0000 🔗

Wow… There’s some really stupid people floating around. “Wireshark” is an awesome packet-sniffing program. “Wireshark Antivirus” is a virus, and is not related to Wireshark in any way. Get a brain, people.

I would smack you people so hard, if I could. Give Gerald a break from your stupidity…

Comment by Joe Sammarco on 2010-08-24 13:13:10 +0000 🔗

This piece of malware is almost indistinguishable from the “SuperAntivirus 09” bug of recent fame. These idiots probably pulled the name “Wireshark” out of the blue because it sounded cool to them. The bug is easily eradicated by running the free application “Malwarebytes anti malware scanner” in windows safe mode. Just download the free software and make sure it updates before you scan with it. If you are not computer literate enough to do this for yourself, there are plenty of guys like me around willing to charge for this work.

Comment by Chris Maynard on 2010-08-29 07:36:45 +0000 🔗

Wow, how sad is it that the first site listed after a google or yahoo! search for wireshark is “Wireshark Removal”.

Comment by Michael McNamara on 2010-08-30 20:37:38 +0000 🔗

I’ve been on the receiving end of a few similar situations. Unfortunately you’ve got to bite your tongue and soldier along. You did a great job of communicating the issue once you learned of it. It’s a shame that users continue to be the mindless people that we know them to be.

Cheers!

Comment by Jason Cruse on 2010-08-31 07:58:50 +0000 🔗

Well I do computer work and let me tell you this and other fakeAlert programs and rogue spyware is crazy here in ohio. some let it go as far as were the system is so far bogged down that I end up having to do a renistall. Usually you can get rid of everthing but the redirector. Its my job…but still a pain.

Comment by M. O’Connor on 2010-09-16 13:16:58 +0000 🔗

Don’t want to sound flippant but…

Whoever created the wireshark AV app has created a new definition of “Wireshark” 🙂

T-Mobile: Clever or Insane?

Sun, 11 Apr 2010 00:36:35 +0000

I recently got an Android phone. After downloading the Android SDK I noticed that my cellular provider (T-Mobile) was doing something odd. According to the netcfg command they’re using 25.0.0.0/8 on their GPRS/EDGE network:

$ netcfg
lo       UP    127.0.0.1       255.0.0.0       0x00000049
dummy0   DOWN  0.0.0.0         0.0.0.0         0x00000082
rmnet0   UP    25.130.205.212  255.255.255.252 0x00001043
rmnet1   DOWN  0.0.0.0         0.0.0.0         0x00001002
rmnet2   DOWN  0.0.0.0         0.0.0.0         0x00001002
sit0     DOWN  0.0.0.0         0.0.0.0         0x00000080
ip6tnl0  DOWN  0.0.0.0         0.0.0.0         0x00000080

T-Mobile doesn’t own that netblock. The UK Ministry of Defence does. Why would they do such a thing? After all, RFC 1918 gives you three whole blocks (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) to do with as you please. Straying from those on your private will damn you to an eternity of network flakiness and give your twisted pair cabling scurvy, right?

Why this is clever 🔗

According to several BGP looking glasses and figure 5 of Geoff Huston’s IPv4 Address Report the Ministry of Defence doesn’t advertise any routes for 25.0.0.0/8. That means that none of the 25.x.x.x addresses are being used on the public Internet. If you’re on a private network they’re effectively free for the taking. But still, why aren’t they using the officially-sanctioned RFC 1918 address?

My phone also has an 802.11 interface. Let’s take a look at netcfg’s output when I’m connected to T-Mobile’s network and my home network:

$ netcfg     
lo       UP    127.0.0.1       255.0.0.0       0x00000049
dummy0   DOWN  0.0.0.0         0.0.0.0         0x00000082
rmnet0   DOWN  25.130.205.212  255.255.255.252 0x00001002
rmnet1   DOWN  0.0.0.0         0.0.0.0         0x00001002
rmnet2   DOWN  0.0.0.0         0.0.0.0         0x00001002
sit0     DOWN  0.0.0.0         0.0.0.0         0x00000080
ip6tnl0  DOWN  0.0.0.0         0.0.0.0         0x00000080
eth0     UP    192.168.25.4    255.255.255.0   0x00001043

See the 192.168.25.4? That could just as easily be 10.0.0.4, 172.18.34.4, or any other RFC 1918 address. On many networks (particularly universities) it could even be a public address. T-Mobile has no way of predicting or controlling what happens on that interface. The 25.0.0.0/8 netblock has the following advantages:

It doesn’t overlap with any other network, public or private. Therefore you won’t get any routing confusion when the phone is connected on GPRS/EDGE and WiFi at the same time.
It’s not in public use. The next Facebook or Lolcats isn’t going to show up with a 25.x.x.x address, thereby causing routing confusion for your users.
Even if the UK MoD is handing out 25.x.x.x address over 802.11 they’re way over in the UK. It’s unlikely that my phone will be connected to the MoD and T-Mobile networks at the same time.

Why this is insane 🔗

IPv4 addresses are getting scarce. Who says the MoD won’t turn the 25.0.0.0/8 netblock over to RIPE or IANA next week? Even then my phone has to go through a proxy server on T-Mobile’s network so it’s probably not a huge deal.

Update 🔗

Just before publishing this I ran netcfg and my phone was using 14.64.186.160. The 14.0.0.0/8 netblock used to be reserved for public data networks but was allocated to APNIC earlier this month. I wonder what other questionable netblocks they’re using.

Comments 🔗

Comment by Stephen Fisher on 2010-04-11 02:15:40 +0000 🔗

Maybe they should start using that strange “new” thing called IPv6 🙂

Comment by Gerald Combs on 2010-04-12 09:19:00 +0000 🔗

You’re absolutely right. This would be a non-issue with IPv6. To be fair, I’m not sure what else T-Mobile can do in this situation. They probably have a lot of customer handsets that are v4-only. Luckily none of the mail or SSH servers I use have 25/8 or 14/8 addresses.

Comment by Julio De Leon on 2010-04-12 12:52:24 +0000 🔗

Let’s see if I understood well, if I were to point to your address 25.130.205.212/8 from my computer, it will route me to your phone? Instead of correctly route me to anywhere in the UK MoD network?

Comment by Gerald Combs on 2010-04-13 09:54:27 +0000 🔗

@Julio The 25/8 block isn’t publicly routed at all, so you should see a timeout or network unreachable error if you try to connect to 25.130.205.212. T-Mobile’s GPRS/EDGE uses a proxy server for HTTP connections and NAT for everything else so the 25/8 and 14/8 addresses are invisible to the outside world. The problem is when I’m connected via GPRS/EDGE and need to connect to a 25/8 or 14/8 address *outside* of T-Mobile’s network. Right now this isn’t a problem. As the IPv4 address space nears exhaustion it could easily become one.

Comment by Old T-Mo Employee on 2010-05-13 10:15:57 +0000 🔗

Actually, T-Mobile has many “illegal” IP ranges, depending on what network you connect through. In fact, there is a management network which also uses stolen public space. It is a risk, but was done because of the scarcity of RFC1918 space. Believe it or not, there just are not addresses in that range to handle all the network devices and phones.

Comment by Rollo on 2010-05-15 08:25:15 +0000 🔗

Here in Germany t-mobile uses IP-Adresses like 1.2.3.4 for example, APNIC-adress-space. Should work fine, they are not only “way over”, but “down under” 😉

Comment by brn0vrflw on 2010-05-18 10:13:48 +0000 🔗

Why extrapolate ? Just contact them !

Comment by olivia on 2010-05-25 13:38:50 +0000 🔗

i found exactly the same issue with our business “orange” mobiles however T-mobile and orange have now merged. Surely Its obvious UK.gov are turning a blind eye to the misuse of what essentially is a public network.

Comment by Will on 2010-05-25 14:44:10 +0000 🔗

@olivia: It’s not a misuse of a public network… in a worst-case scenario, let’s say you work for the UK Government and need to connect to 25.1.1.1 from your T-Mobile phone– you’ll likely be unable to, as T-Mobile is using that address for their INTERNAL network. However, if you connect from anything else besides your T-Mobile phone, it’ll work fine.

So this isn’t a misuse, it’s just risky since T-Mobile customers could potentially be angry that they can’t reach a certain website.

Currently, however, it’s a smart move on T-Mobile’s part because they can avoid even worse problems if you connected your phone to a wifi network that happened to use the same internal IP range as T-Mobile.

IPv6 will solve all of this, and it should solve it soon as most new devices are IPv6 enabled and strategies for routing between IPv6 and IPv4 networks are already well-known.

Comment by Jodrik on 2010-05-30 23:46:17 +0000 🔗

Versatel also has a hand in this using 1.0.0.0/8 for their GPRS in the Netherlands for instance. I personally think it’s -extremely- annoying that major companies like ISPs just go out and set “bad examples” with work-arounds like this. Yes IPv4 is limited, but how long has IPv6 been in the making? Shouldn’t ISPs be the one pushing phones manufacturers to implement IPv6 instead of just waiting for it to happen and basically abusing privately owned networks.

In my opinion if they should have seen this limitation comming way back when GPRS etc started catching on and should have just implemented IPv6 on it by default.

Comment by Michael Patterson on 2010-06-06 18:20:42 +0000 🔗

Hello Gerald,

We are testing IPFIX in our next release due out later this month. We are finally receiving the data from procflow correctly. What are your intentions with this tool? We noticed it hasn’t been updated for about a year.

See you at sharkfest.

Mike [at] plixer.com

Troubleshooting A Slow Web Site

Tue, 08 Dec 2009 01:58:00 +0000

A couple of weeks ago we had a strange problem in the CACE Technologies World Domination Secret Lair. Loris was having trouble loading the Wireshark blog. It was working fine on my machine so I checked some of the other machines in the office. I found the same problem on one of the development machines. Loading the page in Firebug showed that the object requests were stalling out every 20 seconds or so:

I fired up Wireshark and captured the browser attempting to connect to the blog:

The problem was immediately obvious. The browser attempted to connect to the blog’s IPv6 address (2607:f0d0:2001:e:1::1), timed out, and connected to the blog’s IPv4 address (67.228.110.126).

As it turns out Loris and I ran some IPv6 tests a long time ago and we added unique local addresses to our machines (mine was fd00:cace::4) . Since each machine had an IPv6 address the TCP stack assumed that there was general IPv6 connectivity. However, our ISP is steadfastly ignoring IPv6 so end-to-end connectivity wasn’t there. After timing out the connection fell back to IPv4 and proceeded normally.

This sort of thing will likely crop up more and more often as we transition to IPv6. If either IPv4 or IPv6 connectivity fails, your applications will still have connectivity so the failure may not be immediately obvious. In this case Firefox stalled out but still managed to connect. If it used a connect-by-name socket API the failure wouldn’t have been evident at all.

Comments 🔗

Comment by siyu on 2010-01-28 17:58:55 +0000 🔗

thanks a lot.

Chrome OS

Fri, 20 Nov 2009 00:31:59 +0000

Today I followed the announcement of the new Chrome OS from Google and the acclaiming response it received. Am I the only one thinking: very simple, maybe TOO simple?

Since the beginning of the “browser as an OS” idea, I always wondered how I am supposed to run my favorite program, Wireshark, in a browser. Wireshark, of course, is an example, but many people do things with computers that don’t translate well into the cloud paradigm. Will they just be dismissed by OS manufacturers as a “nerdy minority”? Or will they need to stick with old uncool OSes to do their things? I’d like to be cool too, Google, but I’d still like to run Wireshark.

Another thing I feel weird about: Google is telling me not to worry about data loss, because from now on all my documents will be online. Nothing will need to be saved locally.
Actually, I like that my documents stay in my computer. Am I really the only one in the world? I’m not only talking about personal stuff like the love letters to my wife or the drunk pictures at the party last week. What about the trace files that I get all the time from customers? Will they have to go online too? Hmm, I’m sure my customers will love having them on Google’s server.

I can already hear the objection: “this OS is for netbooks, and netbooks are only used for simple things like going online, so this is perfect for them”. Actually, I love using Wireshark on a netbook! Together with an Airpcap adapter, it’s the perfect portable wireless troubleshooting station.
Why does small need to mean “limited”? Personally, I’d actually love to run Wireshark on my wireless-enabled IPod Touch! Ok, maybe I’m going too far…

http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html

Comments 🔗

Comment by Aaron C. de Bruyn on 2009-11-19 20:16:17 +0000 🔗

I just had the pleasure of using Wireshark on a netbook today.

Looks pretty good on the small screen.

Comment by vasiljevich on 2009-11-21 15:44:49 +0000 🔗

If Chrome OS is only for internet surfing, it seems to be useless, as there are many devices (more comfortable and portable than netbooks) with the same functionality.

Comment by Dan on 2009-11-21 22:00:11 +0000 🔗

Is there any reason wireshark couldn’t run as a javascript webapp?
I look forward to building an ultraportable sniffing machine using the wireshark webapp for Chrome OS on a netbook…
Of course, if I have to rely on a live connection to run the app to sniff the packets to troubleshoot my live connection, that may be a problem 🙂

Comment by Varun on 2009-11-23 00:32:46 +0000 🔗

Hi Loris,

Thanks for posting this. I’ve been thinking about using a sniffer on my iTouch too. (Don’t want to pay for upgrade to 3.0 though :)).

This proves either I’m not an idiot or not the only idiot to think that up 😀

BTW I’m not going for ChromeOS at all after watching them explain how only web browser will take care of my PC experience…

Varun

Comment by ME! on 2009-11-24 16:21:19 +0000 🔗

I guess you’re not cool enough for ChromeOS.
🙁

Comment by Terry on 2009-12-09 19:30:12 +0000 🔗

Loris, You are not alone. Going a bit beyond using applications like Wireshark, the cloud paradigm will have a boundary established by financial interest or technical and legal limitations. A recent example is the I Phone and the attempt to use a voip application not licensed by Apple. In the Chrome cloud Google not the individual or group will determine what is permitted. It will be cheaper for those doing email, Facebook, desktop publishing. The cost will increase for anyone using a standalone OS. I hope the Chrome like goes away quickly.

Comment by Yuval Levy on 2010-01-16 11:39:31 +0000 🔗

Loris, you’re not alone. All of these freebies are cool candies to attract consumers into selling their souls. I rather have a known price tag in US$ than an unknown price tag in relinquishing control over core strategical and personal things. Call me uncool.

I wanted to thank you for wireshark. I am trying to use it to reverse engineer USB camera communication, although with little success so far. My Ubuntu 9.10 system freezes a few seconds after I start sniffing. I’ll keep googling for a solution – that’s what I like google for.

Polycom IP Phone Boot Analysis

Mon, 28 Sep 2009 21:20:29 +0000

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:

SIP firmware download failure

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?

At this point the phone might have an up-to-date copy of the SIP firmware. It would be nice if it could avoid downloading this file every time it booted up. The file is 15 MB, so in some environments this would be really nice. (Imagine a thousand phones trying to download this file at the same time after a power outage. Over a fractional T1. That’s flapping.) Unfortunately methods for comparing files via FTP or HTTP to ones you already have are either rarely used or not supported at all.

Running the strings command on the firmware turns up the following tidbit at the beginning of the file:

Checksum=0x00008c5e

It looks like the phones look for the checksum in the firmware header and drop the connection once they’ve determined they already have an up-to-date copy.

This is a very roundabout way of showing that sometimes error conditions on your network are not only normal but beneficial.

Comments 🔗

Comment by bperkic on 2009-09-30 01:07:36 +0000 🔗

Good point! Thx

Comment by rogio on 2009-10-23 09:16:35 +0000 🔗

Great Read.

Comment by Oldcommguy on 2009-11-05 11:01:59 +0000 🔗

It is no longer a secret…now we know where you are at!!!!

Great article – Flapping indeed and an real OMG!