The picture: My laptop has an ethernet and a wireless card, tlp0 and ath0. Ethernet can be plugged in at times, and should have precedence over wireless -- this is mostly to prevent a wifi network bouncing up and down interrupting operating via the cable. Wireless can be configured in several ways, including no security, WEP or WPA.

The machine should try to find network when waking up from APM, when ethernet is plugged in, or when a wireless network is found (using whatever SSID).

The idea is to use wpa_supplicant(8) to detect wifi networks and mark the ath0 interface as "connected". NetBSD's ifwatchd(8) is used to detect if either ethernet or wifi is "connected" or disconnected when the machine's either running, or returning from sleep. A shell script then runs dhcp and does assorted setup and cleanup.

The main engine in this setup is ifwatchd(8), which basically handles all the work that's either induced by kicking wpa_supplicant(8) via APM, wpa_supplicant(8) finding a working wifi network, or by plugging in/out an ethernet cable.

The configuration:

1. /etc/rc.conf:

   apmd=yes
   wpa_supplicant=yes
   wpa_supplicant_flags="-B -iath0 -c/root/wpa.conf"
   ifwatchd=yes
   ifwatchd_flags="-c /root/ifwatch-up -n /root/ifwatch-down tlp0 ath0" 

2. WPA supplicant config: /root/wpa.conf

   Here's a sample config file for wpa_supplicant(8) that I use for University, home and another place. Note that the WPA in there is a bit more complex than in a home-setup with just a pre-shared key (PSK):

   % cat /root/wpa.conf
   ctrl_interface=/var/run/wpa_supplicant
   ctrl_interface_group=wheel
   
   #
   # WPA-enabled network with identities 
   # (used at uni-regensburg.de and fh-regensburg.de)
   #
   network={
           ssid="802.11i"
           key_mgmt=WPA-EAP
           eap=TTLS
           identity="abc12345"
           password="foobar"
           phase2="auth=PAP"
   }
   
   #
   # An unencrypted (open) network:
   #
   network={
           ssid="eyeswideshut"
           scan_ssid=1
           key_mgmt=NONE
   }
   
   #
   # A WEP-encrypted network with pre-shared key:
   #
   network={
          ssid="wepssid"
          scan_ssid=1
          key_mgmt=NONE
          wep_key0="wepkey"
          #wep_tx_keyidx=0
          #priority=5
   } 

3. Watching interfaces: /root/ifwatch-updown

   ifwatchd(8) can't pass parameters, so I'm using two different scripts, and then look at $0 to see if we're going up or down:

   % ls -la /root/ifwatch-*
   lrwxr-xr-x  1 root  wheel   14 Mar 10 12:27 /root/ifwatch-down -> ifwatch-updown
   lrwxr-xr-x  1 root  wheel   14 Mar 10 12:27 /root/ifwatch-up -> ifwatch-updown
   -rwxr-xr-x  1 root  wheel  760 Aug 16 11:45 /root/ifwatch-updown
   

   Here is the script that handles ethernet and wifi networks going up and down:

   % cat /root/ifwatch-updown
   #!/bin/sh
   #
   # See if network is going up or down, to be called via ifwatchd(8)
   #
   # Copyright (c) 2007 Hubert Feyrer <hubert@feyrer.de>
   # All rights reserved.
   #
   
   case $0 in
   *-up)
           case $1 in
           tlp*)
                   # Disable wireless bouncing up and down if we're on wire
                   #
                   logger stopping wpa_supplicant
                   sh /etc/rc.d/wpa_supplicant stop
                   ;;
           esac
   
           pkill dhclient
           sh /etc/rc.d/network restart
           dhclient $1
           sh /etc/rc.d/ntpd restart
           ;;
   
   *-down)
           case $1 in
           tlp*)
                   # Re-enable wireless if we go off-wire
                   #
                   logger starting wpa_supplicant
                   sh /etc/rc.d/wpa_supplicant start
                   ;;
           esac
   
           pkill -x ssh
           sh /etc/rc.d/ntpd stop
   
           pkill dhclient
   
           sh /etc/rc.d/network stop
           route delete 194.95.108.0/24
           ;;
   
   *)
           logger "$0 $@": unknown 
           ;;
   esac
   
   logger "$0 $@" done.
   echo ^G >/dev/console
   

   A few comments:

   • As the comment says, if the ethernet interface (tlp) is found to be connected, wpa_supplicant(8) is stopped to prevent it from bouncing up and down and possibly disrupt things.
   • I stop the network at every time, to flush routes and everything. This mostly works, but not completely, thus I remove one route manually. Someone please fix "route flush"...
   • I use NTP, and to prevent ntpd(8) from spamming the logs when offline, I disable it when offline.
   • When network goes away, I kill my ssh sessions. I prefer this over dead sessions that I have to kill with ~.
   • The echo-command in the last line sends a beep with ^G to give a signal that network's up/down now.

