Fixing LLDPd Default PortID Configuration

LLDPd is a great program written by Vincent Bernat which implements 802.1ab for unix based OSes.

https://vincentbernat.github.io/lldpd/

Debian and Ubuntu offer this lovely utility right in their default software repositories meaning that is only an apt-get install away. One caveat is that the default configuration provides the MAC address of the interface instead of the interface name which is unusual compared to the implementation of LLDP in use on most network OS vendors like Cumulus, Cisco, Juniper, Arista etc…

Here is what is sent by default as seen by the far side of the link:

-------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------
Interface: swp4, via: LLDP, RID: 2, Time: 0 day, 00:00:12
 Chassis: 
 ChassisID: mac 52:54:00:b9:e3:98
 SysName: server1
 SysDescr: Ubuntu 16.04 LTS Linux 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64
 TTL: 120
 MgmtIP: 192.168.121.53
 MgmtIP: fe80::5054:ff:feb9:e398
 Capability: Bridge, off
 Capability: Router, off
 Capability: Wlan, off
 Capability: Station, on
 Port: 
 PortID: mac 44:38:39:00:00:06
 PortDescr: eth1
 PMD autoneg: supported: yes, enabled: yes
 Adv: 10Base-T, HD: yes, FD: yes
 Adv: 100Base-TX, HD: yes, FD: yes
 Adv: 1000Base-T, HD: no, FD: yes
 MAU oper type: 1000BaseTFD - Four-pair Category 5 UTP, full duplex mode
-------------------------------------------------------------------------

Luckily there are knobs to change that behavior. The configuration below will set LLDPd to provide a more similar configuration like a network device might expect.

sudo apt-get install lldpd
sudo bash -c "echo 'configure lldp portidsubtype ifname' > /etc/lldpd.d/port_info.conf"
sudo systemctl restart lldpd.service

 

Here is the net result of the changed configuration:

-------------------------------------------------------------------------
Interface: swp4, via: LLDP, RID: 2, Time: 0 day, 00:00:21
 Chassis: 
 ChassisID: mac 52:54:00:b9:e3:98
 SysName: server1
 SysDescr: Ubuntu 16.04 LTS Linux 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64
 TTL: 120
 MgmtIP: 192.168.121.53
 MgmtIP: fe80::5054:ff:feb9:e398
 Capability: Bridge, off
 Capability: Router, off
 Capability: Wlan, off
 Capability: Station, on
 Port: 
 PortID: ifname eth1
 PortDescr: eth1
 PMD autoneg: supported: yes, enabled: yes
 Adv: 10Base-T, HD: yes, FD: yes
 Adv: 100Base-TX, HD: yes, FD: yes
 Adv: 1000Base-T, HD: no, FD: yes
 MAU oper type: 1000BaseTFD - Four-pair Category 5 UTP, full duplex mode
-------------------------------------------------------------------------

Handling SSH Protocol Links in Chrome (on Linux)

As a network engineer, I have been annoyed by not being able to click on SSH links in webpages for years while running Linux.

After digging in a bit I was able to find this solution which works for SSH in Chrome.

I’m running Ubuntu 16.04 in my setup.

My SSH URL links look like this:

ssh:///user@host:port

Here is the process I used to get these links working.

#Check which handler is setup for SSH
xdg-mime query default x-scheme-handler/ssh

#Write code for new handler
cat << EOF > ~/.local/share/applications/ssh.desktop
[Desktop Entry]
Version=1.0
Name=SSH Launcher
Exec=bash -c '(URL="%U" HOST=\$(echo \${URL:6} | cut -d ":" -f1) PORT=$(echo \${URL:6} | cut -d ":" -f2); ssh \$HOST -p \$PORT); bash'
Terminal=true
Type=Application
Icon=utilities-terminal
EOF

#Apply New handler for SSH
xdg-mime default ssh.desktop x-scheme-handler/ssh

#Confirm new handler has been applied
xdg-mime query default x-scheme-handler/ssh

Udev Network Interface Renaming with no Reboot

While working on the Topology_Converter for work I came upon several lessons with Udev. The topology_converter project essentially takes input (from a graphiviz file) and builds a network topology with proper interface names. In order to make the interface names work there is a script which spits out udev rules.

Writing Udev Rules

With Udev you can rename interfaces using a number of parameters which are defined in rules. Rules should be stuck in the “/etc/udev/rules.d/70-persistent-net.rules” file to follow convention but you could technically stick them anywher in the rules.d directory.

To see all of the possible criteria that can be matched upon for a given network interface, use the command below replacing “eth0” with your interface of choice.

