Networks

using ip link in brief mode:

# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 
eno1             UP             c8:1f:66:ea:43:20 
eno2             UP             c8:1f:66:ea:43:21 
eno3             UP             c8:1f:66:ea:43:22 
eno4             DOWN           c8:1f:66:ea:43:23 

using ip addr in brief mode:

# ip -br a
lo               UNKNOWN        127.0.0.1/8 10.32.0.12/32 ::1/128
eno1             UP
eno2             UP
eno3             UP             10.32.3.12/24 fe80::ca1f:66ff:feea:4322/64
eno4             DOWN

Access to the SFP style:

# ethtool -m enp65s0f0np0
Identifier                                : 0x03 (SFP)
Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector                                 : 0x23 (No separable connector)
Transceiver codes                         : 0x01 0x00 0x00 0x04 0x00 0x04 0x00 0x00 0x0d
Transceiver type                          : Infiniband: 1X Copper Passive
Transceiver type                          : Ethernet: 1000BASE-CX
Transceiver type                          : Passive Cable
Transceiver type                          : Extended: 25G Base-CR CA-N
Encoding                                  : 0x06 (64B/66B)
BR, Nominal                               : 25750MBd
Rate identifier                           : 0x00 (unspecified)
Length (SMF,km)                           : 0km
Length (SMF)                              : 0m
Length (50um)                             : 0m
Length (62.5um)                           : 0m
Length (Copper)                           : 1m
Length (OM3)                              : 0m
Passive Cu cmplnce.                       : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]
Vendor name                               : Mellanox
Vendor OUI                                : 00:02:c9
Vendor PN                                 : MCP2M00-A001E30N
Vendor rev                                : A4
Option values                             : 0x00 0x00
BR margin, max                            : 0%
BR margin, min                            : 0%
Vendor SN                                 : MT2010VB00194
Date code                                 : 200219
Optical diagnostics support               : No

driver and firmware info:

# ethtool -i enp65s0f0np0
driver: mlx5_core
version: 5.15.39-4-pve
firmware-version: 16.34.1002 (MT_0000000183)
expansion-rom-version:
bus-info: 0000:41:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

The dummy interface is not used in the actual routing process in most cases. The dummy ip address is inserted into the local route table as a local address (check it out yourself: ip ro sh table local). Ingress packets from all interfaces are checked against this table first (as it is the maximum priority rule in the ip rule), and if a local-type route matches, the packet is queued for local delivery. Egress packets are even simpler: your default route will point towards your physical interface; the packets will be queued directly to that interface's queues and you'll keep all your regular GSOs and GROs -- at least the ones that are managed by the kernel.

There are standard ways many nics can offload packets: TSO (tcp segment offloading), gso (generic segment offloading), gro (generic receive offload), lro (large receive offload) are the common ones. You can see which ones are enabled with ethtool -k interface_name, interface usually has to be down to change them.

From the P4-dev mailing list, an interesting tool which deep dives wifi, P4, the kernel, ...

you may want to look at the BATMAN and P4 examples in Mininet-WiFi: Manet Routing Protocols or P4 Programming Protocol-Independent Packet Processors .

BTW, we recently fully open-sourced here: mn-wifi-ebook.

The English version of the Mininet-WiFi book: The Mininet-WiFi Book

Found on a email list:

The Netgear GS108T is my typical go-to "not a dumb switch". 8 ports for about $80.

Make sure you get the v3 if you want most of the modern IPv6 L2 features (you also get some very limited L3 capabilities).