4. APM setup:

   During my experiments, wpa_supplicant(8) died during suspend/resume, I thus stop it before suspending, and start after resuming. This may also have positive effects on power consumption (if not it should probably be hooked in here). My machine uses APM, and I mostly use /usr/share/examples/apm/script, see that file for install instructions.

   Here's the diff that I use to handle wpa_supplicant - dhclient is restarted via ifwatchd:

   % diff -u /usr/share/examples/apm/script /etc/apm/battery
   --- /usr/share/examples/apm/script      2003-03-11 15:56:54.000000000 +0100
   +++ /etc/apm/battery    2007-03-10 12:57:21.000000000 +0100
   @@ -25,7 +25,7 @@
    S=/usr/X11R6/share/kde/sounds
    
    # What my network card's recognized as:
   -if=ne0
   +if=ath0
    
    LOGGER='logger -t apm'
    
   @@ -43,8 +43,11 @@
           # In case some NFS mounts still exist - we don't want them to hang:
           umount -a    -t nfs
           umount -a -f -t nfs
   -       ifconfig $if down
   -       sh /etc/rc.d/dhclient stop
   +
   +       sh /etc/rc.d/wpa_supplicant stop
   +
   +       cd /usr/tmp ; make off
   +
           $LOGGER 'Suspending done.'
           ;;
    
   @@ -62,7 +65,9 @@
    *resume)
           $LOGGER 'Resuming...'
           noise $S/KDE_Startup.wav
   -       sh /etc/rc.d/dhclient start
   +
   +       sh /etc/rc.d/wpa_supplicant start
   +
           # mount /home
           # mount /data
           $LOGGER 'Resuming done.'
   

   The "make off" when shutting down the machine unmounts the cgf-encrypted data partition that I'm using for SSH and PGP keys. I manually mount it when I need it again.

The future -- more work on this would include adding ACPI/powerd(8) scripts, and putting all of this either into the default NetBSD install, or at least into NetBSD's /usr/share/examples.

[Tags: apm, cgd, cgf, ifwatchd, networking, wlan, wpa]

• bootprops: As an update of turning knobs on the NetBSD kernel without recompiling, Jared has issued Patch #3 and Patch #4 with lots of feedback, and he went on to work on boot properties in his own SVN now, see his blog entry.

• pkgsrc logo: It seems I've started yet another discussion about a pkgsrc logo. Given that people ask on and off about an official logo (e.g. for pkgsrcCon t-shirts), I think it would be nice to have. Entries so far are Chris Wareham's entry, and a cute idea (in varying colors and several different shapes, and readability plus an ASCII and a Java-enabled online version X-) by Thomas Bieg.

  Looking at this from someone that raised and left pkgsrc, and who's doing public relations these days, I'm looking forward to see an official pick by the people managing pkgsrc this time!

• Chaos Singularity (cosin): Hernani Marques Madeira ran a NetBSD booth with many presentations at swiss Chaos Singularity, and he also wrote a lengthy (german-language) report and sent a link to pictures.

• Automatic TCP socket buffer sizing: Mindaugas has ported automatic TCP socket buffer sizing from FreeBSD, and is looking for testers. This code should render some benefit while reducing the need for manual tuning in highspeed network scenarios.

• Package security auditing now part of package tools: Originally, audit-packages was a script that matched every entry in a file against all installed packages to indicate known security problems. After some intermediate speedups, this was finally integrated into the package tools package, "pkg_install" now - see the link for more details. Kudos to Adrian Portelli from the pkgsrc-security team!

Update: Thomas Bieg has made a webpage that documents the progress of his logo suggestion.

[Tags: bootprops, Events, logos, networking, pkgsrc, Security]

