Entries by Raymond P. Burkholder

• Pressure Stall Information (PSI), to be upstreamed to kernel 4.20 possibly, provides for the first time a canonical way to see resource pressure increases as they develop, with new pressure metrics for three major resources—memory, CPU, and IO.
• handystats - C++ library for collecting user-defined in-process runtime statistics with low overhead

• crowd sourced tower map
• FCC Listings - Sizable towers need to be registered with the FAA

Learned at Samsung Phone Users Perturbed to Find They Can't Delete Facebook:

• 1. Download Android platform tools for your platform: https://developer.android.com/studio/releases/platform-tools...
• 2. Unzip it, open cmd and head to the unpacked folder.
• 3. Enable developer tools and USB debugging in your Android.
• 4. List packages avaiable:

  adb shell pm list packages

• 5. Delete the unwanted package:

  adb shell pm uninstall --user 0 com.package.name

There are a few web sites which have had quite a bit of work done to them to make available colour selections.

I think paletton is probably my favorite. They have a two part selector choosing a colour once choosing a variant of: a) monochromatic, b) adjacent 3 colour, c) triad 3 colour, d) tetrad 4 colour, or e) free style with 4 colour. Once chosen, you can emit the colour selection as html, css, sas, text, or a couple of other styles.

Next up is the Adobe Color CC. It has variants of analogous, monochromatic, triad, complementary, compound, shades, and custom.

A few other choosers:

• Colors on the Web Color Wizard
• HTML Color Picker from w3schools
• Color Emotion Guide using a chart of existing logos

I was happily building some code to filter and manage traffic in Open vSwitch via C++ communicating via the OpenFlow interface. Then, ... well, I realized I was missing some things. In OVS's documentation, much of it uses the command line tools to inject the rules. Some of those examples show automatic mac swaps and such. hmm, Nicera extensions but not in the openflow specification. Which means changing code to interface to other api bind points of OVS.

I had also written some code to interface to the OVSDB so I could list interfaces, detect changes, and obtain statistics.

In stepping back and thinking about this, I came across a youtube video on youtube:

which talks about Stratum and Next-Gen SDN. I wasn't so interested in the Stratum concept in as much as I was interested in the p4.org concept of writing code to filter packets.

From a Linux network stack perspective, a little closer to home, there is eBGP and XDP. The best diagram I've seen of XDP and eBGP hook points is on page 3 of The eXpress Data Path: Fast Programmable Packet Processing inthe Operating System Kernel which was presented at 2018 SigComm CoNEXT Conference. As an aside, another interesting paper there is " Leveraging eBPF for programmable network functions with IPv6 Segment Routing".

Other references:

• BPF and XDP Reference Guide
• BPF Compiler Collection (BCC)
• Linux Plumbers Conference 2018 BPF Microconference
• Linux Plumbers Conference 2018 Networking Track
• Linux Bridge, l2-overlays, E-VPN!
• Scaling bridge forwarding database
• Lifetime of BPF objects
• P4-16 Language Specification
• net: add bpfilter
• AF_XDP
• Linux Network Programming with P4
• bpf - perform a command on an extended BPF map or program
• BPF - BPF programmable classifier and actions for ingress/egress queueing disciplines
• 7 tools for analyzing performance in Linux with bcc/BPF

In Debian with Kernel "4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22)", the following are set:

# grep -i bpf /boot/config-4.19.0-1-amd64
CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
# CONFIG_BPF_JIT_ALWAYS_ON is not set
CONFIG_IPV6_SEG6_BPF=y
CONFIG_NETFILTER_XT_MATCH_BPF=m
# CONFIG_BPFILTER is not set
CONFIG_NET_CLS_BPF=m
CONFIG_NET_ACT_BPF=m
CONFIG_BPF_JIT=y
# CONFIG_BPF_STREAM_PARSER is not set
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
# CONFIG_BPF_KPROBE_OVERRIDE is not set
CONFIG_TEST_BPF=m
# grep -i xdp /boot/config-4.19.0-1-amd64
# CONFIG_XDP_SOCKETS is not set

Install the the BPF Compiler Tools with:

apt install libbpfcc libbpfcc-dev bpfcc-tools python-bpfcc

bcc header files are in '/usr/include/bcc/'. Many tools with suffic 'bpfcc' are installed in /usr/sbin. There is a man page for each. Many many examples can be found in /usr/share/doc/bpfcc-tools/examples/doc/.

