I'm analyzing some captured packets and see that for some of the packets, Wireshark displays the image below, which appears to contain several Modbus PDUs in the one TCP segment. I have searched online for answers but can't see this behavior anywhere I looked. From what I'm reading, Wireshark re-assembly gathers the different TCP segments, and so it appears this can't be reassembly.
My question is: is this behavior (i.e. having several Modbus PDUs in one TCP segment) normal and expected? If not, what is causing this problem? Is this an issue with Wireshark?
link to fullsize image
Yes - Modbus TCP runs at the application layer and supports multiple simultaneous transactions over a single connection (see page 10 of the spec). So sending:
00 01 00 00 00 06 01 03 00 00 00 01 00 02 00 00 00 06 01 03 00 01 00 01
is fine (this is 2 x "Read Holding Register" commands - note the different transaction identifiers). If this is sent at the same time it's likely the two commands will be sent out in the same packet. While this is supported (by some devices!) its not something I see often (unless performance is key its easier to process the response before sending another request).
However I don't think this is what is happening in your case. The lines you are highlighting are flagged TCP Retransmission so I'm assuming there was a connectivity issue. You can also see this in the 1s gap between the retransmitted packed and the previous request (it looks like queries are being sent every 300ms).
862.493794
862.805685 - 0.3s gap
863.117588 - 0.3s gap
864.232576 1st retransmission - 1.1s gap
You will also note that after the retransmissions there are a couple of responses that come in very close together (less than 1ms apart).
When data is retransmitted I believe (not my area so relying on this answer and assumptions!) that multiple packets may be combined. So I suspect you are seeing is:
Network connectivity issue starts
Client sends request
No response received so Client tries again (may happen multiple times)
Connectivity issue resolved
The packets sent while there was an issue are combined and retransmitted (handled by the network stack).
In no case does TCP ensure that if you send a packet of x bytes, the other end will receive the x bytes in a single packet.
It can happen that one side sends 1000 bytes and the other side receives first 800 and then 200, or two packets of 1000 and 2000 are sent and the other side receives only one of 3000.
From the received PDU, first you have to read the bytes necessary to obtain the length and then read the rest and so on to extract the PDUs
Related
I try to get the channel width of networks so I'm using WlanGetNetworkBssList to retrieve a list of BSS entries of the wireless networks on a wireless LAN interface but I don't see any information about the channel width. It's kinda trivial to get the channel center frequency to obtain the number of used channel and many other information but the channel width seems to be an obscure information stored somewhere in IE data blob of BSS entry structure. I managed to get some information about the width of the channel from HT and VHT Operation information elements but doesn't seem to be enough. I found on Github a python wrapper that extract info from Extension information element but it's not clear from which one since IE data blob of BSS entry structure might have more IE Extension elements.
For example I have 5 different IE Extension elements:
FF 1A 230108080E00580C2F4EC96FC927DE018F00FAFFFAFFFAFFFAFF
FF 07 24E43F003CFCFF
FF 03 272500
FF 0E 260600FFFF20FFFF40FFFF60FFFF
FF 02 252A
I found some basic information about HT Operation and VHT Operation information elements but nothing about Extension information element.
Where I can find the specifications for these information elements of AP beacon frames?
I have connected OBD2 and getting the can data (11bit 500kpbs CAN) using atmel can controller.
I get data.
Now, how do I get the mode and PIDs from this data?
For example, my data looks like this:
15164A8A-FF088B52 -- Data: 00,00,00,86,9C,FE,9C,FE,
I could see RPM changing, ignition on/off etc... on the data fields.
I don't want to use ELM chips. I need to handle the raw data directly.
HINT: All of my numbers are in HEX.
OBD2 protocol sends you responses in bytes (8 bits). responses are subdivided into header (or called ID as well) and data.
IDs are the address of the ECU and data is "response data" from ECU and it is always 8 bytes (in CAN Bus protocol?!).
8 Bytes of data will be divided into PCI (which can be one or two bytes) and values. PCI will show you what is your frame type (single, First, consecutive or flow control frame) and how many bytes are incoming.
to make it easier I make an example only for single frame:
you might send an OBD request to main ECU like this:
7DF 02 01 0C 00 00 00 00 00
7DF is ECU address for diagnose tester device.
02 is number of sending data bytes
01 is the mode (which you might be interesting in!) 01 is current data, 02 is freeze frame and etc.
0C is rpm PID.
The response from ECU would be something like (single frame):
7E8 04 41 0C 12 13 00 00 00
7E8 is the ECU that responding.
04 number of incoming data bytes.
41 the data are in response to 01 PID
0C response to this PID
12 13 are two byte in response to 0C. Please keep in mind that you have to decode these two bytes with OBD II ISO protocol. you can also find some of conversion rates on Wikipedia.
Other bytes are useless.
To make it short: you have to parse each response from ECU and try to convert the useful bytes to readable decimal value. It depends on which programming language you are using. in C/C++ the best practice in my opinion would be unsigned char which is guaranteed by compiler to be 8 bits and in JAVA it can be Byte. Moreover, try to use bitwise operators to make your life a bit easier.
By more questions do not hesitate to ask.
I am integrating an iOS app with a Bluetooth chip.
I am trying to understand the differences between a constant BLE connection and an iBeacon notifications in terms of the protocol.
So I am able to connect to the chip and send/recieve data from/to iPhone.
To communicate , you need 3 things :
name
service UUID
characteristic UUID (to write and read from).
Then, when you want to register to a region of an iBeacon, you also need a UUID of the characteristic, but also major/minor values.
Thing is, all iBeacon apps will not detect this type of broadcast- the one I use for communication.
So, whats basically the difference in the protocol? what if I keep advertising the same service/char I use for regular communication? is it good also for beacon push notification ? apparently not- but whats the different?
Also, I have 2 hardware chips, both will not let you set a major/minor values, but only to update the characteristic to notify a new value to subscribers which is hex (not an integer like major/minor) - is that equivalent to an iOS push notification by iBeacon detection ??
Difference between constant BLE connection and Beacons
A "constant BLE connection" is a connection, two devices pair with each other.
A BLE iBeacon device does not know about other devices. It simply broadcasts a certain signal frequently. Other devices can than listen to this signal and evaluate the signals strength to estimate how nearby the sender might be.
"Is it equivalent to Push Notifications?"
No.
Major & Minor
The major number (2 bytes) is used to group a related set of beacons. For example, all beacons in my flat will have the same major number, while the neighbour uses his own. That way the application know in which specific flat the application is.
The minor number (2 bytes) is used to identify the actual beacon. Each beacon in my flat has a different minor number, so that you know where within my flat the application is.
" value to subscribers ... is hex ... not an integer"
An hexadecimal is an integer.
HowTo
You need to insert a specific set of bytes into the optional manufacturer specific Data field (your "new value" for subscribers).
According to this site, you need the following values:
ID (uint8_t)
Data Length (uint8_t) - The number of bytes in the rest of the payload = 0x15
128-bit UUID (uint8_t[16]) - The 128-bit ID identifying the Beacons manufacturer
Major (uint16_t) - The major value
Minor (uint16_t) - The minor value
TX Power (uint8_t) - This value is used to try to estimate distance based on the RSSI value
Example from this site:
0x02 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 00 00 00 00 C8 00
0x02
0x0008
1E 02 01 1A 1A FF 4C 00 02 15 Manufacturer
00 00 Major
00 00 Minor
C8 00 Power
My project contains a Sender/Receiver framework that can only talk one-way , there is no a return channel from the receiver to the sender.
The sender compress part of the data it's send to the receiver using zlib.
I want to make my receiver resilient to crashes/reboots/restarts, is it possible to join the zlib stream from a random point somehow?
Both Sender/Receiver using Z_SYNC_FLUSH.
Some ideas I had:
Saving state structures to disk and reload them after restart of the receiver.
Replacing Z_SYNC_FLUSH to Z_FULL_FLUSH.
I tried saving the first chunk of zlib compressed data, restart the receiver and than resend the first chunk again and after that continue the stream from a random chunk and it seems to work - I don't understand why, is it a solid solution or it was just a luck?
Replacing to Z_FULL_FLUSH didn't seem to make any difference.
Is there another way to work around this? Do you think I missed something?
Thanks a lot,
Jason
To assure that you can start decompression at some point with no history, you must either use Z_FULL_FLUSH or simply end the stream and start a new one.
For the former you could do a Z_SYNC_FLUSH followed by a Z_FULL_FLUSH in order to insert two markers resulting in the nine bytes 00 00 ff ff 00 00 00 ff ff, which would be unlikely to be seen randomly in the compressed data. You can do the same for the latter, simply inserting a large-enough marker between the end of the previous zlib stream and the start of the next zlib stream.
While debugging on Windows XP 32-bit using the immunity debugger, I see the following on the stack:
_Address_ -Value_
00ff2254 ff090045
00ff2258 00000002
My understanding is that every address location contains 8 bits.
Is this correct?
If I'm understanding your question correctly, the answer is yes, every individual memory location contains 8 bits.
The debugger is showing you 4 bytes (32 bits) at a time, to make the display more compact (and because many data types take up 32 bits, so it's often useful to see 32-bit values). That's why the addresses in the left column are 4 locations apart.
If the debugger showed one byte (8 bits) at a time, the display would look like this:
_Address_ -Value_
00ff2254 45
00ff2255 00
00ff2256 09
00ff2257 ff
00ff2258 02
00ff2259 00
00ff225a 00
00ff225b 00
(assuming you're on a "little-endian" machine, which most modern desktop PCs are.)
I think the main problem with your question is that you ask for one thing, but I detect a different question lurking in the shadows.
First, and foremost, addressable entities in the memory of a computer is organized as bytes, which are 8 bits each, so yes, each address can be said to refer to 8 bits, or a byte.
However, you can easily group more bytes together to form bigger and more complex data structures.
If your question is really "Why am I seeing an 8-digit value as the contents at an address in my stack dump", then the reason for that is that it dumps 32-bit (4 bytes) values.
In other words, you can take the address, the address+1, the address+2, and the address+3, grab the bytes from each of those, and combine to a 32-bit value.
Is that really your question?
To complete the answer of RH, you may be surprised to have so many numbers for a given address.
You should consider
Address Byte (8 bits)
00ff2254 45
00ff2255 00
00ff2256 09
00ff2257 ff
00ff2258 02
...
(On a cpu architecture used by XP)
A memory location refers to a location of memory, and each consecutive memory location refers to the next byte in memory. So, you can only address memory on a one byte boundary, and everyone should know that a byte is 8 bits wide.