``Force10 Networks® has leveraged NetBSD® as the foundation for the Force10 Operating System (FTOS). Based on the open source UNIX-like system, FTOS provides the software scalability and resiliency that powers the Force10 TeraScale E-Series® family of switch/routers. See our full press release for more details. Some technical details that did not make it into the press release: Today, many of the worlds largest Gigabit Ethernet and 10 Gigabit Ethernet networks depend on Force10 Networks. The Force10 TeraScale E-Series switches/routers support this by providing features like massive scalability, 1260 Gigabit Ethernet ports or 224 Ten Gigabit Ethernet ports per chassis. The machines are battle tested and provide full function L2 switching and L3 routing. Internally, they are equipped with PowerPC CPUs, and for communication, dedicated 100M Ethernet networks are used in each system that connect the Route Processor Module (RPM) and line cards that are for system control. There are three active CPUs on the primary RPM, and a CPU on each line card that are all active in the control plane. While data itself is forwarded by the hardware, management overhead exists if you consider running 1.500 VRRP groups, 600 OSPF neighbors, BFD on thousands of ports, ARPs on thousands of ports, collecting statistics on thousands of ports etc. All this work is done by the Force10 Operating System, FTOS''.

Force10 Networks TeraScale E-Series Products

Update: The news item is now on the Force10 Networks frontpage, and also available as press release from their site in HTML and in PDF. It's also available on BusinessWire.

Update #2: There's another text that seems to be written down from the announcement with some Linux-babble put in at Linuxworld Update #3: The Linuxworld text was now published on NetworkWorld. Same author, same Linux-babble. Update #4: OSNEWS has an item on it too, including user comments.

[Tags: force10, networking, Products]

Administrative policies to using password-less ssh logins only is something that needs some adjusting from users.

Most of the mentioned programs parse logfiles and then act on them. Among them are fail2ban, denyhost and a similar script, OSsec, blockhosts and a shell-based approach by Rhialto.

The latter post also mentions going the PAM way, which hooks right into the authentication framework and can detect repeated authentication failures best - at the place where they get detected first. This is implemented by the anti-bruteforce PAM module in pkgsrc/security/pam-af.

I guess that's some food for thoughts, and a lot of programs to do the job. Let's see what comes up in Jan 2008 for this topic... :-)

Update: Elad Efrat wrote me to tell that server site log parsing may not be such a good idea as it has a potential to open up for some nasty attacks, see this thread on the fulldisclosuer list. You've been warned!

[Tags: ids, ipfilter, networking, Security, ssh]

Modern network cards can do a lot of things in hardware today, and -- depending on the card! -- some do support calculating checksums for IP, TCP and UDP for both IPv4 and IPv6, and some even support packet fragmentation. The latter is known as TCP segmentation offloading (TSO), as it reduces the load on the hosts's CPU by moving the job to the network card.

NetBSD supports calculating of various checksums in hardware for quite some time now (see the {ip,tcp,udp}{4,6}sum options in ifconfig(8)), and support for TSO is available for TCP/IPv4 for some time, too, see the 'tso4' option of ifconfig(8). In the past weeks, Matthias Scheler and Yamamoto Takashi have worked on adding support for TCP/IPv6 TSO and the wm(4) driver, and the code is now available in NetBSD-current, it can be enabled via the 'tso6' option of ifconfig(8).

According to measurements by Matthias, load on the host CPU was reduced from ~16% to ~12%, while throughput went up at the same time from ~710MBit/s to ~806MBit/s. For comparison: TSO for IPv4 bumps the throughput from ~624MBit/s to ~713MBit/s.

[Tags: ipv6, networking, tso]

The only difference between an etherip interface and a real ethernet interface is that there is an IP tunnel instead of a wire. Therefore, to use etherip the administrator must first create the interface and then configure protocol and addresses used for the outer header. This can be done by using ifconfig(8) create and tunnel subcommands, or SIOCIFCREATE and SIOCSLIFPHYADDR ioctls.''

See Hans' posting to tech-net for more details and a link to the code.

[Tags: driver, etherip, networking]

• The Newsforge article "Which distro should I choose?" refers us to a Comparison between NetBSD and OpenBSD, the website apparently allows other comparisons.

• Parallels is a ``powerful, easy to use, cost effective desktop virtualization solution that empowers PC users with the ability to create completely networked, fully portable, entirely independent virtual machines on a single physical machine.'' In other words "something like VMware". In contrast to the leading(?) product in that area, Parallels supports NetBSD as guest OS officially.

