Τρίτη , 21 Οκτωβρίου 2014
Τελευταία

USB Wireless Access Point

This page focuses around the Access Point needed for the project. The available hardware I had was a Belkin F5D7050 that uses a Zydas chipset, version /release 4000.

The drivers for this device are the zd1211b, or zd1211rw according to some. These have been included in kernels since v.2.6, but as the SheevaPlug has custom kernel releases (I currently have the 2.6.31 provided by sheeva.with-linux.com) it is not built in.

The main problem here is the lack of header files in these releases. The headers are provided individually in the form of a tarred directory. In theory, these should work when pointed to by a link in the directory specified in the Makefile (or hard-coded in the Makefile for that matter). In reality this does not work. Any suggestions feel free to comment :P

Here are some steps taken, and the subsequent results:

First, a little info:

The firmware used can be found from sourceforge. The driver used is the r85 version of the zd1211 and can be found on openwrt.

The driver Makefile is as follows (the relevant bits):

VERSION := $(shell uname -r)
MODPATH := /lib/modules/$(VERSION)

# if the kernel is 2.6.x, turn on this
KERN_26=y

KERNEL_SOURCE=$(MODPATH)/source
#KERNEL_SOURCE=/usr/src/linux

# set to 1 for zd1211b
ZD1211REV_B=0

What initially needs changing is the ZD1211REV_B=0 from 0 to 1 if you have the same version of the Belkin as me (V4000). You can check that by checking the back for a small sticker with the version #, or by sticking the device in the USB slot of the SheevaPlug and doing lsusb. You should get an output of something like this:

Bus 001 Device 003: ID 050d:705c Belkin Components F5D7050 v4000 Wireless Adapter

where as you can see it clearly depicts your version of the adapter.

In my case, were currently working with v.2.6.31 of the Kernel provided by sheeva.with-linux. If you check the directory specified in the Makefile, it points to /lib/modules/2.6.31/source and /usr/src/linux. Now in the /lib/modules/2.6.31 directory a source pointer can be found, which wrongly points to /home/kelly/src/Sheeva/SheevaPlug_LSP/Sources/linux-2.6.30.6-work, which obviously is a remnant of the personal directories of the provider of the kernel. The same is true for a link called build, pointing to the same location.

Initial results of make with no changes:

root@ubuntu:~/zd1211-driver-r85# make
/lib/modules/2.6.31/build
/root/zd1211-driver-r85
-I/root/zd1211-driver-r85/src/include -fomit-frame-pointer -O2 -Wall -Wstrict-prototypes -pipe -DZDCONF_WE_STAT_SUPPORT=1 -DHOST_IF_USB -DAMAC -DGCCK -DOFDM -DHOSTAPD_SUPPORT -DUSE_EP4_SET_REG -DDOWNLOADFIRMWARE -DfTX_GAIN_OFDM=0 -DfNEW_CODE_MAP=1 -DfWRITE_WORD_REG=1 -DfREAD_MUL_REG=1 -DENHANCE_RX=1 -DZD1211
src/zd1205.o src/zdasocsvc.o src/zdauthreq.o src/zdauthrsp.o src/zdmmrx.o src/zdshared.o src/zdhci.o src/zdglobal.o src/zdencrypt.o src/zdpmfilter.o src/zdpsmon.o src/zdsynch.o src/zdbuf.o src/zd1205_proc.o src/zdhw.o src/zddebug.o src/zdtkipseed.o src/zdmic.o src/zdusb.o src/zd1211.o
make -C /lib/modules/2.6.31/build SUBDIRS=/root/zd1211-driver-r85 modules
make: *** /lib/modules/2.6.31/build: No such file or directory. Stop.
make: *** [all] Error 2

After unpacking headers to / and creating links

ln -s /usr/include/linux/ /lib/modules/2.6.31/build

and

ln -s /usr/include/linux/ /lib/modules/2.6.31/source

the Makefile proceeds to the directories but cant find anything useful in the headers found:

