I started looking into Wifi driver integration into Android. Android from one and only Google..which has created a big storm in the mobile platform world. Android is basicaly combination of Linux kernel with Java stack. It has got cutstomoized and optmized libc (bionic) and java virtual machine (Dalvik).
Wifi conifiguration in Android starts from Java application and goes till driver/firmware insertion through JNI interface and wifi native component. Before starting modification for these components, I wanted to verify whether Wifi driver for my target will work under Android or not.
wpa_supplicant component was not enabled by default in android 1.0 release. So to enable
Add HAVE_CUSTOM_WIFI_DRIVER_2 := true to build/target/board/generic/BoardConfig.mk file.
2. make sure external/wpa_supplicant/.config has got below entries
CONFIG_WIRELESS_EXTENSION=y
CONFIG_CTRL_IFACE=y
CONFIG_DRIVER_WEXT=y
3. Build android with this to get support for WEXT and wpa_supplicant client.
4. After the system boot, insert driver and know the interface (in my case it is eth1)
5. Modify wpa_supplicant.conf file for AP configuration and Run
/system/bin/wpa_supplicant -Dwext -ieth1 -c/sdcard/wpa_supplicant.conf
6. Run dhcp to get the IP/system/bin/dhcpcd -d eth1
7. Ping to AP to check connectivity.
To automate these steps, put above commands for wpa_supplicant and dhcpcd in init.rc.
POSTED BY VINAY H AT 3:02 AM
2009年5月25日 星期一
802.11i preauthentication
Preauthentication Using IEEE 802.1X
If you have a mobile device and move around a reasonably sized network, you need to roam. Or, to be more specific, your mobile device has to switch from one access point to another due to the limited coverage area of each access point. Ideally, you would like this to happen so fast that you, the user, don't notice it happening. You don't want your laptop to freeze up for a few seconds each time it happens and, worse still, you don't want it to come back with a "network failure" message in the middle of a file transfer.
To achieve this type of seamless handover, you need the switchover to be very fast, preferably milliseconds. This has two implications. First, you need the switchover to occur before you get outside the coverage area of the access point you are currently using. Second, you want the new access point to accept you as quickly as possible so you can continue operation. Security presents a problem for the second objective.
If you wait until the switchover before starting the authentication process, it could take a few seconds before the access point lets you back onto the network. This is especially true if you are using upper-layer authentication needing the services of some remote authentication server. One way to get around this problem is to do the authentication in advance so the access point is ready to let you join as soon as you are ready. The process is called preauthentication.
The original IEEE 802.11 WEP system allowed preauthentication using the simple authenticate messages. However, these messages are not relevant to RSN or WPA. We need to perform full authentication using IEEE 802.1X, including upper-layer authentication if required. The superficial difficulty is that we can't talk to the new access point until after we have associated with it—or can we? Remember, we do have an existing connection with the old access point, which, if we are doing things right, is still connecting us to the wired network. Clearly the new access point must be on the same wired network if the roaming operation is to make any sense. Therefore, we should be able to talk to the new access point via its wired connection. Although we may detect the new access point from the radio signal, we preauthenticate using the wired infrastructure. This is shown in Figure 13.1.
Figure 13.1. Preauthentication Communications
In principle, communicating via the wired network allows the mobile device to perform all the same EAP operations that would typically be performed wirelessly after association. This includes the conversation with a remote authentication server as well as the four-way pairwise key exchange and the group key exchange. Because all the messages are sent in EAPOL messages, they can travel equally well over a wired or wireless LAN. We say "in principle" because, although it is practical, this approach does drive a dump truck through the underlying architecture assumptions in IEEE 802.1X and causes sleepless nights among the standards purists. The problem is that technically the IEEE 802.1X authenticator controls a data port that is created when the station associates. But with preauthentication, no such port exists yet. You can think of ways to deal with this problem by creating a temporary port that get connected later, but it is a bit messy.
If preauthentication is done, the mobile can have an entire set of keys already in place at the point where it roams and associates with the new access point. If the new access point can map the mobile device onto the temporary IEEE 802.1X port that was authorized earlier, it can resume communication immediately. This is where we make further use of the copies of the Information Element that are included with the four-way handshake. When the mobile device preauthenticates, it needs to inform the authenticator which type of cipher it is going to use. This information is provided in the Information Element sent with the handshake. When the mobile device finally roams, the new access point needs to check that it has selected the same cipher in the association request that it selected during the handshake.
If you have a mobile device and move around a reasonably sized network, you need to roam. Or, to be more specific, your mobile device has to switch from one access point to another due to the limited coverage area of each access point. Ideally, you would like this to happen so fast that you, the user, don't notice it happening. You don't want your laptop to freeze up for a few seconds each time it happens and, worse still, you don't want it to come back with a "network failure" message in the middle of a file transfer.
To achieve this type of seamless handover, you need the switchover to be very fast, preferably milliseconds. This has two implications. First, you need the switchover to occur before you get outside the coverage area of the access point you are currently using. Second, you want the new access point to accept you as quickly as possible so you can continue operation. Security presents a problem for the second objective.
If you wait until the switchover before starting the authentication process, it could take a few seconds before the access point lets you back onto the network. This is especially true if you are using upper-layer authentication needing the services of some remote authentication server. One way to get around this problem is to do the authentication in advance so the access point is ready to let you join as soon as you are ready. The process is called preauthentication.
The original IEEE 802.11 WEP system allowed preauthentication using the simple authenticate messages. However, these messages are not relevant to RSN or WPA. We need to perform full authentication using IEEE 802.1X, including upper-layer authentication if required. The superficial difficulty is that we can't talk to the new access point until after we have associated with it—or can we? Remember, we do have an existing connection with the old access point, which, if we are doing things right, is still connecting us to the wired network. Clearly the new access point must be on the same wired network if the roaming operation is to make any sense. Therefore, we should be able to talk to the new access point via its wired connection. Although we may detect the new access point from the radio signal, we preauthenticate using the wired infrastructure. This is shown in Figure 13.1.
Figure 13.1. Preauthentication Communications
In principle, communicating via the wired network allows the mobile device to perform all the same EAP operations that would typically be performed wirelessly after association. This includes the conversation with a remote authentication server as well as the four-way pairwise key exchange and the group key exchange. Because all the messages are sent in EAPOL messages, they can travel equally well over a wired or wireless LAN. We say "in principle" because, although it is practical, this approach does drive a dump truck through the underlying architecture assumptions in IEEE 802.1X and causes sleepless nights among the standards purists. The problem is that technically the IEEE 802.1X authenticator controls a data port that is created when the station associates. But with preauthentication, no such port exists yet. You can think of ways to deal with this problem by creating a temporary port that get connected later, but it is a bit messy.
If preauthentication is done, the mobile can have an entire set of keys already in place at the point where it roams and associates with the new access point. If the new access point can map the mobile device onto the temporary IEEE 802.1X port that was authorized earlier, it can resume communication immediately. This is where we make further use of the copies of the Information Element that are included with the four-way handshake. When the mobile device preauthenticates, it needs to inform the authenticator which type of cipher it is going to use. This information is provided in the Information Element sent with the handshake. When the mobile device finally roams, the new access point needs to check that it has selected the same cipher in the association request that it selected during the handshake.
2009年5月13日 星期三
MPEG I,II,II.5
MPEG 1 Layer 3是常见的MP3编码的音频文件，而所谓的MPEG 2 Layer 3其实只是22050HZ采样率的MP3，MPEG 2.5 Layer 3也是采用更底采样率的MP3。所以，MPEG 2 Layer 3、MPEG 2.5 Layer 3根本没有采用44100HZ或48000HZ采样率。由于采样率的偏底，所以MPEG 2 Layer 3、MPEG 2.5 Layer 3音质应该不会比MPEG 1 Layer 3的音质好
2009年5月7日 星期四
ubifs轻松上路
Analib的专栏
ubifs轻松上路
ubifs轻松上路
第一、什么是ubifs？
由IBM、nokia工程师Thomas Gleixner，Artem Bityutskiy等人于2006年发起，致力于开发性能卓越、扩展性高的FLASH专用文件系统，以解决当前嵌入式环境下以FLASH作为MTD设备使用时的技术瓶颈。
关键字：
UBI：一种类似于LVM的逻辑卷管理层。主要实现损益均衡，逻辑擦除块、卷管理，坏块管理等。
UBIFS：基于UBI的FLASH日志文件系统。
有关ubifs的详细介绍，请参考：
http://www.linux-mtd.infradead.org/doc/ubi.html
http://www.linux-mtd.infradead.org/doc/ubifs.html
第二、为何使用ubifs？
第三、如何得到ubifs？
2.6.22以后，ubifs活跃于git管理工程中：
git://git.infradead.org/ubi-2.6.git
2.6.27以后，ubifs被整合进内核树中，用户只需下载最新内核即可获取ubifs支持。
第四、如何使用ubifs？
软件环境：
linux-2.6.28
arm-linux-gcc 3.4.5
硬件环境：
s3c2410
k9f1208
一、准备
1、内核
配置的时候选上
1)Device Drivers --->Memory Technology Device (MTD) support --->UBI - Unsorted block images --->Enable UBI
2)File systems --->Miscellaneous filesystems --->UBIFS file system support
2、mtd-utils工具(flash_eraseall、ubiattach、ubimkvol)准备
1)下载(mtd-utils、zlib、lzo)源码
wget http://debian.mirror.inra.fr/debian/pool/main/m/mtd-utils/mtd-utils_20080508.orig.tar.gz
wget http://www.zlib.net/zlib-1.2.3.tar.gz
wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz
2)编译安装zlib
tar xzvf zlib-1.2.3.tar.gz
cd zlib-1.2.3
CC=arm-linux-gcc ./configure --shared --prefix=/usr/local/arm/3.4.5/arm-linux
make
make install
cd ..
3)编译安装lzo
tar xzvf lzo-2.03.tar.gz
cd lzo-2.03
CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr/local/arm/3.4.5/arm-linux
make
make install
cd ..
4)编译mtd-utils
tar xzvf mtd-utils_20080508.orig.tar.gz
cd mtd-utils-20080508
修改Makefile文件：
#CROSS=arm-linux-
修改为 CROSS=arm-linux-
BUILDDIR := $(CROSS:-=)
修改为 BUILDDIR := .
修改ubi-utils/Makefile文件：
添加 CROSS=arm-linux-
修改 ubi-utils/new-utils/Makefile文件：
添加 CROSS=arm-linux-
make WITHOUT_XATTR=1
ubi-utils子目录下生成我们需要的ubiattach、ubimkvol等文件(请确保是交叉编译所得)
3、mtd-utils工具(mkfs.ubifs、ubinize)准备
git-clone git://git.infradead.org/mtd-utils.git
cd mtd-utils/
make
mkfs.ubifs子目录下生成我们需要的mkfs.ubifs工具
ubi-utils/new-utils子目录下生成我们需要的ubinize工具
二、使用
1、使用ramfs或nfs启动系统，执行以下命令挂载ubifs：
1)flash_eraseall /dev/mtd4
2)ubiattach /dev/ubi_ctrl -m 4
3)ubimkvol /dev/ubi0 -N rootfs -s 50MiB
4)mount -t ubifs ubi0_0 /mnt或mount -t ubifs ubi0:rootfs /mnt
2、如果你想使用ubifs为rootfs，把文件系统内容解压到ubifs挂载目录下，并修改内核启动参数为：
console=ttySAC0 ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs
3、如果你想直接在bootloader下烧写ubifs映像，使用以下命令制作ubi烧写映像：
mkfs.ubifs -r rootfs -m 512 -e 15872 -c 3303 -o ubifs.img
ubinize -o ubi.img -m 512 -p 16KiB -s 256 ubinize.cfg
其中：
1)以上命令的参数可从ubifs挂载信息中提取：
UBI: attaching mtd4 to ubi0
UBI: physical eraseblock size: 16384 bytes (16 KiB)
UBI: logical eraseblock size: 15872 bytes
UBI: smallest flash I/O unit: 512
UBI: sub-page size: 256
UBI: VID header offset: 256 (aligned 256)
UBI: data offset: 512
UBI: attached mtd4 to ubi0
2)配置文件ubinize.cfg的内容为：
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=50MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
注：
其他nand flash下ubifs的使用方法类似(参数不同)。
ubifs轻松上路
ubifs轻松上路
第一、什么是ubifs？
由IBM、nokia工程师Thomas Gleixner，Artem Bityutskiy等人于2006年发起，致力于开发性能卓越、扩展性高的FLASH专用文件系统，以解决当前嵌入式环境下以FLASH作为MTD设备使用时的技术瓶颈。
关键字：
UBI：一种类似于LVM的逻辑卷管理层。主要实现损益均衡，逻辑擦除块、卷管理，坏块管理等。
UBIFS：基于UBI的FLASH日志文件系统。
有关ubifs的详细介绍，请参考：
http://www.linux-mtd.infradead.org/doc/ubi.html
http://www.linux-mtd.infradead.org/doc/ubifs.html
第二、为何使用ubifs？
第三、如何得到ubifs？
2.6.22以后，ubifs活跃于git管理工程中：
git://git.infradead.org/ubi-2.6.git
2.6.27以后，ubifs被整合进内核树中，用户只需下载最新内核即可获取ubifs支持。
第四、如何使用ubifs？
软件环境：
linux-2.6.28
arm-linux-gcc 3.4.5
硬件环境：
s3c2410
k9f1208
一、准备
1、内核
配置的时候选上
1)Device Drivers --->Memory Technology Device (MTD) support --->UBI - Unsorted block images --->Enable UBI
2)File systems --->Miscellaneous filesystems --->UBIFS file system support
2、mtd-utils工具(flash_eraseall、ubiattach、ubimkvol)准备
1)下载(mtd-utils、zlib、lzo)源码
wget http://debian.mirror.inra.fr/debian/pool/main/m/mtd-utils/mtd-utils_20080508.orig.tar.gz
wget http://www.zlib.net/zlib-1.2.3.tar.gz
wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz
2)编译安装zlib
tar xzvf zlib-1.2.3.tar.gz
cd zlib-1.2.3
CC=arm-linux-gcc ./configure --shared --prefix=/usr/local/arm/3.4.5/arm-linux
make
make install
cd ..
3)编译安装lzo
tar xzvf lzo-2.03.tar.gz
cd lzo-2.03
CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr/local/arm/3.4.5/arm-linux
make
make install
cd ..
4)编译mtd-utils
tar xzvf mtd-utils_20080508.orig.tar.gz
cd mtd-utils-20080508
修改Makefile文件：
#CROSS=arm-linux-
修改为 CROSS=arm-linux-
BUILDDIR := $(CROSS:-=)
修改为 BUILDDIR := .
修改ubi-utils/Makefile文件：
添加 CROSS=arm-linux-
修改 ubi-utils/new-utils/Makefile文件：
添加 CROSS=arm-linux-
make WITHOUT_XATTR=1
ubi-utils子目录下生成我们需要的ubiattach、ubimkvol等文件(请确保是交叉编译所得)
3、mtd-utils工具(mkfs.ubifs、ubinize)准备
git-clone git://git.infradead.org/mtd-utils.git
cd mtd-utils/
make
mkfs.ubifs子目录下生成我们需要的mkfs.ubifs工具
ubi-utils/new-utils子目录下生成我们需要的ubinize工具
二、使用
1、使用ramfs或nfs启动系统，执行以下命令挂载ubifs：
1)flash_eraseall /dev/mtd4
2)ubiattach /dev/ubi_ctrl -m 4
3)ubimkvol /dev/ubi0 -N rootfs -s 50MiB
4)mount -t ubifs ubi0_0 /mnt或mount -t ubifs ubi0:rootfs /mnt
2、如果你想使用ubifs为rootfs，把文件系统内容解压到ubifs挂载目录下，并修改内核启动参数为：
console=ttySAC0 ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs
3、如果你想直接在bootloader下烧写ubifs映像，使用以下命令制作ubi烧写映像：
mkfs.ubifs -r rootfs -m 512 -e 15872 -c 3303 -o ubifs.img
ubinize -o ubi.img -m 512 -p 16KiB -s 256 ubinize.cfg
其中：
1)以上命令的参数可从ubifs挂载信息中提取：
UBI: attaching mtd4 to ubi0
UBI: physical eraseblock size: 16384 bytes (16 KiB)
UBI: logical eraseblock size: 15872 bytes
UBI: smallest flash I/O unit: 512
UBI: sub-page size: 256
UBI: VID header offset: 256 (aligned 256)
UBI: data offset: 512
UBI: attached mtd4 to ubi0
2)配置文件ubinize.cfg的内容为：
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=50MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
注：
其他nand flash下ubifs的使用方法类似(参数不同)。
2009年5月5日 星期二
WPA vs WPA2
1) TKIP vs WEP
A cryptographic message integrity check to protect packets(MIC)
An initialization-vector sequencing mechanism that includes hashing, as opposed to WEP's plain text transmission
A per-packet key-mixing function to increase cryptographic strength
A re-keying mechanism to provide key generation every 10,000 packets.
2) WPA2
MIC->CCMP
RC4->AES
* Support for opportunistic key caching to reduce the overhead in roaming between access points;
* Support for pre-authentication
A cryptographic message integrity check to protect packets(MIC)
An initialization-vector sequencing mechanism that includes hashing, as opposed to WEP's plain text transmission
A per-packet key-mixing function to increase cryptographic strength
A re-keying mechanism to provide key generation every 10,000 packets.
2) WPA2
MIC->CCMP
RC4->AES
* Support for opportunistic key caching to reduce the overhead in roaming between access points;
* Support for pre-authentication
訂閱：
文章 (Atom)