• PC-98 is a PC-like computer from NEC that has a Intel CPU and that was only sold in Japan. Due to some subtle differences from the "original" (IBMesque) PC architecture, it can't run NetBSD/i386 and was so far supported e.g. by FreeBSD/PC98. Now, Kiyohara Takashi has made patches and a floppy image available for a NetBSD/pc98 port - see Kiyohara's mail to tech-kern for more details, and also some discussion about further abstraction of the current x86 architecture to support machines with Intel CPUs that can't run NetBSD/i386.

• Staying on the technical side, David Young has a need to tunnel packets through consumer-grade (and consumer-intelligence) devices, which are unlikely to cope with anything outside of the IP protocol. As such, he has posted patches to tunnel gre(4) over UDP.

  Now let's hope this works as a foundation for Teredo (tunneling IPv6 over UDP)... :-)

• Verified Exec is a security subsystem inside NetBSD that verified fingerprints of binaries before loading them. This prevents binaries from being changed unnoticed, e.g. by trojan horses. Now when NetBSD runs such a system and memory becomes tight, only the process' data is paged to disk, the executables text is simply discarded with the assumption that it can be paged in from the disk again when needed. Of course this assumes that the binary won't change, which may not be true in a networked scenario with NFS or a disk on a fiber channel SAN that may be beyond control of the local system administrator. To prevent attacks of this kind, Brett Lymn has worked to generate per-page fingerprints that are kept in memory even when the executable pages are freed, for later verification when they are paged in from storage again.

  The code is currently under review and available as a patch set - see Brett's mail to tech-kern for all the details!

• While talking about security subsystems, Elad Efrat, who also worked on veriexec previously continued his work to factor out authentication inside the kernel: After introducing the kauth(9) framework and replacing all manual checks for "am I running as root" or "does the current secure level allow this operating" with calls to it, the next step is to seperate the the place where those calls are made from a back-end implementation that will determine what is allowed and what is not, who is privileged and what is not, etc. While these questions are traditionally answered via special user ids (0, root), group membership or secure levels, other methods like capability databases could be imagined.

  Elad has been working along these lines, and he has posted the next step in his work, outlining the upcoming security model abstraction - see Elad's mail to tech-security for details & code references.

• NetBSD 3.1 is around the corner, which will be an update to NetBSD 3.0 with lots of bugfixes and some minor feature enhancements like new drivers and also support for Xen 3 DomainU. There's a NetBSD 3.1 Release Candidate 1 available - be sure to have a look!

• FWIW, I've also updated the overview of NetBSD release branches a few days ago, as I still see a lot of people that are confused over NetBSD's three lines of release branches (well, counting the development branch NetBSD-current as release branch :), and the differences between what a branch and what a release is. With NetBSD 3.0, 3.0.1 and 3.1 this sure makes my little head spin...

• But there's more than NetBSD 3.x! If you've watched the above link, you will understand that the next release after the NetBSD 3.x set of releases is NetBSD 4.x. The release cycle for NetBSD 4.0 has started a few days ago, and there's also an announcement about the start of the NetBSD 4.0 release process by the NetBSD 4.0 release engineer Jef Rizzo which has information on schedule, how YOU can help and getting beta binaries and sources.

• The working period of the Google Summer of Code is over, and while mentors are still evaluating the code submitted by students, there are some public status reports: Alwe MainD'argent about the status of the 'ipsec6' project and Sumantra Kundu about the 'congest' project

• Sysjail 1.0 has been released! Includes some interesting overhead benchmarks.

• As reported in the #NetBSD Community Blog, an alpha version of sBSD was released: It's a NetBSD-based system for easy installation on USB sticks and CF cards.

Of course having full specs to write a proper driver would be ways preferred over this.

[Tags: dmesg, networking, nforce, nvidia, pkgsrc]

Further references to NetBSD can be found by searching for "NetBSD" on the Cray documentation archive. Their vfork(2) manpage refers to NetBSD's documentation on why to implement traditional vfork() in context of 4.4BSD's changes, which I find interesting in historical context.

