Skb- Data

[Eddie Boyum]

Typicallywhen building output packets, we reserve enough bytesfor the maximum amount of header space we think we'll need. MostIPV4 protocols can do this by using the socket valuesk->sk_prot->max_header.

When setting up receive packets that an ethernet device will DMA into,we typically call skb_reserve(skb, NET_IP_ALIGN). By defaultNET_IP_ALIGN is defined to '2'. This makes it so that,after the ethernet header, the protocol header will be aligned onat least a 4-byte boundary. Nearly all of the IPV4 and IPV6 protocolprocessing assumes that the headers are properly aligned.

skb_put() advances 'skb->tail' by the specified number ofbytes, it also increments 'skb->len' by that number of bytes as well.This routine must not be called on a SKB that has any paged data.You must also be sure that there is enough tail room in the SKB forthe amount of bytes you are trying to put. Both of these conditionsare checked for by skb_put() and an assertion failure willtrigger if either rule is violated.

skb_push() will decrement the 'skb->data' pointer by thespecified number of bytes. It will also increment 'skb->len' bythat number of bytes as well. The caller must make sure there isenough head room for the push being performed. This condition ischecked for by skb_push() and an assertion failure willtrigger if this rule is violated.

Things start to get a little bit more complicated once paged databegins to be used. For the most part the ability to use [page,offset, len] tuples for SKB data came about so that file systemfile contents could be directly sent over a socket. But, as it turnsout, it is sometimes beneficial to use this for nomal buffering ofprocess sendmsg() data.

It must be understood that once paged data starts to be used on anSKB, this puts a specific restriction on all future SKB data areaoperations. In particular, it is no longer possible to doskb_put() operations.

We will now mention that there are actually two length variablesassosciated with an SKB, len and data_len. Thelatter only comes into play when there is paged data in the SKB.skb->data_len tells how many bytes of paged data thereare in the SKB. From this we can derive a few more things: The existence of paged data in an SKB is indicated byskb->data_len being non-zero. This is codified inthe helper routine skb_is_nonlinear() so that it thefunction you should use to test this. The amount of non-paged data at skb->data can becalculated as skb->len - skb->data_len. Again, thereis a helper routine already defined for this calledskb_headlen() so please use that.The main abstraction is that, when there is paged data, thepacket begins at skb->data for skb_headlen(skb)bytes, then continues on into the paged data area forskb->data_len bytes. That is why it is illogical to tryand do an skb_put(skb) when there is paged data. You haveto add data onto the end of the paged data area instead.

The paged frags are organized into an array in the sharedSKB area, defined by this structure:#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 2)struct skb_shared_info atomic_t dataref;unsigned intnr_frags;unsigned shorttso_size;unsigned shorttso_segs;struct sk_buff*frag_list;skb_frag_tfrags[MAX_SKB_FRAGS];;The nr_frags member states how many frags there areactive in the frags[] array. The tso_sizeand tso_segs is used to convey information to thedevice driver for TCP segmentation offload. The frag_listis used to maintain a chain of SKBs organized for fragmentationpurposes, it is _not_ used for maintaining paged data. Andfinally the frags[] holds the frag descriptors themselves.

A helper routine is available to help you fill in page descriptors.void skb_fill_page_desc(struct sk_buff *skb, int i,struct page *page,int off, int size)This fills the i'th page vector to point to pageat offset off of size size. It also updates thenr_frags member to be one past i.

With all of the complications imposed by non-linear SKBs, it mayseem difficult to inspect areas of a packet in a straightforwardway, or to copy data out from a packet into another buffer. Thisis not the case. There are two helper routines available whichmake this pretty easy.

You are returned a pointer to the data item, or NULL if you askedfor an invalid offset and len parameter. This pointer could beone of two things. First, if what you asked for is directly inthe skb->data linear data area, you are given a directpointer into there. Else, you are given the buffer pointer youpassed in.

