I am trying to write a DBC Paser, but I never saw a DBC file with two baud rates and I wanted to ask if anyone has an example of a DBC file with two baud rates?
Related
Is it possible to re-do numbering in Wireshark. For example i have filtered packets to one side:
So the numbers are (they are not in order because of filtering):
416,419,420,423,424,426,427.
But i would like to number them like this, line by line:
1,2,3,4,5,6,7
The reason is that it would be easier to count all the packets. I know tshark has statistical operation COUNT, but for quick counting this would be a lot better.
You can export the displayed packets into a new file via File -> Export Specified Packets... -> All packets: Displayed. The new capture file will contain sequentially numbered packets starting from 1.
But if you just want to know how many displayed packets there are, you could just look at the Wireshark status line where it will indicate the number of displayed packets.
Statistics -> Capture File Properties will also tell you the number of displayed packets.
I'm using tshark to extract specific TCP streams and write that to an output pcap file using the -w option.
But, the frames in the output pcap do not have any timestamps or delta times (they're all zero while in the original pcap there are timestamps and delta times for the frames).
Is there any way to ensure that the original timestamps (from the original pcap file) are preserved in the output pcap?
I'm using TShark 1.10.5 (SVN Rev 54262 from /trunk-1.10) on MacOS.
Thanks!
the frames in the output pcap do not have any timestamps or delta times (they're all zero while in the original pcap there are timestamps and delta times for the frames).
That is what is technically known as a "bug". Please file it as a bug on the Wireshark Bugzilla; if you can attach your original pcap file for testing purposes, that would be good. (If not, please run the file command on it and show the results, just so we know what file type the input file is - it might, for example, be a pcap-ng file rather than a pcap file).
I have the pcap of a VoIP call involving SILK.
I'm able to see in Wireshark the RTP payload.
From the RTP headers I can understand the sample rate (e.g. 24 KHz) and the frame size (e.g. 20 ms).
What I'd like to do is extract the RTP payload and generate a file containing the SILK-encoded audio.
From the RTP payload format description I can see that in the case of storage in a file, each block of audio needs a block header, to specify the sample rate and block size (because the block size is variable and can be different on each frame).
How can I generate a file with the correct file header ("magic number") and add a block header for each block of audio?
I can use a few different programming languages so I'm mainly interested in the required algorithm, but would appreciate references to code implementations (or perhaps some existing tool?).
Use pcaputil of pjproject: Converts captured RTP packets in PCAP file to WAV file or play it to audio device. Can filter the PCAP file on source or destination IP or port, is able to deal with SRTP and supports all codecs in PJMEDIA, including SILK (have not tried this myself).
Examples:
pcaputil file.pcap output.wav
pcaputil -c AES_CM_128_HMAC_SHA1_80 -k VLDONbsbGl2Puqy+0PV7w/uGfpSPKFevDpxGsxN3 file.pcap output.wav
I have a simple point to point UDP WiFi simulation in NS-3 that outputs data to a trace file. It provides lots of useful data but there is no information that gives a unique ID for each packet. I can't find anything in wireshark either when I open the pcap files.
I have output the results of my simulation to an ascii trace file and pcap files for both nodes but I can't find any packet identifier. I can see the sequence numbers of the packets but that's it.
I am new to NS-3 so I am not sure how to produce this information.
Here is some of the output from the trace file.
t 2.00082 /NodeList/0/DeviceList/0/$ns3::WifiNetDevice/Phy/State/Tx ns3::WifiMacHeader (DATA ToDS=0, FromDS=0, MoreFrag=0, Retry=0, MoreData=0 Duration/ID=0usDA=ff:ff:ff:ff:ff:ff, SA=00:00:00:00:00:01, BSSID=00:00:00:00:00:01, FragNumber=0, SeqNumber=0) ns3::LlcSnapHeader (type 0x806) ns3::ArpHeader (request source mac: 00-06-00:00:00:00:00:01 source ipv4: 10.1.1.1 dest ipv4: 10.1.1.2) ns3::WifiMacTrailer ()
Any suggestions are appreciated.
Thanks.
In case you might not be aware of this already, let me first point out what might seem to be the obvious but: "there is no such thing as unique packet id in real networks" and since pcap traces are designed to contain dumps of real packets in real networks, there is zero chance you will be able to find a unique packet id in a pcap trace generated by ns-3.
Now, ns-3 does contain a per-packet unique id that is available with the Packet::GetId method and you can trivially change the source code of the function that generates your ascii dump to add this in src/wifi/helper/yans-wifi-helper.cc. Grep for "Ascii".
Now if you want to know why it does not do this by default because it is so useful, I honestly can't remember but:
there is probably something related to the ns2 trace format that inspired this ascii format. Compatibility with existing tools might have been an issue
adding a packet id goes against the ns-3 philosophy of matching what real networks do
Well, even Embarcadero states that it is not guaranteed to return accurate result of the bytes ready to read in the socket buffer, but if you look at it, when you place -1 at Socket.ReceiveBuf (this is what ReceiveLength wraps) it calls ioctlsocket with FIONREAD to determine the amount of data pending in the network's input buffer that can be read from socket s.
so, how is it not safe or bad ?
e.g: ioctlsocket(Socket.SocketHandle, FIONREAD, Longint(i));
The documentation you mention specifically says (emphasis mine)
Note: ReceiveLength is not guaranteed to be accurate for streaming socket connections.
This means that the length is not known ahead of time because it's being supplied by a stream of data. Obviously, if you don't know how big the data is that's being sent ahead of time, you can't properly set the length the client should expect.
Consider it like generic code to copy a file. If you don't know ahead of time how big the file is you'll be copying, you can't predict how many bytes you'll be copying. In the case of the socket, the stream size that's supplying the socket isn't known in advance (for instance, for data being generated real-time and sent), so there's no way to inform the client socket how much to expect.