| Posted by: | oz |
|---|
| Subject: | Version Mismatch question |
|---|
| Date: | 23:09:54 22/05/2004 |
|---|
Hi,
I got the same problem while trying to run kismet_server on OS X and communicate with the kismet_drone running on a wrt54g. Because I did not find a solution searching with google I think it might be wise to share my knowledge (because I found the problem). Description / solution is further down.
> > FATAL: version mismatch: Drone sending version 51963, expected 8.
> >
> > I compiled the same source package on my Linux server, and everything seems to work fine, so I can rule out a configuration issue. My only suspicion is that there may have been a problem in the initial compiling on OS X that is causing kismet to incorrectly read the version of the drone. Are there any flags that I can use with ./configure that may help to fix this?
>
> That's odd. It sounds like an endian bug, I'll take a look in a bit and see if that guess is right. The protocol should be fully endian clean...
I digged into the code and the problem does not have something to do with endianness, it is a bug in the version of the gcc delivered with OS X (version 3.3 with some changes by apple). This compiler can not handle packed structures correctly and therefore sizeof(struct stream_frame_header) becomes 12 (instead of 9). Thats why 0xCAFB from the next packet is interpreted as the version number.
I installed gcc 3.3.2 on OS X and compiled kismet and with this binary I am able to receive data from the kismet_drone (btw I couldn't compile kismet with gcc 3.4.0 on OS X)
oz
Reply to this message
