Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

packet.pkt(1) [centos man page]

PACKET.PKT(1)							 packet.pkt 1.0.1						     PACKET.PKT(1)

NAME
packet.pkt - Pkt module DESCRIPTION
Provides the object for a packet and the string representation of the packet. This object has an attribute for each of the layers in the packet so each layer can be accessed directly instead of going through each layer. To access the nfs layer object you can use 'x.nfs' instead of using 'x.ethernet.ip.tcp.rpc.nfs' which would very cumbersome to use. Also, since NFS can be used with either TCP or UDP it would be harder to to access the nfs object independently or the protocol. Packet object attributes: Pkt( record = Record information (frame number, etc.) ethernet = ETHERNET II (RFC 894) object ip = IPv4 object tcp = TCP object rpc = RPC object nfs = NFS object ) CLASSES
class Pkt(baseobj.BaseObj) Packet object Usage: from packet.pkt import Pkt x = Pkt() Methods defined here: --------------------- __str__(self) String representation of object The representation depends on the verbose level set by debug_repr(). If set to 0 the generic object representation is returned. If set to 1 the representation of is condensed into a single line. It contains, the frame number, IP source and destination and/or the last layer: '1 0.386615 192.168.0.62 -> 192.168.0.17 TCP 2049 -> 708, seq: 3395733180, ack: 3294169773, ACK,SYN' '5 0.530957 00:0c:29:54:09:ef -> ff:ff:ff:ff:ff:ff, type: 0x806' '19 0.434370 192.168.0.17 -> 192.168.0.62 NFS v4 COMPOUND4 call SEQUENCE;PUTFH;GETATTR' If set to 2 the representation of the object is a line for each layer: 'Pkt( RECORD: frame 19 @ 0.434370 secs, 238 bytes on wire, 238 bytes captured ETHERNET: 00:0c:29:54:09:ef -> e4:ce:8f:58:9f:f4, type: 0x800(IPv4) IP: 192.168.0.17 -> 192.168.0.62, protocol: 6(TCP), len: 224 TCP: src port 708 -> dst port 2049, seq: 3294170673, ack: 3395734137, len: 172, flags: ACK,PSH RPC: CALL(0), program: 100003, version: 4, procedure: 1, xid: 0x1437d3d5 NFS: COMPOUND4args(tag='', minorversion=1, argarray=[nfs_argop4(argop=OP_SEQUENCE, ...), ...]) )' SEE ALSO
baseobj(1) BUGS
No known bugs. AUTHOR
Jorge Mora (mora@netapp.com) NFStest 1.0.2 10 April 2013 PACKET.PKT(1)

Check Out this Related Man Page

SHOREWALL-EXCLUSION(5)						  [FIXME: manual]					    SHOREWALL-EXCLUSION(5)

NAME
exclusion - Exclude a set of hosts from a definition in a shorewall configuration file. SYNOPSIS
!address-or-range[,address-or-range]... !zone-name[,zone-name]... DESCRIPTION
The first form of exclusion is used when you wish to exclude one or more addresses from a definition. An exclaimation point is followed by a comma-separated list of addresses. The addresses may be single host addresses (e.g., 192.168.1.4) or they may be network addresses in CIDR format (e.g., 192.168.1.0/24). If your kernel and iptables include iprange support, you may also specify ranges of ip addresses of the form lowaddress-highaddress No embedded whitespace is allowed. Exclusion can appear after a list of addresses and/or address ranges. In that case, the final list of address is formed by taking the first list and then removing the addresses defined in the exclusion. Beginning in Shorewall 4.4.13, the second form of exclusion is allowed after all and any in the SOURCE and DEST columns of /etc/shorewall/rules. It allows you to omit arbitrary zones from the list generated by those key words. Warning If you omit a sub-zone and there is an explicit or explicit CONTINUE policy, a connection to/from that zone can still be matched by the rule generated for a parent zone. For example: /etc/shorewall/zones: #ZONE TYPE z1 ip z2:z1 ip ... /etc/shorewall/policy: #SOURCE DEST POLICY z1 net CONTINUE z2 net REJECT /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT all!z2 net tcp 22 In this case, SSH connections from z2 to net will be accepted by the generated z1 to net ACCEPT rule. In most contexts, ipset names can be used as an address-or-range. Beginning with Shorewall 4.4.14, ipset lists enclosed in +[...] may also be included (see shorewall-ipsets[1] (5)). The semantics of these lists when used in an exclusion are as follows: o !+[set1,set2,...setN] produces a packet match if the packet does not match at least one of the sets. In other words, it is like NOT match set1 OR NOT match set2 ... OR NOT match setN. o +[!set1,!set2,...!setN] produces a packet match if the packet does not match any of the sets. In other words, it is like NOT match set1 AND NOT match set2 ... AND NOT match setN. EXAMPLES
Example 1 - All IPv4 addresses except 192.168.3.4 !192.168.3.4 Example 2 - All IPv4 addresses except the network 192.168.1.0/24 and the host 10.2.3.4 !192.168.1.0/24,10.1.3.4 Example 3 - All IPv4 addresses except the range 192.168.1.3-192.168.1.12 and the network 10.0.0.0/8 !192.168.1.3-192.168.1.12,10.0.0.0/8 Example 4 - The network 192.168.1.0/24 except hosts 192.168.1.3 and 192.168.1.9 192.168.1.0/24!192.168.1.3,192.168.1.9 Example 5 - All parent zones except loc any!loc FILES
/etc/shorewall/hosts /etc/shorewall/masq /etc/shorewall/rules /etc/shorewall/tcrules SEE ALSO
shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) NOTES
1. shorewall-ipsets http://www.shorewall.net/manpages/shorewall-ipsets.html [FIXME: source] 06/28/2012 SHOREWALL-EXCLUSION(5)
Man Page

Featured Tech Videos