Fragmented TCP/IP packets malformed

Using RCM3000, DC 9.21.

Is it normal when sending a single character to a socket that the
packet length is set to 1, but that there are 5 additional bytes of
data in the packet? Wireshark flags the packet as "malformed", but's
it's unclear if this is because of the data length discrepancy or
because the port number of 2000 is used, which is apparently a Cisco
port number, and wireshark is reacting to that.

char ch = '6';

sock_write(socket, ch, 1);

Steve

Start a New Thread

Hi Steve

The minimum packet size allowed for an ethernet frame is 64 bytes. Without VLAN tagging, if you take away the ethernet header and CRC you have a minimum data payload of 46 bytes.

The IP header is 20 bytes and the minimum TCP header is also 20 bytes. This leaves 6 bytes one of which is your data and the other 5 are padding to bring the payload up to the required minimum.

Can you post some samples of the Wireshark captures?

Regards
Peter Start a New Thread

That was good information. The frame size is "60 bytes on wire" as
reported by wireshark. I can't figure out how to copy and paste from
wireshark, so I saved the packet/frame to a text file and pasted it
in below. It's only raw bytes, so it's not easy to read. The 6th byte
from the end, "15", is the one byte that was sent, and the last 5 are
the padding. Any reason why the padding bytes are the values they are?
I would have expected filler bytes to be either zeros or all ones.

02:52:24,352,530 ETHER
|0 |00|1c|23|01|07|d3|00|90|c2|e0|21|46|08|00|45|00|00|29|5a|e2|00|00|40|06|fb|32|0a
|fa|07|36|0a|fa|07|91|07|d0|07|f9|54|ba|75|de|45|7e|e6|3c|50|18|07|fe|67|f6|00|00|15
|c3|08|00|13|1c|

Steve Start a New Thread

Hi Steve,

The simplest way to do it is to use the "save as" option and create a small pcap file with just one or two of the packets that can then be opened in wireshark to show exactly what is there.

The network drivers can also play tricks here as Wireshark typically does not get the ethernet CRC for example and so shows 60bytes captured on many systems. On one of my PCs it looks like the network driver also strips out padding before passing them to Wireshark and I see even smaller packets.

Regards,
Peter Start a New Thread

Oh, and another thing - the random values for the padding is probably because the Rabbit Network does not zero the buffer before constructing the packet to speed up the network code. Most "bigger" systems send nice 0s as it is considered a potential security issue to leak internal memory contents onto the wire.

Regards,
Peter Start a New Thread

As I study this more, I'm beginning to think that I really don't
have a fragmented packet.
What the code does is (this is someone else's code), rather than
build a string and send it with a single call to sock_write(),
it makes multiple calls to sock_write() with each call containing
a portion of the complete message.
For example, if the string "Hello world" were being sent, it would
do something like this:

char start, end;
start = 2; // ASCII STX
end = 3; // ASCII ETX

sock_write(socket, &start, 1);
sock_write(socket, "Hello", 5);
sock_write(socket, " ", 1);
sock_write(socket, "world", 5);
sock_write(socket, &end, 1);

What happens is that the single "start" character is sent in one
packet, and the rest of the message is sent in a second packet.
Interestingly, according to wireshark logs, both packets have always
had the same sequence number. Which seems odd. I would expect
different sequence numbers. Does anyone know why that is?

Could this method of transmission potentially cause problems at the
receiving end? Since there is no guarentee that packets will be
received in the right order, and since, technically, this is not one
message that has been fragmented, the receiving host has no reason
to reassemble the packets. Am I understanding this correctly?

Steve Start a New Thread