Although FreeBSD/mips has been committed to the tree, a few stragglers haven't been pushed into the tree for various reasons. Oleksandr Tymoshenko and I have been honing them down and have just published a set for review.
If you'd like to try FreeBSD/mips out, you can grab these patches from Oleksandr's directory. There's four diffs included. Please send any feedback to arch@freebsd.org.
20080729
20080726
Minor wi(4) hacking
I finally had some time, a need for wireless connectivity in the shop and found my stash of old Prism 2, 2.5 and 3 cards. I thought I'd try them out with the new vap stuff.
First, there's a new filter on the firmware revisions in the driver. Very old versions of the firmware basically don't work without a lot of coaxing and workarounds. They are no longer supported. In addition, symbol cards are fairly rare and there's no readily available documentation for them, so support for them was removed as well. This filtering is a good thing, since it will keep people from using cards that are known to be broken. However, I had to fix a bug in the interrupt registration to make this work out OK (and to also stop spontaneous panics sometimes on attach if there was a lot of interrupt activity on a shared interrupt). I basically moved the interrupt registration to the end of the attach function, rather than the beginning and solved both problems.
All of these cards that I had don't have new enough firmware to support WPA. This highlights another problem: wpa_supplicant doesn't filter out WPA APs when it is looking for things to attach to, or otherwise provide a meaningful error message that would tell the user the reason that WPA isn't working is that their card is too old/lame to support this new-fangled stuff....
I wound up solving my problem with an atheros card that just worked, once I found them...
First, there's a new filter on the firmware revisions in the driver. Very old versions of the firmware basically don't work without a lot of coaxing and workarounds. They are no longer supported. In addition, symbol cards are fairly rare and there's no readily available documentation for them, so support for them was removed as well. This filtering is a good thing, since it will keep people from using cards that are known to be broken. However, I had to fix a bug in the interrupt registration to make this work out OK (and to also stop spontaneous panics sometimes on attach if there was a lot of interrupt activity on a shared interrupt). I basically moved the interrupt registration to the end of the attach function, rather than the beginning and solved both problems.
All of these cards that I had don't have new enough firmware to support WPA. This highlights another problem: wpa_supplicant doesn't filter out WPA APs when it is looking for things to attach to, or otherwise provide a meaningful error message that would tell the user the reason that WPA isn't working is that their card is too old/lame to support this new-fangled stuff....
I wound up solving my problem with an atheros card that just worked, once I found them...
20080722
Taking a break from FreeBSD core team
As has been recently announced, the FreeBSD project has selected a new core team. The project elects a new team every two years. This time, I've decided to take a break from the core team. I have a new son and I want to spend more time with him and the rest of my family.
I've had a great time on the core team. I've been serving now for 8 years. I've really enjoyed being on the core team and leading the project through some difficult times. Since my son and family are taking a lot of my time these days, I have limited time to spend on the FreeBSD project. I've done my time in the administrative side of the project for a while, and I want to spend my limited time working to make FreeBSD a better platform for the embedded platforms. I'm taking a 2 year break. We'll see how things are in 2 years...
I wish the new core team luck, although they are good people and they won't need my luck to be successful.
I've had a great time on the core team. I've been serving now for 8 years. I've really enjoyed being on the core team and leading the project through some difficult times. Since my son and family are taking a lot of my time these days, I have limited time to spend on the FreeBSD project. I've done my time in the administrative side of the project for a while, and I want to spend my limited time working to make FreeBSD a better platform for the embedded platforms. I'm taking a 2 year break. We'll see how things are in 2 years...
I wish the new core team luck, although they are good people and they won't need my luck to be successful.
20080715
Quick Guide to FreeBSD hostap for FreeBSD 8
I have a need to setup an access point. Many of the discussions on the web include all kinds of extra goodies that one normally sets up with the access point. But I just needed an access point: no dhcp, bridging, etc. Here's how I did it.
Recently, some really cool stuff when into the kernel for wireless. This is the VAP stuff, or the virtual access point code. This allows freebsd to decouple the code for doing access points, and a bunch of other stuff, from the code to drive the wireless hardware. Great in concept, and quite useful with some of the advanced wireless hardware.
However, it did change the way things were configured. The handbook is now out of date. Until it can be updated, here's what I did, with some explanations about each step.
First, I needed to create an rc.conf setup for my needs. Here's the one I came up with.
devd_enable turns on the devd(8) process. This process is responsible for dealing with the different device events in the system. This is the hook that we use for hot-plug insertions, which is how we configure the wireless devices.
wlans_ath0 is used to create the virtual interface wlan0 associated with ath0. This is how all the wireless stuff is setup now. You configure the basics with the wlan_IF=wlanX command, and set more specific stuff via the wlanX interface.
create_wlan0 gives the arguments with which to create the wlan interface. There are many that can only be created at wlanX creation time, and it happens that hostap is one of them. I'm not 100% sure that I need to bother with the 11g mode command or not here, but it seems to work.
ifconfig_wlan0 sets the device's IP address. In my example, I wanted the interface to have an IP address, but not be bridgable since I didn't have any other interfaces on the laptop I wanted to be the AP for the thing I'm doing.
hostapd_enable turns on the hostapd daemon. You won't get far without this, so we turn it on.
We've enabled a daemon, and now it is time to configure it. Here's the config file that I used for hostapd.conf:
itnerface specifies which interface to use. Duh! However, this needs to be the wlan device, not the hardware device.
hw_mode sets the hardware into 802.11g. Not sure if this is needed, but it works for me.
macaddr_acl is wide open: it allows anybody to connect. As you may have noticed, this setup is very permissive. It has nothing locked down at all. It should be the first thing you do as an experiment before proceeding on to enabling WPA or WPA2 to get a reasonable level of security.
auth_algs sets which authorization algorithms can be used. See the hostapd man page for details.
ssid sets the name of the network you are serving.
The rest can be gleaned from the manual.
Chances are this post should be updated, so if you have any suggestions on how to do that, please leave then as comments.
Recently, some really cool stuff when into the kernel for wireless. This is the VAP stuff, or the virtual access point code. This allows freebsd to decouple the code for doing access points, and a bunch of other stuff, from the code to drive the wireless hardware. Great in concept, and quite useful with some of the advanced wireless hardware.
However, it did change the way things were configured. The handbook is now out of date. Until it can be updated, here's what I did, with some explanations about each step.
First, I needed to create an rc.conf setup for my needs. Here's the one I came up with.
devd_enable=YES
ifconfig_wlan0="inet 10.0.0.1/24"
wlans_ath0="wlan0"
create_args_wlan0="wlanmode hostap mode 11g"
hostapd_enable=YES
devd_enable turns on the devd(8) process. This process is responsible for dealing with the different device events in the system. This is the hook that we use for hot-plug insertions, which is how we configure the wireless devices.
wlans_ath0 is used to create the virtual interface wlan0 associated with ath0. This is how all the wireless stuff is setup now. You configure the basics with the wlan_IF=wlanX command, and set more specific stuff via the wlanX interface.
create_wlan0 gives the arguments with which to create the wlan interface. There are many that can only be created at wlanX creation time, and it happens that hostap is one of them. I'm not 100% sure that I need to bother with the 11g mode command or not here, but it seems to work.
ifconfig_wlan0 sets the device's IP address. In my example, I wanted the interface to have an IP address, but not be bridgable since I didn't have any other interfaces on the laptop I wanted to be the AP for the thing I'm doing.
hostapd_enable turns on the hostapd daemon. You won't get far without this, so we turn it on.
We've enabled a daemon, and now it is time to configure it. Here's the config file that I used for hostapd.conf:
interface=wlan0
hw_mode=g
macaddr_acl=0
auth_algs=1
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
ssid=bsdimp hacking blog
itnerface specifies which interface to use. Duh! However, this needs to be the wlan device, not the hardware device.
hw_mode sets the hardware into 802.11g. Not sure if this is needed, but it works for me.
macaddr_acl is wide open: it allows anybody to connect. As you may have noticed, this setup is very permissive. It has nothing locked down at all. It should be the first thing you do as an experiment before proceeding on to enabling WPA or WPA2 to get a reasonable level of security.
auth_algs sets which authorization algorithms can be used. See the hostapd man page for details.
ssid sets the name of the network you are serving.
The rest can be gleaned from the manual.
Chances are this post should be updated, so if you have any suggestions on how to do that, please leave then as comments.
20080706
Minor mips reorg and plans for the future
In trying to bring the MIPS tree more into line with idealized FreeBSD practices, I've moved the SoC directories up one level in the hierarchy. Future changes will make it easier to define different boards, as well as stylizing these sorts of things across different CPU architectures. I need this for the Plat'Home OpenMicroServer work I've started on, so I'll use that to drive these changes.
For the curious, I've moved mips/mips32/adm5120 -> mips/adm5120, likewise with the idt, malta, and sentry5 directories. While all of these were, strictly speaking, mips32 CPUs, having them in their own subdirectory doesn't make a lot of sense. There's never going to be so many of them that having an extra layer of indirection is going to help. Also, mips32 is ambiguous. Does it mean the MIPS ISA known as MIPS32 and MIPS32r2? Does it mean that the ports are running in 32-bit mode? It wasn't clear where a 32-bit kernel for a mips64 processor would live. Also, the idt parts aren't completely mips32 compliant in a couple of minor details. Is that non-compliance enough to move them elsewhere?
The next set of changes will try to tease apart the boot loader environment from the SoC that it is running on. While many SoCs have their own bootloader, often times one may also run uboot on the same hardware. In addition, things like uboot are used in many different platforms, so duplicating that code will grow tiresome.
Once the boot loader stuff is better abstracted, the next set of problems will be how to create a system that can run on multiple different boards of the same SoC. At first, this will be statically compiled, but eventually it will be dynamic.
Another key component of this work, whose overall goal is to make it easier to add board support to FreeBSD embedded platforms, will be an overhaul of the hints system. While it can be made to work, there are some practical problems it solves poorly that are desirable to have solved better. For example, it has no good way to tie attributes or parameters to hardware. Today, one can only tie them to a driver instance, which itself can be tied to hardware.
Finally, the last planned component in this work is a simplification of creation of busses with attributes and fixed or semi-fixed children. You can't have variants of hints loaded today that say "If I'm running on a AT91RM9200, use this set, but if I'm runnning on an AT91SAM9620 use this other set of hints" to enumerate the busses. This makes it hard to achieve the dynamic selection of boot code to run needed to allow kernels to boot on a variety of boards.
Most of this is low-level code janitor stuff. However, it is code janitor stuff that's needed and will be important to FreeBSD's success in the future.
For the curious, I've moved mips/mips32/adm5120 -> mips/adm5120, likewise with the idt, malta, and sentry5 directories. While all of these were, strictly speaking, mips32 CPUs, having them in their own subdirectory doesn't make a lot of sense. There's never going to be so many of them that having an extra layer of indirection is going to help. Also, mips32 is ambiguous. Does it mean the MIPS ISA known as MIPS32 and MIPS32r2? Does it mean that the ports are running in 32-bit mode? It wasn't clear where a 32-bit kernel for a mips64 processor would live. Also, the idt parts aren't completely mips32 compliant in a couple of minor details. Is that non-compliance enough to move them elsewhere?
The next set of changes will try to tease apart the boot loader environment from the SoC that it is running on. While many SoCs have their own bootloader, often times one may also run uboot on the same hardware. In addition, things like uboot are used in many different platforms, so duplicating that code will grow tiresome.
Once the boot loader stuff is better abstracted, the next set of problems will be how to create a system that can run on multiple different boards of the same SoC. At first, this will be statically compiled, but eventually it will be dynamic.
Another key component of this work, whose overall goal is to make it easier to add board support to FreeBSD embedded platforms, will be an overhaul of the hints system. While it can be made to work, there are some practical problems it solves poorly that are desirable to have solved better. For example, it has no good way to tie attributes or parameters to hardware. Today, one can only tie them to a driver instance, which itself can be tied to hardware.
Finally, the last planned component in this work is a simplification of creation of busses with attributes and fixed or semi-fixed children. You can't have variants of hints loaded today that say "If I'm running on a AT91RM9200, use this set, but if I'm runnning on an AT91SAM9620 use this other set of hints" to enumerate the busses. This makes it hard to achieve the dynamic selection of boot code to run needed to allow kernels to boot on a variety of boards.
Most of this is low-level code janitor stuff. However, it is code janitor stuff that's needed and will be important to FreeBSD's success in the future.
Subscribe to:
Posts (Atom)