For larger pieces of data other than protocol headers, it maybe more appropriate to use the following helper routine instead.int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len);This will copy the specified number of bytes, and the specifiedoffset, of the given SKB into the 'to'buffer. Thisis used for copies of SKB data into kernel buffers, and thereforeit is not to be used for copying SKB data into userspace. Thereis another helper routine for that:int skb_copy_datagram_iovec(const struct sk_buff *from, int offset, struct iovec *to, int size);Here, the user's data area is described by the given IOVEC.The other parameters are nearly identical to those passed into skb_copy_bits() above.

As you can see, this function is straightforward. The result is offset from the sk_buff memory start (head) by some value from the mac_header variable. This variable initialized during packet reception in a driver (or in the stack during packet generation and transmission).

To analyze this data with Wireshark (which is very handy), we need to copy this text in some text files (for example, packet_dump.txt), remove timestamps, and convert this text into binary pcap format.

Our data protection guidelines regulate how we process your personal data to comply with the General Data Protection Regulation* (also known as GDPR) when you visit our websites, our facilities or are in contact with us in some other way.

Below we describe the principles on which our data protection guidelines for processing your personal data are based. You can find more detailed information about our processing of personal data here.

Your personal data will be collected on a legal basis, i.e. either via consent, an agreement between us, a legal basis or a balance of interests. Employee personal data is collected primarily on the basis of your employment contract and our obligation to comply with laws, regulations and collective agreements.

Collected personal data must be correct and, where possible, fully updated. The personal data collected is the information you provide when registering. Depending on the personal data processing in question, the personal data submitted may be reviewed to ensure your identity. You can at any time make corrections to your personal data, for example in the event of a name change, address change, etc.

All personal data will be treated confidentially. SKB guarantees confidentiality through well-established security procedures with different employee authorisation classifications, where only those who need to process your personal data will do so. SKB also conducts ongoing employee training and provides information on how personal data may be collected, processed and handled.

The Swedish Nuclear Fuel and Waste Management company is the personal data controller. You can reach us at personu...@skb.se or +46 (0)8 459 84 00. You are welcome to contact us if you want to know more about how we process your personal data, want to correct it, want it deleted or want to know what personal data we have saved about you. You can read more about your rights here.

You are always entitled to lodge a complaint if you believe that we are not processing your personal data in accordance with applicable regulations. The supervisory authority is Integritetsskyddsmyndigheten (Data Protection Authority).

Our mission is to deal with all the radioactive waste from the nuclear power plants in Sweden. In doing so we must meet the most stringent requirements regarding the safety of human beings and the environment.

Effective date: June 12, 2018

SKB Cases ("us", "we", or "our") operates the website (the "Service").

This page informs you of our policies regarding the collection, use, and disclosure of personal data when you use our Service and the choices you have associated with that data.

We use your data to provide and improve the Service. By using the Service, you agree to the collection and use of information in accordance with this policy. Unless otherwise defined in this Privacy Policy, terms used in this Privacy Policy have the same meanings as in our Terms and Conditions, accessible from

Service is the website operated by SKB Cases.

Personal Data means data about a living individual who can be identified from those data (or from those and other information either in our possession or likely to come into our possession).

Usage Data is data collected automatically either generated by the use of the Service or from the Service infrastructure itself (for example, the duration of a page visit).

Cookies are small pieces of data stored on your device (computer or mobile device).

Data Controller means the natural or legal person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal information are, or are to be, processed. For the purpose of this Privacy Policy, we are a Data Controller of your Personal Data.

Data Processors (or Service Providers) means any natural or legal person who processes the data on behalf of the Data Controller.

Data Subject (or User) is any living individual who is using our Service and is the subject of Personal Data.

Personal Data

While using our Service, we may ask you to provide us with certain personally identifiable information that can be used to contact or identify you ("Personal Data"). Personally identifiable information may include, but is not limited to:

3a8082e126