Setting up a connection to the network is fairly simple from OpenBSD. The steps are:
/etc/hostname.if file, where if is your
interface name.
For example, my /etc/hostname.vr0 contains:
dhcp NONE NONE NONE
On booting the vr0 is configured automatically and
receives the (fictional) address YYY.YYY.YYY.YYY:
May 7 14:45:09 habanero dhclient[2071]: DHCPDISCOVER on vr0 to 255.255.255.255 port 67 interval 4
May 7 14:45:10 habanero dhclient[2071]: DHCPOFFER from XXX.XXX.XXX.XXX
May 7 14:45:12 habanero dhclient[2071]: DHCPREQUEST on vr0 to 255.255.255.255 port 67
May 7 14:45:12 habanero dhclient[2071]: DHCPACK from XXX.XXX.XXX.XXX
May 7 14:45:13 habanero dhclient[2071]: bound to YYY.YYY.YYY.YYY -- renewal in 14400 seconds.
We're now ready to connect to Exetel via pppoe.
The easiest way to get started is with the userland pppoe program. It
provides a multitude of debugging options, and is fairly simple to set
up and pull down. It is configured, in this case, via a
/etc/ppp/ppp.conf file.
We need to tell ppp to use the pppoe pseudo-device, and to specify our login details (Exetel uses CHAP authentication for its wireless users). Also, we can ask for a nameserver list, and set the default route to be through Exetel.
An example/etc/ppp/ppp.conf:
default:
set log Phase Chat Connect hdlc LCP IPCP CCP tun command
pppoe:
set device "!/usr/sbin/pppoe -i vr0"
set mtu max 1492
set mru max 1492
set speed sync
disable acfcomp protocomp
deny acfcomp
set authname "YOURNAME"
set authkey "YOURPASSWORD"
add! default HISADDR
enable dns
The full details of this configuration language are specified in ppp(8).
At this point it's a good idea to turn on logging. Add the following to
/etc/syslog.conf:
!ppp
*.* /var/log/ppp.log
And create the file /var/log/ppp.log. Then restart syslog:
kill -HUP `cat /var/run/syslog.pid`.
We're now in a position to connect to Exetel:
# ppp pppoe
> dial
This should create the pppoe0 device, and then connect and authenticate via CHAP to Exetel. Once that's done, the pppoe0 device is configured with your IP address, DNS should be up, and the default route should be in place. If there are problems, inspect the log file. Read ppp(8) for more information.
Once pppoe is set up nicely, you can ask ppp to dial in the background, or add a line to rc.local to bring the network up when the machine is booted.
OpenBSD 3.7 introduced the kernel pppoe driver. Its advantage over the userland driver is that it is much simpler to configure, and comes up automatically on booting. Its disadvantage is that it's harder to debug.
The in-kernel pppoe is configured by creating the
/etc/hostname.pppoe0 file along these lines:
pppoedev vr0
!/usr/sbin/spppcontrol \$if myauthproto=chap myauthname=YOURNAME myauthkey=YOURPASSWORD
!/sbin/ifconfig \$if inet XXX.XXX.XXX.XXX 0.0.0.1 netmask 0xffffffff link1
!/sbin/route add default 0.0.0.1
up
This specifies which real device the pppoe0 interface is connected to.
We also specify how to authenticate to Exetel. The ifconfig
line enables the interface, where XXX.XXX.XXX.XXX is the static IP
Exetel assigns you. The link1 flag says to only bring up
the interface when data is ready to be sent over it (this has the side
effect of also reconnecting if it is dropped). The link1
hack to enable reconnection shouldn't be needed with a -current kernel.
Finally, we set the default route to be the magic value 0.0.0.1.
On booting you can see the network come up, around the same time as the dhcp requests go out:
pppoe0: phase establish
pppoe0: phase authenticate
pppoe0: phase network
The kernel pppoe driver isn't as configurable as the userland flavour,
and doesn't know how to ask for nameservers, so we have to enable DNS
ourselves. This can be done by writing your own
/etc/resolv.conf with the nameserver information the
userland pppoe gathers.
Sometimes, depending on the speed of the machine (I think) dhcp takes a
bit longer than the pppoe interface to set up. As a result, the default
route is not set properly. This can be fixed by making sure the magic
default route is also set when the interface that's configured by dhcp
comes up. Just add the !/sbin/route add default 0.0.0.1 to
the hostname.if file for the interface configured
via dhcp.
You may want to allow hosts on an internal LAN to access the internet
through the box connected to the wireless modem. This is done by setting
up a nat rule in the packet filter config file
/etc/pf.conf. Something like:
nat on $pppoe from $machine to any -> ($pppoe)
Here $pppoe is the pppoe0 interface, and
$machine is the (internal) IP address of the machine you
wish to let out through your wireless gateway.
One small difficulty arises when using the in-kernel pppoe driver, and network address translation. pppoe(4) explains this:
MTU/MSS ISSUES
Problems can arise on machines with private IPs connecting to the Inter-
net via a machine running both Network Address Translation (NAT) and
pppoe. Standard Ethernet uses a Maximum Transmission Unit (MTU) of 1500
bytes, whereas PPPoE mechanisms need a further 8 bytes of overhead. This
leaves a maximum MTU of 1492. pppoe sets the MTU on its interface to
1492 as a matter of course. However, machines connecting on a private
LAN will still have their MTUs set to 1500, causing conflict.
Userland pppoe(8) users do not have to worry about this issue, since
ppp(8) itself has an option, ``mssfixup'', which is enabled by default
and takes care of this. Kernel pppoe users have to rely on other meth-
ods:
o Using a packet filter, the Maximum Segment Size (MSS) can be set
(clamped) to the required value. The following rule in pf.conf(5)
would set the MSS to 1440:
scrub out on pppoe0 max-mss 1440
Although in theory the maximum MSS over a PPPoE interface is 1452
bytes, 1440 appears to be a safer bet. Note that setting the MSS
this way can have undesirable effects, such as reducing TCP/IP
throughput, and interfering with the OS detection features of pf(4).
Adding
scrub out on $pppoe max-mss 1440
to /etc/pf.conf on the gateway box is enough to deal with this.
Navini provides some diagnostic tools as linux binaries. They come bunded in a self-extracting sh archive containing the Java VM and some Java binaries. In theory the diagnostic program should be executable with linux emulation turned on (and the redhat_base package installed). In practice, the Java VM seems to run away on an infinite loop. We can work around this by installing the jdk-linux-1.3.1_15 package from the OpenBSD ports system, and encouraging the diagnostics tools to use our JVM, instead of the one that comes bundled.
You'll need to install the jdk-linux-1.3.1 package (which involves downloading some stuff from Sun). Make sure the redhat emul package is installed, and kern.emul.linux sysctl has been set to 1. Now, attempt to install the app navdiag_linux.bin :
$ env LAX_DEBUG=1 ./navdiag_linux.bin
(make sure you're not using the ion window manager -- the app doesn't seem to like ion). This should install a bunch of stuff into /tmp, and open up a small empty window, and then sit there. There appear to be multiple problems with the jvm that comes bundled with NavDiag.
We can work around this by using the linux emulated jdk 1.3. Note down the "VM Command Line" output from the installer, and (without quitting the installer) run the exact same command line, but replace "/tmp/install.dir.$PID/Linux/resource/jre/bin/java" with our java. You'll need to run commands along the lines of (where you use the $PID value the navdiag_linux.bin installer prints out):
$ export CLASSPATH=/tmp/install.dir.26648/InstallerData:/tmp/install.dir.26648/InstallerData/installer.zip
$ /usr/local/jdk1.3.1-linux/bin/java -Djava.compiler=NONE -Xmx50331648 -Xms16777216 com.zerog.lax.LAX "/tmp/install.dir.26648/temp.lax"
You'll probably have to drop the "/tmp/env.properties.$PID" argument to java too, as that file disappears too fast (doesn't seem to matter). After a while, the installer should open up, and you should be able to successfully install the NavDiag utility. Our java will get hard coded into the app (but you may want to turn on kern.emul.linux permanently in /etc/sysctl.conf).
After installation, you can attempt to run NavDiag. As long as you've made sure the program can get through the packet filter to talk to the modem, everything should run ok from this point, and you should be able to use the tool as on linux:
With some adjusting of the location of my modem (i.e. into the ceiling), I was able to lift my constant red signal to constant orange:
Test run on 13/08/2006 @ 2:30 PMSometime in late 2005 the signal deteriorated, and I was rarely able to hold a connection for more than an hour at a time, though late at night was often good. The good signal was restored, and is in fact much better, by moving the antenna into the roof.