[Tags: cray, ftp, ftpd, networking, Products, unicos]

 Dec 11 09:21:50 xxx sshd[15335]: Failed password for root from 220.[...]
 Dec 11 09:21:53 xxx sshd[2720]: Failed password for root from 220.13[...]
 Dec 11 09:21:56 xxx sshd[7260]: Failed password for root from 220.13[...]
 Dec 11 09:22:28 xxx sshd[1762]: Illegal user enterprise from 220.135[...]
 Dec 11 09:22:31 xxx sshd[20415]: Illegal user release from 220.135.88.151
 Dec 11 09:22:34 xxx sshd[2405]: Illegal user release from 220.135.88.151
 Dec 11 09:22:37 xxx sshd[27329]: Illegal user release from 220.135.88.151
 Dec 11 09:22:40 xxx sshd[22310]: Illegal user release from 220.135.88.151 

And there's help, in the form of a blog article (found via the #NetBSD Community Blog) describing how to use pop-before-smtp and IPfilter to firewall those people into eternity. (As far as I understand, the pop-before-smtp thing is mostly used to emulate 'tail -f', so I dare saying the meat of that article could be rewritten to only use tools that come with NetBSD. Any takers? Send URL! :)

Update: Ian Spray has taken the challenge and made a version that only uses tools that come with NetBSD. See his blog entry!

Update #2: Geert also brought this variant to my attention, which convers IPFilter, PF and IPFW (For FreeBSD, obviously). He found it in the BSDWiki.

[Tags: ipfilter, networking, Security, ssh]

Update #1: Eric has updated me that ``radiotap gives informations about the state of the card at the time the packet was received, the best example for that is using radiotap headers to have signal/noise informations without each time asking the card (using ioctl()).

With radiotap header the signal informations for this packet are embedded in those headers, same for channel informations, malformed packet flags, other flags or infos the card can provide directly within the driver (usually not accessible from userland) etc..''

For more data, see the ieee80211_radiotap(9) manpage (on -current, maybe 3.0 - I'm happy with 2.1 on my laptop!)

[Tags: networking, radiotap, wlan]

(While there, someone asked about reverse resolving of 6to4 address space the other day... if that is of interest to you check out https://6to4.nro.net/)

[Tags: ipv6, networking]

Here's an example:

 (a) --> miyu# egrep '^(tcpmux|ftp)' /etc/inetd.conf 
         ftp             stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -ll
         tcpmux          stream  tcp     nowait  root    internal
 (b) --> miyu# telnet localhost 1
         Trying 127.0.0.1...
         Connected to localhost.
         Escape character is '^]'.
 (c) --> ftp
 (d) --> -Service not available
         Connection closed by foreign host.
 (e) --> miyu# egrep ^ftp /etc/inetd.conf | sed 's,^,tcpmux/,' >>/etc/inetd.conf
 (f) --> miyu# egrep '^ftp' /etc/inetd.conf
         ftp             stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -ll
         tcpmux          stream  tcp     nowait  root    internal
         tcpmux/ftp      stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -ll
         miyu# alias hup 
         kill -1 `cat /var/run/!*.pid`
 (g) --> miyu# hup inetd
 (h) --> miyu# telnet localhost 1
         Trying 127.0.0.1...
         Connected to localhost.
         Escape character is '^]'.
 (i) --> ftp
 (j) --> 220-
         220 localhost FTP server (NetBSD-ftpd 20050303) ready.
 (k) --> ^]
         telnet> quit
         Connection closed.
         miyu# 

As I don't really feel like speaking FTP without a client, I disconnect (k) and exit telnet.

So, the tcpmux service seems quite a nice tool which could be used to obsolete assigning ports in favour of service names. The problem is that no TCP service that I've stumbled across ever uses this nice mechanism. Even more strange, I wonder why things like rpcbind/portmap were invented in the presence of that serivce (and I guess that tcpmux does predate rpcbind etc.).

To play a bit more, I built myself a "cookie" service, adding this to /etc/inetd.conf:

tcpmux/cookie   stream  tcp     nowait  root    /usr/games/fortune fortune

      miyu# echo cookie | nc localhost 1
      'Home, Sweet Home' must surely have been written by a bachelor.
      miyu# 

Who needs port numbers when you can request a service like this easily. :-) After reading RFC 1078, I even found that the protocol could safe one portscanning a machine to find out the services it runs:

      miyu# echo HELP | nc localhost 1
      +Available services:
      help
      cookie
      ftp
      miyu# 

And for the problem of having multiple versions of the same service running (which rpcbind addresses), RFC 1078 has a suggestion, too: ``Multiple versions of a protocol can suffix the service name with a protocol version number. ''. Easy, huh?

