Hi I expect the answer here to be YES! but I just need a sanity check. I've been using wireshark to analyse packets coming to my server. My server uses Java NIO to process incoming bytes using a ByteBuffer. I was seeing some irregular looking data coming in on the socket, and I thought I missing some. What I'm doing is flashing a firmware over the air, to do this I send a command, wait for an ACK from the bootloader, send another command, wait for an ACK... and so on. However, on the very first command I didn't get an ACK (or a NACK). So while testing, I decided to not wait for the first ACK and just carry on with the process. Everything else worked as expected. This was a few months ago. Our firmwares have since been upgraded, so I decide to test again and verify everything is the same. I do some tests in wireshark to see if there's an extra ACK in there. I figure I need to run wireshark an see if it's arriving and I'm trying to read it too quickly or something. Send instruction 1 The buffer size being read/written by the server is two bytes, with each instruction being a 1 byte instruction and a 1 byte checksum, each ACK/NACK is 1 byte. Now, here's where it gets odd, if I set the server to check for an ACK after the first instruction too with this new firmware (as it ideally should) then I get the following: Send instruction 1 So, I was initially expecting the server to wait for an ACK/NACK on the first instruction and not proceed beyond that point, like it did with the original firmware, but that isn't the case. Is it guaranteed that these two ACKs being sent from the bootloader are actually being sent together? or is it possible they're sent separately and I'm doing something serverside that makes it look like they arrive together? The reason I'm asking is because I would expect the two ACKs to arrive after instruction 2, but they don't. asked 02 May '16, 06:42  elektrovert edited 02 May '16, 06:43 |
2 Answers:
To answer the question itself: if you really mean bytes in a packet, then it is 100% true, as Wireshark handles a packet (well, frame) as an indivisible unit. If an IP packet is fragmented into several frames, Wireshark shows you each of those frames, with individual timestamps. The reassembled packet is shown in the dissection & packet bytes pane of the last frame, but with just a little extra effort you can still tell which of the reassembled packet's bytes has arrived in which frame. So if both bytes share the same frame, there is no way how Wireshark could mislead you. If they don't (which you may encounter as well), the situation is slightly more complex, because libpcap/WinPcap doesn't assign the frame timestamp at the moment of physical arrival of the packet to the Ethernet/802.11 interface but as late as when the kernel fetches it from the buffer and "shows" it to libpcap/WinPcap. So if the kernel is busy, several frames may wait in the NIC's buffers, and then the kernel fetches them almost at the same time. In this case, their order of arrival is still kept, but the timestamp resolution may be so coarse that they'll all get the same timestamp value. But the information about the order is only reliable for frames going the same direction. Hypothetically, you could see a sent frame with a timestamp lower than the timestamp of a received frame which has actually arrived earlier than the sent frame has been sent - that could happen if the kernel has first sent the frame and only then has looked into the receive buffer. answered 02 May '16, 07:08  sindy edited 02 May '16, 07:40 |
The answer is yes, and that's the beauty of it: It shows you what's actually going on in the network. Mind you, this is at the lowest level of the network, so to get here your data has to traverse the socket layer, TCP/IP stack and get to the network driver before being picked up for capture. Same goes for packet reception. The capture takes place at the lowest level, after which the packets with your data has to move up all the way through the TCP/IP and socket layer to your application. And all these layers can have buffers, which influence when the data is handled. The specifics of these are out of scope of this site, but looking at socket options should get you on you way. answered 02 May '16, 07:16  Jaap ♦ |
As you say each ACK/NAK is 1 byte, I suppose they all look the same, i.e. you cannot tell which ACK acknowledges which forward message, right? So I would expect that you send the 2nd forward message too early and thus the ACK for the 1st one arrives later and so on, and only between the 3rd and 4th forward message things settle down because the target manages to send two ACKs before the server sends the 4th forward message.
To confirm that, if you can affect the code at server side that deep, try to delay the 2nd forward message for long enough to give the ACK a chance to arrive, but don't trigger its sending by reception of the ACK, just wait.
Yes, thanks, that's my next step. I expect that this is the case, just needed to be sure.