From: Jouni Malinen (jkmaline_at_cc.hut.fi)
Date: 2001-12-14 21:11:24 UTC
On Fri, Dec 14, 2001 at 09:40:40AM -1000, Tim Newsham wrote:
> So far I'm having no luck using this API however. I try
> constructing a frame with a hfa384x_tx_frame header on it,
> then writing it down through the PRISM2_MONITOR_GROUP netlink
> socket. The send() returns success, but the driver fails
> to write out a frame, instead getting a TX exception:
I was going to include couple of example programs that used packet injection (e.g., to simulate an authentication and association or to replay WEP-protected frames), but I did not have time for this and then forgot about it.. In addition, I have not tested packet injection with latest versions of the driver, so some changes may have broken it. You should also note, that this uses undocumented "features" of the station firmware and might well not work with all versions. I have used packet injection successfully with Compaq WL100 and STA f/w 0.8.0. I'll try to find my examples somewhere and make them available after a quick test.
> wlan0: TXEXC - fid=0x0124 - status=0x0008 ([FormErr]) tx_control=0d0c
> retry_count=10 tx_rate=11 fc=0x0008 (Data::0)
> addr1=c5:34:db:04:b8:68 addr2=c0:cd:5c:d6:92:a5 addr3=2c:81:ed:8e:c3:17
> Could not find STA for this TX error
>
> I assume this is because the firmware finds the frame to
> be unacceptable. So my question is, how can I use this interface
> to send frames through the driver?
Yes, firmware generates TxExc when it is given an invalid frame. There are also couple of limitations on what can be sent (although, most fields can be set freely). Since you apparently have been able to get an TxExc, the driver was trying to send something. If I remember correctly, there is nothing special in the user space program I used to send frames. You just have to construct a frame that will pass firmware's verification.
> I've tried both with and without PRISM2_MONITOR_PACKET_INJECT
> defined in the driver.
Compiling with PRISM2_MONITOR_PACKET_INJECT seemed to allow more fields to be set in the frames.
> (btw, is there any reason the AP was implemented in the
> driver itself rather than as a userland program? I would
> think that development would be easier if it was possible
> to develop AP functionality in a userland program).
AP needs to check various things about each data frame and part of these verifications are based on sending station authentication/association state. I think that all tests for data packets should be done in the driver. It would be possible to perform management function in a userspace daemon. However, this would require keeping station information synchronized between the kernel driver and userspace daemon. In addition, functions like power saving station polling for buffered packets have somewhat strict latency requirements and these might suffer from context switches.
So far the management functions (mainly authentication and association) have been quite simple and I haven't seen enough need to move these to userspace. However, if anything more complex should be needed (like extended authentication, etc.), I would consider designing an API for userspace daemon to handle management tasks and to update station information in the kernel driver.
-- Jouni Malinen PGP id EFC895FA