Remosi’s Rants

So I've recently recieved a second hand ipod nano (2GB) from my brother who upgraded to a large ipod video. He gave it to me dead flat, so I plugged it into my laptop so it could charge, and after a while it started saying "Do Not Disconnect". ah, it's registered itself as a USB mass storage and thinks it's in use. Fair enough, lets see what Linux thought of it. Linux found a two partitions /dev/sda1 and /dev/sda2. Lets try and mount them. /dev/sda1 failed to mount, didn't detect the partition type, fair enough, lets try /dev/sda2. /dev/sda2 mounted ok with some interesting stuff on it. Now what was /dev/sda1, lets try file(1), hrm, it doesn't detect it. Lets try less then…. wait, what's THAT?

perry@shine:/mnt$ sudo dd if=/dev/sda1 bs=512 count=1 | fold -w 16
{{~~  /-----\
{{~~ /       \
{{~~|         |
{{~~| S T O P |
{{~~|         |
{{~~ \       /
{{~~  \-----/
Copyright(C) 200
1 Apple Computer
, Inc.----------
----------------
----------------
----------------
----------------
----------------
---------------
]ih[@

It appears that the first sector of the first partition has an ascii art stop sign in it!

Now *THAT* is cool.

Networking policy is currently defined in 3 seperate places:

• The Routing Table
• Firewalling Rules
• QoS Rules

Each of these systems has different mechanisms for matching packets. Under Linux (and under most systems) the firewalling rules have the most sophisticated mechanisms for matching packets, QoS matching rules are somewhat random, and the routing rules are overly simplistic (You can match on source network, destination network, and ToS bits).

This leads to bizarre hacks like FWMARK, where you use Linux's firewalling matching rules to match a packet so you can do QoS or Routing based on it. You also can do the same thing in multiple different ways. To prevent the routing of a packet you can use a reject route, or you can REJECT it using firewalling.

Thus my solution is to merge QoS, Firewalling and routing into one networking policy engine. A packet can be matched using a pluggable matching system, have various effects applied to it (such as NAT, ToS mangling, IPsec, logging etc), and then can be destined to one or more queues of the local machine, an interface, or a locally connected host.

Some example rules for a host with 3 interfaces (eth0 an expensive low latency internet connection used for ssh, eth1 where most of the internet traffic goes, and eth2 which has a nat'd network behind it) might look like:

# Firewall rules
 protocol tcp, destination-port 137, reject
 protocol udp, destination-port 137, reject

# Policy routes
 from 10.1.0.0/16, protocol tcp, destination-port 22,
   via 192.168.1.1, dev eth0, queue lowlatency

# NAT
 from 10.1.0.0/24, dest 192.168.0.0/16, snat 192.168.1.1

# Routes for local processing
 dest 192.0.2.254, dev host
 dest 10.1.1.254, dev host
 dest 192.168.1.254, dev host

# Routes for local networks
 dest 10.1.0.0/16, dev eth2, queue normal
 dest 192.0.2.0/24, dev eth1, queue normal
 dest 192.168.0.0/16, dev eth0, queue normal

# Default route(s)
 dest 0.0.0.0/0, via 192.0.2.254, dev eth1, queue normal

Queues need to be configured seperately, probably much as they are done today. I think such an integrated system would ease system administrators burden of having to specify policy in several difference places using several different algorithms.