When reading through the Ethernet frame format in IEEE 802.3 , the EtherType was explained as below:
0 - 1500 (Decimal) comes under packet data payload length.
1536(0x600) and above it means the value is determining the type of the frame.(Eg. 0x800 stands for IPV4)
What about the values in between 1501 to 1535? Why these values been left off?
Note: On the Wiki link it is been mentioned it is not defined. But not finding as explanation in any standardized documents.
These values are reserved to avoid ambiguity (e.g. when 802.1Q tagging is used, slightly increasing the frame size).
Using the Ethertype field for the frame length is obsolete though, Ethernet II framing (using the Ethertype field to indicate the protocol carried as payload) far outnumbers any other frame type. Instead, the length of the frame is indicated by carrier loss or a special end-of-frame symbol, depending on the PHY in use.
Related
In the document,
PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot (Initialization Configuration) Firmware
it says, for the Memory Space,
The encoding of the base address registers for Memory Space allows a
resource to require address allocation within the first 1 MB. This
requirement is reflected in the "reg" property entry for that base
register by having the 't' bit set.
Also, for the IO space,
PCI also allows devices to have I/O base address registers that
implement only the low-order 16 bits. I.e., the upper 16 bits are
assumed to be 0. When probing, after writing all 1s, the data read
back will have the high-order 16 bits equal to 0, while the low-order
16 bits will reflect the address space requirement.
Address space for such a base register must be allocated within the
first 64 KB of I/O Space. This requirement is reflected in the "reg"
property for that base register by having the 't'-bit set.
But what is this 't' bit? The document later says about PCI address representation that uses 3 bit 'npt' values. I already knew for specifying "ranges" property, the child address (PCI address) uses 3 cells and the first 32bit contains 'n','p','t' bits at the MSB bits to express non-relocatable, prefetchable and the type(meaning varies according to address space type). But "reg" property in dts normally represents the register regions representing the start and size and doesn't use this npt values but just physical address. So I'm confused. https://elinux.org/Device_Tree_Usage#PCI_Address_Translation)
If the datagram bigger than MTU， 2 layer switch will drop it? Dose 2 layer switch can report a ICMP? If not report ICMP, how can I determine the data size to pass the switch successfully?
If the datagram bigger than MTU， 2 layer switch will drop it?
Yes. A switch does not forward frames larger than the (configured) maximum size and drops them. For standard Ethernet, that's 1500 bytes payload plus 18 bytes L2 overhead. Note that MTU is an L3 term referring to the maximum packet size that an underlying network can transport.
Does 2 layer switch report a ICMP?
No. A layer-2 switch generally sends no ICMP messages nor is there an ICMP message to report oversized frames in L2.
A layer-3 switch used as gateway should return an ICMP Fragmentation required when the destination network's MTU does not admit the IP packet without fragmentation and its DF bit is set or IPv6 is used. For IPv4 without DF, the gateway just fragments the packet.
If not report ICMP, how can I determine the data size to pass the switch successfully?
On an unmanaged switch, see above for the maximum standard size. A few support jumbo frames, check their documentation. On some managed switches you can configure the maximum frame size globally or by VLAN. Methods and syntax vary.
I am currently using libopus in order to encode some audio that I have.
When consulting the documentation for how to use the encoder, one of the arguments the encode function takes in is max_data_bytes, a opus_int32 that has the following documentation:
Size of the allocated memory for the output payload. May be used to impose an upper limit on the instant bitrate, but should not be used as the only bitrate control
Unfortunately, I wasn't able to get much out of this definition as to how to set the upper size and the relation of this argument to bitrate. I tried consulting some of the examples provided such as this or this but both have the argument defined as some constant without much information.
Could anyone help me understand the definition of this value, and what number I might be interested in using for it? Thank you!
Depends on encoder version and encoding parameters.
In 1.1.4 the encoder doesn't merge packets and the upper limit should be 1275 byte. For the decoder, if repacketizer is used, you could find some packet up to 3*1275.
Things could be changed in recent version, I'm quite sure that the repacketizer has been somehow merged in the encoder. Look into the RFC.
Just paste here some of my notes from a 1½ years ago...
//Max opus frame size if 1275 as from RFC6716.
//If sample <= 20ms opus_encode return always an one frame packet.
//If celt is used and sample is 40 or 60ms, two or three frames packet is generated as max celt frame size is 20ms
//in this very specific case, the max packet size is multiplied by 2 or 3 respectively
Let's take a sample write packet : Suppose that the CPU wrote the
value 0x12345678 to the physical address 0xfdaff040 using 32-bit
addressing
This example is from this site (I didn't understand the explanations in the original post)
Why does the address start at the second bit [31 : 2]
Why isn't the address the same
An address of an aligned, 32-bit chunk always has two zero bits at the end of the address. You can think of this as either writing the address of the chunk to the 32-bit slot or as writing the addresses divided by four to bits 2 through 31 of the address. The result is the same either way since dividing by four is equivalent to shifting two bit positions to the right.
This is wikipedia's explanation of the length field of the UDP header:
Length
A field that specifies the length in bytes of the UDP header
and UDP data. The minimum length is 8 bytes because that is the length
of the header. The field size sets a theoretical limit of 65,535 bytes
(8 byte header + 65,527 bytes of data) for a UDP datagram. The
practical limit for the data length which is imposed by the underlying
IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP
header).
The practical limit for the data length should minus 20 byte IP header, why is that?
Take a good look at the explanation of the IP header at this link :
https://www.ietf.org/rfc/rfc791.txt
I quote :
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams.
The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols.
So the maximum total length is 65535 but this includes the IP header itself.
Therefore you have an IP payload that can be 65535 - 20 = 65515.
But the payload of IP in your case is UDP and UDP has a header of its own which is 8 bytes. Hence you get to the theoretical limit of the payload of a UDP packet : 65,535 − 8 byte UDP header − 20 byte IP header
Note the use of theoretical instead of practical. The practical limit of a UDP packet takes into account the probability of fragmentation and thus considers the mtu of the network layer. The link above also has an interesting sentence containing the value 576. 576 - 20 - 8 = 548 which is not quite 534 but getting close. This might explain this practical limit.
Because UDP packets are encapsulated in IP packets which headers are 20 bytes. You can't send UDP packets without a encapsulated IP packet. Usually the actual limit is way less and it depends on the MTU of the routers between the two endpoints transmitting the UDP packet.
Because the IP header has to be (a) sent and (b) counted in the 16-bit length word. See RFC 791 #3.1.
However the real practical limit is generally accepted to be 534 bytes, to avoid fragmentation at the IP layer, which increases the risk of datagram loss.