/lib/modules/2.6.31/build
/root/zd1211-driver-r85
-I/root/zd1211-driver-r85/src/include -fomit-frame-pointer -O2 -Wall -Wstrict-prototypes -pipe -DZDCONF_WE_STAT_SUPPORT=1 -DHOST_IF_USB -DAMAC -DGCCK -DOFDM -DHOSTAPD_SUPPORT -DUSE_EP4_SET_REG -DDOWNLOADFIRMWARE -DfTX_GAIN_OFDM=0 -DfNEW_CODE_MAP=1 -DfWRITE_WORD_REG=1 -DfREAD_MUL_REG=1 -DENHANCE_RX=1 -DZD1211B
src/zd1205.o src/zdasocsvc.o src/zdauthreq.o src/zdauthrsp.o src/zdmmrx.o src/zdshared.o src/zdhci.o src/zdglobal.o src/zdencrypt.o src/zdpmfilter.o src/zdpsmon.o src/zdsynch.o src/zdbuf.o src/zd1205_proc.o src/zdhw.o src/zddebug.o src/zdtkipseed.o src/zdmic.o src/zdusb.o src/zd1211.o
make -C /lib/modules/2.6.31/build SUBDIRS=/root/zd1211-driver-r85 modules
make[1]: Entering directory `/usr/include/linux”
make[1]: *** No rule to make target `modules’. Stop.
make[1]: Leaving directory `/usr/include/linux”
make: *** [all] Error 2

So without the proper sources and complete headers, this seems about as much as we can currently do. The only viable solution would be to make a custom kernel that already includes the device drivers, and maybe any other modules the project needs. More on this soon.

After the kernel compilation the Belkin appears in iwconfig and is configurable.  Unfortunately, it seems that the zd1211rw drivers that are included in the kernel dont support master mode, essential for the creation of an access point. This can be countered by blacklisting the included driver and installing an older version of the drivers such as zd1211b. This however brings us back to the previous problem, of the lack of compilation.

One approach to the current problem was the installation of hostapd, which is a user space daemon for access point and authentication server. According to the site, it works with mac80211 based drivers such as the zd1211rw. It does so by supporting them with its own driver, nl80211. This driver however requires the libnl-1.0 library (or higher), which gave me problems upon configuration, making it impossible to do a make and install the library, needed for the actual driver.

The current approach is using the wireless USB in ad-hoc mode, sharing the ethernet connection of the plug with the wireless. This can be done with some manual editing of the /etc/network/interfaces file and the use of ipmasq and dnsmasq.

  • ipmasq is a utility that initializes IP masquerade on a linux system for use as a firewall. IP masquerade can be compared to a NAT on other systems.
  • dnsmasq is a small DNS forwarder and dhcp server.

Ad-hoc setup:

For the device to act like an Ad-hoc its simply a matter of editing the /etc/network/interfaces file. The file currently looks like this:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

#wifi ap
auto wlan0
iface wlan0 inet static
wireless-mode ad-hoc
wireless-essid sheevasec
wireless-key xxxxxxxxxx
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255

where 192.168.0.1 has to be a different subnet from the eth0 subnet (in my case 192.168.1.0). The wireless-key here is for WEP «security».

After this configuration the wlan0 interface acts like an ad-hoc network which can be connected to, but is a bit useless as Internet Connection Sharing is non-existant.
After some basic configuration of both the iptables and dnsmasq, success! A laptop is able to connect to the ad-hoc and gain access to the internet. The steps taken are similar to the ones described in the ICS howto in the ubuntu community documentation. Even though the guide is for wired ICS, it works perfectly with wireless:

index: eth0 is the internet interface (in this case the plugs ethernet port), wlan0 is the ad-hoc network.

to configure NAT (Network Address Translation), iptables need to be configured:

iptables -A FORWARD -i eth0 -o wlan0 -s 192.168.0.0/24 -m conntrack –ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE

where rule1 allows forwarding of initial packets, rule2 allows forwarding of established connection packets and rule3 does the actual NAT through Masquerade.

Routing also needs to be configured between the two interfaces, done by enabling IP forwarding:

sh -c «echo 1 > /proc/sys/net/ipv4/ip_forward»

and editing /etc/sysctl.conf and adding these:

net.ipv4.conf.default.forwarding=1
net.ipv4.conf.all.forwarding=1

After this, a laptop can connect and access the internet, but only with additional configuration on the client (IP and DNS). This is handled by the dnsmasq app.

By adding these lines to the /etc/dnsmasq.conf file, the plug acts like a DHCP server and DNS forwarder:

interface=wlan0
dhcp-range=192.168.0.100,192.168.0.250,72h

this specifies the working interface for dnsmasq and the IP-range pool.

Now a client can connect to the ad-hoc and access the internet through the plug.

* an interesting thing with the iptables, after adding WEP the ICS stopped working properly. The solution was to redo the iptables steps.

Further work would be to do MAC address filtering, and ultimately using a USB adapter that supports master mode, so as to have a proper access point. Also, proper configuration of ipmasq so as to have a proper firewall controlling rogue connection attempts to the plug.
Back to Plug Computing

Leave a Reply

Your email address will not be published. Required fields are marked *

*


Επιτρέπονται τα εξής στοιχεία και ιδιότητες HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll To Top

Facebook

Twitter

Google Plus

x