7 tools for analyzing performance in Linux with bcc/BPF covers execsnoop, opensnoop, xfsslower, biolatency, tcplife, gethostlatency and trace. The article also refers to bcc Python Developer Tutorial. Also referenced was bpftrace. A better page referencing these tools is Linux Extended BPF (eBPF) Tracing Tools. eBPF: One Small Step is an early Brendan Gregg article on eBPF tracing.

Going even deeper into the woods, another tool referenced includes SystemTap which has a Debian Package.

The BCC has a reference guide. Most of the preceding has to do with tracing. Now to get to packet manipulation.

For compiling, some packages:

apt install clang llvm clang-7-doc ncurses-doc libomp-7-doc llvm-7-doc

Some items from Making the Kernel’s Networking Data Path Programmable with BPF and XDP:

• 11 64bit registers, 32bit subregisters, up to 512bytes stack
• Instructions 64bit wide, max 4096 per program
• BPF calling convention for helpers allows for efficient mapping: a) R0 →return value from helper call, b) R1 - R5 →argument registers for helper call, c) R6 - R9 → callee saved, preserved on helper call
• /proc/kallsyms exposure of JIT image as symbol for stack traces
• Since LLVM 3.7: clang -O2 -target bpf -c foo.c -o foo.o
• To show ability: llc --version | grep bpf
• Assembler output through -S supported
• llvm-objdump for disassembler and code annotations (via DWARF)
• C example walkthrough: tools/testing/selftests/bpf/testl_4lb.c
• when attaching to generic XDP kernel driver via iproute2: ip link set dev eno1 xdpgeneric obj prog.o

In building an openflow controller, the controller needs to perform some packet interception, inspection, and modification activities. This is easy from a UDP perspective. But when the openflow engine forwards the complete packet, mac addresses and all, the packets need to be decoded. And for TCP, there are various connection oriented states which need to be taken in to account when trying to perform deep packet inspection.

This means creating a purpose built TCP stack to perform the state management, or someone make use of existing tools to perform the state management. In my searches, I came across:

• chobits/tapip - a user-mode TCP/IP stack based on linux tap device - with a basic state machine - but I don't need the tun/tap integration as I already have the buffered inbound and outbound raw packets.
• tass-belgium/picotcp - PicoTCP is a free TCP/IP stack implementation - this is better as it has an api for providing timers and packet-in/packet-out flows. Documentation looks good.
• hacker's userspace TCP/IP stack with a five part TCP stack tutorial at www.saminiir.com. It has a simple and self contained state machine.
• lwIP mirror - an embeddable tcp stack with a number of bundled applications.

The book "TCP/IP Illustrated, Volume 1, 2e" discusses timers extensively, something useful, as I am considering putting in the basic state handling code manually, rather than using one of the above libraries.

From a mailing list:

One way to avoid knowing or typing the specific LL address is to ping the all-nodes link scoped multicast address, and looking for the address you're after in the response.

E.g. under Linux, the following command will show all IPv6 link local addresses on the link (assuming they reply to an ICMPv6 echo request) that respond within 1 second:

# ping -w 1 -I wlp6s0 ff02::1
ping6: Warning: source address might be selected on device other than wlp6s0.
PING ff02::1(ff02::1) from :: wlp6s0: 56 data bytes
64 bytes from fe80::e54:15ff:fe66:3b9a%wlp6s0: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from fe80::aca7:4aff:fed2:a7dd%wlp6s0: icmp_seq=1 ttl=64 time=3.47 ms (DUP!)
64 bytes from fe80::400:55ff:fe40:5%wlp6s0: icmp_seq=1 ttl=64 time=3.51 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:6709%wlp6s0: icmp_seq=1 ttl=64 time=216 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:66ff%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::fe90:d8d2:7ec5:3c8%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::a65d:36ff:fe40:e31c%wlp6s0: icmp_seq=1 ttl=64 time=250 ms (DUP!)

--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +6 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.074/130.707/249.971/111.633 ms

From a mailing list:

To the thief who stole my anti-depressants: I hope you're happy

-- seen somewhere on the Internet on a photo of a billboard

From a Debian mailing list:

You can use a serial console or netconsole to send the kernel log to another computer:

