| TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2004.
Copyright © The Internet Society (2004). All Rights Reserved.
This document describes a format to dump captured packets on a file. This format is extensible and it is currently proposed for implementation in the libpcap/WinPcap packet capture library.
1.
Objectives
2.
General File Structure
2.1.
General Block Structure
2.2.
Block Types
2.3.
Logical Block Hierarchy
2.4.
Physical File Layout
2.5.
Options
2.6.
Data format
3.
Block Definition
3.1.
Section Header Block (mandatory)
3.2.
Interface Description Block (mandatory)
3.3.
Enhanced Packet Block (optional)
3.4.
Simple Packet Block (optional)
3.5.
Packet Block (obsolete!)
3.6.
Name Resolution Block (optional)
3.7.
Interface Statistics Block (optional)
4.
Experimental Blocks (deserved to a further investigation)
4.1.
Alternative Packet Blocks (experimental)
4.2.
Compression Block (experimental)
4.3.
Encryption Block (experimental)
4.4.
Fixed Length Block (experimental)
4.5.
Directory Block (experimental)
4.6.
Traffic Statistics and Monitoring Blocks (experimental)
4.7.
Event/Security Block (experimental)
5.
Recommended File Name Extension: .pcapng
6.
How to add Vendor / Domain specific extensions
7.
Conclusions
Appendix A.
Packet Block Flags Word
Appendix B.
Standardized Block Type Codes
Appendix C.
Standardized Link Type Codes
Appendix D.
Link Layer Headers
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The problem of exchanging packet traces becomes more and more critical every day; unfortunately, no standard solutions exist for this task right now. One of the most accepted packet interchange formats is the one defined by libpcap, which is rather old and does not fit for some of the nowadays applications particularly from the extensibility point of view.
This document proposes a new format for dumping packet traces. The following goals are being pursued:
| TOC |
| TOC |
A capture file is organized in blocks, that are appended one to another to form the file. All the blocks share a common format, which is shown in Figure 1 (Basic block structure.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Block Body / / /* variable length, aligned to 32 bits */ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 1: Basic block structure. |
The fields have the following meaning:
This structure, shared among all blocks, makes it easy to process a file and to skip unneeded or unknown blocks.  Some of the blocks are mandatory, i.e. a dump file is not valid if they are not present, other are optional.
The General Block Structure allows defining other blocks if needed. A parser that does non understand them can simply ignore their content.
| TOC |
The currently standardized Block Type codes are specified in Appendix B (Standardized Block Type Codes), they have been grouped in the following four categories:
MANDATORY blocks must appear at least once in each file:
OPTIONAL blocks can appear in a file:
OBSOLETE blocks should not appear in newly written files (but left here for reference):
EXPERIMENTAL blocks are considered interesting but the authors believe that they deserve more in-depth discussion before being defined:
| TOC |
The blocks build a logical hierarchy as they refer to each other. Figure 2 (Logical block Hierarchy of a pcapng file.) shows the logical hierarchy of the currently defined blocks in the form of a "tree view":
Section Header | +- Interface Description | +- Simple Packet | +- Enhanced Packet | +- Interface Statistics | +- Name Resolution
| Figure 2: Logical block Hierarchy of a pcapng file. |
For example: each captured packet refers to a specific capture interface, the interface itself refers to a specific section.
| TOC |
The file must begin with a Section Header Block. However, more than one Section Header Block can be present on the dump, each one covering the data following it till the next one (or the end of file). A Section includes the data delimited by two Section Header Blocks (or by a Section Header Block and the end of the file), including the first Section Header Block.
In case an application cannot read a Section because of different version number, it must skip everything until the next Section Header Block. Note that, in order to properly skip the blocks until the next section, all blocks must have the fields Type and Length at the beginning. This is a mandatory requirement that must be maintained in future versions of the block format.
Figure 3 (File structure example: Typical configuration with a single Section Header Block.) shows a typical file configuration, with a single Section Header that covers the whole file.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHB v1.0 | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 3: File structure example: Typical configuration with a single Section Header Block. |
Figure 4 (File structure example: three Section Header Blocks in a single file.) shows a file that contains three headers, and is normally the result of file concatenation. An application that understands only version 1.0 of the file format skips the intermediate section and restart processing the packets after the third Section Header.
|-- 1st Section --|-- 2nd Section --|-- 3rd Section --| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 4: File structure example: three Section Header Blocks in a single file. |
Figure 5 (File structure example: a pcapng file similar to a classical libpcap file.) shows a file comparable to a "classic libpcap" file - the minimum for a useful capture file. It contains a single Section Header Block (SHB), a single Interface Description Block (IDB) and a few Enhanced Packet Blocks (EPB).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHB | IDB | EPB | EPB | ... | EPB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 5: File structure example: a pcapng file similar to a classical libpcap file. |
Figure 6 (File structure example: more complex pcapng file.) shows a complex example file. In addition to the minimum file above, it contains packets captured from three interfaces, and also includes some Name Resolution Blocks (NRB) and an Interface Statistics Block (ISB).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHB | IDB | IDB | IDB | EPB | EPB | NRB | ... | EPB | ISB | NRB | EPB | EPB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 6: File structure example: more complex pcapng file. |
The last example should make it obvious, that the block structure makes the file format very flexible compared to the classical libpcap format.
| TOC |
All the block bodies have the possibility to embed optional fields. Optional fields can be used to insert some information that may be useful when reading data, but that is not really needed for packet processing. Therefore, each tool can either read the content of the optional fields (if any), or skip some of them or even all at once.
Skipping all the optional fields at once is straightforward because most of the blocks are made of a first part with fixed format, and a second optional part. Therefore, the Block Length field (present in the General Block Structure, see Section 2.1 (General Block Structure)) can be used to skip everything till the next block.
Options are a list of Type - Length - Value fields, each one containing a single value:
Options may be repeated several times (e.g. an interface that has several IP addresses associated to it) TODO: mention for each option, if it can/shouldn't appear more than one time. The option list is terminated by a Option which uses the special 'End of Option' code (opt_endofopt).
The format of the optional fields is shown in Figure 7 (Options format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Option Value / / /* variable length, aligned to 32 bits */ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / . . . other options . . . / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code == opt_endofopt | Option Length == 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 7: Options format. |
The following codes can always be present in any optional field:
| Name | Code | Length | Description | Example(s) |
|---|---|---|---|---|
| opt_endofopt | 0 | 0 | It delimits the end of the optional fields. This block cannot be repeated within a given list of options. | |
| opt_comment | 1 | variable | A UTF-8 string containing a comment that is associated to the current block. | "This packet is the beginning of all of our problems" / "Packets 17-23 showing a bogus TCP retransmission, as reported in bugzilla entry 1486!" / "Captured at the southern plant" / "I've checked again, now it's working ok" / ... |
| TOC |
Endianess
Data contained in each section will always be saved according to the characteristics (little endian / big endian) of the dumping machine. This refers to all the fields that are saved as numbers and that span over two or more bytes.
The approach of having each section saved in the native format of the generating host is more efficient because it avoids translation of data when reading / writing on the host itself, which is the most common case when generating/processing capture dumps.
Please note: The endianess is indicated by the Section Header Block (Section Header Block (mandatory)). As this block can appear several times in a pcapng file, a single file can contain both endianess variants!
Alignment
Most (all?) fields of this specification uses proper alignment for 16- and 32-bit values. This makes it easier and faster to read/write file contents if using techniques like memory mapped files.
The alignment bytes (marked in this document e.g. with "aligned to 32 bits") should be filled with zero bytes (TODO: is this requirement a good idea for the sake of performance / do we want to allow bogus bytes here?).
Please note: 64-bit values are not aligned to 64-bit boundaries. This is because the file is naturally aligned to 32-bit boundaries only. Special care should be taken when reading and writing such values. TODO: the spec is not too consistent wrt how 64-bit values are saved. in the Packet blocks we clearly specify where the low and high 32-bits of a 64-bit timestamp should be saved. In the SHB we do use the endianess of the machine when we save the section length.
TODO - Maybe we have to specify something more here. Is what we're saying enough to avoid any kind of ambiguity?.
| TOC |
This section details the format of the body of the blocks currently defined.
| TOC |
The Section Header Block is mandatory. It identifies the beginning of a section of the capture dump file. The Section Header Block does not contain data but it rather identifies a list of blocks (interfaces, packets) that are logically correlated. Its format is shown in Figure 8 (Section Header Block format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ 0 | Block Type = 0x0A0D0D0A | +---------------------------------------------------------------+ 4 | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Byte-Order Magic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Major Version | Minor Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | | | Section Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 / / / Options (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 8: Section Header Block format. |
The meaning of the fields is:
Adding new block types or options would not necessarily require that either Major or Minor numbers be changed, as code that does not know about the block type or option could just skip it; only if skipping a block or option does not work should the minor version number be changed.
Aside from the options defined in Section 2.5 (Options), the following options are valid within this block:
| Name | Code | Length | Description | Example(s) |
|---|---|---|---|---|
| shb_hardware | 2 | variable | An UTF-8 string containing the description of the hardware used to create this section. | "x86 Personal Computer" / "Sun Sparc Workstation" / ... |
| shb_os | 3 | variable | An UTF-8 string containing the name of the operating system used to create this section. | "Windows XP SP2" / "openSUSE 10.2" / ... |
| shb_userappl | 4 | variable | An UTF-8 string containing the name of the application used to create this section. | "dumpcap V0.99.7" / ... |
| TOC |
The Interface Description Block is mandatory. This block is needed to specify the characteristics of the network interface on which the capture has been made. In order to properly associate the captured data to the corresponding interface, the Interface Description Block must be defined before any other block that uses it; therefore, this block is usually placed immediately after the Section Header Block.
An Interface Description Block is valid only inside the section which it belongs to. The structure of a Interface Description Block is shown in Figure 9 (Interface Description Block format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ 0 | Block Type = 0x00000001 | +---------------------------------------------------------------+ 4 | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | LinkType | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | SnapLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 / / / Options (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 9: Interface Description Block format. |
The meaning of the fields is:
Interface ID: Tools that write / read the capture file associate a progressive 16-bit number (starting from '0') to each Interface Definition Block. This number is unique within each Section and uniquely identifies the interface (inside the current section); therefore, two Sections can have interfaces identified by the same identifiers. This unique identifier is referenced by other blocks (e.g. Packet Block) to point out the interface the block refers to (e.g. the interface that was used to capture the packet). (TODO - It would be nice, to have a "invalid Interface ID" defined, e.g. 0xFFFFFFFF)
In addition to the options defined in Section 2.5 (Options), the following options are valid within this block:
| Name | Code | Length | Description | Example(s) |
|---|---|---|---|---|
| if_name | 2 | Variable | A UTF-8 string containing the name of the device used to capture data. | "eth0" / "\Device\NPF_{AD1CE675-96D0-47C5-ADD0-2504B9126B68}" / ... |
| if_description | 3 | Variable | A UTF-8 string containing the description of the device used to capture data. | "Broadcom NetXtreme" / "First Ethernet Interface" / ... |
| if_IPv4addr | 4 | 8 | Interface network address and netmask. This option can be repeated multiple times within the same Interface Description Block when multiple IPv4 addresses are assigned to the interface. | 192 168 1 1 255 255 255 0 |
| if_IPv6addr | 5 | 17 | Interface network address and prefix length (stored in the last byte). This option can be repeated multiple times within the same Interface Description Block when multiple IPv6 addresses are assigned to the interface. | 2001:0db8:85a3:08d3:1319:8a2e:0370:7344/64 is written (in hex) as "20 01 0d b8 85 a3 08 d3 13 19 8a 2e 03 70 73 44 40" |
| if_MACaddr | 6 | 6 | Interface Hardware MAC address (48 bits). | 00 01 02 03 04 05 |
| if_EUIaddr | 7 | 8 | Interface Hardware EUI address (64 bits), if available. | TODO: give a good example |
| if_speed | 8 | 8 | Interface speed (in bps). | 100000000 for 100Mbps |
| if_tsresol | 9 | 1 | Resolution of timestamps. If the Most Significant Bit is equal to zero, the remaining bits indicates the resolution of the timestamp as as a negative power of 10 (e.g. 6 means microsecond resolution, timestamps are the number of microseconds since 1/1/1970). If the Most Significant Bit is equal to one, the remaining bits indicates the resolution as as negative power of 2 (e.g. 10 means 1/1024 of second). If this option is not present, a resolution of 10^-6 is assumed (i.e. timestamps have the same resolution of the standard 'libpcap' timestamps). | 6 |
| if_tzone | 10 | 4 | Time zone for GMT support (TODO: specify better). | TODO: give a good example |
| if_filter | 11 | variable | The filter (e.g. "capture only TCP traffic") used to capture traffic. The first byte of the Option Data keeps a code of the filter used (e.g. if this is a libpcap string, or BPF bytecode, and more). More details about this format will be presented in Appendix XXX (TODO). (TODO: better use different options for different fields? e.g. if_filter_pcap, if_filter_bpf, ...) | 00 "tcp port 23 and host <IP_ADDRESS>" |
| if_os | 12 | variable | A UTF-8 string containing the name of the operating system of the machine in which this interface is installed. This can be different from the same information that can be contained by the Section Header Block (Section 3.1 (Section Header Block (mandatory))) because the capture can have been done on a remote machine. | "Windows XP SP2" / "openSUSE 10.2" / ... |
| if_fcslen | 13 | 1 | An integer value that specified the length of the Frame Check Sequence (in bits) for this interface. For link layers whose FCS length can change during time, the Packet Block Flags Word can be used (see Appendix A (Packet Block Flags Word)). | 4 |
| if_tsoffset | 14 | 8 | A 64 bits integer value that specifies an offset (in seconds) that must be added to the timestamp of each packet to obtain the absolute timestamp of a packet. If the option is missing, the timestamps stored in the packet must be considered absolute timestamps. The time zone of the offset can be specified with the option if_tzone. TODO: won't a if_tsoffset_low for fractional second offsets be useful for highly syncronized capture systems? | 1234 |
| TOC |
An Enhanced Packet Block is the standard container for storing the packets coming from the network. The Enhanced Packet Block is optional because packets can be stored either by means of this block or the Simple Packet Block, which can be used to speed up dump generation. The format of an Enhanced Packet Block is shown in Figure 10 (Enhanced Packet Block format.).
The Enhanced Packet Block is an improvement over the original Packet Block (Packet Block (obsolete!)):
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ 0 | Block Type = 0x00000006 | +---------------------------------------------------------------+ 4 | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Timestamp (High) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Timestamp (Low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | Captured Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | Packet Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 / / / Packet Data / / /* variable length, aligned to 32 bits */ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Options (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 10: Enhanced Packet Block format. |
The Enhanced Packet Block has the following fields:
In addition to the options defined in Section 2.5 (Options) and in the Packet Block, the following options are valid within this block:
| Name | Code | Length | Description | Example(s) |
|---|---|---|---|---|
| epb_flags | 2 | 4 | A flags word containing link-layer information. A complete specification of the allowed flags can be found in Appendix A (Packet Block Flags Word). | 0 |
| epb_hash | 3 | variable | This option contains a hash of the packet. The first byte specifies the hashing algorithm, while the following bytes contain the actual hash, whose size depends on the hashing algorithm, and hence from the value in the first bit. The hashing algorithm can be: 2s complement (algorithm byte = 0, size=XXX), XOR (algorithm byte = 1, size=XXX), CRC32 (algorithm byte = 2, size = 4), MD-5 (algorithm byte = 3, size=XXX), SHA-1 (algorithm byte = 4, size=XXX). The hash covers only the packet, not the header added by the capture driver: this gives the possibility to calculate it inside the network card. The hash allows easier comparison/merging of different capture files, and reliable data transfer between the data acquisition system and the capture library. (TODO: the text above uses "first bit", but shouldn't this be "first byte"?!?) | TODO: give a good example |
| epb_dropcount | 4 | 8 | A 64bit integer value specifying the number of packets lost (by the interface and the operating system) between this packet and the preceding one. | 0 |
| TOC |
The Simple Packet Block is a lightweight container for storing the packets coming from the network. Its presence is optional.
A Simple Packet Block is similar to a Packet Block (see Section 3.5 (Packet Block (obsolete!))), but it is smaller, simpler to process and contains only a minimal set of information. This block is preferred to the standard Packet Block when performance or space occupation are critical factors, such as in sustained traffic dump applications. A capture file can contain both Packet Blocks and Simple Packet Blocks: for example, a capture tool could switch from Packet Blocks to Simple Packet Blocks when the hardware resources become critical.
The Simple Packet Block does not contain the Interface ID field. Therefore, it must be assumed that all the Simple Packet Blocks have been captured on the interface previously specified in the first Interface Description Block.
Figure 11 (Simple Packet Block format.) shows the format of the Simple Packet Block.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ 0 | Block Type = 0x00000003 | +---------------------------------------------------------------+ 4 | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Packet Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 / / / Packet Data / / /* variable length, aligned to 32 bits */ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 11: Simple Packet Block format. |
The Simple Packet Block has the following fields:
The Simple Packet Block does not contain the timestamp because this is often one of the most costly operations on PCs. Additionally, there are applications that do not require it; e.g. an Intrusion Detection System is interested in packets, not in their timestamp.
A Simple Packet Block cannot be present in a Section that has more than one interface because of the impossibility to refer to the correct one (it does not contain any Interface ID field).
The Simple Packet Block is very efficient in term of disk space: a snapshot whose length is 100 bytes requires only 16 bytes of overhead, which corresponds to an efficiency of more than 86%.
| TOC |
The Packet Block is marked obsolete, better use the Enhanced Packet Block instead!
A Packet Block is the standard container for storing the packets coming from the network. The Packet Block is optional because packets can be stored either by means of this block or the Simple Packet Block, which can be used to speed up dump generation. The format of a packet block is shown in Figure 12 (Packet Block format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ 0 | Block Type = 0x00000002 | +---------------------------------------------------------------+ 4 | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Interface ID | Drops Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Timestamp (High) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Timestamp (Low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | Captured Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | Packet Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 / / / Packet Data / / /* variable length, aligned to 32 bits */ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Options (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 12: Packet Block format. |
The Packet Block has the following fields:
In addition to the options defined in Section 2.5 (Options), the following options are valid within this block:
| Name | Code | Length | Description | Example(s) |
|---|---|---|---|---|
| pack_flags | 2 | 4 | Same as epb_flags of the enhanced packet block. | 0 |
| pack_hash | 3 | variable | Same as epb_hash of the enhanced packet block. | TODO: give a good example |
| Table 1 |
| TOC |
The Name Resolution Block is used to support the correlation of numeric addresses (present in the captured packets) and their corresponding canonical names and it is optional. Having the literal names saved in the file, this prevents the need of a name resolution in a delayed time, when the association between names and addresses can be different from the one in use at capture time. Moreover, the Name Resolution Block avoids the need of issuing a lot of DNS requests every time the trace capture is opened, and allows to have name resolution also when reading the capture with a machine not connected to the network.
A Name Resolution Block is normally placed at the beginning of the file, but no assumptions can be taken about its position. Name Resolution Blocks can be added in a second time by tools that process the file, like network analyzers.
The format of the Name Resolution Block is shown in Figure 13 (Name Resolution Block format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ 0 | Block Type = 0x00000004 | +---------------------------------------------------------------+ 4 | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Record Type | Record Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 / Record Value / / /* variable length, aligned to 32 bits */ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . other records . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Type == end_of_recs | Record Length == 00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Options (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 13: Name Resolution Block format. |
The Name Resolution Block has the following fields:
This is followed by a zero-terminated list of records (in the TLV format), each of which contains an association between a network address and a name. There are three possible types of records:
| Name | Code | Length | Description | Example(s) |
|---|---|---|---|---|
| nres_endofrecord | 0 | 0 | It delimits the end of name resolution records. This record is needed to determine when the list of name resolution records has ended and some options (if any) begin. | |
| nres_ip4record | 1 | Variable | Specifies an IPv4 address (contained in the first 4 bytes), followed by one or more zero-terminated strings containing the DNS entries for that address. | 127 0 0 1 "localhost" |
| nres_ip6record | 2 | Variable | Specifies an IPv6 address (contained in the first 16 bytes), followed by one or more zero-terminated strings containing the DNS entries for that address. | TODO: give a good example |
| Table 2 |
Each Record Value is aligned to a 32-bit boundary. The corresponding Record Length reflects the actual length of the Record Value.
After the list of Name Resolution Records, optionally, a list of options (formatted according to the rules defined in Section 2.5 (Options)) can be present.
In addiction to the options defined in Section 2.5 (Options), the following options are valid within this block:
| Name | Code | Length | Description | Example(s) |
|---|---|---|---|---|
| ns_dnsname | 2 | Variable | A UTF-8 string containing the name of the machine (DNS server) used to perform the name resolution. | "our_nameserver" |
| ns_dnsIP4addr | 3 | 4 | The IPv4 address of the DNS server. | 192 168 0 1 |
| ns_dnsIP6addr | 4 | 16 | The IPv6 address of the DNS server. | TODO: give a good example |
TODO: Add an "Interface ID" option, if the name resolution is only valid for a specific interface?
TODO: Does it make sense to have two "optional mechanisms" (records vs. options) here?
| TOC |
The Interface Statistics Block contains the capture statistics for a given interface and it is optional. The statistics are referred to the interface defined in the current Section identified by the Interface ID field. An Interface Statistics Block is normally placed at the end of the file, but no assumptions can be taken about its position - it can even appear multiple times for the same interface.
The format of the Interface Statistics Block is shown in Figure 14 (Interface Statistics Block format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ 0 | Block Type = 0x00000005 | +---------------------------------------------------------------+ 4 | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Timestamp (High) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Timestamp (Low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 / / / Options (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 14: Interface Statistics Block format. |
The fields have the following meaning:
All the statistic fields are defined as options in order to deal with systems that do not have a complete set of statistics. Therefore, In addiction to the options defined in Section 2.5 (Options), the following options are valid within this block:
| Name | Code | Length | Description | TODO: give a good example |
|---|---|---|---|---|
| isb_starttime | 2 | 8 | Time in which the capture started; time will be stored in two blocks of four bytes each. The format of the timestamp is the same already defined in the Enhanced Packet Block (Section 3.3 (Enhanced Packet Block (optional))). | TODO: give a good example |
| isb_endtime | 3 | 8 | Time in which the capture ended; ; time will be stored in two blocks of four bytes each. The format of the timestamp is the same already defined in the Enhanced Packet Block (Section 3.3 (Enhanced Packet Block (optional))). | TODO: give a good example |
| isb_ifrecv | 4 | 8 | Number of packets received from the physical interface starting from the beginning of the capture. | 100 |
| isb_ifdrop | 5 | 8 | Number of packets dropped by the interface due to lack of resources starting from the beginning of the capture. | 0 |
| isb_filteraccept | 6 | 8 | Number of packets accepted by filter starting from the beginning of the capture. | 100 |
| isb_osdrop | 7 | 8 | Number of packets dropped by the operating system starting from the beginning of the capture. | 0 |
| isb_usrdeliv | 8 | 8 | Number of packets delivered to the user starting from the beginning of the capture. The value contained in this field can be different from the value 'isb_filteraccept - isb_osdrop' because some packets could still lay in the OS buffers when the capture ended. | 0 |
All the fields that refer to packet counters are 64-bit values, represented with the byte order of the current section. Special care must be taken in accessing these fields: since all the blocks are aligned to a 32-bit boundary, such fields are not guaranteed to be aligned on a 64-bit boundary.
| TOC |
| TOC |
Can some other packet blocks (besides the ones described in the previous paragraphs) be useful?
| TOC |
The Compression Block is optional. A file can contain an arbitrary number of these blocks. A Compression Block, as the name says, is used to store compressed data. Its format is shown in Figure 15 (Compression Block format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | Block Type = ? | +---------------------------------------------------------------+ | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compr. Type | | +-+-+-+-+-+-+-+-+ | | | | Compressed Data | | | | /* variable length, byte-aligned */ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 15: Compression Block format. |
The fields have the following meaning:
| TOC |
The Encryption Block is optional. A file can contain an arbitrary number of these blocks. An Encryption Block is used to store encrypted data. Its format is shown in Figure 16 (Encryption Block format.).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | Block Type = ? | +---------------------------------------------------------------+ | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encr. Type | | +-+-+-+-+-+-+-+-+ | | | | Encrypted Data | | | | /* variable length, byte-aligned */ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 16: Encryption Block format. |
The fields have the following meaning:
| TOC |
The Fixed Length Block is optional. A file can contain an arbitrary number of these blocks. A Fixed Length Block can be used to optimize the access to the file. Its format is shown in Figure 17 (Fixed Length Block format.). A Fixed Length Block stores records with constant size. It contains a set of Blocks (normally Packet Blocks or Simple Packet Blocks), of wihich it specifies the size. Knowing this size a priori helps to scan the file and to load some portions of it without truncating a block, and is particularly useful with cell-based networks like ATM.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | Block Type = ? | +---------------------------------------------------------------+ | Block Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cell Size | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Fixed Size Data | | | | /* variable length, byte-aligned */ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Total Length | +---------------------------------------------------------------+
| Figure 17: Fixed Length Block format. |
The fields have the following meaning:
| TOC |
If present, this block contains the following information:
A directory block must be followed by at least N packets, otherwise it must be considered invalid. It can be used to efficiently load portions of the file to memory and to support operations on memory mapped files. This block can be added by tools like network analyzers as a consequence of file processing.
| TOC |
One or more blocks could be defined to contain network statistics or traffic monitoring information. They could be use to store data collected from RMON or Netflow probes, or from other network monitoring tools.
| TOC |
This block could be used to store events. Events could contain generic information (for example network load over 50%, server down...) or security alerts. An event could be:
| TOC |
The recommended file name extension for the "PCAP Next Generation Dump File Format" specified in this document is ".pcapng".
At least in the "Windows world", files are distinguished by an extension to their filename. Such an extension is technically not actually required, as applications should be able to automatically detect the pcapng file format through the "magic bytes" at the beginning of the file. However, using name extensions makes it easier to work with files (e.g. visually distinguish file formats) so it is recommended - though not required - to use .pcapng as the name extension for files following this specification.
Please note: To avoid confusion (like the current usage of .cap for a pletora of different capture file formats) other file name extensions than .pcapng should be avoided!
| TOC |
TODO - explain the preferred way to add new block types and new options for existing blocks in more detail.
| TOC |
The file format proposed in this document should be very versatile and satisfy a wide range of applications. In the simplest case, it can contain a raw dump of the network data, made of a series of Simple Packet Blocks. In the most complex case, it can be used as a repository for heterogeneous information. In every case, the file remains easy to parse and an application can always skip the data it is not interested in; at the same time, different applications can share the file, and each of them can benefit of the information produced by the others. Two or more files can be concatenated obtaining another valid file.
| TOC |
The Packet Block Flags Word is a 32-bit value that contains link-layer information about the packet.
The meaning of the bits is the following:
| Bit Number | Description |
|---|---|
| 0-1 | Inbound / Outbound packet (00 = information not available, 01 = inbound, 10 = outbound) |
| 2-4 | Reception type (000 = not specified, 001 = unicast, 010 = multicast, 011 = broadcast, 100 = promiscuous). |
| 5-8 | FCS length, in bytes (0000 if this information is not available). This value overrides the if_fcslen option of the Interface Description Block, and is used with those link layers (e.g. PPP) where the length of the FCS can change during time. |
| 9-15 | Reserved (must be set to zero). |
| 16-31 | link-layer-dependent errors (Bit 31 = symbol error, Bit 30 = preamble error, Bit 29 = Start Frame Delimiter error, Bit 28 = unaligned frame error, Bit 27 = wrong Inter Frame Gap error, Bit 26 = packet too short error, Bit 25 = packet too long error, Bit 24 = CRC error, other?? are 16 bit enough?). |
| TOC |
Every Block is uniquely identified by a 32 bit integer value, stored in the Block Header.
As pointed out in Section 2.1 (General Block Structure), Block Types codes whose Most Significant Bit (bit 31) is set to 1 are reserved for local use by the application.
All the remaining Block Type codes (0x00000000 to 0x7FFFFFFF) are standardized by this document. A request should be sent to the authors of this document to add a new Standard Block Type code to the specification.
Here is a list of the Standardized Block Type Codes.
| Block Type Code | Description |
|---|---|
| 0x00000000 | Reserved ??? |
| 0x00000001 | Interface Description Block (Interface Description Block (mandatory)) |
| 0x00000002 | Packet Block (Packet Block (obsolete!)) |
| 0x00000003 | Simple Packet Block (Simple Packet Block (optional)) |
| 0x00000004 | Name Resolution Block (Name Resolution Block (optional)) |
| 0x00000005 | Interface Statistics Block (Interface Statistics Block (optional)) |
| 0x00000006 | Enhanced Packet Block (Enhanced Packet Block (optional)) |
| 0x00000007 | IRIG Timestamp Block (requested by Gianluca Varenni<EMAIL_ADDRESS>CACE Technologies LLC) |
| 0x00000008 | Arinc 429 in AFDX Encapsulation Information Block (requested by Gianluca Varenni<EMAIL_ADDRESS>CACE Technologies LLC) |
| 0x0A0D0D0A | Section Header Block (Section Header Block (mandatory)) |
| 0x0A0D0A00-0x0A0D0AFF | Reserved. Used to detect trace files corrupted because of file transfers using the HTTP protocol in text mode. |
| 0x000A0D0A-0xFF0A0D0A | Reserved. Used to detect trace files corrupted because of file transfers using the HTTP protocol in text mode. |
| 0x000A0D0D-0xFF0A0D0D | Reserved. Used to detect trace files corrupted because of file transfers using the HTTP protocol in text mode. |
| 0x0D0D0A00-0x0D0D0AFF | Reserved. Used to detect trace files corrupted because of file transfers using the FTP protocol in text mode. |
| TOC |
NOTE: we should decide if we want to have this list here or in a separate document. It may make sense to have this list in a separate document and describe the format of a frame for each different linktype, or specify that the frame format is proprietary of a company and not public. There are a large number of encapsulations that are really vague and unspecified at all (even the name does not make any sense). Moreover, we should decide if we want to have *all* the linktypes (LINKTYPE_XXX) defined by libpcap, or just a subset of them, thus trying to remove the big mess and confusion of similar headers.
Here is a list of the Standardized Link Type Codes.
| Link Type Name | Link Type Code | Description |
|---|---|---|
| LINKTYPE_NULL | 0 | No link layer information. A packet saved with this link layer contains a raw L3 packet preceded by a 32-bit host-byte-order AF_ value indicating the specific L3 type. |
| LINKTYPE_ETHERNET | 1 | D/I/X and 802.3 Ethernet |
| LINKTYPE_EXP_ETHERNET | 2 | Experimental Ethernet (3Mb) |
| LINKTYPE_AX25 | 3 | Amateur Radio AX.25 |
| LINKTYPE_PRONET | 4 | Proteon ProNET Token Ring |
| LINKTYPE_CHAOS | 5 | Chaos |
| LINKTYPE_TOKEN_RING | 6 | IEEE 802 Networks |
| LINKTYPE_ARCNET | 7 | ARCNET, with BSD-style header |
| LINKTYPE_SLIP | 8 | Serial Line IP |
| LINKTYPE_PPP | 9 | Point-to-point Protocol |
| LINKTYPE_FDDI | 10 | FDDI |
| LINKTYPE_PPP_HDLC | 50 | PPP in HDLC-like framing |
| LINKTYPE_PPP_ETHER | 51 | NetBSD PPP-over-Ethernet |
| LINKTYPE_SYMANTEC_FIREWALL | 99 | Symantec Enterprise Firewall |
| LINKTYPE_ATM_RFC1483 | 100 | LLC/SNAP-encapsulated ATM |
| LINKTYPE_RAW | 101 | Raw IP |
| LINKTYPE_SLIP_BSDOS | 102 | BSD/OS SLIP BPF header |
| LINKTYPE_PPP_BSDOS | 103 | BSD/OS PPP BPF header |
| LINKTYPE_C_HDLC | 104 | Cisco HDLC |
| LINKTYPE_IEEE802_11 | 105 | IEEE 802.11 (wireless) |
| LINKTYPE_ATM_CLIP | 106 | Linux Classical IP over ATM |
| LINKTYPE_FRELAY | 107 | Frame Relay |
| LINKTYPE_LOOP | 108 | OpenBSD loopback |
| LINKTYPE_ENC | 109 | OpenBSD IPSEC enc |
| LINKTYPE_LANE8023 | 110 | ATM LANE + 802.3 (Reserved for future use) |
| LINKTYPE_HIPPI | 111 | NetBSD HIPPI (Reserved for future use) |
| LINKTYPE_HDLC | 112 | NetBSD HDLC framing (Reserved for future use) |
| LINKTYPE_LINUX_SLL | 113 | Linux cooked socket capture |
| LINKTYPE_LTALK | 114 | Apple LocalTalk hardware |
| LINKTYPE_ECONET | 115 | Acorn Econet |
| LINKTYPE_IPFILTER | 116 | Reserved for use with OpenBSD ipfilter |
| LINKTYPE_PFLOG | 117 | OpenBSD DLT_PFLOG |
| LINKTYPE_CISCO_IOS | 118 | For Cisco-internal use |
| LINKTYPE_PRISM_HEADER | 119 | 802.11+Prism II monitor mode |
| LINKTYPE_AIRONET_HEADER | 120 | FreeBSD Aironet driver stuff |
| LINKTYPE_HHDLC | 121 | Reserved for Siemens HiPath HDLC |
| LINKTYPE_IP_OVER_FC | 122 | RFC 2625 IP-over-Fibre Channel |
| LINKTYPE_SUNATM | 123 | Solaris+SunATM |
| LINKTYPE_RIO | 124 | RapidIO - Reserved as per request from Kent Dahlgren<EMAIL_ADDRESS>for private use. |
| LINKTYPE_PCI_EXP | 125 | PCI Express - Reserved as per request from Kent Dahlgren<EMAIL_ADDRESS>for private use. |
| LINKTYPE_AURORA | 126 | Xilinx Aurora link layer - Reserved as per request from Kent Dahlgren<EMAIL_ADDRESS>for private use. |
| LINKTYPE_IEEE802_11_RADIO | 127 | 802.11 plus BSD radio header |
| LINKTYPE_TZSP | 128 | Tazmen Sniffer Protocol - Reserved for the TZSP encapsulation, as per request from Chris Waters<EMAIL_ADDRESS>TZSP is a generic encapsulation for any other link type, which includes a means to include meta-information with the packet, e.g. signal strength and channel for 802.11 packets. |
| LINKTYPE_ARCNET_LINUX | 129 | Linux-style headers |
| LINKTYPE_JUNIPER_MLPPP | 130 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_JUNIPER_MLFR | 131 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_JUNIPER_ES | 132 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_JUNIPER_GGSN | 133 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_JUNIPER_MFR | 134 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_JUNIPER_ATM2 | 135 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_JUNIPER_SERVICES | 136 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_JUNIPER_ATM1 | 137 | Juniper-private data link type, as per request from Hannes Gredler<EMAIL_ADDRESS>The corresponding DLT_s are used for passing on chassis-internal metainformation such as QOS profiles, etc.. |
| LINKTYPE_APPLE_IP_OVER_IEEE1394 | 138 | Apple IP-over-IEEE 1394 cooked header |
| LINKTYPE_MTP2_WITH_PHDR | 139 | ??? |
| LINKTYPE_MTP2 | 140 | ??? |
| LINKTYPE_MTP3 | 141 | ??? |
| LINKTYPE_SCCP | 142 | ??? |
| LINKTYPE_DOCSIS | 143 | DOCSIS MAC frames |
| LINKTYPE_LINUX_IRDA | 144 | Linux-IrDA |
| LINKTYPE_IBM_SP | 145 | Reserved for IBM SP switch and IBM Next Federation switch. |
| LINKTYPE_IBM_SN | 146 | Reserved for IBM SP switch and IBM Next Federation switch. |
| TOC |
The Packet Data field of the Packet Blocks won't start with the actual network data captured, but with some link type specific "meta data". The format of this meta data depends on the link type used. TODO: mention example code in libpcap that lists these link headers.
| TOC |
| Loris Degioanni | |
| CACE Technologies | |
| 1949 Fifth Street #103 | |
| Davis, CA 95616 | |
| United States | |
| Phone: | +1<PHONE_NUMBER> |
| Email: |<EMAIL_ADDRESS>|
| URI: | http://www.winpcap.org/loris/ |
| Fulvio Risso | |
| Politecnico di Torino | |
| Corso Duca degli Abruzzi, 24 | |
| Torino 10129 | |
| Italy | |
| Phone: | +39<PHONE_NUMBER> |
| Email: |<EMAIL_ADDRESS>|
| URI: | http://staff.polito.it/fulvio.risso/ |
| Gianluca Varenni | |
| CACE Technologies | |
| 1949 Fifth Street #103 | |
| Davis, CA 95616 | |
| United States | |
| Phone: | +1<PHONE_NUMBER> |
| Email: |<EMAIL_ADDRESS>|
| URI: | http://www.winpcap.org/gianluca/ |
| TOC |
Copyright © The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Funding for the RFC Editor function is currently provided by the Internet Society.


Density, Probability and Quantile functions, and random number generation for (skew) stable distributions, using the parametrizations of Nolan.
| Version: | 0.7-1 |
| Depends: | R (≥ 3.1.0) |
| Imports: | stats |
| Suggests: | Matrix, fBasics, FMStable, RUnit, Rmpfr, sfsmisc |
| Published: | 2016-09-12 |
| Author: | Diethelm Wuertz, Martin Maechler and Rmetrics core team members. |
| Maintainer: | Martin Maechler <maechler at stat.math.ethz.ch> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| URL: | http://www.rmetrics.org, https://r-forge.r-project.org/scm/viewvc.php/pkg/stabledist/?root=rmetrics |
| NeedsCompilation: | no |
| Materials: | ChangeLog |
| In views: | Distributions |
| CRAN checks: | stabledist results |
| Reference manual: | stabledist.pdf |
| Package source: | stabledist_0.7-1.tar.gz |
| Windows binaries: | r-devel: stabledist_0.7-1.zip, r-release: stabledist_0.7-1.zip, r-oldrel: stabledist_0.7-1.zip |
| OS X binaries: | r-release: stabledist_0.7-1.tgz, r-oldrel: stabledist_0.7-1.tgz |
| Old sources: | stabledist archive |
| Reverse depends: | mleur, StableEstim |
| Reverse imports: | alphastable, copula, ecd, fBasics, GEVStableGarch, MARX, MHTcop, MittagLeffleR, modeest, rlfsm, stable |
| Reverse suggests: | fitteR, gmm, synlik, tweedie |
Please use the canonical form https://CRAN.R-project.org/package=stabledist to link to this page.


Order Status
Avatar
Full Name
Email
Registered
Role
<EMAIL_ADDRESS>02/02/2020
Employee
Admin
Add Employee
This email is already taken!
First Name
Last Name
Email
Password
Add


MSG_GEN_VIEW_CONTROL_SET_ATTRS, MSG_GEN_VIEW_CONTROL_SET_MINIMUM_SCALE_FACTOR, MSG_GEN_VIEW_CONTROL_SET_MAXIMUM_SCALE_FACTOR
GenViewControlClass
handles several messages that allow its characteristics to be set or modified at run-time. It also has several other internal messages which are not documented here.
void MSG_GEN_VIEW_CONTROL_SET_ATTRS( GenViewControlAttrs attrsToSet, GenViewControlAttrs attrsToClear);
This message sets the GenViewControlAttrs in GVCI_attrs. Attributes noted in both parameters will be turned off for the controller.
Source: Unrestricted.
Destination: Any GenViewControl object.
Parameters:
attrsToSet
Attributes to be turned on should be set.
attrsToClear
Return: Nothing.
Interception: Generally not intercepted.
void MSG_GEN_VIEW_CONTROL_SET_MINIMUM_SCALE_FACTOR( word minimumScaleFactor);
This message sets the view controller's minimum allowable scale factor.
Source: Unrestricted.
Destination: Any GenViewControl object.
Parameters:
minimumScaleFactor
The new minimum scale factor (a percentage).
Return: Nothing.
Interception: Generally not intercepted.
void MSG_GEN_VIEW_CONTROL_SET_MAXIMUM_SCALE_FACTOR( word maximumScaleFactor);
This message sets the maximum settable scale factor for the view controller.
Source: Unrestricted.
Destination: Any GenViewControl object.
Parameters:
maximumScaleFactor
The maximum settable scale factor (as a percent).
Return: Nothing.
Interception: Generally not intercepted.


Yay! I've successfully deployed a project on Github.
I'm already well into my graduate school, but it seems that I haven't found my studying pace yet. I need to develop a habit of constantly writing down what I'm learning for better reflection.
Therefore, I think it might be a good idea to start a new blog, which technically puts me in the public eye. The pressure to update this blog might force me to work harder. In short, I voluntarily place myself inside a panopticon under the premise that potential supervision would discipline my behavior.
That was creepy. In a brighter note, this is an open notebook of technology studies. Many scholars have willingly share their research ideas and processes with the public via open notebooks. If anyone happens to stop by, I hope some of the notes would be deemed helpful.
Finally, if not for Mozfest 2015, I wouldn't have a Github account. I love what Mozilla's been doing, and I want to make the web a even better place.


I like to travel to alien worlds, likee Arrakis.
My friend is a 500 meter long sandworm.
I stay in shape by riding sandworms with the Fremen I hang with.


Erin Woo is a senior undergradute student studying computing at UC Santa Barbara's College of Creative Studies.
She was previously a software engineering intern for WeWork in San Francisco on the Core Platform - Devices team and is currently a software engineering intern for the Teams Android app at Microsoft.
Read more about Erin in her Women Who Reign feature.


The Stranded Island of Fantasia
You just woke up from a sleep and you dont remember anything. Suddenly, you see a group of pirates with swords running towards you. What should you do?
What do you do?
1
2
3


Type of Lists
Ordered Lists
To make a list we use the tag's OL and LI, OL being the list and LI the content of that list
- To the left
- To the right
- Foward
- And beyond
The LI doenst need to be close with /li
If we want to change that type of list, from number to letter, we must use OL TYPE
- To the left
- To the right
- Foward
- And beyond
And to change the begginer number or letter we must use start=, ol type="" start="".
- To the left
- To the right
- Foward
- And beyond
Unordered Lists
We use UL to make a unordered list
- To the left
- To the right
- Foward
- And beyond
We can use others types too
- To the left
- To the right
- Foward
- And beyond
- To the left
- To the right
- Foward
- And beyond
A List Inside a List
We can open a OL and LI, and inside that LI we can open another OL or UL
- Favorite Foods
- Buttered popcorn
- Poutine
- Penang assam laksa
- Favorite Drinks
Definition List
DL is used to make a list of defenitions, DT being de object and DD explaining that object, like a dictionary.
- Mishpocha
- an entire family network comprising relatives by blood and marriage and sometimes including close friends; clan.
- Joao Vitor Junckes
- An apprentice in the programming world


Login
About
Adminstrator Login
Register with us
sign up
Already regestired?
Login
Login
Not Registered?
Sign Up


@import com.gu.contentapi.client.model.v1.{Asset, AssetFields, AssetType} @import common.commercial.hosted.HostedPage @import layout.ContentWidths.ImageContentMedia @import model.{ImageAsset, ImageMedia} @()(implicit request: RequestHeader)
Get your flights and tickets to the Singapore GP (and treat yourselves to some R&R afterwards)…
It's not too late to get a great deal on a package to the 2016 Formula 1 Singapore Airlines Singapore Grand Prix. A three-night race-weekend package – including flights, transfers, accommodation and race tickets – starts from £1,320 per person.* You'll receive up to 12,000 KrisFlyer miles with selected ticket categories, if you opt for the exclusive 2016 FORMULA 1 land packages, offered on the sianightrace.com website.
Tick off your flights, hotel airport transfers and even race tickets in one fell swoop at Singapore Airlines' sianightrace.com. Just enter your Singapore dates, pick one of the swish hotels on offer, select a GP ticket type (the default 3-Day Bay Grandstand access, or an upgraded version, subject to a top-up fee) and add optional airport transfers. Your Grand Prix travel is fixed – in just a few clicks.
There's a wide range of packages available. Here are our highlights:
Terms & conditions here.
More information here.
@fragments.imageFigure( ImageMedia.make(Seq(ImageAsset.make(Asset(AssetType.Image, Some("image/jpeg"), Some("https://media.guim.co.uk/5dfce3ee95c325437fd26d1757a5a9032c514400/0_81_3008_1805/2000.jpg"), typeData = Some(AssetFields(width = Some(5), height = Some(3)))), 0))), lightboxIndex = None, widthsByBreakpoint = ImageContentMedia.inline )Another great option is to combine your visit with a side trip. Singapore Airlines and Trailfinders have teamed up to offer some dual-destination F1 packages – pick from Singapore and Phuket, Singapore and Borneo, or Singapore and Sydney. Wherever you decide to go, you can take advantage of big savings; there are also slashed-price flights just to Singapore, if you've got a one-track mind.
Explore our packages here.
When you're booking your flights, don't forget to add on a Singapore Explorer Pass , which will give you one-time access over 20 attractions and benefits over the duration of your purchased pass. The list includes: Alive Museum, Cable Car (two-way), Gardens By the Bay, Jurong Bird Park, the National Orchid Garden, a Singapore River Cruise, Science Centre & IMAX movie, Sentosa admission, Images of Singapore LIVE, Madame Tussauds – plus much more. Passes aren't sold in Singapore, and can only be bought from your local Singapore Airlines office, or from travel agents prior to your arrival into Singapore. Your Singapore Grand Prix experience: sorted.
Terms & conditions here.
Download the Circuit Park map.


Your essay should be typed and double-spaced on standard-sized paper (8.5" x 11"), with 1" margins on all sides. Include a page header (also known as the “running head”) at the top of every page. For a professional paper, this includes your paper title and the page number. For a student paper, this only includes the page number. To create a page header/running head, insert page numbers flush right. Then type "TITLE OF YOUR PAPER" in the header flush left using all capital letters. The running head is a shortened version of your paper's title and cannot exceed 50 characters including spacing and punctuation.
The 7th edition of the APA Publication Manual requires that the chosen font be accessible (i.e., legible) to all readers and that it be used consistently throughout the paper. It acknowledges that many font choices are legitimate, and it advises writers to check with their publishers, instructors, or institutions for guidance in cases of uncertainty.
While the APA Manual does not specify a single font or set of fonts for professional writing, it does recommend a few fonts that are widely available. These include sans serif fonts such as 11-point Calibri, 11-point Arial, and 10-point Lucida Sans Unicode as well as serif fonts such as 12-point Times New Roman, 11-point Georgia, 10-point Computer Modern.
Your essay should include four major sections: the Title Page, Abstract, Main Body, and References.
Note:APA 7 provides slightly different directions for formatting the title pages of professional papers (e.g., those intended for scholarly publication) and student papers (e.g., those turned in for credit in a high school or college course).
The title page should contain the title of the paper, the author's name, and the institutional affiliation. A professional paper should also include the author note. A student paper should also include the course number and name, instructor name, and assignment due date.
Type your title in upper and lowercase letters centered in the upper half of the page. The title should be centered and written in boldface. APA recommends that your title be focused and succinct and that it should not contain abbreviations or words that serve no purpose. Your title may take up one or two lines. All text on the title page, and throughout your paper, should be double-spaced.
Beneath the title, type the author's name: first name, middle initial(s), and last name. Do not use titles (Dr.) or degrees (PhD).
Beneath the author's name, type the institutional affiliation, which should indicate the location where the author(s) conducted the research.
A professional paper should include the author note beneath the institutional affiliation, in the bottom half of the title page. This should be divided up into several paragraphs, with any paragraphs that are not relevant omitted. The first paragraph should include the author’s name, the symbol for the ORCID iD, and the URL for the ORCID iD. Any authors who do not have an ORCID iD should be omitted. The second paragraph should show any change in affiliation or any deaths of the authors. The third paragraph should include any disclosures or acknowledgements, such as study registration, open practices and data sharing, disclosure of related reports and conflicts of interest, and acknowledgement of financial support and other assistance. The fourth paragraph should include contact information for the corresponding author.
A student paper should not include an author note.
Note again that page headers/page numbers (described above for professional and student papers) also appear at the top of the title page. In other words, a professional paper's title page will include the title of the paper flush left in all capitals and the page number flush right, while a student paper will only contain the page number flush right.


|
Jala 1.3 | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Object | +--jala.Mp3
This is a class representing an MP3 file
providing methods to access its metadata.
Defined in Mp3.js
| Nested Class Summary | |
<static class> |
jala.Mp3.Id3v1 |
<static class> |
jala.Mp3.Id3v2 |
| Field Summary | |
Object |
album
|
Object |
artist
|
Object |
comment
|
Object |
genre
|
Object |
title
|
Object |
trackNumber
|
Object |
year
|
<static> <final> Array |
GENRES
Array defining valid genres in ID3v1 |
<static> <final> Array |
MODES
Array defining mp3 modes. |
<static> <final> Array |
PICTURE_TYPES
Array defining valid picture types. |
<static> <final> Array |
TEXT_ENCODINGS
Array defining valid text encodings. |
| Constructor Summary | |
jala.Mp3
(<String|File> file)
Constructs a new jala.Mp3 wrapper and parses the header data of the MP3 file. |
| Method Summary | |
Object
|
createTag(<Object> tagClass, <Object> tagObject)
This method creates a new tag object, attaches it to the file (thereby replacing an existing tag of this type) and returns it. |
jala.Mp3.Id3v1
|
createV1Tag(<Object> tagObject)
If the file doesn't contain an ID3v1 tag, this method creates a new ID3v1 tag object, attaches it to the file and returns it. |
jala.Mp3.Id3v2
|
createV2Tag(<Object> tagObject)
If the file doesn't contain an ID3v2 tag, this method creates a new ID3v2 tag object, attaches it to the file and returns it. |
Number
|
getBitRate()
Returns the bit rate the file was encoded with. |
String
|
getChannelMode()
Returns the channel mode the file was encoded with. |
Number
|
getDuration()
The audio length of the file in seconds at best estimate from the file info (method returns immediately). |
helma.File
|
getFile()
Returns a helma.File reference to the wrapped file. |
Number
|
getFrequency()
Returns the frequency the file was encoded with. |
org.farng.mp3.MP3File
|
getJavaObject()
Returns the underlying java object |
Object
|
getMetadata()
Returns a plain JavaScript object containing the values of all fields stored in either the Id3 V1 or V2 tag |
Number
|
getSize()
Returns the file size in bytes. |
Object
|
getTag(tagClass)
Returns a tag object, type is specified using the class name in jala.Mp3.*. |
jala.Mp3.Id3v1
|
getV1Tag()
|
jala.Mp3.Id3v2
|
getV2Tag()
|
Object
|
hasTag(tagClass)
Tells if the file contains a certain tag, type is specified using the class name in jala.Mp3. |
Boolean
|
hasV1Tag()
Returns true if the file contains a ID3v1 tag. |
Boolean
|
hasV2Tag()
Returns true if the file contains a ID3v2 tag. |
Boolean
|
isVariableBitRate()
Returns true if the file is (or seems to be) encoded with variable bit rate. |
Number
|
parseDuration()
Parses the audio file to extract the precise duration of the audio. |
void
|
removeTag(tagClass)
Removes a tag from the file, type is specified using the class name in jala.Mp3.* |
void
|
removeV1Tag()
Removes the ID3v1 tag from the file. |
Object
|
removeV2Tag()
Removes the ID3v2 tag from the file. |
Boolean
|
save(<String|helma.File> outFile)
Writes changed metadata back to the source file or to a new file. |
void
|
setMetadata(<Object> metadata)
Stores the metadata passed as argument in the ID2 v1 and v2 tags of the wrapped MP3 file. |
| Field Detail |
Object album
Object artist
Object comment
Object genre
Object title
Object trackNumber
Object year
<static> <final> Array GENRES
<static> <final> Array MODES
<static> <final> Array PICTURE_TYPES
<static> <final> Array TEXT_ENCODINGS
| Constructor Detail |
jala.Mp3(<String|File> file)
file
- The mp3 file to be parsed, either as path string or as any kind of file object
| Method Detail |
Object createTag(<Object> tagClass, <Object> tagObject)
tagClass
-
tagObject
- optional tag whose standard properties are copied to the new tag.
jala.Mp3.Id3v1 createV1Tag(<Object> tagObject)
tagObject
- optional tag whose standard properties are copied to the new tag.
jala.Mp3.Id3v2 createV2Tag(<Object> tagObject)
tagObject
- optional tag whose standard properties are copied to the new tag.
Number getBitRate()
String getChannelMode()
Number getDuration()
helma.File getFile()
Number getFrequency()
org.farng.mp3.MP3File getJavaObject()
Object getMetadata()
Number getSize()
Object getTag(tagClass)
jala.Mp3.Id3v1 getV1Tag()
jala.Mp3.Id3v2 getV2Tag()
Object hasTag(tagClass)
Boolean hasV1Tag()
Boolean hasV2Tag()
Boolean isVariableBitRate()
Number parseDuration()
void removeTag(tagClass)
void removeV1Tag()
Object removeV2Tag()
Boolean save(<String|helma.File> outFile)
outFile
- (optional) save the modified file to a different file
void setMetadata(<Object> metadata)
metadata
- An object containing the fields to set and their values.
|
Jala 1.3 | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


This page contains instructions for common ways to enhance the user experience. For a list of all the configurable Helm chart options, see the Configuration Reference.
The user environment is the set of software packages, environment variables, and various files that are present when the user logs into JupyterHub. The user may also see different tools that provide interfaces to perform specialized tasks, such as JupyterLab, RStudio, RISE and others.
A Docker image built from a Dockerfile will lay the foundation for the environment that you will provide for the users. The image will for example determine what Linux software (curl, vim …), programming languages (Julia, Python, R, …) and development environments (JupyterLab, RStudio, …) are made available for use.
To get started customizing the user environment, see the topics below.
Project Jupyter maintains the jupyter/docker-stacks repository, which contains ready to use Docker images. Each image includes a set of commonly used science and data science libraries and tools. They also provide excellent documentation on how to choose a suitable image.
If you wish to use another image from jupyter/docker-stacks than the base-notebook used by default, such as the datascience-notebook image containing useful tools and libraries for datascience, complete these steps:
Modify your config.yaml file to specify the image. For example:
config.yaml
singleuser: image: # Get the latest image tag at: # https://hub.docker.com/r/jupyter/datascience-notebook/tags/ # Inspect the Dockerfile at: # https://github.com/jupyter/docker-stacks/tree/master/datascience-notebook/Dockerfile name: jupyter/datascience-notebook tag: 177037d09156
Note
Container image names cannot be longer than 63 characters.
Always use an explicit tag, such as a specific commit. Avoid using latest as it might cause a several minute delay, confusion, or failures for users when a new version of the image is released.
tag
latest
Apply the changes by following the directions listed in apply the changes.
If you have configured prePuller.hook.enabled, all the nodes in your cluster will pull the image before the hub is upgraded to let users use the image. The image pulling may take several minutes to complete, depending on the size of the image.
Restart your server from JupyterHub control panel if you are already logged in.
If you’d like users to select an environment from multiple docker images, see Using multiple profiles to let users select their environment.
JupyterLab is a new user interface for Jupyter about to replace the classic user interface (UI). While users already can interchange /tree and /lab in the URL to switch between the classic UI and JupyterLab, they will default to use the classic UI.
/tree
/lab
The classic Jupyter Notebook UI is the default provided, but you can change it to JupyterLab with the following config in your config.yaml:
singleuser: defaultUrl: "/lab"
You need the jupyterlab package (installable via pip or conda) for this to work. All images in the jupyter/docker-stacks repository come pre-installed with it.
jupyterlab
pip
conda
If you are missing something in the image that you would like all users to have, we recommend that you build a new image on top of an existing Docker image from jupyter/docker-stacks.
Below is an example Dockerfile building on top of the minimal-notebook image. This file can be built to a Docker image, and pushed to a image registry, and finally configured in config.yaml to be used by the Helm chart.
FROM jupyter/minimal-notebook:177037d09156 # Get the latest image tag at: # https://hub.docker.com/r/jupyter/minimal-notebook/tags/ # Inspect the Dockerfile at: # https://github.com/jupyter/docker-stacks/tree/master/minimal-notebook/Dockerfile # install additional package... RUN pip install --no-cache-dir astropy
One way to affect your user’s environment is by setting environment variables. While you can set them up in your Docker image if you build it yourself, it is often easier to configure your Helm chart through values provided in your config.yaml.
To set this up, edit your config.yaml and apply the changes. For example, this code snippet will set the environment variable EDITOR to the value vim:
EDITOR
vim
singleuser: extraEnv: EDITOR: "vim"
You can set any number of static environment variables in the config.yaml file.
Users can read the environment variables in their code in various ways. In Python, for example, the following code reads an environment variable’s value:
import os my_value = os.environ["MY_ENVIRONMENT_VARIABLE"]
It is important to understand the basics of how user storage is set up. By default, each user will get 10GB of space on a harddrive that will persist in between restarts of their server. This harddrive will be mounted to their home directory. In practice this means that everything a user writes to the home directory (/home/jovyan) will remain, and everything else will be reset in between server restarts.
/home/jovyan
A server can be shut down by culling. By default, JupyterHub’s culling service is configured to cull a users server that has been inactive for one hour. Note that JupyterLab will autosave files, and as long as the file was within the users home directory no work is lost.
In Kubernetes, a PersistantVolume (PV) represents the harddrive. KubeSpawner will create a PersistantVolumeClaim that requests a PV from the cloud. By default, deleting the PVC will cause the cloud to delete the PV.
Docker image’s $HOME directory will be hidden from the user. To make these contents visible to the user, you must pre-populate the user’s filesystem. To do so, you would include commands in the config.yaml that would be run each time a user starts their server. The following pattern can be used in config.yaml:
singleuser: lifecycleHooks: postStart: exec: command: ["cp", "-a", "src", "target"]
Each element of the command needs to be a separate item in the list. Note that this command will be run from the $HOME location of the user’s running container, meaning that commands that place files relative to ./ will result in users seeing those files in their home directory. You can use commands like wget to place files where you like.
$HOME
./
wget
A simple way to populate the notebook user’s home directory is to add the required files to the container’s /tmp directory and then copy them to /home/jovyan using a postStart hook. This example shows the use of multiple commands.
/tmp
postStart
singleuser: lifecycleHooks: postStart: exec: command: - "sh" - "-c" - > cp -r /tmp/foo /home/jovyan; cp -r /tmp/bar /home/jovyan
Keep in mind that commands will be run each time a user starts their server. For this reason, we recommend using nbgitpuller to synchronize your user folders with a git repository.
nbgitpuller
We recommend using the tool nbgitpuller to synchronize a folder in your user’s filesystem with a git repository whenever a user starts their server. This synchronization can also be triggered by letting a user visit a link like https://your-domain.com/hub/user-redirect/git-pull?repo=https://github.com/data-8/materials-fa18 (e.g., as alternative start url).
git
https://your-domain.com/hub/user-redirect/git-pull?repo=https://github.com/data-8/materials-fa18
To use nbgitpuller, first make sure that you install it in your Docker image. Once this is done, you’ll have access to the nbgitpuller CLI from within JupyterHub. You can run it with a postStart hook with the following configuration
singleuser: lifecycleHooks: postStart: exec: command: ["gitpuller", "https://github.com/data-8/materials-fa17", "master", "materials-fa"]
This will synchronize the master branch of the repository to a folder called $HOME/materials-fa each time a user logs in. See the nbgitpuller documentation for more information on using this tool.
$HOME/materials-fa
Warning
nbgitpuller will attempt to automatically resolve merge conflicts if your user’s repository has changed since the last sync. You should familiarize yourself with the nbgitpuller merging behavior prior to using the tool in production.
Sometimes you want users to be able to create their own conda environments. By default, any environments created in a JupyterHub session will not persist across sessions. To resolve this, take the following steps:
Ensure the nb_conda_kernels package is installed in the root environment (e.g., see Build a Docker image with repo2docker)
nb_conda_kernels
Configure Anaconda to install user environments to a folder within $HOME.
Create a file called .condarc in the home folder for all users, and make sure that the following lines are inside:
.condarc
envs_dirs: - /home/jovyan/my-conda-envs/
The text above will cause Anaconda to install new environments to this folder, which will persist across sessions.
These environments are supposed to be used in notebooks, so a typical use case:
Create one with at least a kernel, e.g. for Python it’s conda create -n myenv ipykernel scipy
conda create -n myenv ipykernel scipy
Now this env should be available in the list of kernels
You can create configurations for multiple user environments, and let users select from them once they log in to your JupyterHub. This is done by creating multiple profiles, each of which is attached to a set of configuration options that override your JupyterHub’s default configuration (specified in your Helm Chart). This can be used to let users choose among many Docker images, to select the hardware on which they want their jobs to run, or to configure default interfaces such as Jupyter Lab vs. RStudio.
Each configuration is a set of options for Kubespawner, which defines how Kubernetes should launch a new user server pod. Any configuration options passed to the profileList configuration will overwrite the defaults in Kubespawner (or any configuration you’ve added elsewhere in your helm chart).
profileList
Profiles are stored under singleuser.profileList, and are defined as a list of profiles with specific configuration options each. Here’s an example:
singleuser.profileList
singleuser: profileList: - display_name: "Name to be displayed to users" description: "Longer description for users." # Configuration unique to this profile kubespawner_override: your_config: "Your value" # Defines the default profile - only use for one profile default: true
The above configuration will show a screen with information about this profile displayed when users start a new server.
Here’s an example with four profiles that lets users select the environment they wish to use.
singleuser: # Defines the default image image: name: jupyter/minimal-notebook tag: 2343e33dec46 profileList: - display_name: "Minimal environment" description: "To avoid too much bells and whistles: Python." default: true - display_name: "Datascience environment" description: "If you want the additional bells and whistles: Python, R, and Julia." kubespawner_override: image: jupyter/datascience-notebook:2343e33dec46 - display_name: "Spark environment" description: "The Jupyter Stacks spark image!" kubespawner_override: image: jupyter/all-spark-notebook:2343e33dec46 - display_name: "Learning Data Science" description: "Datascience Environment with Sample Notebooks" kubespawner_override: image: jupyter/datascience-notebook:2343e33dec46 lifecycle_hooks: postStart: exec: command: - "sh" - "-c" - > gitpuller https://github.com/data-8/materials-fa17 master materials-fa;
This allows users to select from three profiles, each with their own environment (defined by each Docker image in the configuration above).
The “Learning Data Science” environment in the above example overrides the postStart lifecycle hook. Note that when using kubespawner_override the values must be in the format that comply with the KubeSpawner configuration. For instance, when overriding the lifecycle hooks in kubespawner_override, the configuration is for lifecycle_hooks (snake_case) rather than lifecycleHooks (camelCase) which is how it is used directly under the singleuser configuration section. A further explanation for this can be found in this github issue.
kubespawner_override
lifecycle_hooks
lifecycleHooks
singleuser
You can also control the HTML used for the profile selection page by using the Kubespawner profile_form_template configuration. See the Kubespawner configuration reference for more information.
profile_form_template


Office
More
Office Bearers
Holiday Homes
Photo Gallery
Video Gallery
+
Downloads
Links
Contact
Office
More
Holiday Homes
Photo Gallery
Video Gallery
Downloads
Links
Contact
Useful Links
Click on the links
ONLINE SBI
Download
SBI EMS
Download
SBI HRMS
Download
SBI CARD
Download
SBI SMART
Download
SBI
Download
INCOME TAX e-filing
Download
RBI
Download
IIBF
Download
IRCTC
Download
APSRTC
Download
TSRTC
Download


Select can call an arbitrary function on show. If this function returns a promise, it will display a loading indicator while it is being resolved:
You have assigned the task to: {{ user ? user.name : 'No one yet' }}


{% with messages = get_flashed_messages() %}
{% if messages %}
{{ messages[0] }}
{% endif %}
{% endwith %}
Currently, you may submit your project to The Open Source Platform if it is publicly hosted on github. Simply enter your github username and the name of the repo below.