I'm reading on this topic, and I just found that IP headers, or even TCP headers, can be of variable length.
I thought routers will use a known length, divided into segments of a known format, to do whatever they do. So, how can you know which segements of bits mean what, if the length of the header is variable?
The way I understand it, is that the Options field at the end of the header determines the total length of the header (present if the Length field value > 5). The Length field has a minimum value of 5 (no options present) and a maximum of 15. This indicates a header length from 20 bytes (5 × 32 bits) to 60 bytes (15 × 32 bits). As all other fields apart from the Options field have a fixed length, it is clear where the header ends and where a given field is supposed to be. The Option field in itself also includes a Option length field for determining the length of Option data.
Related
I checked the storage size but I'm confused when it comes to storing numbers.
In case of Bytes, what does "Byte length" mean? If I store -128 what's the length? And in case of 12?
In case of Floating-point number and Integer, it doesn't matter if I store 325 or 9.9999999999999 it will always be 8 bytes?
In case of Array? Let' say we have ["ab", "bcd"], what's the size, (2+3=5) or (2+1)+(3+1)=7
If you store an array of bytes, the size will simply be the length of that array. An array with a single byte value of -128 is still just one byte.
Yes, all numbers occupy the same 8-byte size, even if you don't see a fractional part.
The documentation says it's the sum of the array element sizes, so I would expect 7, the sum of the two individual string sizes, each encoded in UTF-8 + 1
spend couple of hours looking for tcpdump filter to get all packets with tcp option kind equals to x ( specifically 8 ). Wireshark's filter is simply tcp.option_kind == 8.
After reading https://www.wains.be/pub/networking/tcpdump_advanced_filters.txt tried using 'tcp[22] =8' with no luck
Your assistance will be appreciated :) Thanks
I only have a partial answer for you. If the option you're looking for happens to always be the 1st TCP option, then you can use the following filter:
"(((tcp[12] & 0xf0) >> 2) > 20) && tcp[20] = 8"
What does this filter do? This filter isolates the data offset field (i.e., the TCP header length) to first ensure that the TCP header contains any options at all. Since the data offset field comprises only the 1st 4 bits of the byte at offset 12 of the TCP header, we have to isolate those bits by applying a mask of 0xf0. Next, the value is shifted 4 bits to the right to convert this to a number we can use and then multiplied by 4 (or shifted back to the left 2 bits) since the data offset represents the number of 32-bit words of the header. The equivalent of shifting right by 4 and then left by 2 is simply to shift right by 2. If the data offset value is greater than 20 bytes, then we know that some TCP options are present and we can compare the byte at offset 20, which is the location of the 1st option's "kind" field, to the TCP option kind of interest, in this case 8, which is the timestamps option.
Again, the above filter will only work if the TCP option of interest is always the 1st option. If the option occurs after other options, it will fail to capture those packets. Expanding this filter to capture the TCP option of interest regardless of its location may be possible, but I don't think it will be easy to do.
what will happen when Total Length field value in IPv4 header is smaller than length of ethernet frame? How will behave a device when receive that kind of frame? Device recognized frame as invalid due to inconsistency and rejected it?
Second situation, max ethernet frame length is 1518 bytes - what will happen when I extend this frame and add additional 2 bytes. Assuming that IPv4 total length match length of extended frame.
Thanks.
The value of the Total Length field in an IPv4 header must be smaller than the frame length; anything else is a sign of corruption. The IPv4 packet is the payload of the frame, so the frame length is the total packet length plus the frame header and trailer.
I've understood that an USSD message consists of 160 bytes. For 7 bit data coding schemes, the maximum number of characters is 160*8/7 which gives 182 characters. It's unclear to me what is the maximum number of characters for UCS2 encoding. Normally, it would be something like 160/2, but I have some mixed information on this.
The maximum size of a USSD message is 160 bytes. For GSM 7 Bit messages you are correct in saying the limit is 182 characters. UC2 encoding per definition is fixed 2 bytes per character so you will have a maximum of 80 characters.
I am simulating the IEEE802.11b PHY Model. I am building the header of the Packet in the Physical Layer.
As per the Literature
The PLCP LENGTH field shall be an unsigned 16-bit integer that indicates the number of microseconds to transmit the PPDU.
If I assume the packet size to be 1024Bytes, what should be the value of the Length field(16 bit wide)
The calculation of the LENGTH field depends on the number of bytes to send, as well as on the data rate (5.5 or 11 Mbps). The basic idea of the calculation is:
Bytes * 8
LENGTH = Time (µs) = ----------------
Data rate (Mbps)
However, you need to read Section 18.2.3.5, Long PLCP LENGTH field in the 802.11b-1999 Standard, pages 15-17. It has the complete details of how to calculate this value, along with several examples. It unambiguously explains how to properly round the data, as well as when the length extension bit in the SERVICE field should be set.
I will not reproduce the text of the section here since it looks like IEEE might be strict about enforcing their copyright. However, if you don't have the standard already, I suggest you download it now from the link above -- it's free!
If you have any questions about interpreting the standard, don't hesitate to ask.