[PATCH] orinoco rfmon
Could anyone elaborate on the status of this patch? I've had 344 days of uptime
on a PPC
powerbook using it on 2.4.22 and about 3 months of solid use on 2.6.
If the code looks problematic could someone point out possible deficiencies so
we can work
toward a satisfactory resolution? I didn't write the code but I'm willing do
what I have to
in order to get this (wireless scanning) into the official tree.
diff -ur linux-2.6.9/drivers/net/wireless/hermes.c
linux-2.6.9-orinoco/drivers/net/wireless/hermes.c
--- linux-2.6.9/drivers/net/wireless/hermes.c 2004-10-20 15:26:41.0
-0400
+++ linux-2.6.9-orinoco/drivers/net/wireless/hermes.c 2004-10-20
14:55:01.0 -0400
@@ -182,6 +182,10 @@
if (err)
return err;
+for ( k = 0; k < HERMES_NUMPORTS_MAX; k++) {
+ hw->port_enabled[k] = 0;
+ }
+
reg = hermes_read_regn(hw, EVSTAT);
k = CMD_INIT_TIMEOUT;
while ( (! (reg & HERMES_EV_CMD)) && k) {
diff -ur linux-2.6.9/drivers/net/wireless/hermes.h
linux-2.6.9-orinoco/drivers/net/wireless/hermes.h
--- linux-2.6.9/drivers/net/wireless/hermes.h 2004-10-20 15:26:41.0
-0400
+++ linux-2.6.9-orinoco/drivers/net/wireless/hermes.h 2004-10-20
15:24:55.0 -0400
@@ -34,6 +34,10 @@
#include
#include
+#defineHFA384x_PORTTYPE_IBSS ((uint16_t)3)
+#defineHFA384x_WEPFLAGS_DISABLE_TXCRYPT(0x10)
+#defineHFA384x_WEPFLAGS_DISABLE_RXCRYPT(0x80)
+
/*
* Limits and constants
*/
@@ -150,6 +154,11 @@
/*--- Debugging Commands -*/
#defineHERMES_CMD_TEST (0x0038)
+/*--- Debugging Commands -*/
+/* We want these in this byte arrangement. Why is it even being changed? */
+#defineHERMES_CMD_MONITOR (0x0038)
+#defineHERMES_MONITOR_ENABLE (0x000b)
+#defineHERMES_MONITOR_DISABLE (0x000f)
/* Test command arguments */
#defineHERMES_TEST_SET_CHANNEL 0x0800
@@ -173,6 +182,38 @@
#defineHERMES_HOSTSCAN_SYMBOL_BCAST0x0080
/*
+ * Configuration RIDs
+ */
+
+#defineHERMES_RID_CNF_PORTTYPE (0xfc00)
+#defineHERMES_RID_CNF_CHANNEL (0xfc03)
+#defineHERMES_RID_CNF_PRISM2_WEP_ON(0xfc28)
+
+/*-- Status Fields --*/
+#defineHERMES_RXSTATUS_MSGTYPE (0xE000)
+#defineHERMES_RXSTATUS_MACPORT (0x0700)
+#defineHERMES_RXSTATUS_UNDECR (0x0002)
+#defineHERMES_RXSTATUS_FCSERR (0x0001)
+
+/*
+Communication Frames: Test/Get/Set Field Values for Receive Frames
+*/
+#defineHERMES_RXSTATUS_MSGTYPE_GET(value) (((value) &
HERMES_RXSTATUS_MSGTYPE) >> 13)
+#defineHERMES_RXSTATUS_MSGTYPE_SET(value) ((value) << 13)
+#defineHERMES_RXSTATUS_MACPORT_GET(value) (((value) &
HERMES_RXSTATUS_MACPORT) >> 8)
+#defineHERMES_RXSTATUS_MACPORT_SET(value) ((value) << 8)
+#defineHERMES_RXSTATUS_ISUNDECR(value) ((value) &
HERMES_RXSTATUS_UNDECR)
+#defineHERMES_RXSTATUS_ISFCSERR(value) ((value) &
HERMES_RXSTATUS_FCSERR)
+
+/*
+Communication Frames: Field Masks for Receive Frames
+*/
+/*-- Offsets */
+#defineHERMES_RX_DATA_LEN_OFF (44)
+#defineHERMES_RX_80211HDR_OFF (14)
+#defineHERMES_RX_DATA_OFF (60)
+
+/*
* Frame structures and constants
*/
@@ -181,6 +222,16 @@
#define HERMES_802_3_OFFSET(14+32)
#define HERMES_802_2_OFFSET(14+32+14)
+struct hermes_rx_descriptor {
+ u16 status;
+ u32 time;
+ u8 silence;
+ u8 signal;
+ u8 rate;
+ u8 rxflow;
+ u32 reserved;
+} __attribute__ ((packed));
+
#define HERMES_RXSTAT_ERR (0x0003)
#defineHERMES_RXSTAT_BADCRC(0x0001)
#defineHERMES_RXSTAT_UNDECRYPTABLE (0x0002)
@@ -353,6 +404,7 @@
#define HERMES_32BIT_REGSPACING1
u16 inten; /* Which interrupts should be enabled? */
+ uint8_t port_enabled[HERMES_NUMPORTS_MAX];
#ifdef HERMES_DEBUG_BUFFER
struct hermes_debug_entry dbuf[HERMES_DEBUG_BUFSIZE];
@@ -406,12 +458,14 @@
static inline int hermes_enable_port(hermes_t *hw, int port)
{
+hw->port_enabled[port] = 1;
return hermes_docmd_wait(hw, HERMES_CMD_ENABLE | (port << 8),
0, NULL);
}
static inline int hermes_disable_port(hermes_t *hw, int
Re: [PATCH] orinoco rfmon
Alexey Dobriyan wrote: On Saturday 26 February 2005 20:10, Eric Gaumer wrote: If the code looks problematic could someone point out possible deficiencies so we can work toward a satisfactory resolution? I didn't write the code but I'm willing do what I have to in order to get this (wireless scanning) into the official tree. Uhhh... Started to comment line-by-line but then realized it would take too much time. * Read Documentaion/CodingStyle. * Indent code with tabs where it is already indented with tabs. * Brackets around a single number in #define's are useless. * Use u8, u16, u32 (not uint*_t) where the code already uses them. * Comments are supposed to be anonymous. * Use appropriate KERN_* constant in printk()'s. * Don't pack simple types (uint32_t, ...) * Common convention is to return 0 on success, negative number on error. Positive return values don't fit well into this scheme. If possible follow it. Oh, and the type p80211item_uint32_t when in fact it is a 12-bytes long structure ... Alexey What is the difference between u* and uint*_t ? Both are derived from the same basic data type. typedef unsigned char __u8; typedef __u8uint8_t; And... typedef unsigned char u8; -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] orinoco rfmon
David Gibson wrote:
This looks like the ancient version of the monitor patch - which
includes importing a lot of needless junk from the linux-wlan-ng
tree. A cleaned up version of monitor has been merged in the orinoco
CVS tree for ages now, but unfortunately that's long overdue for a
merge with mainline. I'm trying to get that merge done - I just don't
have much time or energy for the orinoco driver these days. One stack
of patches which gets part of the way went to Jeff Garzik last week.
We'll see how we go.
In the meantime go to http://savannah.nongnu.org/projects/orinoco for
access to the driver CVS. You probably want to get the "for_linus"
branch of CVS if you're planning to work with 2.6.
Thanks David, the CVS code works great with the small excpetion of the
following change to
get it to build.
diff -Nru orinoco-cvs/orinoco_cs.c orinoco-build/orinoco_cs.c
--- orinoco-cvs/orinoco_cs.c2005-02-26 22:21:55.0 -0800
+++ orinoco-build/orinoco_cs.c 2005-02-27 15:00:07.698368136 -0800
@@ -428,7 +428,7 @@
SET_MODULE_OWNER(dev);
card->node.major = card->node.minor = 0;
- SET_NETDEV_DEV(dev, &handle_to_dev(handle));
+ dev->name[0] = '\0';
/* Tell the stack we exist */
if (register_netdev(dev) != 0) {
printk(KERN_ERR PFX "register_netdev() failed\n");
What's the deal with the broken firmware for monitor mode?
* v0.15rc1 -> v0.15rc2 - 28 Jul 2004 - Pavel Roskin & David Gibson
* o orinoco_pci saves PCI registers on suspend (Simon Huggins).
* o Monitor mode disabled on Agere 8.xx firmware - it's broken.
I have 8.4 but things seem fine (used this card in monitor mode for over a year
without
problems).
I just disabled the check for broken firmware and things seem fine (better than
the original
patch I posted). The iwlist command now works. Could the buggy firmware be
generalized a bit
too much? Perhaps only certain versions > 8 are buggy?
--
"Education is what remains after one has forgotten everything he learned in
school."
- Albert Einstein
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] orinoco rfmon
Greg KH wrote: On Sat, Feb 26, 2005 at 02:45:49PM -0800, Eric Gaumer wrote: What is the difference between u* and uint*_t ? Both are derived from the same basic data type. typedef unsigned char __u8; typedef __u8uint8_t; And... typedef unsigned char u8; Don't use the uint*_t types, they are not correct. See the lkml archives for why this is true. Use the u8 for when you are in the kernel, and __u8 when you need it for a variable that crosses the userspace/kernelspace barrier. thanks, Thanks, I'll dig up those archives. -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein signature.asc Description: OpenPGP digital signature
Re: RFD: Kernel release numbering
Greg KH wrote: On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote: So what's the problem with this approach? It would seem to make everybody happy: it would reduce my load, it would give people the alternate "2.6.x base kernel plus fixes only" parallell track, and it would _not_ have the testability issue (because I think a lot of people would be happy to test that tree, and if it was always based on the last 2.6.x release, there would be no issues. Anybody? Well, I'm one person who has said that this would be a very tough problem to solve. And hey, I like tough problems, so I'll volunteer to start this. If I burn out, I'll take the responsibility of finding someone else to take it over. I really like the rules you've outlined, that makes it almost possible to achieve sanity. How does what Linus outlined differ from splitting to 2.7? Isn't it the same thing with just a different versioning scheme? In the end we have a stable 2.6 tree. What's the difference between the 2.6 development tree and 2.7. All that aside... why not make the "sucker tree" a breeding ground for new kernel hackers. I've been trying to get more involved with kernel development (as are others) but it's tough because things change so rapidly that once you finally figure it out, it has changed. As the kernel matures into new versions it's getting much harder for guys coming out of school to figure out. Sure you have that exceptional individual but maybe you're committing genocide in the end. If someone like Greg could lead this band of gypsies then that would be great. Most of the more experienced hackers don't want to slow pace and do all this boring work but people like myself would be honored to "pay our dues". We would feel free to ask some questions and see a slower pace so we can learn. If patches are small and truly only fix bugs then wouldn't you say this would be possible? In fact one criteria could be that if we can't understand just what exactly the patch fixes then it probably doesn't belong in this tree? It's a win - win situation. End users are happy and we start a semi-structured training camp. -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein signature.asc Description: OpenPGP digital signature