Extra bonus with the GS108Tv3, and anything else based on the RTL8380, is that you can run OpenWrt on it.

   [ Noah Meyerhans ]
   * net: Use fq_codel as the default network qdisc (Closes: #890343)

From ticket #890343:

by default Debian uses the pfifo_fast network queuing algorithm:

# tc -s qdisc show
[...]
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 413728102 bytes 475015 pkt (dropped 0, overlimits 0 requeues 785)
 backlog 0b 0p requeues 785

The systemd source package contains this file:

  ./systemd-237/sysctl.d/50-default.conf:net.core.default_qdisc = fq_codel

whose purpose is to set the default queuing algorithm to fq_codel.  
According to the NEWS file, this is a better alternative:

        * The default sysctl.d/ snippets will now set:

                net.core.default_qdisc = fq_codel

          This selects Fair Queuing Controlled Delay as the default
          queuing discipline for network interfaces. fq_codel helps
          fight the network bufferbloat problem. It is believed to be
          a good default with no tuning required for most workloads.
          Downstream distributions may override this choice. On 10Gbit
          servers that do not do forwarding, "fq" may perform better.
          Systems without a good clocksource should use "pfifo_fast".

However the 50-default.conf file is not in the Debian binary package.
Is this intentional or an omission?
Could it be possible to enable fq_codel by default?

Flexible routing has now come down in price with the Raspberry Pi Compute Module 4 IoT Router Carrier Board Mini which takes a Raspberry Pi Compute Module 4 and places it on a Compute Module 4 IoT Router Carrier Board Mini.

Here is someone building a Raspberry Pi Firewall and Router with DF Robot Dual NIC with Ubuntu.

How to get stats at all of the different points in the stack to track down reasons for dropped packets:

• ethtool -S for h/w and driver
• tc -s for drops by the qdisc
• /proc/net/softnet_stat for drops at the backlog layer
• netstat -s for network and transport layer
• ip -s

The key is the 'ether' specifier. The -e option shows the mac address in the output:

$ sudo tcpdump -n -i vlan50 ether host e4:54:e8:29:44:2d or ether host ff:ff:ff:ff:ff:ff -vv -e

The country code is not read from ACPI but from the EEPROM of the WiFi-card (0x0 "World Regulatory Domain" by default).

How to Build your Own Wireless Router (Part 3) - kernel requires code patch to enable 5GHz operations.

ath10k locks to regulatory domain US on ACPI platforms

From Phoronix - Linux 5.6 To Bring FQ-PIE Packet Scheduler To Help Fight Bufferbloat, there are some example configurations for using different buffering mechanisms (Implementing the Flow Queue PIE AQM in the Linux Kernel).

For wireless clients:

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control = bbr

and fq_codel (codel) is better suited for router.

Another possibility:

I had pretty amazing results with cake. I prefer it over fq_codel and it is now part of main line since 4.19.

Cake - Common Applications Kept Enhanced

In the past the internet would just grind to a halt when the Apple devices started cloud syncing. They would totally swamp the outgoing bandwidth. Now nobody notices when an Apple device is syncing.

Open firmware for small routers for congestion management:

The OpenWrt issue with 4MB has to do with using newer kernels. For those devices, DD-WRT is a better bet (still on kernel 3.10).

Courtesy of 3 quick ways to reduce your attack surface on Linux, a command to identify open ports and identify the associated application:

$ ss -tulnp --no-header | awk '{print($1, $5, $7)}'
udp 0.0.0.0:32770 users:(("vlc",pid=2786557,fd=39))
udp 0.0.0.0:32771 users:(("vlc",pid=2786557,fd=40))
udp 127.0.0.1:123
udp 0.0.0.0:123
udp 0.0.0.0:631
udp 0.0.0.0:37019
udp 0.0.0.0:5353
udp 0.0.0.0:39276 users:(("vlc",pid=2786557,fd=50))
udp 0.0.0.0:39277 users:(("vlc",pid=2786557,fd=51))
tcp 0.0.0.0:61209
tcp 127.0.0.1:25
tcp 127.0.0.1:5433
tcp 0.0.0.0:8794
tcp 127.0.0.1:3493
tcp 127.0.0.1:5101 users:(("ssh",pid=899751,fd=4))
tcp 127.0.0.1:5102 users:(("ssh",pid=2187130,fd=4))
tcp 127.0.0.1:5201 users:(("ssh",pid=2186389,fd=5))
tcp 127.0.0.1:5202 users:(("ssh",pid=2186389,fd=7))
tcp 0.0.0.0:22
tcp 127.0.0.1:631
tcp 127.0.0.1:5432
...

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.

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.

2019/02/18 From a different direction, via the Debian Bugs list, I've come across Lamobo R1 which is another name for the Banana Pi R1. The page has some additional information, and by cruising to the main page, additional AllWinner SoC info can be obtained.

In addition, Armbian Build on GitHub offers the code for building Arm kernels on these types of boards.

Kernel CI shows results of Kernel Builds on various devices, with an example entry of Kernel 5.0 booting on Banana Pi R2

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.