udevadm info -a -p /sys/class/net/eth0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:19.0/net/eth0':
 KERNEL=="eth0"
 SUBSYSTEM=="net"
 DRIVER==""
 ATTR{addr_assign_type}=="0"
 ATTR{addr_len}=="6"
 ATTR{address}=="54:ee:75:22:3d:70"
 ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
 ATTR{carrier}=="0"
 ATTR{carrier_changes}=="1"
 ATTR{dev_id}=="0x0"
 ATTR{dev_port}=="0"
 ATTR{dormant}=="0"
 ATTR{duplex}=="unknown"
 ATTR{flags}=="0x1003"
 ATTR{gro_flush_timeout}=="0"
 ATTR{ifalias}==""
 ATTR{ifindex}=="2"
 ATTR{iflink}=="2"
 ATTR{link_mode}=="0"
 ATTR{mtu}=="1500"
 ATTR{netdev_group}=="0"
 ATTR{operstate}=="down"
 ATTR{proto_down}=="0"
 ATTR{speed}=="-1"
 ATTR{tx_queue_len}=="1000"
 ATTR{type}=="1"

looking at parent device '/devices/pci0000:00/0000:00:19.0':
 KERNELS=="0000:00:19.0"
 SUBSYSTEMS=="pci"
 DRIVERS=="e1000e"
 ATTRS{broken_parity_status}=="0"
 ATTRS{class}=="0x020000"
 ATTRS{consistent_dma_mask_bits}=="64"
 ATTRS{d3cold_allowed}=="1"
 ATTRS{device}=="0x15a2"
 ATTRS{dma_mask_bits}=="64"
 ATTRS{driver_override}=="(null)"
 ATTRS{enable}=="1"
 ATTRS{irq}=="56"
 ATTRS{local_cpulist}=="0-3"
 ATTRS{local_cpus}=="0f"
 ATTRS{msi_bus}=="1"
 ATTRS{numa_node}=="-1"
 ATTRS{subsystem_device}=="0x2227"
 ATTRS{subsystem_vendor}=="0x17aa"
 ATTRS{vendor}=="0x8086"

looking at parent device '/devices/pci0000:00':
 KERNELS=="pci0000:00"
 SUBSYSTEMS==""
 DRIVERS==""

</code>

You can see there are quite a few options to match on. When remapping physical interfaces on Linux, I strongly recommend adding the match for PCI to make sure this interface is mapped to the PCI bus in some way. The concern when not using the PCI match (as shown below) is that if these physical interfaces are to take part in bridges or bonds with vlans or sub interfaces…. in that case your bridge or bond may inherit mac addresses from a physical interface and there will be a collision in the renaming process which means your interfaces may be left named “renameXX” or something like that.

Here are some sample Udev rules for a given series of interface renaming operations.

#### UDEV Rules (/etc/udev/rules.d/70-persistent-net.rules) ####
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="44:38:39:00:00:1a", NAME="swp2", SUBSYSTEMS=="pci" 
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="44:38:39:00:00:12", NAME="swp1", SUBSYSTEMS=="pci" 
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="44:38:39:00:00:49", NAME="swp48", SUBSYSTEMS=="pci" 
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="44:38:39:00:00:42", NAME="eth0", SUBSYSTEMS=="pci" 
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="08:00:27:8a:39:05", NAME="vagrant", SUBSYSTEMS=="pci"

Applying the New Rules

Now that you’ve written the new rules it’d be nice to apply them without having to reboot.

That can be a little complicated and is totally disruptive to networking traffic likely on all interfaces but the procedure looks like this:

  1. Detect the driver used by each interface that requres a remap. The easiest way is to use
    $ ethtool -i eth0
    driver: e1000e
    version: 3.2.6-k
    firmware-version: 0.2-4
    expansion-rom-version: 
    bus-info: 0000:00:19.0
    supports-statistics: yes
    supports-test: yes
    supports-eeprom-access: yes
    supports-register-dump: yes
    supports-priv-flags: no

    You could potentially use this technique:

    $ basename $(readlink /sys/class/net/eth0
    /device/driver/module)

    or this one:

    $ basename $(readlink /sys/class/net/+interface+/device/driver)

    YMMV  depending on the driver in use.

  2. Remove the driver that is shared/used by each interface that is to be remapped (other interfaces that are using that driver may get caught in the crossfire here).
    $ modprobe -r e1000e
  3. Run the following command to detect the newly installed rules
    $ udevadm control --reload-rules
  4. Apply the new rules with the last command
    $ udevadm trigger

Applying the new rules with the trigger operation will also reinitialize the driver that you’ve previously removed.

Presto you’re done.

Basic Raspberry Pi Home Wifi Router

The Goal of This Post:

