88 posts categorized "Wireshark" Feed

IP Subnet Wireshark Display Filter (by Tony Fortunato)

When asked for advice on how to be a proficient protocol analyst, I give 2 pieces of advice;

  1. Practice looking for patterns. In most cases, you are looking for patterns, or a break in the pattern.  Don’t worry about memorizing the RFC’s or learning about every protocol. It is easier to focus on whatever protocol you are working on at that time.
  2. Learn your display filters in whatever your protocol analyzer you use. The correct display filter will make the patterns jump out at you.

I caution analysts about going capture filter crazy. Unless you know exactly what you are capturing, I typically try to leave the capture filter as ‘open’ as possible. My concern when troubleshooting is that due to the very nature of the unknowns when troubleshooting, you may inadvertently filter out valuable packets.

I great example is you may decide to use a capture filter for a web server ip address when capturing from the client. In this scenario you would miss any packets from the router or other devices along the way if they send the client an ICMP error packet or if the client communicates with other servers.

In this example, I show you that the ip.addr display filter can be used for a subnet.  You are probably familiar with this filter when filtering on a single device. What do you do if you need to filter on more than one host? The typical approach is to combine the ip.addr filter with an or. For example ip.addr==192.168.1.1 or ip.addr== 192.168.1.2 is one way to capture from two hosts.

Now let’s take this a step further. What would you do if you wanted to capture from all addresses on a server farm or client subnet?  I’ll make this a touch more realistic and add that you don’t know the all the IP addresses on the other subnet.  This is where the subnet/mask option comes in.

You can simply use that format with the ip.addr == or ip.addr eq display filter. If I wanted to display the IP addresses from the 192.168.1.1 to 192.168.1.254, my filter would be ip.addr == 192.168.1.0/24 or ip.addr eq 192.168.1.0/24.  The mask does not need to match your local subnet mask since it is used to define the range. If you wanted to display all the packet from 192.168.1.1 – 192.168.1.14, my display filter would be ip.addr == 192.168.1.0/28.

 

 

 

Continue reading other LoveMyTool posts by Tony Fortunato »


LMTV LIVE | Troubleshooting Tesla Model S Connectivity (with Jonathan Whiteside, Darrin Roach and Paul Offord)

Tesla Motors is very much at the forefront of the ‘Connected Vehicle’ revolution, producing vehicles with ‘always on’ connectivity through 4G LTE and WiFi. This gives the driver features such as Google Maps navigation, web access and Spotify.

If you had a connectivity issue with a Tesla Model S, how could you troubleshoot it?  Are specialist tools needed or could you just use standard kit?

In this week's session, Jonathan Whiteside and Darrin Roach of Advance7 describe an experiment to learn more about connected vehicle technology by tracing the data flows between a desktop PC app called Tesla Control, the Tesla Cloud Services and a Tesla Model S.  There were some challenges and a couple of surprises.

For more background information, see Jonathan's paper "Tesla Model S Remote Control" on the TribeLab site - https://community.tribelab.com/course/view.php?id=37


Slow Transfer, Packet Losses, Congestion Avoidance, Shaping and Policing (by Phil Storey)

Problem: Slow Transfer, Packet Losses, Congestion Avoidance, Shaping and Policing!

This is a response to a question asked on Tuesday 5th December by “u/thegreattriscuit” in Reddit’s “r/Networking” subreddit.

The original question that started the investigation! Click to go to page -

Question Summary - The problem was slow file transfer throughput across a long 1 Gbps WAN (“across an ocean”) and caused by packet losses. However, we’re told that the packet loss behaviour was consistent and readily reproducible for this particular iPerf test - but not apparent for other transfers across the same link.

The provided “topology” diagram is below. The flow is from Host-A at the left to Host-Z on the right and the packet losses occur somewhere between the two points (as indicated by the blue line between two capture points). The losses could be within the Cisco 4500, ASR1000, Force10 WAN, ASR1000 or Force10 switch).

1

A commercial packet analysis tool called NetData Pro was used to perform this analysis and provide the detrail visuals included - 

Full Details of the analysis and Conclusions following - 

*Note for larger diagrams click on image - 

Continue reading "Slow Transfer, Packet Losses, Congestion Avoidance, Shaping and Policing (by Phil Storey)" »


IoT: Tesla Model S Remote Control (by Jonathan Whiteside, Darrin Roach and Paul Offord)

With the proliferation and expansion of wireless technologies, it is now becoming commonplace for vehicles to be connected to the Internet for numerous reasons, such as website access, telematics and always connected emergency services.

Tesla Motors is very much at the forefront of the ‘Connected Vehicle’ revolution, producing vehicles with ‘always on’ connectivity through 4G LTE and WiFi.  This gives the driver features such as Google Maps navigation, web access and Spotify.

Tesla_control

It also allows remote operation features such as climate control and charge port opening/closing, as well as providing an instant view of battery charge levels.  All these features can be readily accessed from a mobile phone app or desktop app on a PC.

The objective of this experiment was ...

Continue reading "IoT: Tesla Model S Remote Control (by Jonathan Whiteside, Darrin Roach and Paul Offord)" »


Wireshark Fundamentals (by Tony Fortunato)

I am noticing that i am  seeing a lot of people who are self taught when it comes to Wireshark and protocol analysis as well as those who want to get into it.

I decided to create a 2 hour Udemy (Wireshark Fundamentals) course to teach people Wireshark basics and in the last lecture Idemonstrate how to get started with protocol analysis.

The key is to demonstrate why and when to use a feature. Knowing where the features are doesn't imply you know when and why to use them.

I encourage anyone interested in protocol analysis to get familiar with cause and effect. That is where you simply do something and review those packets.

Last month had a draw for free coupons to take my class and thought it would be cool to post an entire lecture from the course.  Enjoy.

 

 

 

Continue reading other LoveMyTool posts by Tony Fortunato »