370 posts categorized "Protocol Analysis" Feed

Fresh look: When Do Laptops Start Dropping Packets? (by Chris Greer)

In this video, we took a traffic generator and slammed packets at a laptop to see what it could handle. 

The results may surprise you!

After finding the point where the laptop started dropping, we looked at the inter-packet delays. Even though the laptop was capturing all the transmitted packets, the packet timing was far from accurate. 


Questions? Get in touch. 

Chris Greer Packet Pioneer Logo

Author Profile - Chris Greer is a Network Analyst for Packet Pioneer LLC and a Certified Wireshark Network Analyst. Chris regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. Chris also delivers training and develops technical content for several analysis vendors.

TCP Fundamentals: Analyzing TCP Resets (RST) (by Chris Greer)

Are TCP resets bad?

TCP RST reset bad or good

Wireshark can sure make them look that way. After all, bold red lines rarely highlight something positive. But like many things TCP, the good-or-bad factor of resets just depends on when they happen and how they are affecting end users.

There are a two common ways that a TCP connection can be torn down. I like to call these the polite way (FIN) and the talk-to-the-hand way (Reset). Tearing down TCP connections is a good thing as long as it is not actively in use, or won’t be needed in the very near future. We want each side of the conversation to open up the resources for other connections rather than maintaining idle ones in an active state.

In most cases, we want to see FINs tear down a connection rather than resets. However there are some examples of normal behavior where a reset is sent rather than a FIN.

Here are a few questions to answer about resets when they appear in a trace file. 

Continue reading "TCP Fundamentals: Analyzing TCP Resets (RST) (by Chris Greer)" »

Extending the Value of Your Existing Security and Monitoring Tools! (by Keith Bromley)

Extending the Value of Your Existing Security and Monitoring Tools –

Also Referred to as Pulling a Rabbit Out Of Hat!

Editor's Note - this article is also followed up on with a free Webinar,

Thursday September 15, 1400 ET - Do Not Miss This Learning Experience!

Maybe you’re getting ready to perform a network upgrade – say 10G to 40G. Maybe you’ve just been through one. Maybe your IT budget is stretched far too thin with little relief coming. In all of these situations, one of the biggest portions of your monitoring budget is spent on purpose-built monitoring and security tools. Some examples include IPS’, SIEMs, threat detection tools, application monitoring tools, and network performance monitoring tools. These tools are necessary and useful but at the same time, they take budget away from other networking components that you need buy.  If you run out of budget for both activities (building the network out completely and being able to monitor it completely), you need a way to compromise.  You need a way to push your tools to the max, without losing critical data or causing yourself other problems, so that you still have money left to spend on other activities.

Magic hat of network tools

Return on investment (ROI) is an important factor for new technology purchase decisions. However, having invested in many security and monitoring tools, what is the best way to maximize the value of your tools and previous user training and experience? Cost avoidance for new tool purchases is one way for IT to maximize this ROI and make your security and monitoring solutions stronger. As we all know technology is rapidly changing and a usable life of 3 years or less for equipment is the norm. So, cost elimination can save you money up front but could end up costing your business 3 to 4 times more in the long run due to costly network downtime, opportunity cost for using expensive level 3 engineers to fight fires, longer mean times to repair, inefficient processes, QoS and QoE issues for customers and increased costs for mega breaches.


Continue reading "Extending the Value of Your Existing Security and Monitoring Tools! (by Keith Bromley)" »

Hey Network - Leave the Packets Alone! (by Chris Greer)

TCP MSS Segment Size change


Or… if you are going to change things, at least don’t break things!

Remember the first time you learned about NAT? Or PAT? Or changing TCP MSS at the router level?

Cool stuff. The network became involved in adjusting, changing, shaping, or translating packet header values as data passed through. These alterations to packet headers were made for several reasons - everything from extending the life of IPv4 address ranges to making header room for WAN acceleration technologies - allowing engineers to keep data flowing in today’s networks at top speed. That is pretty impressive given that the two main data protocols, IP and TCP, are about to turn 40 years old. (Wow!)

These adjustments to header values by the network are very much in use today, which is a great thing - until something goes wrong. At times, the configurations on routers and other network devices that make these adjustments can be either mistyped, misunderstood, miscalculated, or some combination of the three. This can lead to problems in both connectivity and performance of applications, which can appear to lag or break altogether.

Continue reading "Hey Network - Leave the Packets Alone! (by Chris Greer)" »

The 5 Reasons Traditional Packet Capture will not work anymore (by Boris Rogier)


Traditionally network administrators have learned to use packet analysis for troubleshooting complex network problems. Some invested in expensive traffic capture appliances to capture and retain the traffic for later analysis; in case they get reports of a performance degradation issue, they can extract trace files and load them into a network analyzer (Wireshark or commercial) and look at the packets to try and determine the issues that caused the reported degradation. 


The evolution of IT systems is challenging this way of undertaking network diagnostics.

Traffic data focused analysis will remain the main source of troubleshooting network issues, but network teams need to take another perspective on it.  

What are these trends that make it more complex for network administrators to diagnose performance issues fast enough with stream to disk appliances and network analyzers ? 



Continue reading "The 5 Reasons Traditional Packet Capture will not work anymore (by Boris Rogier)" »

Monitoring network file stores by analysing network traffic! (by Darragh Delaney)

Monitoring network file stores by analysing network traffic!

Network based file stores have been around for quite some time now and they continue to be a popular way to share data within organizations. While cloud based services such as Dropbox and Office 365 are popular, network based file stores will be around for a long time.

There are many reasons why organizations choose to store their data locally on their network. For many, it comes down to the security risks of storing confidential data outside of their networks. For others, it is the convenience of locally stored data which can be easily accessed and it won’t go offline if Internet connectivity is lost.

See your network

However, network based file stores have become the number one target for Ransomware attacks. All it takes is for one infected client to encrypt all data on network file shares. For this very reason alone,  it is vital that you have some level of visibility as to what is happening on your network file stores. From my own experience, I know of three approaches:

  1. Agent\client based software solutions
  2. Native logging on file server
  3. Network traffic analysis

I am not going into any detail on the agent\client options as they are very vendor specific and I don’t know of any that does not impact on file server performance.

Continue reading "Monitoring network file stores by analysing network traffic! (by Darragh Delaney)" »