This post is an extension to Jacob Salema’s Guide that was picked up by Lifehacker. My main issue with his post is that he refers to the end result as a wireless router, which is not entirely accurate. This device is not meant to be internet-facing and is really more of a wireless/ethernet bridge with the configurations provided.

My goal here was to extend what was provided in his initial post and make it suitable for placing a Raspberry Pi directly behind a cable modem and fully exposed to the internet.

raspberry_pi_pi_ap
image kindly borrowed from adafruit

Materials:

  • Raspberry Pi B (gen 2 model) any Raspberry Pi could potentially work here though
  • Edimax EW-7811Un
  • Short piece of Ethernet (to connect to cable modem)
  • Power Adapter and cord for Pi
  • SD card with Raspbian installed
  • (Optional) USB Keyboard and HDMI Monitor to access the PI. All of these steps can be performed over SSH with a little creativity however.

Performance:

The Raspberry Pi’s performance is limited by the USB throughput of the WLAN adapter; which on the Raspberry Pi is a USB2.0 hub limited to a theoretical maximum of 480mbps, so you’ll never be able to pull gigabit ethernet here but this will get the job done for small sites. However if you have really crappy broadband like I do in this location the chokepoint will be the crappy broadband and not the Raspberry Pi.

I have maxed out my crappy broadband connection with the following speedtest.net performance results:

A BLAZING — 2.78mbps download
A SIMILARLY BLAZING — 1.28mbps upload

I repeated the same speedtest.net tests using a top-notch Lenovo X1 Gen3 laptop and got the exact same results so there is no lag using the raspberry pi here (for this crappy broadband connection). Since my broadband is so crappy here I’m using 802.11G wifi which won’t choke anything.

Note: I probably wouldn’t trust this for anything over 10mbps. I think the Raspberry Pi 2 with 802.11n wifi could handle a standard 40mbps connection based on some of the numbers I’m seeing here.

1). Required Installs:

Perform these first before any of the other steps.

sudo apt-get update -y
sudo apt-get install rfkill zd1211-firmware hostapd hostap-utils iw dnsmasq bridge-utils -y

 

2). Interfaces Configuration (/etc/network/interfaces):

Modify the interfaces file (/etc/network/interfaces) as shown below.

allow-hotplug wlan0
allow-hotplug eth0

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
 
auto wlan0
iface wlan0 inet static
   address 192.168.2.1
   netmask 255.255.255.0

3). DNSmasq Configuration (/etc/dnsmasq.conf):

Modify the DNSmasq configuration file to look exactly like what you see below.

Feel free to modify your domain.

domain=example.com
bogus-priv
no-resolv
server=8.8.8.8
server=8.8.4.4
cache-size=10000
interface=wlan0
dhcp-range=192.168.2.2,192.168.2.254,12h

4). HostAPD Configuration (/etc/hostapd/hostapd.conf):

Modify the configuration file for hostapd to have the following content.

Notice we’re using the “hw_mode=g” option here this is because my limited internet connection couldn’t support max throughput of a wifi-N connection so there would be minimal benefit. If you’re interested in N and have a Raspberry Pi2 and a faster internet connection it may make sense to enable that in your scenario.

Also feel free to modify the SSID to whatever you like and modify the password too, you’ll need at least 8 characters for the password. The channel can also be set to any value between 1-14 (1,6,11,14 are common in the USA)

interface=wlan0
driver=rtl871xdrv
country_code=US
ctrl_interface=wlan0
ctrl_interface_group=0
ssid=NETWORKNAME
hw_mode=g
channel=1
wpa=3
wpa_passphrase=password
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
beacon_int=100
auth_algs=3
macaddr_acl=0
wmm_enabled=1
eap_reauth_period=360000000


5). HostAPD Default Configuration (/etc/default/hostapd):

Modify the defaults file for hostapd (/etc/default/hostapd) to have the same DAEMON_CONF line. The type of quotes used to surround the /etc/hostapd/hostapd.conf file are mission critical; if you use the wrong kind of quotes, hostapd will not start. You can debug the start of hostapd with the command “hostapd -d /etc/hostapd/hostapd.conf” which puts it into debugging mode.

# Defaults for hostapd initscript
#
# See /usr/share/doc/hostapd/README.Debian for information about alternative
# methods of managing hostapd.
#
# Uncomment and set DAEMON_CONF to the absolute path of a hostapd configuration
# file and hostapd will be started during system boot. An example configuration
# file can be found at /usr/share/doc/hostapd/examples/hostapd.conf.gz
#
DAEMON_CONF="/etc/hostapd/hostapd.conf"

