The Lintrack advantage
This page introduces unique Lintrack features.
Flatconf
Flatconf is a new way of describing and storing software configuration. Conceptually it is divided into three parts: Flatconf standard, software library and user interface.
The Flatconf standard describes the Flatconf itself, ie. what it is, what and how can be stored using it. Basically, Flatconf divides traditional configuration files into multiple files holding single value. Such files can then have metainformation (called properties), like title, type definition or shell scripts to execute on value change.
To access such a file system structure, a special software is needed, in this case the libflatconf library. It is implemented in C for speed and size concerns and provides an API which Flatconf interfaces use to do operations required by the end user.
On top of Flatconf stack there is a user interface. Currently the only user interface is an interactive command-line interface called fcc, but a modern (asynchronous) web-based interface should be available in future.
How does it look like, you ask - here is a short "screenshot":
root@venus:~# fcc
Welcome to Flatconf CLI. Type "?" for help.
venus.lan fc> cd sys
venus.lan sys> ls
[dir] disks Disks
[dir] ssl Certificates (OpenSSL)
[dir] time Date and time
[txt] hostname Host name
`venus.lan'
[txt] hostip Preferred host IP address
`192.168.1.1'
[txt] sysloc System location
`US, NYC, Street 2/3'
[txt] sysmail System administrator e-mail address
`admin@somenetwork.net'
[dir] modules Kernel modules
[fil] rc_local Local startup script (rc.local)
venus.lan sys> ls / net if
Ethernet devices
[dir] eth Fast Ethernet devices
[dir] ath WiFi interfaces: Atheros
[dir] bond Interface bonding
[dir] br Ethernet bridges
PPP devices
[dir] ppp PPP interfaces
[dir] pppoe PPPoE interfaces [help]
Tunneling devices
[dir] tun IP tunnels
[dir] openvpn OpenVPN tunnels
[dir] chilli Chillispot
venus.lan sys>
As of 2.0 version, Flatconf configuration in Lintrack consist of almost 10000 files and directories. On system startup the "run control scripts" (ie. /etc/rc.d) executes configuration parsers which generates traditional configuration files for target programs.
Improved MadWiFi
Thanks to MadWiFi driver Lintrack-enabled routers are able to use wireless hardware from Atheros® as their network interfaces. The official release of MadWifi already contains a lot of very useful features. However, it suffers from some security and stability issues which we considered unacceptable. Some extra functionality was needed as well.
Therefore Lintrack is shipped with a modified version of MadWiFi, which contains the following improvements:
- A few bugs causing spurious Beacon misses were fixed. Now STA's connection to the AP is no longer unstable when the Beacon Interval is greater than the "standard" 100 TU. This is important when operating in hand-tuned WiFi networks.
- Information advertised in management frames is now examined more closely, so that inconsistencies do not have severe impact on network stability anymore. Prior to this an attacker could easily disrupt the communication (DoS) by injecting spoofed Beacon or Probe Response frames. This affected even WPA/WPA2-secured connections.
- Smarter handling of incoming Channel Switch Announcements (DFS functionality) in Beacon Frames has been implemented. Now the client station will follow the channel switch even if some Beacons were missed, what is quite likely to happen. Of course sanity-checks of inconsistent data as described above are also performed.
- A few other bugs were fixed. They concerned security (plaintext data leakage before WPA authentication), state changes (spurious packets before association), Monitor mode (sequence numbers, improved radiotap support).
Cheap crypt
Cheap crypt (ccrypt) encrypts whole network interfaces without expanding Ethernet frames. It has been designed to securely pass network traffic through wireless Ethernet bridges with weak (WEP) data security (or not supporting encryption at all) without fragmentation overhead (it's quite common in such bridges that MTU can't be larger than 1500).
Ccrypt uses any block cipher supported by the Linux kernel crypto API (AES, Blowfish, to name a few) in CBC (Cipher-block chaining) mode and Residual Block Termination to avoid frame padding. It can use different keys for different traffic directions.
Below you can see how a ccrypt-encrypted ARP and ping requests from 192.168.111.2 to 192.168.111.3 look like in tcpdump:
19:38:12.585727 truncated-arp
0x0000: bc75 eb25 8af0 1e9a 01dd feed 81f6 174d .u.%...........M
0x0010: fcaf 1d2c e784 d353 e155 92f8 91c6 fab8 ...,...S.U......
0x0020: 148c c80d 282b f5db 351e 921c 059c ....(+..5.....
0x0000: ffff ffff ffff 5254 0012 7ff5 0806 bc75 ......RT.......u
0x0010: eb25 8af0 1e9a 01dd feed 81f6 174d fcaf .%...........M..
0x0020: 1d2c e784 d353 e155 92f8 91c6 fab8 148c .,...S.U........
0x0030: c80d 282b f5db 351e 921c 059c ..(+..5.....
19:38:12.587365 truncated-arp
0x0000: 3d4e 6726 e37c 475d 4fca 3a81 4c6f f9b7 =Ng&.|G]O.:.Lo..
0x0010: f08c a89b 1922 3ce6 40ca b73e 9cc4 7427 ....."<.@..>..t'
0x0020: 6d46 dbf0 f9fb 55dd 814a ab36 033b mF....U..J.6.;
0x0000: 5254 0012 7ff5 5254 0012 ddd7 0806 3d4e RT....RT......=N
0x0010: 6726 e37c 475d 4fca 3a81 4c6f f9b7 f08c g&.|G]O.:.Lo....
0x0020: a89b 1922 3ce6 40ca b73e 9cc4 7427 6d46 ..."<.@..>..t'mF
0x0030: dbf0 f9fb 55dd 814a ab36 033b ....U..J.6.;
19:38:12.609685 IP13 truncated-ip - 39385 bytes missing! 205.84.36.69 > 90.22.168.137: ip-proto-33
0x0000: 5254 0012 ddd7 5254 0012 7ff5 0800 dc41 RT....RT.......A
0x0010: 9a2d a83d 554d 0821 d325 cd54 2445 5a16 .-.=UM.!.%.T$EZ.
0x0020: a889 5989 d83a fac3 4600 bd89 afb1 31c4 ..Y..:..F.....1.
0x0030: b582 7a8c 25ac 1702 5dc3 0ce3 b2d9 2a95 ..z.%...].....*.
0x0040: 4dfb eb44 d57d 0c5c 0441 782c 6886 91a6 M..D.}.\.Ax,h...
0x0050: 17c3 d588 45f1 dfdd 5342 1e2a b4a4 435b ....E...SB.*..C[
19:38:12.612029 IP14 bad-hlen 12
0x0000: 5254 0012 7ff5 5254 0012 ddd7 0800 e32d RT....RT.......-
0x0010: 60bd 0ecd 0ef0 afae f636 085b af32 a45a `........6.[.2.Z
0x0020: 239d 862c 09c0 75ad 7462 a9b1 e896 ce80 #..,..u.tb......
0x0030: af24 5410 b5d2 91c9 be37 e8d5 deb1 7dd8 .$T......7....}.
0x0040: b620 93de a30b ba5b e0ef 51ba b348 bdb2 .......[..Q..H..
0x0050: cb57 5a73 0173 8c8f 0785 d0e4 9139 3173 .WZs.s.......91s
(We wonder how long would it take to discover a security vulnerability in an Ethernet sniffer just by listening on a ccrypted LAN? :-)
Link quality monitoring
Lintrack comes with a Bash script called ifquald which periodically runs ICMP Echo (ping) and iperf tests to requested remote hosts. Such tests give following diagnosis information: minimum/average/maximum latency, mean latency deviation (mdev), percentage packet loss, download/upload bandwidth and names of interfaces on which bandwidth tests have been received. In order to give accurate results during normal traffic flow, ifquald measures bandwidth on whole network interface, not just flowing from/to single IP address.
Each time a bandwidth test is finished, ifquald will report the results via syslog, e.g.
Sep 26 18:01:36 venus ifquald-iperfc: Bandwidth to 192.168.1.2 (eth0): 13386 kbps Sep 26 18:02:51 venus ifquald-iperfd: Bandwidth from 192.168.1.2 (eth0): 15675 kbps
Several integrated programs may then react to changes in measured values, e.g. weighted round-robin bonding and OSPF routing daemon.
Weighted round-robin Ethernet bonding
Ethernet device bonding has existed in Linux kernel for a long time, but it was mainly used for strictly Ethernet devices, where maximal link speed is guaranteed and is not supposed to change in time. However, this is not the case for wireless links, where device speed may depend on environment, change in time and be asymmetrical.
In order to overcome this problem, Lintrack comes with special bonding mode which can have arbitrary device weights set on slave interfaces (you can even have "0" set on an interface if you only wish to receive traffic on it). What's even more interesting here is that after configuring ifquald properly, weights may be updated automatically. Basing on measurement results, after each test, Lintrack will use a tunable formula to derive device weight from set of link quality values and update slaves' weights. It will even react to high packet loss values (by default more than 25%) and manually disable the unreliable link.
All such activity will be logged to syslog, e.g.:
Sep 26 16:15:51 venus ifquald-ifenslave[192.168.1.2][bond0/eth0]: setting weight to 5 Sep 26 16:25:32 venus ifquald-ifenslave[192.168.1.2][bond0/eth1]: setting weight to 35 Sep 26 16:28:23 venus ifquald-ifenslave[192.168.1.2][bond0/eth0]: setting weight to 37 Sep 26 18:21:12 venus ifquald-ifenslave[192.168.1.2][bond0/eth0]: -> packet loss to 192.168.1.2 > 25% (37%) - disabling Sep 26 18:41:04 venus ifquald-ifenslave[192.168.1.2][bond0/eth0]: -> packet loss to 192.168.1.2 decreased to 1% - enabling with weight 37
Similar functionality is present in OSPFv2 support, where path costs are set using the same algorithm.
Superior PPPoE and RADIUS support
In Lintrack, PPPoE server with RADIUS backend is very important. We have implemented our own RADIUS extensions in the pppd daemon so it is possible to limit user's link speed, enable server-side firewall and content filters, do advanced QoS, etc. out-of-the-box.
Because we are aware about possible frequent packet losses in wireless networks we have implemented libradius-asn - a RADIUS client library with reliable accounting messages delivery.
Basic idea behind libradius-asn is that RADIUS accounting messages go to a spool directory (which may be stored on a solid-state storage device, hard disk) and wait there until they're sucessfully delivered.
Interface and address descriptions
We all sysadmins know how hard is it sometimes to quickly find a network interface (or an alias) we are searching for - was it eth0 or eth1? Lintrack comes with in-kernel interface and address descriptions which will help you to better understand the output of "ip addr show", e.g.:
root@venus:~# ip link set dev eth0 descr "To ap2.wrt4.rt18.lan"
root@venus:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0E:2E:84:D1:31
Descr: To ap2.wrt4.rt18.lan
inet addr:192.168.3.168 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::20e:2eff:fe84:d131/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:111975803 errors:593 dropped:676 overruns:181 frame:0
TX packets:111914347 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:941252977 (897.6 Mb) TX bytes:894967803 (853.5 Mb)
Interrupt:10 Base address:0x2000
root@venus:~# ip addr add dev eth0 192.168.1.1/24 descr "Alias for public AP subnet"
root@venus:~# ip addr show dev eth0
6: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
descr To ap2.wrt4.rt18.lan
link/ether 00:0e:2e:84:d1:31 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.168/24 brd 192.168.3.255 scope global eth0
-- Alias for public AP subnet:
inet 192.168.1.1/24 scope global eth0
inet6 fe80::20e:2eff:fe84:d131/64 scope link
valid_lft forever preferred_lft forever