• https://www.kernel.org/doc/html/latest/admin-guide/serial-console.html
• https://www.kernel.org/doc/Documentation/networking/netconsole.txt

I saw a debian bug report Installation was successfully at BananaPi. When initially looking at the Banana Pi, as it has a version with a number of network interfaces, I didn't readily see the tooling necessary for booting images.

The bug report shows that Debian now has native images available, and similar images can be found in the Buster and Sid distributions. There are also Beagle Bone Black images in there.

Random links I picked up for building custom installs:

• Building a pure Debian armhf rootfs - good writeup by Tim Fletcher
• DebianInstallerArmOtherPlatforms - Howto install Debian/armel with a custom kernel - links on the page lead to other excellent articles
• debian debootstrap - from one of the primary contributors to Banana Pi builds
• Banana Pi BPI-R2 Wiki - much updated since I last landed on it
• Searching testing people for hdmi + wifi in Kernel 4.16 - forum entry
• How to build an Ubuntu/Debian SD image from scratch - with some bonding notes
• Banana Pi BPI-R64 - wonder when the release date is

Kind of related, Redhat has a summary article of Introduction to Linux interfaces for virtual networking. Excellent summary of many interface types in Linux.

An interesting library I came across. It currently has CVE-2018-4013 associated, but nonetheless, it provides a solution to some things I've been considering:

LIVE555 Streaming Media "forms a set of C++ libraries for multimedia streaming, using open standard protocols (RTP/RTCP, RTSP, SIP) ... These libraries ... can be used to build streaming applications ... The libraries can also be used to stream, receive, and process MPEG, H.265, H.264, H.263+, DV or JPEG video, and several audio codecs ... They can easily be extended to support additional (audio and/or video) codecs, and can also be used to build basic RTSP or SIP clients and servers"

Comment:

Can you write the code which tells you when you have the no IPv4 “thing” without trying the IPv4 thing on a network which by definition should not have the IPv4 thing where you want people not to try the IPv4 thing?

Response:

We've been here before - I don't think there is any way to write an algorithm that can differentiate between "I can see IPv4 chatter and I should join in because this network is completely IPv6 only yet" and "I can see IPv4 chatter and I shouldn't join in because this network is supposed to be IPv6 only but some other nodes don't understand that". If a key part of the algorithm is "there aren't other IPv4 nodes chattering" then you only need one device on the network to prevent everything else shutting down IPv4.

Because ovsdb is a generic database tool, some one may have build other schemas. But for a native open vswitch install, this is the default state:

# ovsdb-client list-dbs
Open_vSwitch
_Server

It is possible to add a tcp connection to gain access to the database:

# ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640
# netstat -antp |grep ovs
tcp        0      0 0.0.0.0:6640            0.0.0.0:*               LISTEN      746/ovsdb-server
tcp        0      0 127.0.0.1:57424         127.0.0.1:6633          ESTABLISHED 397/ovs-vswitchd

But on linux, there is an existing linux stream available:

# lsof|grep ovsdb|grep STREAM
ovsdb-ser   746                   root    5u     unix 0x000000001740f722        0t0   59425581 /var/run/openvswitch/db.sock type=STREAM
ovsdb-ser   746                   root   16u     unix 0x0000000021edd23e        0t0      12914 /var/run/openvswitch/db.sock type=STREAM
ovsdb-ser   746                   root   19u     unix 0x000000001b392a81        0t0      20287 /var/run/openvswitch/ovsdb-server.746.ctl type=STREAM

# ovs-vsctl list open_vswitch
_uuid               : 8cfeb1c0-34ca-4f91-a162-7e9aef141344
bridges             : [e65f5e97-36ec-45e3-b83e-64129dae61d3]
cur_cfg             : 65
datapath_types      : [netdev, system]
db_version          : "7.16.1"
dpdk_initialized    : false
dpdk_version        : none
external_ids        : {hostname="nuc8i7hvk01.burkholder.net", rundir="/var/run/openvswitch", system-id="02700cd5-96f5-4b4e-90b4-5e67fe06abf7"}
iface_types         : [erspan, geneve, gre, internal, "ip6erspan", "ip6gre", lisp, patch, stt, system, tap, vxlan]
manager_options     : []
next_cfg            : 65
other_config        : {}
ovs_version         : "2.10.1"
ssl                 : []
statistics          : {}
system_type         : debian
system_version      : []