# Additional daemon options to be appended to hostapd command:-
# -d show more debug messages (-dd for even more)
# -K include key data in debug messages
# -t include timestamps in some debug messages
#
# Note that -B (daemon mode) and -P (pidfile) options are automatically
# configured by the init.d script and must not be added to DAEMON_OPTS.
#
#DAEMON_OPTS=""

6). Reboot the Pi

Reboot the Pi to apply the interfaces config, start the hostapd daemon, start dnsmasq daemon. After the reboot you should see your new wireless SSID being broadcast and you should be able to login to it too with your provided password. At this point we need to proceed with the IP tables configuration to setup routing and PAT (port address translation).

7). Enable NAT and Routing Non-Persistently

Execute the following commands to enable NAT and routing for this particular session (we will make these settings persistent across reboots in steps 9 and 10).

#Enable Routing
sudo sysctl -w net.ipv4.ip_forward=1

#Apply the NAT/PAT config 
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Routing allows the Pi to move (or “route”) packets between the two interfaces (Wlan0 and Eth0). Making the Pi a Router allows packets which come in on the Wlan interfaces to be forwarded through the Pi and out the Eth0 port.

NAT stands for Network Address Translation. In this case we’re technically performing PAT or Port Address Translation because we are aggregating the connections and streams of multiple downstream/client IP addresses across a single public IP address using different source ports. As a result packets will be re-written as they pass through a NAT router to be sourced from the public IP address of the NAT router. This re-write hides the original source IP address of the client which generated the traffic. In order to keep track of which stream should be returned to which client, the NAT router keeps a table that maps the Egress destination port to an client IP and source port. This table is called a NAT translation table. You can view the content of the Translation table at any time with the following command:

cat /proc/net/ip_conntrack

8). IP Tables Configuration:

IPtables is a program which interacts with the networking stack in the Linux kernel and tells the kernel how to handle incoming network traffic. There are all kinds of customizations that can be made to an internet facing router. What I show below are pretty basic and generally recognized as safe defaults.

Apply the default config by pasting the following commands into the command line on your device:

#allow incoming traffic from the localhost
sudo iptables -A INPUT -i lo -j ACCEPT
#explicitly allow all icmp/ping traffic
sudo iptables -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
#explicitly allow all traffic that is already established
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#Allow new traffic only from the local/WLAN network
sudo iptables -A INPUT -i wlan0 -m state --state NEW -j ACCEPT
#Drop all other new traffic
sudo iptables -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP<
#Drop all fragments
sudo iptables -A INPUT -f -j DROP 
# Drop XMAS packets
sudo iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
# Drop NULL packets
sudo iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
#allow our dns traffic 
sudo iptables -A INPUT -i wlan0 -p udp -m udp --sport 53 -j ACCEPT
#log everything else that is about to get dropped. 
sudo iptables -A INPUT -j LOG --log-prefix "IPTABLES Dropped: " --log-level 7 
#drop everything else that has made it this far down and not matched. 
sudo iptables -A INPUT -j DROP

You can see the presently applied iptables rules using the “iptables-save” command with sudo.

pi@raspberrypi:~ $ sudo iptables-save
# Generated by iptables-save v1.4.21 on Thu Dec 24 17:37:34 2015
*nat
:PREROUTING ACCEPT [7039:855804]
:INPUT ACCEPT [1138:80267]
:OUTPUT ACCEPT [1167:81793]
:POSTROUTING ACCEPT [21:3945]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Dec 24 17:37:34 2015
# Generated by iptables-save v1.4.21 on Thu Dec 24 17:37:34 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [444346:360889024]
:OUTPUT ACCEPT [4390:510099]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -f -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -i wlan0 -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -j LOG --log-prefix "IPTABLES Dropped: " --log-level 7
-A INPUT -j DROP
COMMIT
# Completed on Thu Dec 24 17:37:34 2015

Once you’ve setup the rules you’d like, and you’ve tested that they behave as expected, proceed to step 8 to save the IP tables rules.

9). Make the IPtables Settings Persistent

During the installation of the iptables-persistent program it will ask you if you want to save the presently applied rules, select YES.

sudo apt-get install iptables-persistent -y

Once the rules are saved, they can be edited at the /etc/iptables/rules.v4 (for normal IPv4 traffic). If you’re testing your iptables changes by applying the rules directly using the iptables syntax in step 7 then as you make changes, they can be made persistent by writing the output of the “iptables-save” command directly to the rules.v4 file like so.

sudo iptables-save > /etc/iptables/rules.v4

10). Enable Routing Persistently

The following change allows the Raspi Router to move packets from one interface (wlan0) to another (eth0) by making the device a router.

sudo sed -i 's/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/g' /etc/sysctl.conf