WirelessAfrica - User contributions [en]

John's research

2009-06-08T17:23:33Z

Jhay: This page has moved to wirelessdev

[[Category: Development Team Research Pages]]

This page has moved to http://wirelessdev.meraka.org.za/index.php/John's_research

John's research

2009-05-20T10:28:59Z

Jhay: /* Less commonly used/needed configs */

[[Category: Development Team Research Pages]]
==Intro==
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades. Remember that the CF is normally read-only, so has to be made read-write before editing the file with
mount -u -w /
And made read-only again afterwards with
mount -u -r /

=== Commonly used configs ===

If the box is the one that connect the network to the "internet", you will have to set
mesh_type="gateway"
This will enable a lot of things as listed on the [[High_performance_node_page#Behavior_of_the_GateWay_node_in_a_mesh | HPN page]], for instance announce a default route, be a dns server for the network, be a ntp time server, be an update server, etc.

A network needs one box that is the dns server. If you go not have a gateway, you can use this. On that box you will need to set
mesh_dns_enable="YES"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

One thing that is often needed is to swap channels on the BackBone links. On the newer distros, you can configure the box as "green" (default) or "red".
mesh_node="red"

On older boxes, you will have to do it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

To force the box to hunt for channels on the next boot:
mesh_hunt="YES"

=== Less commonly used/needed configs ===

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"
You can also just override the channel with:
mesh_bbchana="140"
mesh_bbchanb="140"
mesh_hspchan="13"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

If you need to turn 4over6 off or change the prefix:
auto4over6_enable="NO"
auto4over6_prefix="fec0:0:0:aaaa::"

If you need to turn auto updates off or change the extension:
autoupgrade_enable="NO"
autoupgrade_url="ftp://mesh-updates/"
autoupgrade_suffix=".mesh"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf

site_type="auto|host|node|repeater|hotspot|quad"
rtadvd_enable="YES|NO"
olsrd_enable="YES|NO"

Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===

Disk split in 2 partitions. Upgrade the one that is not active.

Auto script run from cron to check for updates.

/upgrade tool used for manual updates and by the auto script to do the actual updating.

===4over6 Automatic tunnels===
An idea to tunnel IPv4 packets over our IPv6 mesh networks without having to configure each tunnel. Think of it as a kind of one to many tunnel. So only one need to be configured on a host.

====Assumptions====
The IPv6 part will use OLSR or some routing protocol where static routes can be injected. The host doing the tunneling needs to be dual stacked. The edges will have IPv4 subnets from the 10.0.0.0/8 network in addition to the IPv6 subnets.

====The way it works====
An IPv6 subnet address (/64) is chosen that will be used as the tunnel prefix throughout the network. Each tunnel box must be configured in the following way:
* Its "local" interface(s) is/are configured with a 10.0.0.0 subnet(s).
* A virtual tunnel interface (tunX?) is created.
* An IPv4 static route for the whole 10.0.0.0/8 subnet is added into this interface. (XXX Maybe default route?)
* An IPv6 static route is calculated from the chosen IPv6 tunnel prefix plus the local IPv4 subnet(s) (fdfd:efef:abab:cdcd::10.1.2.0/120)
* This static route is also given to the routing protocol to announce.
* The 4over6 tunnel daemon [*] is attached to the tunnel interface. It is configured with the IPv6 tunnel prefix.

====The 4over6 tunnel daemon====
The configuration it needs is the IPv6 tunnel prefix. It receives IPv4 packets (from the local interface(s)) convert the header to IPv6 using the IPv6 tunnel prefix and sends it out again. It receives IPv6 packets, convert the IPv6 addresses back to IPv4 and sends it out again.

|------------------| |------------------|
| host1 | | host2 |
| | | |
| |---| | | |---| |
| | B | | | | E | |
|------------------| /\/\/\/\/\/\/\ |------------------|
A | | C / IPv6 \ D | | F
---------| |--------< Routed Network >----------| |----------
\ /
\/\/\/\/\/\/\/

Host1 and host2 are connected via an IPv6 routed network. (No native IPv4) prefix used for 4over6 fd9c:6829:597c:fefe/64

host1
A - 10.1.1.1/24
B - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.1.1.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.2.2.0/120 pointing in host2's direction.
C - IPv6-only address.

host2
D - IPv6-only address.
E - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.2.2.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.1.1.0/120 pointing in host1's direction.
F - 10.2.2.1/24

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type (as root):
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the ARM boards, you will need a tftp server loaded with boot2 and an ARM kernel with nfs booting compiled in. You will also need a nfs server setup with an extracted FreeBSD ARM tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?
* A wacky idea for updating even in the face of incompatible routing protocols. Have every box run a tcp relay to an update box. So every box can connect to a neighbor's relay for updates. This will not solve the problem of incompatible links, eg. adding wep or changing ssids.
* Robust addressing scheme for big networks that need to cooperate.
* What else?

John's research

2009-05-20T10:13:50Z

Jhay: /* What is there to tweak */ Start to flesh out our new stuff

[[Category: Development Team Research Pages]]
==Intro==
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades. Remember that the CF is normally read-only, so has to be made read-write before editing the file with
mount -u -w /
And made read-only again afterwards with
mount -u -r /

=== Commonly used configs ===

If the box is the one that connect the network to the "internet", you will have to set
mesh_type="gateway"
This will enable a lot of things as listed on the [[High_performance_node_page#Behavior_of_the_GateWay_node_in_a_mesh | HPN page]], for instance announce a default route, be a dns server for the network, be a ntp time server, be an update server, etc.

A network needs one box that is the dns server. If you go not have a gateway, you can use this. On that box you will need to set
mesh_dns_enable="YES"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

One thing that is often needed is to swap channels on the BackBone links. On the newer distros, you can configure the box as "green" (default) or "red".
mesh_node="red"

On older boxes, you will have to do it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

To force the box to hunt for channels on the next boot:
mesh_hunt="YES"

=== Less commonly used/needed configs ===

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===

Disk split in 2 partitions. Upgrade the one that is not active.

Auto script run from cron to check for updates.

/upgrade tool used for manual updates and by the auto script to do the actual updating.

===4over6 Automatic tunnels===
An idea to tunnel IPv4 packets over our IPv6 mesh networks without having to configure each tunnel. Think of it as a kind of one to many tunnel. So only one need to be configured on a host.

====Assumptions====
The IPv6 part will use OLSR or some routing protocol where static routes can be injected. The host doing the tunneling needs to be dual stacked. The edges will have IPv4 subnets from the 10.0.0.0/8 network in addition to the IPv6 subnets.

====The way it works====
An IPv6 subnet address (/64) is chosen that will be used as the tunnel prefix throughout the network. Each tunnel box must be configured in the following way:
* Its "local" interface(s) is/are configured with a 10.0.0.0 subnet(s).
* A virtual tunnel interface (tunX?) is created.
* An IPv4 static route for the whole 10.0.0.0/8 subnet is added into this interface. (XXX Maybe default route?)
* An IPv6 static route is calculated from the chosen IPv6 tunnel prefix plus the local IPv4 subnet(s) (fdfd:efef:abab:cdcd::10.1.2.0/120)
* This static route is also given to the routing protocol to announce.
* The 4over6 tunnel daemon [*] is attached to the tunnel interface. It is configured with the IPv6 tunnel prefix.

====The 4over6 tunnel daemon====
The configuration it needs is the IPv6 tunnel prefix. It receives IPv4 packets (from the local interface(s)) convert the header to IPv6 using the IPv6 tunnel prefix and sends it out again. It receives IPv6 packets, convert the IPv6 addresses back to IPv4 and sends it out again.

|------------------| |------------------|
| host1 | | host2 |
| | | |
| |---| | | |---| |
| | B | | | | E | |
|------------------| /\/\/\/\/\/\/\ |------------------|
A | | C / IPv6 \ D | | F
---------| |--------< Routed Network >----------| |----------
\ /
\/\/\/\/\/\/\/

Host1 and host2 are connected via an IPv6 routed network. (No native IPv4) prefix used for 4over6 fd9c:6829:597c:fefe/64

host1
A - 10.1.1.1/24
B - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.1.1.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.2.2.0/120 pointing in host2's direction.
C - IPv6-only address.

host2
D - IPv6-only address.
E - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.2.2.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.1.1.0/120 pointing in host1's direction.
F - 10.2.2.1/24

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type (as root):
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the ARM boards, you will need a tftp server loaded with boot2 and an ARM kernel with nfs booting compiled in. You will also need a nfs server setup with an extracted FreeBSD ARM tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?
* A wacky idea for updating even in the face of incompatible routing protocols. Have every box run a tcp relay to an update box. So every box can connect to a neighbor's relay for updates. This will not solve the problem of incompatible links, eg. adding wep or changing ssids.
* Robust addressing scheme for big networks that need to cooperate.
* What else?

John's research

2009-05-20T03:47:06Z

Jhay: /* Todo */

[[Category: Development Team Research Pages]]
==Intro==
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades. Remember that the CF is normally read-only, so has to be made read-write before editing the file with
mount -u -w /
And made read-only again afterwards with
mount -u -r /

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===

Disk split in 2 partitions. Upgrade the one that is not active.

Auto script run from cron to check for updates.

/upgrade tool used for manual updates and by the auto script to do the actual updating.

===4over6 Automatic tunnels===
An idea to tunnel IPv4 packets over our IPv6 mesh networks without having to configure each tunnel. Think of it as a kind of one to many tunnel. So only one need to be configured on a host.

====Assumptions====
The IPv6 part will use OLSR or some routing protocol where static routes can be injected. The host doing the tunneling needs to be dual stacked. The edges will have IPv4 subnets from the 10.0.0.0/8 network in addition to the IPv6 subnets.

====The way it works====
An IPv6 subnet address (/64) is chosen that will be used as the tunnel prefix throughout the network. Each tunnel box must be configured in the following way:
* Its "local" interface(s) is/are configured with a 10.0.0.0 subnet(s).
* A virtual tunnel interface (tunX?) is created.
* An IPv4 static route for the whole 10.0.0.0/8 subnet is added into this interface. (XXX Maybe default route?)
* An IPv6 static route is calculated from the chosen IPv6 tunnel prefix plus the local IPv4 subnet(s) (fdfd:efef:abab:cdcd::10.1.2.0/120)
* This static route is also given to the routing protocol to announce.
* The 4over6 tunnel daemon [*] is attached to the tunnel interface. It is configured with the IPv6 tunnel prefix.

====The 4over6 tunnel daemon====
The configuration it needs is the IPv6 tunnel prefix. It receives IPv4 packets (from the local interface(s)) convert the header to IPv6 using the IPv6 tunnel prefix and sends it out again. It receives IPv6 packets, convert the IPv6 addresses back to IPv4 and sends it out again.

|------------------| |------------------|
| host1 | | host2 |
| | | |
| |---| | | |---| |
| | B | | | | E | |
|------------------| /\/\/\/\/\/\/\ |------------------|
A | | C / IPv6 \ D | | F
---------| |--------< Routed Network >----------| |----------
\ /
\/\/\/\/\/\/\/

Host1 and host2 are connected via an IPv6 routed network. (No native IPv4) prefix used for 4over6 fd9c:6829:597c:fefe/64

host1
A - 10.1.1.1/24
B - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.1.1.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.2.2.0/120 pointing in host2's direction.
C - IPv6-only address.

host2
D - IPv6-only address.
E - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.2.2.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.1.1.0/120 pointing in host1's direction.
F - 10.2.2.1/24

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type (as root):
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the ARM boards, you will need a tftp server loaded with boot2 and an ARM kernel with nfs booting compiled in. You will also need a nfs server setup with an extracted FreeBSD ARM tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?
* A wacky idea for updating even in the face of incompatible routing protocols. Have every box run a tcp relay to an update box. So every box can connect to a neighbor's relay for updates. This will not solve the problem of incompatible links, eg. adding wep or changing ssids.
* Robust addressing scheme for big networks that need to cooperate.
* What else?

John's research

2009-03-13T06:22:40Z

Jhay: /* Todo */ Add something

[[Category: Development Team Research Pages]]
==Intro==
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades. Remember that the CF is normally read-only, so has to be made read-write before editing the file with
mount -u -w /
And made read-only again afterwards with
mount -u -r /

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===

Disk split in 2 partitions. Upgrade the one that is not active.

Auto script run from cron to check for updates.

/upgrade tool used for manual updates and by the auto script to do the actual updating.

===4over6 Automatic tunnels===
An idea to tunnel IPv4 packets over our IPv6 mesh networks without having to configure each tunnel. Think of it as a kind of one to many tunnel. So only one need to be configured on a host.

====Assumptions====
The IPv6 part will use OLSR or some routing protocol where static routes can be injected. The host doing the tunneling needs to be dual stacked. The edges will have IPv4 subnets from the 10.0.0.0/8 network in addition to the IPv6 subnets.

====The way it works====
An IPv6 subnet address (/64) is chosen that will be used as the tunnel prefix throughout the network. Each tunnel box must be configured in the following way:
* Its "local" interface(s) is/are configured with a 10.0.0.0 subnet(s).
* A virtual tunnel interface (tunX?) is created.
* An IPv4 static route for the whole 10.0.0.0/8 subnet is added into this interface. (XXX Maybe default route?)
* An IPv6 static route is calculated from the chosen IPv6 tunnel prefix plus the local IPv4 subnet(s) (fdfd:efef:abab:cdcd::10.1.2.0/120)
* This static route is also given to the routing protocol to announce.
* The 4over6 tunnel daemon [*] is attached to the tunnel interface. It is configured with the IPv6 tunnel prefix.

====The 4over6 tunnel daemon====
The configuration it needs is the IPv6 tunnel prefix. It receives IPv4 packets (from the local interface(s)) convert the header to IPv6 using the IPv6 tunnel prefix and sends it out again. It receives IPv6 packets, convert the IPv6 addresses back to IPv4 and sends it out again.

|------------------| |------------------|
| host1 | | host2 |
| | | |
| |---| | | |---| |
| | B | | | | E | |
|------------------| /\/\/\/\/\/\/\ |------------------|
A | | C / IPv6 \ D | | F
---------| |--------< Routed Network >----------| |----------
\ /
\/\/\/\/\/\/\/

Host1 and host2 are connected via an IPv6 routed network. (No native IPv4) prefix used for 4over6 fd9c:6829:597c:fefe/64

host1
A - 10.1.1.1/24
B - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.1.1.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.2.2.0/120 pointing in host2's direction.
C - IPv6-only address.

host2
D - IPv6-only address.
E - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.2.2.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.1.1.0/120 pointing in host1's direction.
F - 10.2.2.1/24

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type (as root):
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the ARM boards, you will need a tftp server loaded with boot2 and an ARM kernel with nfs booting compiled in. You will also need a nfs server setup with an extracted FreeBSD ARM tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?
* A wacky idea for updating even in the face of incompatible routing protocols. Have every box run a tcp relay to an update box. So every box can connect to a neighbor's relay for updates. This will not solve the problem of incompatible links, eg. adding wep or changing ssids.
* Robust addressing scheme for big networks that need to cooperate.

John's research

2008-08-14T20:04:39Z

Jhay: /* Upgrades and Automagic upgrades */ Still need lots of work

[[Category: Development Team Research Pages]]
==Intro==
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades. Remember that the CF is normally read-only, so has to be made read-write before editing the file with
mount -u -w /
And made read-only again afterwards with
mount -u -r /

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===

Disk split in 2 partitions. Upgrade the one that is not active.

Auto script run from cron to check for updates.

/upgrade tool used for manual updates and by the auto script to do the actual updating.

===4over6 Automatic tunnels===
An idea to tunnel IPv4 packets over our IPv6 mesh networks without having to configure each tunnel. Think of it as a kind of one to many tunnel. So only one need to be configured on a host.

====Assumptions====
The IPv6 part will use OLSR or some routing protocol where static routes can be injected. The host doing the tunneling needs to be dual stacked. The edges will have IPv4 subnets from the 10.0.0.0/8 network in addition to the IPv6 subnets.

====The way it works====
An IPv6 subnet address (/64) is chosen that will be used as the tunnel prefix throughout the network. Each tunnel box must be configured in the following way:
* Its "local" interface(s) is/are configured with a 10.0.0.0 subnet(s).
* A virtual tunnel interface (tunX?) is created.
* An IPv4 static route for the whole 10.0.0.0/8 subnet is added into this interface. (XXX Maybe default route?)
* An IPv6 static route is calculated from the chosen IPv6 tunnel prefix plus the local IPv4 subnet(s) (fdfd:efef:abab:cdcd::10.1.2.0/120)
* This static route is also given to the routing protocol to announce.
* The 4over6 tunnel daemon [*] is attached to the tunnel interface. It is configured with the IPv6 tunnel prefix.

====The 4over6 tunnel daemon====
The configuration it needs is the IPv6 tunnel prefix. It receives IPv4 packets (from the local interface(s)) convert the header to IPv6 using the IPv6 tunnel prefix and sends it out again. It receives IPv6 packets, convert the IPv6 addresses back to IPv4 and sends it out again.

|------------------| |------------------|
| host1 | | host2 |
| | | |
| |---| | | |---| |
| | B | | | | E | |
|------------------| /\/\/\/\/\/\/\ |------------------|
A | | C / IPv6 \ D | | F
---------| |--------< Routed Network >----------| |----------
\ /
\/\/\/\/\/\/\/

Host1 and host2 are connected via an IPv6 routed network. (No native IPv4) prefix used for 4over6 fd9c:6829:597c:fefe/64

host1
A - 10.1.1.1/24
B - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.1.1.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.2.2.0/120 pointing in host2's direction.
C - IPv6-only address.

host2
D - IPv6-only address.
E - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.2.2.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.1.1.0/120 pointing in host1's direction.
F - 10.2.2.1/24

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type (as root):
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the ARM boards, you will need a tftp server loaded with boot2 and an ARM kernel with nfs booting compiled in. You will also need a nfs server setup with an extracted FreeBSD ARM tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?
* A wacky idea for updating even in the face of incompatible routing protocols. Have every box run a tcp relay to an update box. So every box can connect to a neighbor's relay for updates. This will not solve the problem of incompatible links, eg. adding wep or changing ssids.

John's research

2008-08-14T06:02:34Z

Jhay: /* What is there to tweak */ Add the requirement to remount /

[[Category: Development Team Research Pages]]
==Intro==
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades. Remember that the CF is normally read-only, so has to be made read-write before editing the file with
mount -u -w /
And made read-only again afterwards with
mount -u -r /

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===
===4over6 Automatic tunnels===
An idea to tunnel IPv4 packets over our IPv6 mesh networks without having to configure each tunnel. Think of it as a kind of one to many tunnel. So only one need to be configured on a host.

====Assumptions====
The IPv6 part will use OLSR or some routing protocol where static routes can be injected. The host doing the tunneling needs to be dual stacked. The edges will have IPv4 subnets from the 10.0.0.0/8 network in addition to the IPv6 subnets.

====The way it works====
An IPv6 subnet address (/64) is chosen that will be used as the tunnel prefix throughout the network. Each tunnel box must be configured in the following way:
* Its "local" interface(s) is/are configured with a 10.0.0.0 subnet(s).
* A virtual tunnel interface (tunX?) is created.
* An IPv4 static route for the whole 10.0.0.0/8 subnet is added into this interface. (XXX Maybe default route?)
* An IPv6 static route is calculated from the chosen IPv6 tunnel prefix plus the local IPv4 subnet(s) (fdfd:efef:abab:cdcd::10.1.2.0/120)
* This static route is also given to the routing protocol to announce.
* The 4over6 tunnel daemon [*] is attached to the tunnel interface. It is configured with the IPv6 tunnel prefix.

====The 4over6 tunnel daemon====
The configuration it needs is the IPv6 tunnel prefix. It receives IPv4 packets (from the local interface(s)) convert the header to IPv6 using the IPv6 tunnel prefix and sends it out again. It receives IPv6 packets, convert the IPv6 addresses back to IPv4 and sends it out again.

|------------------| |------------------|
| host1 | | host2 |
| | | |
| |---| | | |---| |
| | B | | | | E | |
|------------------| /\/\/\/\/\/\/\ |------------------|
A | | C / IPv6 \ D | | F
---------| |--------< Routed Network >----------| |----------
\ /
\/\/\/\/\/\/\/

Host1 and host2 are connected via an IPv6 routed network. (No native IPv4) prefix used for 4over6 fd9c:6829:597c:fefe/64

host1
A - 10.1.1.1/24
B - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.1.1.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.2.2.0/120 pointing in host2's direction.
C - IPv6-only address.

host2
D - IPv6-only address.
E - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.2.2.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.1.1.0/120 pointing in host1's direction.
F - 10.2.2.1/24

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type (as root):
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the ARM boards, you will need a tftp server loaded with boot2 and an ARM kernel with nfs booting compiled in. You will also need a nfs server setup with an extracted FreeBSD ARM tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?
* A wacky idea for updating even in the face of incompatible routing protocols. Have every box run a tcp relay to an update box. So every box can connect to a neighbor's relay for updates. This will not solve the problem of incompatible links, eg. adding wep or changing ssids.

John's research

2008-08-14T05:59:47Z

Jhay: /* 4over6 Automatic tunnels */ First stab at it

[[Category: Development Team Research Pages]]
==Intro==
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===
===4over6 Automatic tunnels===
An idea to tunnel IPv4 packets over our IPv6 mesh networks without having to configure each tunnel. Think of it as a kind of one to many tunnel. So only one need to be configured on a host.

====Assumptions====
The IPv6 part will use OLSR or some routing protocol where static routes can be injected. The host doing the tunneling needs to be dual stacked. The edges will have IPv4 subnets from the 10.0.0.0/8 network in addition to the IPv6 subnets.

====The way it works====
An IPv6 subnet address (/64) is chosen that will be used as the tunnel prefix throughout the network. Each tunnel box must be configured in the following way:
* Its "local" interface(s) is/are configured with a 10.0.0.0 subnet(s).
* A virtual tunnel interface (tunX?) is created.
* An IPv4 static route for the whole 10.0.0.0/8 subnet is added into this interface. (XXX Maybe default route?)
* An IPv6 static route is calculated from the chosen IPv6 tunnel prefix plus the local IPv4 subnet(s) (fdfd:efef:abab:cdcd::10.1.2.0/120)
* This static route is also given to the routing protocol to announce.
* The 4over6 tunnel daemon [*] is attached to the tunnel interface. It is configured with the IPv6 tunnel prefix.

====The 4over6 tunnel daemon====
The configuration it needs is the IPv6 tunnel prefix. It receives IPv4 packets (from the local interface(s)) convert the header to IPv6 using the IPv6 tunnel prefix and sends it out again. It receives IPv6 packets, convert the IPv6 addresses back to IPv4 and sends it out again.

|------------------| |------------------|
| host1 | | host2 |
| | | |
| |---| | | |---| |
| | B | | | | E | |
|------------------| /\/\/\/\/\/\/\ |------------------|
A | | C / IPv6 \ D | | F
---------| |--------< Routed Network >----------| |----------
\ /
\/\/\/\/\/\/\/

Host1 and host2 are connected via an IPv6 routed network. (No native IPv4) prefix used for 4over6 fd9c:6829:597c:fefe/64

host1
A - 10.1.1.1/24
B - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.1.1.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.2.2.0/120 pointing in host2's direction.
C - IPv6-only address.

host2
D - IPv6-only address.
E - virtual (tun) interface. Static routes 10.0.0.0/8 and
fd9c:6829:597c:fefe::10.2.2.0/120 pointing into interface.
A route fd9c:6829:597c:fefe::10.1.1.0/120 pointing in host1's direction.
F - 10.2.2.1/24

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type (as root):
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the ARM boards, you will need a tftp server loaded with boot2 and an ARM kernel with nfs booting compiled in. You will also need a nfs server setup with an extracted FreeBSD ARM tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?
* A wacky idea for updating even in the face of incompatible routing protocols. Have every box run a tcp relay to an update box. So every box can connect to a neighbor's relay for updates. This will not solve the problem of incompatible links, eg. adding wep or changing ssids.

John's research

2008-08-14T05:50:58Z

Jhay: /* New Install */ tweak case

John's research

2008-08-14T05:48:56Z

Jhay: /* Upgrade */ add root requirement

John's research

2008-08-13T20:42:36Z

Jhay: /* Todo */ wacky update idea

John's research

2008-08-13T19:57:35Z

Jhay: Put the start stuff under an intro heading

John's research

2008-08-13T19:52:08Z

Jhay: /* Todo */ Should distros be signed?

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
FreeBSD is a lovely operating system and the standard startup scripts already cater diskless systems, read-only filesystems, network boot with a nfs root, etc. The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible.

This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===
===4over6 Automatic tunnels===

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type:
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the Arm boards, you will need a tftp server loaded with boot2 and a Arm kernel with nfs booting compiled in. You will also need a
nfs server setup with an extracted FreeBSD Arm tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf
* Should updates be signed so that the auto update will only update to a signed distro file?

John's research

2008-08-13T18:56:07Z

Jhay: /* How the config files on our distro fit together */ Praise FreeBSD a bit

John's research

2008-08-13T18:51:57Z

Jhay: Add a "how bits and pieces work" section

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==How bits and pieces work==
===Upgrades and Automagic upgrades===
===4over6 Automatic tunnels===

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type:
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the Arm boards, you will need a tftp server loaded with boot2 and a Arm kernel with nfs booting compiled in. You will also need a
nfs server setup with an extracted FreeBSD Arm tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf

John's research

2008-08-13T18:48:26Z

Jhay: /* Building a distro */ A gypo stab at building a distro

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type:
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the Arm boards, you will need a tftp server loaded with boot2 and a Arm kernel with nfs booting compiled in. You will also need a
nfs server setup with an extracted FreeBSD Arm tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==
This one is easy. If you have root on my box, you go to /home/jhay/small and type:
./build_chroot small-7-arm.cfg
to get an ARM distro or
./build_chroot small-7.cfg
for an i386 distro. A tiny distro that can fit on half of a 64M CF can be built with:
./build_chroot small-7-32m.cfg

The trick is to get root on my box or to get me to document more. :-)

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf

John's research

2008-08-13T18:43:31Z

Jhay: /* Installing a distro */ Firts stab, lots more needed

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==
===Upgrade===
Well if it is only an upgrade, ie. the box is already running an older version, just make sure it is connected to the network and type:
/upgrade ftp://crypton/disk-arm-7-20080813.tgz
Substitute the file name for the correct one. The upgrade script understand ftp, http, ssh and a local file:
/upgrade <user@host:file>
/upgrade <ftp://[user[:password]@]host[:port]/path/file>"
/upgrade <http://[user[:password]@]host[:port]/path/file>"
/upgrade </path/file>"

===New Install===
This is a bit more involved.
* For the Arm boards, you will need a tftp server loaded with boot2 and a Arm kernel with nfs booting compiled in. You will also need a
nfs server setup with an extracted FreeBSD Arm tree.
* For the i386 based boards, you will need a dhcp server that can handle PXE (for the soekris), with a tftp server and a nfs server.

The basic idea is then to nfs boot the board into single user mode and then run the writedisk script which will prepare the disk and install the distro on it.

==Building a distro==

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf

John's research

2008-08-13T18:18:23Z

Jhay: List the boards we use

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers. Currently they are a mix of Soekris net4501, net4526, net4801, Wrap 2C, 1E, Gateworks Avila and ADI Metro Pronghorn boards.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==

==Building a distro==

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf

John's research

2008-08-13T18:07:38Z

Jhay: /* ADI Pronghorn Metro boards */ Clarify a bit

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
> cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
> ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
> ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
> load boot2

* Now write it to flash.
> fis create boot2
* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
> fis free
> fis unlock -f 0x50060000 -l 0x20000

* Now go and configure RedBoot to automatically run boot2 on startup.
> fconfig
* Change the "run script at boot" to true
* Change the startup script to:
fis load boot2
go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

> load -b 0x200000 kernel-avila
> go

* Type <enter> at the shell prompt. It should list all the distros available. Choose the correct one for your architecture.
> ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
> reboot

* Reboot to make sure everything is working.

==Installing a distro==

==Building a distro==

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf

John's research

2008-08-13T17:59:48Z

Jhay: Add todo section

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
* > cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
* > ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
* > ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
* > load boot2

* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
** > fis free
** > fis unlock -f 0x50060000 -l 0x20000

* > fis create boot2

* > fconfig
* Change the "run script at boot" to true
* Change the startup script to:
** fis load boot2
** go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

* > load -b 0x200000 kernel-avila
* > go

* Type <enter> at the shell prompt.
* > ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
* > reboot

* Reboot to make sure everything is working.

==Installing a distro==

==Building a distro==

==Todo==

Ideas that might get implemented.
* Handle extra hna{4|6} entries from rc.conf

John's research

2008-08-13T17:56:36Z

Jhay: /* What is there to tweak */ First stab at it

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild. Anybody with better writing or organizational skills, feel free to tweak. If there are stuff missing, either add or tell me.

Here I'll try to capture the work done with our FreeBSD based wireless routers.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

In theory we want to end up tweaking / configuring nothing, but we are not there yet. :-)

These configs go in /conf/default/etc/rc.conf.local unless otherwise specified. You can look in rc.conf.mesh to see what the defaults are, but do not change it there. That will break upgrades.

A network needs one box that is the dns server. On that box you will need to set
mesh_dns_enable="YES"

One thing that is often needed is to swap channels on the BackBone links. You can change it with lines like this:
mesh_bbchana="140"
mesh_bbchanb="136"

If you want to give the box a name:
hostname="ajay-rtr.cids.org.za"

If you need to override everything for an interface:
ifconfig_ath0="mode 11a mediaopt adhoc channel 165 ssid ptabb"

A specific prefix for an interface:
ipv6_prefix_ath0="fd9c:6829:597c:10"

If you need to override the ipv4 address:
ipv4_addrs_npe0="10.3.2.1/24"

Common files that also might need to be tweaked are:
/conf/default/usr.local.etc/olsrd.conf
/conf/default/usr.local.etc/dnsmasq.conf
Although, if you need to, tell me so that we can see if it can be handled automagically by a script.

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
* > cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
* > ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
* > ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
* > load boot2

* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
** > fis free
** > fis unlock -f 0x50060000 -l 0x20000

* > fis create boot2

* > fconfig
* Change the "run script at boot" to true
* Change the startup script to:
** fis load boot2
** go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

* > load -b 0x200000 kernel-avila
* > go

* Type <enter> at the shell prompt.
* > ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
* > reboot

* Reboot to make sure everything is working.

==Installing a distro==

==Building a distro==

John's research

2008-08-13T17:28:52Z

Jhay: invite help

John's research

2008-08-13T17:26:42Z

Jhay: /* How the config files on our distro fit together */ Clarify rc.conf content

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild.

Here I'll try to capture the work done with our FreeBSD based wireless routers.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order. These files just contain shell variables for example:

hostname="arm-tst.mesh"
mesh_dns_enable="YES"

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
* > cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
* > ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
* > ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
* > load boot2

* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
** > fis free
** > fis unlock -f 0x50060000 -l 0x20000

* > fis create boot2

* > fconfig
* Change the "run script at boot" to true
* Change the startup script to:
** fis load boot2
** go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

* > load -b 0x200000 kernel-avila
* > go

* Type <enter> at the shell prompt.
* > ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
* > reboot

* Reboot to make sure everything is working.

==Installing a distro==

==Building a distro==

John's research

2008-08-13T17:19:41Z

Jhay: /* How the config files on our distro fit together */ Flesh out some more

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild.

Here I'll try to capture the work done with our FreeBSD based wireless routers.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order.

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

So the most important config files are:
* rc.conf - edited by auto script if auto_update_enable and _url set
* rc.conf.mesh - included early by rc.conf with defaults for the mesh
* rc.conf.local - overrides with partly manual conf

The config directories:
* /etc - ramdisk with end results, everything is lost on a reboot
* /conf/base/etc - original FreeBSD stuff
* /conf/default/etc - changed files, our and packages
* /usr/local/etc - a symlink to /etc/usr.local.etc

The basic idea is that config overrides that are done manually, have to be done in /conf/default/etc/rc.conf.local because it is read last and so overrides previous settings.

The startup scripts will create the ramdisk /etc, then recursively copy /conf/base/etc into it and then /conf/default/etc. The real /etc needs diskless, rc, fstab and rc.initdiskless in it for this to
work.

Files that will need to be twiddled by scripts on startup:
* /etc/rc.conf - interface conf
* /usr/local/etc/olsrd.conf - interface, dns
* /usr/local/etc/dhcpd.conf - dhcpd
* /etc/resolv.conf - ?
* /usr/local/etc/dnsmasq.conf - dhcp + dns ?

There are probably more.

==What is there to tweak==

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
* > cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
* > ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
* > ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
* > load boot2

* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
** > fis free
** > fis unlock -f 0x50060000 -l 0x20000

* > fis create boot2

* > fconfig
* Change the "run script at boot" to true
* Change the startup script to:
** fis load boot2
** go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

* > load -b 0x200000 kernel-avila
* > go

* Type <enter> at the shell prompt.
* > ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
* > reboot

* Reboot to make sure everything is working.

==Installing a distro==

==Building a distro==

John's research

2008-08-13T16:35:36Z

Jhay: Some more from my docs and part one of describing how the configs fit in

[[Category: Development Team Research Pages]]
Calling this research is probably a bit wild.

Here I'll try to capture the work done with our FreeBSD based wireless routers.

==How the config files on our distro fit together==
The idea was to try and leverage as much of FreeBSD's startup scripts and procedures as possible. This makes for less work and more testing, at least for the common parts. The standard FreeBSD startup scripts already cater for a diskless case, where /etc and /var are ramdisks and the rest can be read-only. That fits well with our case where we want the Compact Flash (CF) mostly read-only for reliability, but still needs things in /etc and /var to change during and after bootup. So we force this by creating the file /etc/diskless.

So maybe a description of the boot process is in order. I'll skip some detail that I think is not important to understand this. The kernel will at some stage get bored configuring RAM and probe for devices and look for something else to do. It will then load and run /sbin/init. Init will do some things and then run the /etc/rc script. And this is where the interesting stuff begins.

rc will try to determine if it is the diskless case. If so it will run /etc/rc.initdiskless, which will create a ramdisk over /etc and populate it from /conf/base/etc and then from /conf/default/etc. The idea being that you can have a standard /etc tree in /conf/base/ and your local changes in /conf/default/. So all the files that we change will be in /conf/default/. After that, rc.initdiskless will also create and populate a /var ramdisk. When finished, it will return to rc.

FreeBSD startup scripts reside in /etc/rc.d/ and /usr/local/etc/rc.d/ for packages. Now rc will use rcorder on those two directories to determine the dependencies and order they must be run in. /etc/rc.d/early.sh is one of the first to run. It will run /etc/rc.early if it exists. It does not exist by default.

Most startup scripts in rc.d/ can be enabled/disabled in /etc/rc.conf. Maybe that is a bit too simple. They will use a function called load_rc_config to load /etc/defaults/rc.conf, /etc/rc.conf and /etc/rc.conf.local, in that order.

So for our distro we install /etc/rc.early where the biggest chunk of our configuration will happen. A lot of it is just to put the right stuff in /etc/rc.conf and other app specific config files. Then the rest of the normal FreeBSD startup procedure, to run the startup scripts in rc.d/ will take care of the rest.

rc.conf - edited by auto script if auto_update_enable and _url set
rc.conf.mesh - included early by rc.conf with defaults for the mesh
rc.conf.local - overrides with partly manual conf

# conf directories
/etc - ramdisk with end results
/conf/base/etc - original FreeBSD stuff
/conf/default/etc - changed files, our and packages
/usr/local/etc - a symlink to /etc/usr.local.etc
#
# The basic idea is that config overrides that is done manually, have
# to be done in /conf/default/etc/rc.conf.local because it is read last
# and so overrides previous settings.
#
# The startup scripts will create the ramdisk /etc, then recursively copy
# /conf/base/etc into it and then /conf/default/etc.
# The real /etc needs diskless rc fstab rc.initdiskless in it for this to
# work.
#

### files that will need to be twiddled by scripts on startup:
/etc/rc.conf - interface conf
/usr/local/etc/olsrd.conf - interface, dns
/usr/local/etc/dhcpd.conf - dhcpd
/etc/resolv.conf - ?
/usr/local/etc/dnsmasq.conf - dhcp + dns ?

==What is there to tweak==

==Installing FreeBSD on a Avila/Pronghorn Metro ARM board==

===Gateworks Avila boards===
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

===ADI Pronghorn Metro boards===
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
* > cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
* > ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
* > ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
* > load boot2

* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
** > fis free
** > fis unlock -f 0x50060000 -l 0x20000

* > fis create boot2

* > fconfig
* Change the "run script at boot" to true
* Change the startup script to:
** fis load boot2
** go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

* > load -b 0x200000 kernel-avila
* > go

* Type <enter> at the shell prompt.
* > ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
* > reboot

* Reboot to make sure everything is working.

==Installing a distro==

==Building a distro==

John's research

2008-08-13T14:20:40Z

Jhay: Start moving my docs to the wiki - Arm install

[[Category: Development Team Research Pages]]
Research is probably a bit wild.

=Installing FreeBSD on a Avila/Pronghorn Metro ARM board=

==Gateworks Avila boards==
Note! FreeBSD detects the mini-pci cards different from the labeled
order on the PC board. It detects it in this order: J3, J1, J4, J2
So the card in J3 will be ath0...

==ADI Pronghorn Metro boards==
Note! FreeBSD detects the mini-pci cards in reverse order from the
labeling on the PC board. So it will detect from PCI3, PCI2, PCI1
to PCI0. So the card in slot PCI3 will be ath0.

* Redboot use 115200 baud, so use
* > cu -l /dev/your-serial-dev -s 115200

* Break RedBoot with ^C where it says you can. :-)
* > ip -l 10.0.0.234/24 -h 10.0.0.1 # LAB C155
* > ip -l 146.64.5.234/24 -h 146.64.5.1 # JHAY-LAB
* > load boot2

* On the ADI Pronghorn boards you might get an write error. They seem to lock the flash. Just unlock it. Look for the address in the error message and do something like this and do the fis create command again:
** > fis free
** > fis unlock -f 0x50060000 -l 0x20000

* > fis create boot2

* > fconfig
* Change the "run script at boot" to true
* Change the startup script to:
** fis load boot2
** go

* Change the timeout to 3.
* Change BOOTP enabled to false.

* Enter a . on the next option to end fconfig. Choose y to save it.

* > load -b 0x200000 kernel-avila
* > go

* Type <enter> at the shell prompt.
* > ./writedisk disk-arm-7-20070315.tgz # Normally use the latest
* > reboot

* Reboot to make sure everything is working.

High Performance Node - Specification

2008-08-13T13:53:03Z

Jhay: /* Firmware: "bokkie1 mesh distribution" */ Add list of scripts and config files needed to build a "distro"

[[Category: High Performance Node]]

== High Performance Node Development & Test Network ==
'''(Note)''' This is not the proper page for this discussion, will move it later. Keeping it here as much of the discussions currently happening, is around topics on this page

*Development
** Lab development platforms

*Locally deployed Test network
** Installation of a 10 node network on the CSIR campus
** Tx power set on minimum and attenuators used to minimise transmission distance
** Sites on the campus need to be selected
** Equipment for test network needs to be procured - suppliers?
***Enclosures - Poynting Antennas
***Gateworks boards -
***Dual WiFi cards -
***Power over Ethernet(poE)injectors -

*Demo nodes
**The thinking is around something the size of a linksys, using a small patch antenna ( This can use used when the demo needs to travel).

== Hardware ==
[[Image:Bokkie_Router_Pic.png|right|thumb|80px|Current Bokkie router]]
'''HPN based on current “Bokkie” router, to become “Bokkie v2”'''

=== Block Diagram of HPN ===
[[Image:HPN_Block Diagram_v2.png|left|thumb|300px|Block diagram of HPN]]
 

=== Enclosure ===
* Based on Poynting Enclosure ([http://www.poynting.co.za/productdisplay.php?id=186&cat_id=3 Product code:WLAN-A0033])
* Modification: swap 1x 2.4 GHz omni-directional antenna for 1x 5.8 GHz omni-directional antenna

=== Electronics ===
* 1x Gateworks [http://www.gateworks.com/products/avila/gw2348-4.php Avila GW2348-4] Network Platform
* 3x 802.11a/b/g mini PCI Atheros based WiFi cards - [http://www.miro.co.za/detail.aspx?pid=208&p=2&sp=&spp= CX-WLM54AG23 Complex High Power dual-band Mini PCI Card] (It maybe worthwhile to search and evaluate some of the new cards on the market, but our current "bokkie" routers use this one from Miro)
** 2x configured at 5.8 GHz
** 1x configured at 2.4 GHz
* 1x 1GB compact flash card
* 3x [http://en.wikipedia.org/wiki/U.FL U.FL to SMA connectors]

=== Enclosure - Other ===
* 1x External weatherproof Ethernet connector with Ethernet pigtail for POE (install on left side – looking at bokkie – keeping with current standard)
* 4x Gateworks board mounting standoffs
* External Mounting bracket

=== Accessories ===
* Powered 48V power-over-Ethernet injector
*Ethernet Cables
** 1x UV resistant outdoor CATV cable [have different lengths available (5m, 10m, 20m)]
** 1x indoor CATV cable [have different lengths available (5m, 10m, 20m)]
** Need for longer cables, custom make ?
* Some type of surge protection on the power side.
**Thinking of a product from http://www.clearline.co.za/. Still need to investigate

=== Other ===
* Wall mounting bracket (different types depending on type of wall - specification)
* Mounting pole (different types - spec)
* M10\M12 Coach Screws and fisher plugs (# depending on wall mounting bracket)
* 10x pack Cable ties
* Earthing kit Webb Industries have earthing kits that can be used. see http://www.webb.co.za/index.php?nav=news&ID=50
**Clamp\lug on one end of earthing cable for attachment onto wireless installation mounting bracket
**Earthing cable: Length (?), Gauge (?) - 10-15mm diameter
**Clamp on spike for other end of earthing cable for attachment onto earthing spike
**Earthing spike - 1m (driven into the ground at base of wall of the wireless installation)

== Software ==
=== Firmware: "bokkie1 mesh distribution" ===
This software specification is based on the current FreeBSD version of the firmware. I have named it "bokkie1 mesh distribution" as a working title (for want of a better name - please provide a nice snazzy one)

* A script is used to build the current firmware build based on the platform. Please insert the list of packages\utilites\etc used to make this build.
** packages installed
*** dnsmasq
*** ffproxy
*** olsrd
*** php - This is not used at the moment pending what the GUI needs.
*** thttpd - Maybe change to mini_httpd because it can do ssl.

** files with local changes
*** crontab fstab host.conf motd nsswitch.conf syslog.conf termcap ttys boot.config loader.conf localtime motd rc.conf snmpd.config beastie.4th early.sh .cshrc rc.d/var gateways zebra.conf.org ripd.conf.org ripngd.conf.org master.passwd group

** local stuff
*** rc.early
*** rc.conf.mesh.{dbn|pta}
*** rc.subr.mesh
*** add-dd-dns
*** add-mesh-dns
*** dd-list
*** del-dead-dns
*** wlanwd
*** newupdate
*** dnsmasq.conf
*** dnsmasqaddrs
*** regdns
*** rssi
*** rc.d/4over6
*** 4over6
*** bsnmpd6
*** upgrade(2)
*** /root/.ssh/{id_dsa|id_dsa.pub|config}
*** /usr/local/etc/{olsrd.conf|rc.d/olsrd} start_olsrd
*** rc.d/ffproxy
*** udpr
*** pinger
*** namedb/*

** Scripts and configs used to build all of this:
*** build_chroot, create_it, checkfiles
*** small-clean.cfg, small-7-arm.cfg, small-7.cfg, small-7-32m.cfg
*** small-file-list, small-file-curr-list.diff, small-file-named-list, small-file-noathstats-list

* Additional
** IPv4 over IPv6
*** Allows for automatic configuration of the tunnels
*** Automatic DHCP of IPv4
** Supports HTTPS and HTTP
** Runs mini_httpd web server

=== GUI ===
The GUI has two main links, Status and Administration(basic). The Status link is unencrypted, however, the Administrion link(s) are encrypted and authenticated.
*Status link provides for the user to view:
**The configuration status of the Node
**The routing table
**The link/signal strength with respect to other nodes in the vicinity
*Administration
**Change hostname
**Set the NTP server (remote/local)
**Set DNS server (remote/local)
**Create a cluster
**Command line interafce

=== Remote upgradeable ===
*What current functionality exists?

*What further development is needed?

*What limitations exits?
** Cannot be remotely upgraded if there is a protocol change

=== Further development to functionality ===
* GSM modem to the development network and first nodes in the field

* Watchdog
**Problem with native watchdog on Gateworks Avila board
***Boot failure resuscitation
**Specific to Gateworks Avila Board
**PCB to be developed that plugs into the JTag connector

* WEP security

* Mechanism to get the GPS co-ord configured in the HPN. This can later be used in the visualisation tool on the gateway with a Google plot of the nodes.

[[Image:Indicator_v2.png|right|thumb|150px|LED type indicator system]]
* Indicator:
**Visual: Example of indicator system (using LEDs mounted at the bottom of the enclosure) for alignment, type of box (ie. red or green, which is an indication of the channel being used), power to box
***1 - Left most LED can be either RED or GREEN, showing type of box - this can be configured in the setup and commissioning of the router(indication of the channel being used), ie. this is either a red box or a green box
***1 - Right most LED shows power
***2 - 5 Used as 4 point scale for signal strength
**Audible: with a buzzer used for alignment
** Check the power consumption (especially for multiple LEDs), and how to start/stop the beeping mode (may also be used for LEDs)

High Performance Node - Specification

2008-08-13T13:42:31Z

Jhay: /* Firmware: "bokkie1 mesh distribution" */ Add file list

[[Category: High Performance Node]]

== High Performance Node Development & Test Network ==
'''(Note)''' This is not the proper page for this discussion, will move it later. Keeping it here as much of the discussions currently happening, is around topics on this page

*Development
** Lab development platforms

*Locally deployed Test network
** Installation of a 10 node network on the CSIR campus
** Tx power set on minimum and attenuators used to minimise transmission distance
** Sites on the campus need to be selected
** Equipment for test network needs to be procured - suppliers?
***Enclosures - Poynting Antennas
***Gateworks boards -
***Dual WiFi cards -
***Power over Ethernet(poE)injectors -

*Demo nodes
**The thinking is around something the size of a linksys, using a small patch antenna ( This can use used when the demo needs to travel).

== Hardware ==
[[Image:Bokkie_Router_Pic.png|right|thumb|80px|Current Bokkie router]]
'''HPN based on current “Bokkie” router, to become “Bokkie v2”'''

=== Block Diagram of HPN ===
[[Image:HPN_Block Diagram_v2.png|left|thumb|300px|Block diagram of HPN]]
 

=== Enclosure ===
* Based on Poynting Enclosure ([http://www.poynting.co.za/productdisplay.php?id=186&cat_id=3 Product code:WLAN-A0033])
* Modification: swap 1x 2.4 GHz omni-directional antenna for 1x 5.8 GHz omni-directional antenna

=== Electronics ===
* 1x Gateworks [http://www.gateworks.com/products/avila/gw2348-4.php Avila GW2348-4] Network Platform
* 3x 802.11a/b/g mini PCI Atheros based WiFi cards - [http://www.miro.co.za/detail.aspx?pid=208&p=2&sp=&spp= CX-WLM54AG23 Complex High Power dual-band Mini PCI Card] (It maybe worthwhile to search and evaluate some of the new cards on the market, but our current "bokkie" routers use this one from Miro)
** 2x configured at 5.8 GHz
** 1x configured at 2.4 GHz
* 1x 1GB compact flash card
* 3x [http://en.wikipedia.org/wiki/U.FL U.FL to SMA connectors]

=== Enclosure - Other ===
* 1x External weatherproof Ethernet connector with Ethernet pigtail for POE (install on left side – looking at bokkie – keeping with current standard)
* 4x Gateworks board mounting standoffs
* External Mounting bracket

=== Accessories ===
* Powered 48V power-over-Ethernet injector
*Ethernet Cables
** 1x UV resistant outdoor CATV cable [have different lengths available (5m, 10m, 20m)]
** 1x indoor CATV cable [have different lengths available (5m, 10m, 20m)]
** Need for longer cables, custom make ?
* Some type of surge protection on the power side.
**Thinking of a product from http://www.clearline.co.za/. Still need to investigate

=== Other ===
* Wall mounting bracket (different types depending on type of wall - specification)
* Mounting pole (different types - spec)
* M10\M12 Coach Screws and fisher plugs (# depending on wall mounting bracket)
* 10x pack Cable ties
* Earthing kit Webb Industries have earthing kits that can be used. see http://www.webb.co.za/index.php?nav=news&ID=50
**Clamp\lug on one end of earthing cable for attachment onto wireless installation mounting bracket
**Earthing cable: Length (?), Gauge (?) - 10-15mm diameter
**Clamp on spike for other end of earthing cable for attachment onto earthing spike
**Earthing spike - 1m (driven into the ground at base of wall of the wireless installation)

== Software ==
=== Firmware: "bokkie1 mesh distribution" ===
This software specification is based on the current FreeBSD version of the firmware. I have named it "bokkie1 mesh distribution" as a working title (for want of a better name - please provide a nice snazzy one)

* A script is used to build the current firmware build based on the platform. Please insert the list of packages\utilites\etc used to make this build.
** packages installed
*** dnsmasq
*** ffproxy
*** olsrd
*** php - This is not used at the moment pending what the GUI needs.
*** thttpd - Maybe change to mini_httpd because it can do ssl.

** files with local changes
*** crontab fstab host.conf motd nsswitch.conf syslog.conf termcap ttys boot.config loader.conf localtime motd rc.conf snmpd.config beastie.4th early.sh .cshrc rc.d/var gateways zebra.conf.org ripd.conf.org ripngd.conf.org master.passwd group

** local stuff
*** rc.early
*** rc.conf.mesh.{dbn|pta}
*** rc.subr.mesh
*** add-dd-dns
*** add-mesh-dns
*** dd-list
*** del-dead-dns
*** wlanwd
*** newupdate
*** dnsmasq.conf
*** dnsmasqaddrs
*** regdns
*** rssi
*** rc.d/4over6
*** 4over6
*** bsnmpd6
*** upgrade(2)
*** /root/.ssh/{id_dsa|id_dsa.pub|config}
*** /usr/local/etc/{olsrd.conf|rc.d/olsrd} start_olsrd
*** rc.d/ffproxy
*** udpr
*** pinger
*** namedb/*

* Additional
** IPv4 over IPv6
*** Allows for automatic configuration of the tunnels
*** Automatic DHCP of IPv4
** Supports HTTPS and HTTP
** Runs mini_httpd web server

=== GUI ===
The GUI has two main links, Status and Administration(basic). The Status link is unencrypted, however, the Administrion link(s) are encrypted and authenticated.
*Status link provides for the user to view:
**The configuration status of the Node
**The routing table
**The link/signal strength with respect to other nodes in the vicinity
*Administration
**Change hostname
**Set the NTP server (remote/local)
**Set DNS server (remote/local)
**Create a cluster
**Command line interafce

=== Remote upgradeable ===
*What current functionality exists?

*What further development is needed?

*What limitations exits?
** Cannot be remotely upgraded if there is a protocol change

=== Further development to functionality ===
* GSM modem to the development network and first nodes in the field

* Watchdog
**Problem with native watchdog on Gateworks Avila board
***Boot failure resuscitation
**Specific to Gateworks Avila Board
**PCB to be developed that plugs into the JTag connector

* WEP security

* Mechanism to get the GPS co-ord configured in the HPN. This can later be used in the visualisation tool on the gateway with a Google plot of the nodes.

[[Image:Indicator_v2.png|right|thumb|150px|LED type indicator system]]
* Indicator:
**Visual: Example of indicator system (using LEDs mounted at the bottom of the enclosure) for alignment, type of box (ie. red or green, which is an indication of the channel being used), power to box
***1 - Left most LED can be either RED or GREEN, showing type of box - this can be configured in the setup and commissioning of the router(indication of the channel being used), ie. this is either a red box or a green box
***1 - Right most LED shows power
***2 - 5 Used as 4 point scale for signal strength
**Audible: with a buzzer used for alignment
** Check the power consumption (especially for multiple LEDs), and how to start/stop the beeping mode (may also be used for LEDs)

High Performance Node - Specification

2008-08-13T12:59:17Z

Jhay: /* Firmware: "bokkie1 mesh distribution" */

[[Category: High Performance Node]]

== High Performance Node Development & Test Network ==
'''(Note)''' This is not the proper page for this discussion, will move it later. Keeping it here as much of the discussions currently happening, is around topics on this page

*Development
** Lab development platforms

*Locally deployed Test network
** Installation of a 10 node network on the CSIR campus
** Tx power set on minimum and attenuators used to minimise transmission distance
** Sites on the campus need to be selected
** Equipment for test network needs to be procured - suppliers?
***Enclosures - Poynting Antennas
***Gateworks boards -
***Dual WiFi cards -
***Power over Ethernet(poE)injectors -

*Demo nodes
**The thinking is around something the size of a linksys, using a small patch antenna ( This can use used when the demo needs to travel).

== Hardware ==
[[Image:Bokkie_Router_Pic.png|right|thumb|80px|Current Bokkie router]]
'''HPN based on current “Bokkie” router, to become “Bokkie v2”'''

=== Block Diagram of HPN ===
[[Image:HPN_Block Diagram_v2.png|left|thumb|300px|Block diagram of HPN]]
 

=== Enclosure ===
* Based on Poynting Enclosure ([http://www.poynting.co.za/productdisplay.php?id=186&cat_id=3 Product code:WLAN-A0033])
* Modification: swap 1x 2.4 GHz omni-directional antenna for 1x 5.8 GHz omni-directional antenna

=== Electronics ===
* 1x Gateworks [http://www.gateworks.com/products/avila/gw2348-4.php Avila GW2348-4] Network Platform
* 3x 802.11a/b/g mini PCI Atheros based WiFi cards - [http://www.miro.co.za/detail.aspx?pid=208&p=2&sp=&spp= CX-WLM54AG23 Complex High Power dual-band Mini PCI Card] (It maybe worthwhile to search and evaluate some of the new cards on the market, but our current "bokkie" routers use this one from Miro)
** 2x configured at 5.8 GHz
** 1x configured at 2.4 GHz
* 1x 1GB compact flash card
* 3x [http://en.wikipedia.org/wiki/U.FL U.FL to SMA connectors]

=== Enclosure - Other ===
* 1x External weatherproof Ethernet connector with Ethernet pigtail for POE (install on left side – looking at bokkie – keeping with current standard)
* 4x Gateworks board mounting standoffs
* External Mounting bracket

=== Accessories ===
* Powered 48V power-over-Ethernet injector
*Ethernet Cables
** 1x UV resistant outdoor CATV cable [have different lengths available (5m, 10m, 20m)]
** 1x indoor CATV cable [have different lengths available (5m, 10m, 20m)]
** Need for longer cables, custom make ?
* Some type of surge protection on the power side.
**Thinking of a product from http://www.clearline.co.za/. Still need to investigate

=== Other ===
* Wall mounting bracket (different types depending on type of wall - specification)
* Mounting pole (different types - spec)
* M10\M12 Coach Screws and fisher plugs (# depending on wall mounting bracket)
* 10x pack Cable ties
* Earthing kit Webb Industries have earthing kits that can be used. see http://www.webb.co.za/index.php?nav=news&ID=50
**Clamp\lug on one end of earthing cable for attachment onto wireless installation mounting bracket
**Earthing cable: Length (?), Gauge (?) - 10-15mm diameter
**Clamp on spike for other end of earthing cable for attachment onto earthing spike
**Earthing spike - 1m (driven into the ground at base of wall of the wireless installation)

== Software ==
=== Firmware: "bokkie1 mesh distribution" ===
This software specification is based on the current FreeBSD version of the firmware. I have named it "bokkie1 mesh distribution" as a working title (for want of a better name - please provide a nice snazzy one)

* A script is used to build the current firmware build based on the platform. Please insert the list of packages\utilites\etc used to make this build.
** packages installed
*** dnsmasq
*** ffproxy
*** olsrd
*** php - This is not used at the moment pending what the GUI needs.
*** thttpd - Maybe change to mini_httpd because it can do ssl.

* Additional
** IPv4 over IPv6
*** Allows for automatic configuration of the tunnels
*** Automatic DHCP of IPv4
** Supports HTTPS and HTTP
** Runs mini_httpd web server

=== GUI ===
The GUI has two main links, Status and Administration(basic). The Status link is unencrypted, however, the Administrion link(s) are encrypted and authenticated.
*Status link provides for the user to view:
**The configuration status of the Node
**The routing table
**The link/signal strength with respect to other nodes in the vicinity
*Administration
**Change hostname
**Set the NTP server (remote/local)
**Set DNS server (remote/local)
**Create a cluster
**Command line interafce

=== Remote upgradeable ===
*What current functionality exists?

*What further development is needed?

*What limitations exits?
** Cannot be remotely upgraded if there is a protocol change

=== Further development to functionality ===
* GSM modem to the development network and first nodes in the field

* Watchdog
**Problem with native watchdog on Gateworks Avila board
***Boot failure resuscitation
**Specific to Gateworks Avila Board
**PCB to be developed that plugs into the JTag connector

* WEP security

* Mechanism to get the GPS co-ord configured in the HPN. This can later be used in the visualisation tool on the gateway with a Google plot of the nodes.

[[Image:Indicator_v2.png|right|thumb|150px|LED type indicator system]]
* Indicator:
**Visual: Example of indicator system (using LEDs mounted at the bottom of the enclosure) for alignment, type of box (ie. red or green, which is an indication of the channel being used), power to box
***1 - Left most LED can be either RED or GREEN, showing type of box - this can be configured in the setup and commissioning of the router(indication of the channel being used), ie. this is either a red box or a green box
***1 - Right most LED shows power
***2 - 5 Used as 4 point scale for signal strength
**Audible: with a buzzer used for alignment
** Check the power consumption (especially for multiple LEDs), and how to start/stop the beeping mode (may also be used for LEDs)

High Performance Node - Specification

2008-08-13T10:09:27Z

Jhay: /* Firmware: "bokkie1 mesh distribution" */

[[Category: High Performance Node]]

== High Performance Node Development & Test Network ==
'''(Note)''' This is not the proper page for this discussion, will move it later. Keeping it here as much of the discussions currently happening, is around topics on this page

*Development
** Lab development platforms

*Locally deployed Test network
** Installation of a 10 node network on the CSIR campus
** Tx power set on minimum and attenuators used to minimise transmission distance
** Sites on the campus need to be selected
** Equipment for test network needs to be procured - suppliers?
***Enclosures - Poynting Antennas
***Gateworks boards -
***Dual WiFi cards -
***Power over Ethernet(poE)injectors -

*Demo nodes
**The thinking is around something the size of a linksys, using a small patch antenna ( This can use used when the demo needs to travel).

== Hardware ==
[[Image:Bokkie_Router_Pic.png|right|thumb|80px|Current Bokkie router]]
'''HPN based on current “Bokkie” router, to become “Bokkie v2”'''

=== Block Diagram of HPN ===
[[Image:HPN_Block Diagram_v2.png|left|thumb|300px|Block diagram of HPN]]
 

=== Enclosure ===
* Based on Poynting Enclosure ([http://www.poynting.co.za/productdisplay.php?id=186&cat_id=3 Product code:WLAN-A0033])
* Modification: swap 1x 2.4 GHz omni-directional antenna for 1x 5.8 GHz omni-directional antenna

=== Electronics ===
* 1x Gateworks [http://www.gateworks.com/products/avila/gw2348-4.php Avila GW2348-4] Network Platform
* 3x 802.11a/b/g mini PCI Atheros based WiFi cards - [http://www.miro.co.za/detail.aspx?pid=208&p=2&sp=&spp= CX-WLM54AG23 Complex High Power dual-band Mini PCI Card] (It maybe worthwhile to search and evaluate some of the new cards on the market, but our current "bokkie" routers use this one from Miro)
** 2x configured at 5.8 GHz
** 1x configured at 2.4 GHz
* 1x 1GB compact flash card
* 3x [http://en.wikipedia.org/wiki/U.FL U.FL to SMA connectors]

=== Enclosure - Other ===
* 1x External weatherproof Ethernet connector with Ethernet pigtail for POE (install on left side – looking at bokkie – keeping with current standard)
* 4x Gateworks board mounting standoffs
* External Mounting bracket

=== Accessories ===
* Powered 48V power-over-Ethernet injector
*Ethernet Cables
** 1x UV resistant outdoor CATV cable [have different lengths available (5m, 10m, 20m)]
** 1x indoor CATV cable [have different lengths available (5m, 10m, 20m)]
** Need for longer cables, custom make ?
* Some type of surge protection on the power side.
**Thinking of a product from http://www.clearline.co.za/. Still need to investigate

=== Other ===
* Wall mounting bracket (different types depending on type of wall - specification)
* Mounting pole (different types - spec)
* M10\M12 Coach Screws and fisher plugs (# depending on wall mounting bracket)
* 10x pack Cable ties
* Earthing kit Webb Industries have earthing kits that can be used. see http://www.webb.co.za/index.php?nav=news&ID=50
**Clamp\lug on one end of earthing cable for attachment onto wireless installation mounting bracket
**Earthing cable: Length (?), Gauge (?) - 10-15mm diameter
**Clamp on spike for other end of earthing cable for attachment onto earthing spike
**Earthing spike - 1m (driven into the ground at base of wall of the wireless installation)

== Software ==
=== Firmware: "bokkie1 mesh distribution" ===
This software specification is based on the current free BSD version of the firmware. I have named it "bokkie1 mesh distribution" as a working title (for want of a better name - please provide a nice snazzy one)

* A script is used to build the current firmware build based on the platform. Please insert the list of packages\utilites\etc used to make this build.
** packages installed
*** dnsmasq
*** ffproxy
*** olsrd
*** php - This is not used at the moment pending what the GUI needs.
*** thttpd - Maybe change to mini_httpd because it can do ssl.

* Additional
** IPv4 over IPv6
*** Allows for automatic configuration of the tunnels
*** Automatic DHCP of IPv4
** Supports HTTPS and HTTP
** Runs mini_httpd web server

=== GUI ===
The GUI has two main links, Status and Administration(basic). The Status link is unencrypted, however, the Administrion link(s) are encrypted and authenticated.
*Status link provides for the user to view:
**The configuration status of the Node
**The routing table
**The link/signal strength with respect to other nodes in the vicinity
*Administration
**Change hostname
**Set the NTP server (remote/local)
**Set DNS server (remote/local)
**Create a cluster
**Command line interafce

=== Remote upgradeable ===
*What current functionality exists?

*What further development is needed?

*What limitations exits?
** Cannot be remotely upgraded if there is a protocol change

=== Further development to functionality ===
* GSM modem to the development network and first nodes in the field

* Watchdog
**Problem with native watchdog on Gateworks Avila board
***Boot failure resuscitation
**Specific to Gateworks Avila Board
**PCB to be developed that plugs into the JTag connector

* WEP security

* Mechanism to get the GPS co-ord configured in the HPN. This can later be used in the visualisation tool on the gateway with a Google plot of the nodes.

[[Image:Indicator_v2.png|right|thumb|150px|LED type indicator system]]
* Indicator:
**Visual: Example of indicator system (using LEDs mounted at the bottom of the enclosure) for alignment, type of box (ie. red or green, which is an indication of the channel being used), power to box
***1 - Left most LED can be either RED or GREEN, showing type of box - this can be configured in the setup and commissioning of the router(indication of the channel being used), ie. this is either a red box or a green box
***1 - Right most LED shows power
***2 - 5 Used as 4 point scale for signal strength
**Audible: with a buzzer used for alignment
** Check the power consumption (especially for multiple LEDs), and how to start/stop the beeping mode (may also be used for LEDs)

High Performance Node - Specification

2008-08-13T10:02:02Z

Jhay: /* Firmware: "bokkie1 mesh distribution" */

[[Category: High Performance Node]]

== High Performance Node Development & Test Network ==
'''(Note)''' This is not the proper page for this discussion, will move it later. Keeping it here as much of the discussions currently happening, is around topics on this page

*Development
** Lab development platforms

*Locally deployed Test network
** Installation of a 10 node network on the CSIR campus
** Tx power set on minimum and attenuators used to minimise transmission distance
** Sites on the campus need to be selected
** Equipment for test network needs to be procured - suppliers?
***Enclosures - Poynting Antennas
***Gateworks boards -
***Dual WiFi cards -
***Power over Ethernet(poE)injectors -

*Demo nodes
**The thinking is around something the size of a linksys, using a small patch antenna ( This can use used when the demo needs to travel).

== Hardware ==
[[Image:Bokkie_Router_Pic.png|right|thumb|80px|Current Bokkie router]]
'''HPN based on current “Bokkie” router, to become “Bokkie v2”'''

=== Block Diagram of HPN ===
[[Image:HPN_Block Diagram_v2.png|left|thumb|300px|Block diagram of HPN]]
 

=== Enclosure ===
* Based on Poynting Enclosure ([http://www.poynting.co.za/productdisplay.php?id=186&cat_id=3 Product code:WLAN-A0033])
* Modification: swap 1x 2.4 GHz omni-directional antenna for 1x 5.8 GHz omni-directional antenna

=== Electronics ===
* 1x Gateworks [http://www.gateworks.com/products/avila/gw2348-4.php Avila GW2348-4] Network Platform
* 3x 802.11a/b/g mini PCI Atheros based WiFi cards - [http://www.miro.co.za/detail.aspx?pid=208&p=2&sp=&spp= CX-WLM54AG23 Complex High Power dual-band Mini PCI Card] (It maybe worthwhile to search and evaluate some of the new cards on the market, but our current "bokkie" routers use this one from Miro)
** 2x configured at 5.8 GHz
** 1x configured at 2.4 GHz
* 1x 1GB compact flash card
* 3x [http://en.wikipedia.org/wiki/U.FL U.FL to SMA connectors]

=== Enclosure - Other ===
* 1x External weatherproof Ethernet connector with Ethernet pigtail for POE (install on left side – looking at bokkie – keeping with current standard)
* 4x Gateworks board mounting standoffs
* External Mounting bracket

=== Accessories ===
* Powered 48V power-over-Ethernet injector
*Ethernet Cables
** 1x UV resistant outdoor CATV cable [have different lengths available (5m, 10m, 20m)]
** 1x indoor CATV cable [have different lengths available (5m, 10m, 20m)]
** Need for longer cables, custom make ?
* Some type of surge protection on the power side.
**Thinking of a product from http://www.clearline.co.za/. Still need to investigate

=== Other ===
* Wall mounting bracket (different types depending on type of wall - specification)
* Mounting pole (different types - spec)
* M10\M12 Coach Screws and fisher plugs (# depending on wall mounting bracket)
* 10x pack Cable ties
* Earthing kit Webb Industries have earthing kits that can be used. see http://www.webb.co.za/index.php?nav=news&ID=50
**Clamp\lug on one end of earthing cable for attachment onto wireless installation mounting bracket
**Earthing cable: Length (?), Gauge (?) - 10-15mm diameter
**Clamp on spike for other end of earthing cable for attachment onto earthing spike
**Earthing spike - 1m (driven into the ground at base of wall of the wireless installation)

== Software ==
=== Firmware: "bokkie1 mesh distribution" ===
This software specification is based on the current free BSD version of the firmware. I have named it "bokkie1 mesh distribution" as a working title (for want of a better name - please provide a nice snazzy one)

* A script is used to build the current firmware build based on the platform. Please insert the list of packages\utilites\etc used to make this build.
** packages installed
*** dnsmasq
*** ffproxy
*** olsrd
*** php
*** thttpd - Maybe change to mini_httpd because it can do ssl.

* Additional
** IPv4 over IPv6
*** Allows for automatic configuration of the tunnels
*** Automatic DHCP of IPv4
** Supports HTTPS and HTTP
** Runs mini_httpd web server

=== GUI ===
The GUI has two main links, Status and Administration(basic). The Status link is unencrypted, however, the Administrion link(s) are encrypted and authenticated.
*Status link provides for the user to view:
**The configuration status of the Node
**The routing table
**The link/signal strength with respect to other nodes in the vicinity
*Administration
**Change hostname
**Set the NTP server (remote/local)
**Set DNS server (remote/local)
**Create a cluster
**Command line interafce

=== Remote upgradeable ===
*What current functionality exists?

*What further development is needed?

*What limitations exits?
** Cannot be remotely upgraded if there is a protocol change

=== Further development to functionality ===
* GSM modem to the development network and first nodes in the field

* Watchdog
**Problem with native watchdog on Gateworks Avila board
***Boot failure resuscitation
**Specific to Gateworks Avila Board
**PCB to be developed that plugs into the JTag connector

* WEP security

* Mechanism to get the GPS co-ord configured in the HPN. This can later be used in the visualisation tool on the gateway with a Google plot of the nodes.

[[Image:Indicator_v2.png|right|thumb|150px|LED type indicator system]]
* Indicator:
**Visual: Example of indicator system (using LEDs mounted at the bottom of the enclosure) for alignment, type of box (ie. red or green, which is an indication of the channel being used), power to box
***1 - Left most LED can be either RED or GREEN, showing type of box - this can be configured in the setup and commissioning of the router(indication of the channel being used), ie. this is either a red box or a green box
***1 - Right most LED shows power
***2 - 5 Used as 4 point scale for signal strength
**Audible: with a buzzer used for alignment
** Check the power consumption (especially for multiple LEDs), and how to start/stop the beeping mode (may also be used for LEDs)

High Performance Node - Specification

2008-08-13T09:56:24Z

Jhay: /* Firmware: "bokkie1 mesh distribution" */ Add some packages

[[Category: High Performance Node]]

== High Performance Node Development & Test Network ==
'''(Note)''' This is not the proper page for this discussion, will move it later. Keeping it here as much of the discussions currently happening, is around topics on this page

*Development
** Lab development platforms

*Locally deployed Test network
** Installation of a 10 node network on the CSIR campus
** Tx power set on minimum and attenuators used to minimise transmission distance
** Sites on the campus need to be selected
** Equipment for test network needs to be procured - suppliers?
***Enclosures - Poynting Antennas
***Gateworks boards -
***Dual WiFi cards -
***Power over Ethernet(poE)injectors -

*Demo nodes
**The thinking is around something the size of a linksys, using a small patch antenna ( This can use used when the demo needs to travel).

== Hardware ==
[[Image:Bokkie_Router_Pic.png|right|thumb|80px|Current Bokkie router]]
'''HPN based on current “Bokkie” router, to become “Bokkie v2”'''

=== Block Diagram of HPN ===
[[Image:HPN_Block Diagram_v2.png|left|thumb|300px|Block diagram of HPN]]
 

=== Enclosure ===
* Based on Poynting Enclosure ([http://www.poynting.co.za/productdisplay.php?id=186&cat_id=3 Product code:WLAN-A0033])
* Modification: swap 1x 2.4 GHz omni-directional antenna for 1x 5.8 GHz omni-directional antenna

=== Electronics ===
* 1x Gateworks [http://www.gateworks.com/products/avila/gw2348-4.php Avila GW2348-4] Network Platform
* 3x 802.11a/b/g mini PCI Atheros based WiFi cards - [http://www.miro.co.za/detail.aspx?pid=208&p=2&sp=&spp= CX-WLM54AG23 Complex High Power dual-band Mini PCI Card] (It maybe worthwhile to search and evaluate some of the new cards on the market, but our current "bokkie" routers use this one from Miro)
** 2x configured at 5.8 GHz
** 1x configured at 2.4 GHz
* 1x 1GB compact flash card
* 3x [http://en.wikipedia.org/wiki/U.FL U.FL to SMA connectors]

=== Enclosure - Other ===
* 1x External weatherproof Ethernet connector with Ethernet pigtail for POE (install on left side – looking at bokkie – keeping with current standard)
* 4x Gateworks board mounting standoffs
* External Mounting bracket

=== Accessories ===
* Powered 48V power-over-Ethernet injector
*Ethernet Cables
** 1x UV resistant outdoor CATV cable [have different lengths available (5m, 10m, 20m)]
** 1x indoor CATV cable [have different lengths available (5m, 10m, 20m)]
** Need for longer cables, custom make ?
* Some type of surge protection on the power side.
**Thinking of a product from http://www.clearline.co.za/. Still need to investigate

=== Other ===
* Wall mounting bracket (different types depending on type of wall - specification)
* Mounting pole (different types - spec)
* M10\M12 Coach Screws and fisher plugs (# depending on wall mounting bracket)
* 10x pack Cable ties
* Earthing kit Webb Industries have earthing kits that can be used. see http://www.webb.co.za/index.php?nav=news&ID=50
**Clamp\lug on one end of earthing cable for attachment onto wireless installation mounting bracket
**Earthing cable: Length (?), Gauge (?) - 10-15mm diameter
**Clamp on spike for other end of earthing cable for attachment onto earthing spike
**Earthing spike - 1m (driven into the ground at base of wall of the wireless installation)

== Software ==
=== Firmware: "bokkie1 mesh distribution" ===
This software specification is based on the current free BSD version of the firmware. I have named it "bokkie1 mesh distribution" as a working title (for want of a better name - please provide a nice snazzy one)

* A script is used to build the current firmware build based on the platform. Please insert the list of packages\utilites\etc used to make this build.
** packages installed
*** dnsmasq
*** ffproxy
*** olsrd
*** php
*** thttpd

* Additional
** IPv4 over IPv6
*** Allows for automatic configuration of the tunnels
*** Automatic DHCP of IPv4
** Supports HTTPS and HTTP
** Runs mini_httpd web server

=== GUI ===
The GUI has two main links, Status and Administration(basic). The Status link is unencrypted, however, the Administrion link(s) are encrypted and authenticated.
*Status link provides for the user to view:
**The configuration status of the Node
**The routing table
**The link/signal strength with respect to other nodes in the vicinity
*Administration
**Change hostname
**Set the NTP server (remote/local)
**Set DNS server (remote/local)
**Create a cluster
**Command line interafce

=== Remote upgradeable ===
*What current functionality exists?

*What further development is needed?

*What limitations exits?
** Cannot be remotely upgraded if there is a protocol change

=== Further development to functionality ===
* GSM modem to the development network and first nodes in the field

* Watchdog
**Problem with native watchdog on Gateworks Avila board
***Boot failure resuscitation
**Specific to Gateworks Avila Board
**PCB to be developed that plugs into the JTag connector

* WEP security

* Mechanism to get the GPS co-ord configured in the HPN. This can later be used in the visualisation tool on the gateway with a Google plot of the nodes.

[[Image:Indicator_v2.png|right|thumb|150px|LED type indicator system]]
* Indicator:
**Visual: Example of indicator system (using LEDs mounted at the bottom of the enclosure) for alignment, type of box (ie. red or green, which is an indication of the channel being used), power to box
***1 - Left most LED can be either RED or GREEN, showing type of box - this can be configured in the setup and commissioning of the router(indication of the channel being used), ie. this is either a red box or a green box
***1 - Right most LED shows power
***2 - 5 Used as 4 point scale for signal strength
**Audible: with a buzzer used for alignment
** Check the power consumption (especially for multiple LEDs), and how to start/stop the beeping mode (may also be used for LEDs)

User:Jhay

2007-05-30T07:31:05Z

Jhay: Add a link to edit the sidebar

Lets see if I can include a picture.

[[Image:John_Hay.jpg]]

Jip, it seems to work... or is that play?

So do I get email upon changes now?
Seems not yet?

This link should take you to the place where you can edit the sidebar.
[[MediaWiki:Sidebar]]

Main Page

2006-06-26T12:51:32Z

Jhay: Whitespace to get it to update

== [[Image: Meraka.jpg]] Wireless Africa / COIN Wiki ==
''Removing the barriers to enable bottom-up creation of access infrastructure''
----
[[Image: Cantenna-peebles-small.jpg]]
----

== [[NEW: Quick getting started guide for setting up an outdoor mesh node]] ==

Please use the discussion tag above to comment and provide suggestions!

Please Email wa-admin(at)meraka.org.za if you wish to contribute or for further information.

Main Page

2006-06-26T05:45:17Z

Jhay: white space

Downloads

2006-01-30T11:39:17Z

Jhay: Remove more whitespace

=Firmware=
==WRT54G==
===OpenWRT===
===Freifunk===
[[Media:Openwrt-g-freifunk-1point1.pdf|Freifunk 1.1, please rename extension to .bin]]

===DD-WRT===
===SveaSoft===

=Tools=
[[Media:Circular waveguide optimise.xls|Spreadsheet for Optimising Cantennae]]

=Documents=
[[Media:Wndw-ebook.pdf|Wireless Networking in the Developing World]]

Downloads

2006-01-30T11:38:39Z

Jhay: Remove some whitespace

Downloads

2006-01-30T11:37:29Z

Jhay: Part two

Downloads

2006-01-30T11:35:32Z

Jhay: Remove Ronel and my booboo

Downloads

2006-01-30T11:32:28Z

Jhay:

=Firmware=
==WRT54G==
===OpenWRT===
===Freifunk===
[[Media:Openwrt-g-freifunk-1point1.pdf|Freifunk 1.1, please rename extension to .bin]]

===DD-WRT===
===SveaSoft===

=Tools=
[[Media:Circular waveguide optimise.xls|Spreadsheet for Optimising Cantennae]]

=Documents=
[[Media:Women in ICT research outline v2.doc|Women in ICT Research Outline]]

MediaWiki:Sidebar

2005-11-22T08:03:54Z

Jhay:

MediaWiki:Sidebar

2005-11-21T18:30:33Z

Jhay:

MediaWiki:Sidebar

2005-11-21T18:29:08Z

Jhay:

User:Jhay

2005-11-21T10:12:02Z

Jhay:

Lets see if I can include a picture.

[[Image:John_Hay.jpg]]

Jip, it seems to work... or is that play?

So do I get email upon changes now?
Seems not yet?

User:Jhay

2005-11-21T10:09:57Z

Jhay:

Lets see if I can include a picture.

[[Image:John_Hay.jpg]]

Jip, it seems to work... or is that play?

So do I get email upon changes now?

File:Logo wa.jpg

2005-11-18T14:03:32Z

Jhay: Logo done by Yusuf

Logo done by Yusuf

User:Jhay

2005-11-08T06:45:51Z

Jhay:

Lets see if I can include a picture.

[[Image:John_Hay.jpg]]

Jip, it seems to work... or is that play?

User:Jhay

2005-11-08T06:08:59Z

Jhay:

Lets see if I can include a picture.

[[Image:John_Hay.jpg]]

File:John Hay.jpg

2005-11-08T06:07:30Z

Jhay: Family + Cruiser

Family + Cruiser