how do you calculate length, fragment flag and fragment offset? - ip

The IP datagram with size 3700 bytes, including the header 20 bytes, arrives at a router. The MTU of the router’s outgoing link is 1300 bytes. State the value of length, fragment flag and fragment offset of all fragments created by the router.

Since the MTU is 1300 bytes, we can stuff in a maximum of 1300-20=1280 bytes of data per fragment. Our data is 3700-20 = 3680 Bytes.
So two fragments of 1280, and one fragment of 1120 Bytes will do.
1st Fragment: Length = 1300 Bytes. More Fragment Flag is set. The fragment offset is 0.
2nd Fragment: Length = 1300 Bytes. More Fragment Flag is set. The fragment offset is 1280/8 = 160.
3rd Fragment: Length = 1140 Bytes (1120+20). More Fragment Flag is not set since it is the last fragment. The fragment offset is 320.

Related

How do I read gyro information from CleanFlight using MSP?

Using an Arduino, how would I go about getting attitude from the gyro in my flight controller using MultiWii Serial Protocol?
The following is based on just getting gyro attitude information, although it includes some information about using MSP in general. The example code referenced can be found here. The most important part of this that I couldn't find anywhere else (a friend had figured it out and let me in on the secret) is the Data section below.
MultiWii Serial Protocol
Firstly, let's look at how MSP works. I found this link (alternative link here) very useful in understanding this, but I'll summarize here.
There are three types of message that can be sent.
Command -- a message sent to the flight controller which has some information to be sent.
Request -- a message sent to the flight controller asking for some information to be returned.
Response -- a message sent by the flight controller with information responding to a request.
MSP messages have a specific structure. They have a header, size, type, data and checksum, in that order.
I found this diagram from here very helpful:
Header
The header is three bytes and contains the message start characters "$M" and a character showing which direction the message is going. "<" denotes going to the flight controller (command and request), ">" denotes coming from the flight controller (response).
Size
The fourth byte is the length (in bytes) of the data section. For example, if the data section had three INT 16 variables then the size byte would be 6.
Type
The type byte specifies what information is being sent in the message. You can find a list of types here. An example of this would be MSP_ATTITUDE which has type number of 108.
Data
The data is where all the information is sent. Request messages have no data in them. Commands and responses do, because they contain information. The types of data returned can again be found here.
The difficult part of the data section is that the bytes are reversed in order, and this is extremely poorly documented. So, for example, if I get the following two bytes in this order:
10011010
01001111
You would think that should become 10011010 01001111 but in fact does not. It would actually become 01001111 10011010.
In the example code, this operation is done as follows:
int16_t roll;
byte c; // The current byte we read in.
c = mspSerial.read(); // The first sent byte of the number.
roll = c; // Put the first sent byte into the second byte of the int 16.
c = mspSerial.read(); // The second sent byte of the number.
roll <<= 8; // Move the first sent byte into the first byte of the int16.
roll += c; // Put the second sent byte into the second byte of the int 16.
roll = (roll & 0xFF00) >> 8 | (roll & 0x00FF) << 8; // Reverse the order of bytes in the int 16.
Checksum
The final byte of an MSP message is the checksum. "The checksum is the XOR of size, type and payload bytes". For a request message the checksum is equal to the type.
Example
An example response message for an "MSP_ATTITUDE" request would be as follows:
00100100 -- '$' - Byte 1 of the header.
01001101 -- 'M' - Byte 2 of the header.
00111110 -- '>' - Byte 3 of the header.
00000110 -- '6' - The size byte.
01101100 -- '108' - The type number corresponding to "MSP_ATTITUDE".
11100010 -- The first sent byte of the roll INT16.
11111111 -- The second sent byte of the roll INT16.
00010010 -- The first sent byte of the pitch INT16.
00000000 -- The second sent byte of the pitch INT16.
11000010 -- The first sent byte of the yaw INT16.
00000000 -- The second sent byte of the yaw INT16.
10100111 -- The checksum byte.
Roll would become: 11111111 11100010 = -30.
Pitch would become: 00000000 00010010 = 18.
Yaw would become: 11000010 00000000 = 194.
As documented here the roll and pitch are in units of 1/10th of a degree. So the final values would be as follows:
Roll = -3.0
Pitch = 1.8
Yaw = 194
Setting up CleanFlight
To get these values the flight controller must be correctly configured to use MSP. I'll assume you've already got CleanFlight Configurator running.
You may want to use the main Serial connection for something else while your code is running, so we'll use the Soft Serial 2 port for this (pins 7 and 8 on the left of the board).
Go to the "Configuration" tab and scroll down to "Other Features". Make sure "SOFTSERIAL" and "TELEMETRY" are on. Save and Reboot.
Go to the "Ports" tab and set the "Data" column for "SOFTSERIAL2" to be active and set to 9600 (you could also use 19200 if you so desired, higher values may not work on the Arduino end). Save and Reboot.
The flight controller is now correctly configured.
Setting up the Arduino
To setup the Arduino, simply upload the example code to the Arduino. Connect Pin 12 on the Arduino to Pin 7 on the left-hand side of the Naze board, and Pin 11 on the Arduino to Pin 8 on the left-hand side of the Naze board.
Opening a Serial connection to the Arduino should now output Roll, Pitch and Yaw.
Using for other MSP communication
Although the code here is an example using MSP_ATTITUDE, the same theory applies to any of the MSP communications. The main differences would be a command message requiring data to be setup correctly (I haven't tested the code with that purpose in mind), and the readData function would need to have the switch statement modified depending on the data being received.

how to read mavlink package .. is it ok to do it on my way?

i reading about MAVlink and i try to read packages from pixhawk fly controller.
I thought of another way to make the call and i want to know from this discussions readers if its ok and what are you think
On my reader .. i read the two first byte from the pixhawk.
The second byte need to be the PAYLOAD length --> so new i know that i need to read the 4 bytes of the header + PAYLOAD length bytes + 2 chcksub bytes.
So after reading the PAYLOAD length i define a byte array -> size is
( PAYLOAD.length + 4 + 2 ) and read from the serial to this buffer.
Is it ok to do it ?
The MAVLink protocol has HEADER + PAYLOAD + SIGNATURE format.
MAVLink v1.0
v1.0 is the standard protocol as specified by QGroundControl. It has the format:
6 bytes header
(PAYLOAD length) bytes payload
2 bytes signature (checksum)
The first byte is always the protocol start-of-frame: 0xFE
The second byte is always the payload length.
Hence your receive buffer size should be (PAYLOAD length) + 8.
The method you described will generally work for most packets received from the pixhawk. However, pixhawk (ArduPilot) makes use of an extended MAVLink protocol which has been coined "v2.0" which adds additional header and signature bytes.
MAVLink v2.0
v2.0 is the extended protocol which applies to a select few messages such as "STATUSTEXT". It has the format:
10 bytes header
(PAYLOAD length) bytes payload
15 bytes signature
The first byte has the start-of-frame: 0xFD
The second byte is again the payload length.
Hence, your buffer size should be (PAYLOAD length) + 25.
If you want to process MAVLink message data from the pixhawk, or from the generated .tlog file you should set your input message buffer size based on the start of frame and payload length bytes, the first two bytes of any MAVLink message.

Why is sk_buff->protocol stored in network endian order?

Since the sk_buff fields are processed locally it makes more sense to store it in the host order. Fields like sk_buff->vlan_tci are in host order. Is there a reason for storing some fields sk_buff->protocol, sk_buff->vlan_proto in network/big endian format ?
According to http://vger.kernel.org/~davem/skb.html page, protocol field of sk_buff IS used by network:
unsigned short protocol,
The 'protocol' field is initialized by routines such as 'eth_type_trans()'. It takes on one of the 'ETH_P_*' values defined in the 'linux/if_ether.h' header file. Even non-ethernet devices use these ethernet protocol type values to indicate what protocol should receive the packet. As long as we always have some ethernet protocol value for each and every protocol, this should not be a problem.
Also, the comment in skbuff.h says that protocol is from driver:
340 /**
341 * struct sk_buff - socket buffer
369 * #protocol: Packet protocol from driver
391 * #vlan_proto: vlan encapsulation protocol
392 * #vlan_tci: vlan tag control information
So, for incoming packet protocol is filled from the Ethernet packet field "TYPE" (ethertype, network endian)
http://en.wikipedia.org/wiki/Ethernet_frame :
Data on Ethernet is transmitted most-significant octet first. Within each octet, however, the least-significant bit is transmitted first.
Ethertype (Ethernet II) or length 2 octets
For outgoing packet it is filled by network stack and then used to fill the "TYPE" field.
vlan_proto is the copy of first protocol field from ethernet packet, usually 0x8100 when 802.1Q tagging used (http://en.wikipedia.org/wiki/EtherType list it as "VLAN-tagged frame (IEEE 802.1Q)"). And the second protocol field (after VLAN tag), will be used as real protocol. So, vlan_proto is also stored as network order because it is from/to network.
TCI (the information to store in vlan_tci) is also part of network 802.1q packet, it has 2 bytes (octets). But in processing of network fields, it is converted to host format by vlan_untag() in net/8021q/vlan_core.c:
118 struct sk_buff *vlan_untag(struct sk_buff *skb)
119 {
120 struct vlan_hdr *vhdr;
121 u16 vlan_tci;
135 vhdr = (struct vlan_hdr *) skb->data;
136 vlan_tci = ntohs(vhdr->h_vlan_TCI);
137 __vlan_hwaccel_put_tag(skb, skb->protocol, vlan_tci);
I think it is done to make bit operations on TCI easier. They are needed for getting PCP (3 bit), DEI (1 bit) and VID (12 bit) fields from TCI. There is also several additional flag, VLAN_TAG_PRESENT stored in vlan_tci by __vlan_hwaccel_put_tag
There is converting of host TCI to network for outgoing packets, vlan_insert_tag() from linux/if_vlan.h:
277 * Inserts the VLAN tag into #skb as part of the payload
278 * Returns a VLAN tagged skb. If a new skb is created, #skb is freed.
285 static inline struct sk_buff *vlan_insert_tag(struct sk_buff *skb,
286 __be16 vlan_proto, u16 vlan_tci)
287 {
300 /* first, the ethernet type */
301 veth->h_vlan_proto = vlan_proto;
302
303 /* now, the TCI */
304 veth->h_vlan_TCI = htons(vlan_tci);

What to return when range HTTP header requests last byte of file?

I need to handle the Range header programatically in Java for supporting media files on iOS.
If my file is 23843 bytes, for example, I'm getting a request with a range header:
Range: bytes 23842-23842
What am I meant to return in this case? Is it just the last byte of the file?
You should send the file from offset 23842 to offset 23842, so yes, that comes out as one byte.
The spec actually gives a similar example:
The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
(The important bit here being that 0-0 = first byte)

what is relation between content-length and byte ranges in HTTP/1.1?

I am not grasping the idea behind content-length and byte ranges as specified by HTTP 1.1
Is there are connection between the two of some sort? If a client requests in terms of byte ranges, say 0-100 out of 200, will the first response contain the "content-length" equal to 100 bytes followed by 100 actual data?
Thanks
The Content-Length entity-header field indicates the size of the entity-body […] sent to the recipient […]
In a non-multipart message the entity-body is the body of the HTTP message as it only contains one entity. So the Content-Length value indicates the length of the message body that is sent and not the size of the whole resource.
So for a partial content response on a 0-100 byte range request (first byte and last byte inclusive) the Content-Length of the response will be 0 ≤ size ≤ 101.
In case of a 12345 byte long resource the response could look like this:
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-100/12345
Content-Length: 101
… 101 bytes of content …

Resources