I was researching a few things about VLANs and came across the VLAN tag and also the headers.
If we have a MTU for a standard 802.3 Ethernet frame (1518 bytes) what is included in the header 802.3?
Also how do we calculate the header length for that?
What is the difference between 802.3 and 802.1q? I know that the VLAN tag requires extra bytes but how to calculate how many bytes needed to the 802.1q VLAN tag?
Thanks in advance
A regular 802.3/Eth-II ethernet frame doesn't carry VLAN info.
802.1Q can carry VLAN (and QoS) info over to the receiving end.
If the ethertype is 0x8100 then you got yourself an 802.1Q tag which is another 4 bytes in addition to the 14 bytes (dmac+smac+type).
See wikipedia for reference. http://en.wikipedia.org/wiki/Ethernet_frame
EDIT:
Regular Eth-II/802.3 has a total length of:
dmac(6)+smac(6)+etype(2)+payload(1500)+crc(4) = 1518 bytes
For the case of Eth-II/802.3 with 802.1Q tagging:
dmac(6)+smac(6)+8100(2)+vlan/Qos(2)+etype(2)+payload(1500)+crc(4) = 1522 bytes
Related
The safe size of a datagram packet (considering the MTU such that packet will not get fragmented) is said to be 576 bytes for IPV4 and 1500 for IPV6.
Is this correct ?
If i am having a connection from my machine to a server in another country, two of which communicate using UDP, what is the maximum (safest) payload size i should have for the UDP packet, 1500 or 576 ?
Thank you
No. That's the safe size of the total IP packet.
534.
I found the real IP address in my local network. Then, I used recommendations at "www dot asus dot com/support/FAQ/1007914" in order to "check the best value of MTU(Maximum Transmission Unit) for the internet".
I need a capture filter for wireshark that will match two bytes in the UDP payload. I've seen filters with
UDP[8:4]
as matching criteria but there was no explanation of the syntax, and I can't find it in any wireshark wiki (needle in the haystack thing).
I need to only capture UDP 5361, and only packets that have the bytes 8C:61 as the third and fourth bytes in the payload. Something like
udp port 5361 and udp[2:2]=8C:61
But I'm guessing at this of course. Thanks for any help...
Stumbled on it:
udp port 5361 and udp[10:2]==0x8C61
UDP data field (payload) starts at offset 8, and I'm looking at payload bytes 3 and 4. The tip was in WireShark Wiki, after all.
I encounter some problem when I develop a network card driver in Linux. As we all know the MTU refers to the MAX size of IP packet without fragment. And the skb sent to xmit function will be added 14bytes including dst mac addr,src mac addr and lengh. but it's very odd that when I use different values for MTU, the added size to it is different, sometime it's 10bytes, sometime it's 14bytes. It's depending the size of MTU. For example, I use 7828 as the size of UDP payload, when MTU is 7700, the size of skb in xmit function is 7714, while when MTU is 7800, the size of skb is 7810. Can anyone explain this? I guess maybe there are some align limitation for IP packets, but I didn't find that.
I searched the answer from the internet, and I found that there is an align limitation for payload field of IP frame. The payload field must be align to 8 bytes. So if the MTU is 7700, the true size of IP frame should be 7680+20 = 7700 because 7680 can be divisible by 8. While if the MTU is 7800, the true size of IP frame should be 7776+20 = 7796 because 7780 can't be divisible by 8, the last 4 bytes will be assigned to next IP fragment.
Im using UDP packets and I want to be cleared about some points :
1 - what exactly does "recvfrom" Returns ? I mean if i send a packet with size of 450 byte + 20 byte of IP header + 8 byte UDP header does recvfrom returns 478 bytes as a whole or there could be something like :
it received 10 bytes,300 bytes,100 bytes,68 bytes ?
2 - does the return value of "recvfrom" related to packet fragmentation ?
note :
* Im talking with the assumption that "recvfrom" was successful
* I chose 450 byte to be sure that Im less than the min MTU
For an UDP socket, recvfrom() reads the UDP data. So it returns 450 , provided you supply a buffer that is at least 450 bytes big.
If you supply a buffer that is smaller than the received data, the data will be truncated, and recvfrom() will read as much data as can fit in the buffer you give it.
The IP layer will be the part that fragments an UDP packet, on the receiving host it will reassemble it. This is transparent to the sending/receiving application.
There are few types of Ethernet but then also we have 2 bytes for Ethernet Type in the frame structure. Is this not a wastage of space by under utilization of space? I mean is 1 byte not enough to fit all the possibilities of Ethernet Types or is it some other reason?
One possible reason is that those 2 bytes could be the payload length if LLC encapsulation. if length only 1 byte, then it's too small.
Also from the perspective of byte alignment, all fields (except payload) are at least 16 bit aligned.
Look at http://en.wikipedia.org/wiki/Ethertype. It's protocol definition of that frame