I would like to analyze a given TCP connection and record the total number of losses, as well as detailed analysis such as how many losses were of type tripple-duplicate ACKs, single-timeouts, double-timeouts, triple timeouts, etc.
Can anybody suggest a good tool for this?
Thanks in advance!
I suggest that you use tcptrace. It has more detailed TCP statistics than Wireshark, along the lines you are looking for. (use the long output format)
Related
Is it a good choice choice to transfer large amount of data (i.e., each piece of data about 100MB) through Mqtt?
Any advice or suggestion is welcome.
ADDED:
As far as I know, it seems that mqtt could support as much as 256MB as the spec . But it's also known that it usually transfers the data that is less than 1MB.
So, I am a little confused now.
MQTT was designed to send telemetry data (usually something under 500 bytes) to multiple nodes, with various QOS ratings.
This is a question that comes up quite frequently here. When I consult with customers who ask me this kind of question, I always say there are better ways to move large amounts of data to multiple nodes. Consider these:
Copy the large data up to an FTP server, and just send out the address using MQTT.
Stream the data using some kind of streaming protocol, or multicast, and just send the stream address over MQTT.
Can you send large data chunks over MQTT?? Yes. But just because you can do it, does not mean its the best way to do it. Solutions I design for customers never send anything over 100k or so over MQTT. It takes up too much bandwidth and can bog down the Broker very quickly, especially with large number of Subscribers.
There are others on here that will tell you for sure, do it, no problem. I have run into too many issues with too many customers that wanted to do stuff like this, so I never create a solution that uses MQTT for large chunks of data.
We are trying to stream data from a car's OBD-II protocol via Wireshark. It's working fine and we get the IDs and data payloads out interpreted as CAN. However, we would like to take it a step further and "scale" the data according to the documentation on wikipedia.
This requires that we can use a formula that is dependent on information contained in the ID and in the start of the actual data message.
Could anyone provide some guidance as to how we can create such a scaling/conversion of the data into readable output using Wireshark? Ideally we would also like to inform the viewer of what data, units etc. they're looking at - we have all this info, but we would just need to find a way to return it depending on the ID.
Hope you can help - it would be much appreciated! Martin
I recommend obtaining SAE J1979 and SAE 1979DA. In there you will find the complete information necessary to dissect the protocols, including units and scaling / offset for every standardized PID. Then, codify this into a dissection protocol in Wireshark.
i need to create some statistics from packets in my network interface, but i'm concerned only for my tcp sessions. i thought i could do that with nfdump and nfsen. because i'm new to this stuff, i dont really get what nfdump defines as 'flow'.
furthermore, can i get statistics with these tools only for the tcp protocol sessions? i mean, for example, that i need to have some average duration of all the connections(srcip-srcport, dstip-dstport pairs) in a server of mine. And for this reason i need the time between the 3WH and the closing of each connection (either with [fin/ack,ack] or with [rst]). Is that possible with nfdump-nfsen?
Short answer here is no: you don't have anything in your list of software that generates netflow information. It's not going to work. Netflow collectors do not work as hard as you might like to maintain your idea of a connection - a flow is just a collection of related packets that happen during part of the collection cycle. For a long-lived session, you can expect to see a few flows.
For your application, you will do better to capture syn-ack and fin packets with tcpdump and analyse the timing of these with your favourite text processing tool.
Also, on the left side of your keyboard, you may find a key with an arrow that allows you to type capital letters.
I need to classify TCP traffic base on video and non-video. So i need to find characteristics of each flow.
My classification is Flow-based and one of my variables is incoming packet length. but it is not accurate as
P(video|1200Bytes)= 0.04
P(non-Video|1200Bytes) = 0.22
I need some help to find some variables, at least two more to decide more accurately if a flow containing a video or not.
Can anyone help me please?
Thanks
Checking a single packet by itself may not yield a good result, why don't you try profiling based on the source of the packet? If a source sends so much linked TCP packets, then it could be video.
I am looking for the way to calculate the one-way delay in a packet-switched network. I do not want to use NTP or PTP (Network Time Protocol, Precision Time Protocol).
Consider the scenario:
Host-1 Sends the packet to Host-2. Both Hosts have different Clock rates and the hosts are located in different countries.
Packet may be UDP/TCP/Layer 2 Frame.
Is there any way to sync the clock rates of two hosts so as to calculate the one-way delay.
Now how do you guys calculate the one way delay without relying on a timing protocol. I am looking some generic formula to do this.
I would much appreciate the answers for this question.
Thanks a ton in advance.
Synchronizing clocks is exactly what [S]NTP are meant to accomplish. If there was a simpler way, the protocols would be simpler. You can approximate RTT without them, but one-way delay is hard to do.
No, you cannot. Measuring a one-way delay requires synchronized clocks (and NTP is typically not good enough for this task, independent synch to reliable clocks is necessary).
Read RFC 4656 for the gory details. There are two available implementations, OWAMP in C and Jowamp in Java.
refer to UTP in bittorrent, it calcs qdelay, no need to sync at both sides, however, it may be not what you want.
I use iperf to do network testing like that. You might get some insight by looking at how they do it.