Knowledge base : Knowledge Base > ByteBlower > Examples

This article collects a number of example BPF filters. The filters are grouped by the OSI layer.

These BPF filters are used throughout the ByteBlower API. Both for counting traffic, as for selecting the traffic to save in PCAP capture.

Layer 3 Network: IP, IP6, ARP, ...

Example Description
ip Captures all TCP traffic regardless of lower transport layers
ip6 Selects all IP6 traffic. This is not a default filter but has been added to ByteBlower.
arp Captures only messages from the adress resolution protocol.
icmp All ICMP traffic of which ping is the most known application.
igmp IPv4 Multicast traffic

Layer 4 Transport: TCP and UDP

This is the transport layer, ByteBlower supports the two major families: TCP and UDP. Both protocols can be used over IPv4 or IPv6. When  the network layer isn't explicitly mentioned in the filter all traffic from both is captured.

In the examples below we'll use tcp by default, but the last 3 example filters can also be used with udp.

Example Description
tcp Captures all TCP traffic regardless of lower layers transport layers
udp Same as above, but for UDP
ip and tcp Capture only traffic over IP
ip6 and tcp Selects for ip6 and TCP. This not a default BPF filter.
(ip or ip6) and tcp Same behavior as the first filter. This line is only included as an example, prefer to use the first one.

Filter on ports

Both TCP and UDP use ports. In the examples below, the filters are shown for both protocols.

TCP UDP Description
tcp port 80 udp port 80 Captures all traffic from or to port 80. Both directions are collected.
This mainly useful for TCP.
tcp src port 80 udp src port 80 Capture only traffic transmitted from port 80.
tcp dst port 80 udp dst port 80 The inverse of the one above, captures all traffic with port 80 as destination

Filter on TCP flags

The filters below are TCP specific. They filter on specific flags. This makes the following filters very useful to capture only the start of traffic, the end or any abnormal behavior.

This type of filters use the array operators of BPF. The filter tcp[13:1] fetches a single byte at offset 13; i.e. the fourteenth byte of the TCP header. This can be written even easier using the tcpflags shorthand. That is used most heavily in the filters below.

Other shorthands are those for those to select the individual bits of the tcp-flags: tcp-fin (= 0x01),

  • tcp-fin, with value 0x01
  • tcp-syn, 0x02
  • tcp-rst, 0x04
  • tcp-push, 0x08
  • tcp-ack, 0x10
  • tcp-urg, 0x20

The BPF syntax has no such definitions for the slightly newer TCP flags: ECE (0x40), CWR (0x80) and NS (0x100). These flags are related Congestion Notification (rfc3168, rfc3540). Especially this last one poses a challenge, it's the final example in the list below.

TCP Description
tcp[tcpflags] == tcp-syn Selects the initial  SYN packet. This is the initiation of the session by the TCP client.
tcp[tcpflags] == (tcp-syn + tcp-ack) This SYN+ACK response from the TCP server.
(tcp[tcpflags] & tcp-syn) > 0 All packets with the SYN flag enabled. This filter matches the traffic of the above two.
This filter uses the bitwise and operator ('&') to select the the Syn bit out of the TCP flags.
(tcp[tcpflags] & tcp-fin) > 0 All packets with a Fin flag. Similar to the filter directly above, this also selects packets with Fin + Ack.
tcp[tcpflags] == tcp-rst Selects all TCP Resets
(tcp[tcpflags] & tcp-fin) > 0 All packets with a Fin flag.
(tcp[tcpflags] & 0x40)  > 0 This filters captures all packets with the ECE flag enabled. Both the initial negation is thus captured, as well as a TCP session echoing congestion on the network.
(tcp[tcpflags] & (0x40 + tcp-syn))  == (0x40 + tcp-syn) Like the above, this filter selects packets with ECE flag enabled. Extra in this filter is to only select the initial handshake. This is done by adding the tcp-syn value.
In other words, this filters all session that capable to react to Explicit Congestion Notifications.
(tcp[tcpflags] & (0x40 + tcp-syn))  == 0x40 The filter is the inverse of the above. It also packets with the ECE flags but also requires for these packets to have the tcp-syn flag disabled.
This filters thus on actual cases where the session reactes to an explicit congestion notification.
(tcp[12:2] & 0x100) > 0 As promised, in the last filter the NS flag, or ECN-nonce is used.
This flags is experimental, and makes the filter much complex.

The NS flag has value 0x100, this larger the usual single byte for the TCP flags.

As a result, 12:2 is used instead of tcpflags. This expression selects 2 bytes at an offset of 12 bytes in the TCP header.

The remainder of this BPF filter is similar to the above.

GitHub Projects - Frame Blasting Modifiers

Following the previous article (Insert Link), we are going to explore some modifications to the frame and frameblasting flows. This will enable us to utilize more of the GUI's features; in particular the time and frame-size modifiers. These features create variations in the throughput which simulate non-uniform traffic flows.


We will look at 3 scenarios: 

  • Growing frame size - Frame increases size up to a maximum.

  • Random size

  • Bursty traffic - Frames sent in bursts  (1 second intervals).   


Each one of the tests will run vs a default frame for comparison purposes.


Let's go!



Part 1. Docking the Ports

When you open the .bbp file you will see the following displayed:


  • 2 ports configured with DHCP

  • Port 2 is NAT enabled


1.1 Connect the Ports to the Trunk Interface.


Port 1 and Port 2 are set are configured for DHCP so they should be docked onto trunk interfaces compatible with DHCP.

You will see that Port_2 has been NAT enabled but this is not strictly necessary.



  • In this example, trunk 1-3 and 1-4 are such interfaces.




Part 2. Frame Modifiers


In this part we will look at the different frames and frame blasting flows with their modifications. Frames can be modified in terms of their size (number of bytes) as well as adding a modifier at the level 4 layer. This can mean adding a payload offset. Another feature is changing the UDP source and destination ports at the level 4 layer (see below).

2.1 Frames


  • Two frames have been created with the default size of 1024 bytes. 

  • Going to the layer 4 setting we can see that Frame_1 and Frame_2 have different source and destination ports.




2.2 Frame Blasting Flows


In this step, we will look at the different frame blasting flows and how they transmit the data frames. The settings of the 'Frame Blasting' tab enable the user to adjust the thoughput speed as well as change the uniformity of the throughput. A frame blasting flow will take the frame defined in the previous step and repeatedly 'blast' it from source to destination.


In this example:


  • The growing size frame will produce a sawtooth throughput.

  • The random size frame modifier will generate random frame sizes between a minimum (60 bytes) and a maximum (1514 bytes).

  • The bursty traffic frame uses a time frame modifier to produce bursts of traffic containing 5000 frames with an interburst gap of 1.2 seconds.




2.3 Flow


The flow is the traffic that will be sent by the ByteBlower server. Here we can define the source and destination of the generated traffic.


  • Select the source and destination ports. 

  • In this demonstration we will send the frames form Port 1 → Port 2 which are connected back-to-back.

  • A latency distribution has been included.