# kismet - ipw2200-1.0.7 - radiotap :: unkown arptype

## kornhs4

Since the release of ipw2200 version 1.0.7 the driver also supports radiotap. The new kismet version does this too. But when a launch kismet I get this answer:

```

Server options:  none

Client options:  none

Starting server...

Waiting for server to start before starting UI...

Will drop privs to shuber (1002) gid 100

No specific sources given to be enabled, all will be enabled.

Enabling channel hopping.

Enabling channel splitting.

Source 0 (MySource): Enabling monitor mode for ipw2200 source interface eth1 channel 6...

Source 0 (MySource): Opening ipw2200 source interface eth1...

FATAL: arptype 803 not supported by libpcap - falling back to cooked socket

```

The arptype 803 stands for radiotap. My libpcap version is 0.9.3 which should already support radiotap. Kismet already worked for me, before updating to new firmware, ipw and ieee80211. My installed versions:

 ipw2200: 1.0.7

 ipw2200-firmware: 2.3 2.4

 ieee80211: 1.1.5

 libpcap: 0.9.3

 kismet: 2005.08.1 (a version which didn't work for me)

 kernel: suspend2-sources 2.6.13-r5 and 2.6.12-r6

But, if i boot with my old kernel (gentoo-sources-2.6.12), which therefor uses the old ieee80211-1.0.3-r2 and ipw2200-1.0.6, kismet works.

Has anyone the same problem too?

thx,

Stefan!

----------

## Der P@te

Hi there,

you tried version 1.08 and fw 2.4? I have installed this an Kismet still works normaly. But when i try to start airodump i get a similar problem:

```

Unsupported hardware link type  803 - expected ARPHRD_IEEE80211

or ARPHRD_IEEE80211_PRISM instead.  Make sure RFMON is enabled:

run 'ifconfig eth1 up; iwconfig eth1 mode Monitor channel <#>

```

The Firmware 2.4 seems to have a problem..my system lags when i start kismet or monitor mode at ipw2200.

dmesg output:

```

ipw2200: Firmware error detected.  Restarting.

ipw2200: Sysfs 'error' log already exists.

```

Found a bugreport...

http://bughost.org/bugzilla/show_bug.cgi?id=812

----------

## kornhs4

@Der P@ate:

At my system too:

```

airodump eth1 airodump

unsupported hardware link type 803

expected ARPHRD_IEEE80211 or ARPHRD_IEEE80211_PRISM

did you put your card in monitor mode ?

```

I've now tried the version 1.0.8 too, without success. But I've found one thing interessting:

```

tethereal --help

tethereal: invalid option -- -

This is tethereal 0.10.13

 (C) 1998-2005 Gerald Combs <gerald@ethereal.com>

Compiled with GLib 2.6.5, with libpcap 0.9.2, with libz 1.2.3, with libpcre 6.3,

without UCD-SNMP or Net-SNMP, without ADNS.

Running with libpcap version 0.9.2 on Linux 2.6.13-suspend2-r5.

```

but I've installed libpcap-0.9.3!!

```

emerge libpcap -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] net-libs/libpcap-0.9.3  +ipv6 0 kB

* net-libs/libpcap

     Available versions:  0.8.3-r1 0.9.3

     Installed:           0.9.3

     Homepage:            http://www.tcpdump.org/

     Description:         A system-independent library for user-level network packet capture

```

Isn't it strange? So I unmerged libpcap and ethereal, re-emerged them with little hope of change. No success, of course! Is there a way to find out the version of libpcap used by kismet? Could there be a problem with the library-linking of libpcap @kismet/ethereal?

thx,

Stefan

----------

## kornhs4

Strange things again:

```

mynewbestpart kismet # emerge kismet

Calculating dependencies ...done!

>>> emerge (1 of 1) net-wireless/kismet-2005.08.1 to /

>>> md5 files   ;-) kismet-2005.08.1.ebuild

>>> md5 files   ;-) files/digest-kismet-2005.08.1

>>> md5 files   ;-) files/kismet-2005.08.1-conf.d

>>> md5 files   ;-) files/kismet-2005.08.1-init.d

>>> md5 src_uri ;-) kismet-2005-08-R1.tar.gz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.13-suspend2-r5

>>> Unpacking source...

>>> Unpacking kismet-2005-08-R1.tar.gz to /var/tmp/portage/kismet-2005.08.1/work

>>> Source unpacked.

 * econf: updating kismet-2005-08-R1/libpcap-0.9.1-kis/config.guess with

[...]

configure: configuring in libpcap-0.9.1-kis

configure: running /bin/sh './configure' --prefix=/usr  '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--build=i686-pc-linux-gnu' '--disable-gpsmap' '--with-linuxheaders=/usr/src/linux/include' 'CFLAGS=-O2 -march=pentium-m -fomit-frame-pointer

[...]

Linux wireless v.22+ : yes

          pcap capture: yes

           pcap source: libpcap-0.9.1-kis

        WSP100 capture: no

```

Is the kismet version from portage too old? Why does kismet use libpcap-0.9.1?

thx,

Stefan!

----------

## Der P@te

It seems to be right that Kismet uses 0.91 of Libpcab...

```

emerge kismet

Calculating dependencies  ...done!

>>> emerge (1 of 1) net-wireless/kismet-2005.08.1 to /

>>> md5 files   ;-) kismet-2005.08.1.ebuild

>>> md5 files   ;-) files/digest-kismet-2005.08.1

>>> md5 files   ;-) files/kismet-2005.08.1-conf.d

>>> md5 files   ;-) files/kismet-2005.08.1-init.d

>>> md5 src_uri ;-) kismet-2005-08-R1.tar.gz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.13-gentoo-r4

>>> Unpacking source...

>>> Unpacking kismet-2005-08-R1.tar.gz to /var/tmp/portage/kismet-2005.08.1/work

>>> Source unpacked.

 * econf: updating kismet-2005-08-R1/libpcap-0.9.1-kis/config.guess with /usr/share/gnuconfig/config.guess

 * econf: updating kismet-2005-08-R1/libpcap-0.9.1-kis/config.sub with /usr/share/gnuconfig/config.sub

 * econf: updating kismet-2005-08-R1/config.guess with /usr/share/gnuconfig/config.guess

 * econf: updating kismet-2005-08-R1/config.sub with /usr/share/gnuconfig/config.sub

./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-gpsmap --with-linuxheaders=/usr/src/linux/include --build=i686-pc-linux-gnu

checking build system type... i686-pc-linux-gnu

checking host system type... i686-pc-linux-gnu

checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc

checking for C compiler default output file name... Caught signal 2 in pid 8114

```

----------

## kornhs4

Ok, thats the solution! arptype 803 (radiotap) is only supported with libpcap-0.9.3+, version 0.9.1 doesn't support radiotap! But for some reason, still the dev-version of kismet (of kismet site) is using libpcap-0.9.1! So how can radiotap work?

Question for those, who are running >=ipw2200-1.0.7 and kismet: have you used the USE-flag radiotap in ipw - which libpcap uses your kismet installation?

Stefan

----------

## Der P@te

I found some News about it:

http://www.kismetwireless.net/blog/

IPW2200 1.0.7

```

The 1.0.7 ipw2200 drivers have released, including my support for radiotap packet headers. To turn on radiotap (and therefor per-packet signal level reporting for Kismet), you need to edit the Makefile and uncomment the line CONFIG_IEEE80211_RADIOTAP=y

You'll want an up-to-date libpcap (0.9.3+) and a modern Kismet (get the latest or get the stable-devel from svn). 

```

----------

## kornhs4

Ok, I'm using kernel 2.6.12 with the old ipw drivers. In consideration of failing ALSA too, the choice was easy.

----------

## kornhs4

I've a workaround for this problem:

First unpack the source of kismet with

```
ebuild /usr/portage/net-wireless/kismet/kismet-xxx
```

Now change to the directory of the unpacked source

```
cd /var/tmp/portage/kismet-xxx/work/kismet-xxx/
```

To create configure files run

```
./configure
```

Edit the Makefile at postion of CPPFLAGS and change the version of libpcap, in my case to 0.9.3

```
CPPFLAGS =  -Ilibpcap-0.9.3 -I/usr/include
```

Now you can compile kismet and install it, maybe with

```

make dep

make

make install

```

But with this way, kismet will be installed in /usr/local/bin and the configs are in /usr/local/etc/. Maybe you want to change this before or unmerge the original kismet installation.

----------

## klingon

Please would you explain how you fixed this problem in more detail.  I did exactly as you said including editing the Makefile however this was no use.

----------

## kornhs4

Can you compile your kismet with these changes? If yes, what is printed at the beginning of compiling about the libpcap-version? Or is the problem somewhere else? If you call "whereis kismet", which location is printed? Maybe the PATH is listing the original position of kismet at first, now its installed at /usr/local/bin/kismet.

P.S. Excuse me - I saw the message but now.

----------

