"... an engineer who is not only competent at the analytics and technologies of engineering, but can bring value to clients, team well, design well, foster adoptions of new technologies, position for innovations, cope with accelerating change and mentor other engineers" -- CACM 2014/12
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.
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.
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.
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
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/.
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
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.
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.
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
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:
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
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"
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.
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.
Thanks... that is what I don't understand: Why is NAT64 such a
difficult concept to put into routers and firewalls? We already do NAT
with IPv4 just fine.
I feel like IPv6 adoption would be much faster if there was a transition
mechanism other than dual stacking.
Think: Corporate offices. Rather than renumbering everything inside,
they just turn on NAT64 and now they can begin a slow and controlled
transition.
Remember that if your enterprise network has apps that use literals, or they don't support IPv6, you still need dual-stack in the LANs, but access IPv6-only is just fine.
Other comments:
It’s not s difficult concept but you need to remember NAT44 breaks stuff and NAT64/NAT46 breaks more stuff.
Dual stacking is SIMPLE. REALLY. Turn on IPv6 with the M bit set and configure the DHCPv6 server. If you don’t need that level of control of address assignments leave the M bit off. 99.99% of your machines will just add a second address to the interface without you having to do anything more.
Getting to IPv6 resources from IPv4 address is a *much* harder problem that getting to IPv4 resources from IPv6 which is what you are describing here with the “no renumber everything as they already have a IPv4 address” requirement. NAT64 allows IPv6 devices to get to legacy IPv4 servers. To allow IPv4 devices to get to IPv6 servers you need to map the IPv6 addresses you want to talk to in to a pool of IPv4 addresses and push that mapping to a NAT46 (not NAT64) device.
Go dual stack then, once IPv6 is stable, turn off IPv4 if you want to be single stacked. You are then no longer dependent on the services you want want to access continuing to be offered over IPv4. 464XLAT will only work as a stop gap for IPv4 clients while services are offered over IPv4. After ~20 years of IPv6 being available (Windows XP had IPv6 support and it was not the first major OS to have it) just turn on IPv6.
I recommend that eyeball networks don't run any external recursive server for optimal CDN performance. Yes, some CDNs support other methods, but not all. If not all do, then the requirement remains.
See On Firefox Moving DNS to a Third Party
Upcoming changes to the Linux kernel may include add flow_rule infrastructure capabilities in TC's cls_flower dissector. Some of the flow matching performed by Open vSwitch could be / will be offloaded to the kernel. This capability then allows the flow matching to be off-loaded to hardware for specific match / action pairs. I'm not sure how this would integrate into OpenFlows's complicated sequential table evaluations. They are using the bcm_sf2 driver for intial hardware acceleration testing.
Another recently released patch set is the MPTCP v0.94.1 maintenance release based on Linux v4.14.70 which is "the Multipath TCP Kernel v0.94.1 has been released, containing important
bug-fixes. This release is based on Linux v4.14.70".
From user land is the util-linux v2.33-rc1 which includes things like lsblk, mount/umount, fdisk, wipefs, blkid, ...........
