!!! Introduction Melbourne Wireless will come to depend on routing nodes, which tie the mesh together, forwarding traffic on behalf of other peers and clients. Fortunately it is readily possible to do this with PC class platforms running software like FreeBSD, Linux and even Windows NT & XP. However networking is a complex thing, and the configuration has to be "just so" or things tend to not work. !!! A Linux Routing Node Distribution Looking for candidate distributions to suit the following. The Linux Router Project derived (http://leaf.sourceforge.net/ LEAF) distributions seem to come close... leveraging these projects should result in something ideal. Initially, we plan to use a bootable cd, that asks a detailed questionaire on its first boot, and stores the config options on a floppy/HD/compactFlash/whatever !!! Requirements * Maximum "Minimum system requirements" ** 386 processor ** 16MB memory, 8MB if providing swap disk ** Hard drive not required but can be used (moving parts...) ** Boot off CDROM and runs from CDROM (support for boot from floppy & run from CDROM additionally) ** configuration storage on floppy or hard drive * Supports ** Wireless, fixed & dialup interfaces ** IPv4 routing ** IPv6 routing ** DiffServ QoS ** OSPF, BGP, OSPFv3 ** DHCP & DNS servers ** CIPE & FreeSWAN *** ([AndrewGriffiths]) Anyone got CIPE to work out of the box against 2.4.18? I doubt I'll include it until it wants to work for me.. ** MRTG graphing (if HDD) ** Open interface for troubleshooting (read-only view of certain configuration details) ** ssh management ** web management with SSL server security and client certificates ** squid cache (if hard disk available) !!! Other thoughts from DavidArnold * reasonable security focus * automatic or very easy patching/upgrades ** ([AndrewGriffiths]) Assuming no harddrives, anyone got any good ideas? ** mmm. got one. How about a list of process names and offsets, and insert say, int3 or xor eax, eax; inc eax; int 0x80 into the prelude for the vulnerable code? While it doesn't fix the problem, it prevents the exploitable code from being executed? See [Procpatch] for more info. ** Okay, if we do have a harddrive, we can download patches into, say /patches, and I'll write a kernel module to redirect execve/open to /patches first, then fall back to the RO filesystem. (eg, when you execute /bin/ls, it would first look for /patches/bin/ls instead.) Comments anyone? * able to run from read-only media (flash card) * small filesystem (cheap flash cards, floppy/ls120/zip) * net bootable? (tftp/bootp/dhcp) * run from RAM disc (keep any rotating media idle) * simple config for one or more of ** route/serve downstream private network ** route/serve downstream public access network ** point-to-point uplink (one or more) ** point-to-point downlink (one or more) * access control (for public access network) ? * stats collection and reporting (for melbwireless web) ? * remote management * remote logging ? * support for x86 (PCs), 68k (old macs), PPC (newer macs) * serial console support !!! Other suggestions by AndrewGriffiths * for the updates, it'd be nice to be able to gpg sign them to prevent evil proxy attacks that work against, debian and RH. (Note: RH does have an option to check gpg signatures.) * Do we want to use PAX or grsecurity.nets patches (which include PAX)? This would increase security a fair bit. Also, would it be worth modifying the Makefiles so we use the full address space randomisation? It'd increase security a fair bit, but it has a performance impact. (Apparently its less than using a run-time bounds checking code.) !!! Random comments anyone? * ([SimonButcher]) - You'll need more than 16 meg RAM to run MRTG alone without the box swapping like crazy per run. It's perl, afterall, and will run like a dog on a 386, let alone with only a couple of meg aside from the kernel (trust me!). You'll need at least 32 meg RAM (plus swap) to run all those daemons "comfortably" with Linux/FreeBSD/OpenBSD. To run large routing tables, IPv4, IPv6, and QoS you will need at least a Pentium-75 or the latency will suffer dramatically. * ([chewy]) - You dont need to run mrtg on the system, only a snmpd of some sort and the graphing can take place elsewhere. I currently have my wireless node doing the graphs for itself and for the net box. The net box also boots and runs off a 64MB cf card, the init scripts set up a ram drive and files such as the dhcp leases are symlinked from the cf(which is mounted read-only). with the cf, use 40 band ide cables not the 80 band ones, i wasted many hours trying to work out why it wouldnt boot when it was the cable causing the trouble. * (Ashrak) - Willing to host from Home (Narre Warren) or my other node (boronia) would prefer to run Windows 2000 or 2003 as i am familuar with it, but a linux box i will run but will need some support. e-mail me if anyone interested in my involvement ashrak@iprimus.com.au !!! Other Resources: * (http://www.brienposey.com/ospf_2.htm OSPF on Win2k Server family)