Looking into portmap and friends, Appendix A of RFC 1047 says that ``The port mapper program maps RPC program and version numbers to transport-specific port numbers. This program makes dynamic binding of remote programs possible.''. I.e. reasons for existance of rpcbind etc. are that that rpcbind does which are not easily achievable with the inetd/tcpmux combination: dynamic registration of services, transport over UDP and handling of broadcast requests.

P.S.: Try running fortune(6) without argv[0] being set. :-)

Update: Aparently the tcpmux service is actualy being used by Irix 6.5. Martin Neitzel sent me the inetd.conf of such a machine:

 % grep tcpmux irix65_inetd.conf
 tcpmux  stream  tcp     nowait  root    internal
 tcpmux/sgi_scanner stream tcp nowait root   ?/usr/lib/scan/net/scannerd scannerd
 tcpmux/sgi_printer stream tcp nowait root   ?/usr/lib/print/printerd printerd
 tcpmux/sgi_sysadm stream tcp nowait root   ?/usr/sysadm/bin/sysadmd sysadmd
 tcpmux/sgi_dmusrcmd stream tcp nowait root ?/usr/etc/dmusrcmd /usr/etc/dmusrcmd 

1. setup tftp, dhcpd and nfs servers
2. have proper DHCP setup, i.e. include something like this in dhcpd.conf:

    	host pxehost {
    	  hardware ethernet 01:23:45:67:89:ab;    # MAC address of PXE host 
    	  fixed-address 192.168.17.42;            # IP address of PXE host
    	
    	  # stage 1:
    	  filename "pxeboot_ia32.bin";            # relative to /tftpboot
    	
    	  # stage 2:
    	  next-server 192.168.42.1;               # IP of NFS server
    	  option root-path "/nfsroot";            # path on NFS server
    	}

3. copy pxeboot binary from /usr/mdec to /tftpboot (for boot stage 1)
4. setup and export root filesystem via NFS (/nfsroot, for stage 2)
5. tell PC to use PXE

The code is already available for NetBSD 2.0 (and 1.4T, for those still running it 8-), and der Mouse will also present the system at BSDCan 2005. (Pity I didn't have time to accept the invitation when I asked to come to BSDCan :(). Anyways, see the README file to get more information!

[Tags: backup, networking]

On another front, the IETF Zeroconf working group has introduced "link-local" IPv4 addresses which are similar to IPv6 link-local addresses, but only intended if there are no other addresses available, e.g. in unconnected home networks. The draft also states explicitly that it ``does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface''. David Young has posted a patch that implements these link-local IPv4 addresses on NetBSD. So if you're too lazy to manage IP numbers on your unconnected home network, check this out. Or try IPv6. :)

[Tags: networking]

Old record:

• 838860800000 bytes in 1588 real seconds = 4226 Mbit/sec o
• Distance: 16,343 km (10,157 miles)
• 69.073 Petabit-meters/second (12% increase)

New record:

• 1966080000000 bytes in 3648.81 real seconds = 4310.62 Mbit/sec
• Distance: 28,983 km (18,013 miles)
• 124.935 Petabit-meters/second (78.6% increase)

On Linux, the MadWiFi driver patched into either a 2.4.x or 2.6.x kernel didn't work when enabling Turbo mode, giving obscure error messages that we could decode as wrong parameters to one of the HAL functions by the ifconfig(!) command. This and all the maze of various tools like ifconfig, iwconfig, iwpriv together with the lot of undocumented arguments you had to hand them didn't help to make setting up Turbo mode on an Atheros card w/ Linux a straight forward job. Manpages for these tools? You wish! And if available, they're uncomplete and tell the important bits that you have to put into the "private" bits of the card.

Today's experience confirmed that if you want a working setup with little to no fuzz, NetBSD is the right choice! Of course in an economy that lives from consulting and broken things, Linux sounds much better as it will create demand for support, consulting and fixing where things could just work, and people could just get work done otherwise. Oh well!

Performance measurements with iperf showed 43MBit/s (~5MByte/s) between a Pentium-133 running Linux connected to the AP via ethernet, and a PIII-800 running NetBSD 2.0_BETA/i386 and a -current kernel from today.

[Tags: ath, linux, netbsd, networking, wlan]

Note that the driver is based on on NeTBSD 1.6.2, but updates for the upcoming NetBSD 2.0 release won't be away far.

[Tags: centrino, drivers, networking, wlan]