# ovs-appctl dpif/show
system@ovs-system: hit:50661581 missed:207452
  ovsbr0:
    eno1 5/3: (system)
    enp5s0 2/1: (system)
    ovsbr0 65534/2: (internal)
    veth-nvpn-v90 6/6: (system)
    vlan110 4/5: (internal)
    vlan90 3/4: (internal)

# ovs-appctl dpctl/show -s
system@ovs-system:
  lookups: hit:50661616 missed:207458 lost:0
  flows: 6
  masks: hit:211426886 total:10 hit/pkt:4.16
  port 0: ovs-system (internal)
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1428 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:177489 (173.3 KiB)
  port 1: enp5s0
    RX packets:19439356 errors:0 dropped:0 overruns:0 frame:0
    TX packets:30374161 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:10608677166 (9.9 GiB)  TX bytes:29950322693 (27.9 GiB)
  port 2: ovsbr0 (internal)
    RX packets:333032 errors:0 dropped:29829 overruns:0 frame:0
    TX packets:1428 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:23060625 (22.0 MiB)  TX bytes:177489 (173.3 KiB)
  port 3: eno1
    RX packets:6037565 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5719808 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:4726094728 (4.4 GiB)  TX bytes:3277870100 (3.1 GiB)
  port 4: vlan90 (internal)
    RX packets:0 errors:0 dropped:274558 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:0
  port 5: vlan110 (internal)
    RX packets:0 errors:0 dropped:274101 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:0
  port 6: veth-nvpn-v90
    RX packets:5000388 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5788139 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:3055006377 (2.8 GiB)  TX bytes:4647166781 (4.3 GiB)

• Melexis at Mouser
• Melexis MLX90640 Far Infrared Thermal Sensor is a fully calibrated 32 x 24 pixel thermal IR array in a compact
• Excelitas CoolEYE IR Imagers
• AMG88x3,4 Grid-EYE® Sensor Datasheet
• 16 x 4 Infra-Red Array by McLaren Technologies

Sometimes, you just don't know what is on your network. A couple ways of finding out include using nmap or arp-scan.

An easy install:

sudo apt install arp-scan nmap

And an easy use with some basic defaults (the Unknown ones are LXC containers with manual mac addresses, and Cadmus Computer Systems is a VirtualBox device):

$sudo arp-scan --interface=vlan90 --localnet
Interface: vlan90, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)
10.55.90.1      00:13:3b:0f:59:24       Speed Dragon Multimedia Limited
10.55.90.14     08:00:27:de:fc:9d       Cadmus Computer Systems
10.55.90.21     0a:00:55:90:00:ab       (Unknown)
10.55.90.22     0a:00:55:90:00:0c       (Unknown)
10.55.90.23     0a:00:55:90:00:23       (Unknown)
10.55.90.31     f0:ad:4e:03:64:7f       Globalscale Technologies, Inc.

8 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.5: 256 hosts scanned in 3.155 seconds (81.14 hosts/sec). 6 responded

With nmap, it knows about the mis-named mac:

$ sudo nmap -sn 10.55.90.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2018-09-29 20:25 MDT
Nmap scan report for 10.55.90.1
Host is up (0.00032s latency).
MAC Address: 00:13:3B:0F:59:24 (Speed Dragon Multimedia Limited)
Nmap scan report for 10.55.90.14
Host is up (-0.10s latency).
MAC Address: 08:00:27:DE:FC:9D (Oracle VirtualBox virtual NIC)
Nmap scan report for 10.55.90.21
Host is up (-0.100s latency).
MAC Address: 0A:00:55:90:00:AB (Unknown)
Nmap scan report for 10.55.90.22
Host is up (-0.100s latency).
MAC Address: 0A:00:55:90:00:0C (Unknown)
Nmap scan report for 10.55.90.23
Host is up (-0.087s latency).
MAC Address: 0A:00:55:90:00:23 (Unknown)
Nmap scan report for 10.55.90.31
Host is up (0.00074s latency).
MAC Address: F0:AD:4E:03:64:7F (Globalscale Technologies)
Nmap scan report for 10.55.90.10
Host is up.
Nmap done: 256 IP addresses (7 hosts up) scanned in 3.31 seconds

With these specific commands, arp-scan may see things which nmap may not, ie, firewall that are blocking pings. nmap probably has a mode for scanning similarly to arp-scan.