MADWIFI

Dear list-members,

I am working on a little program, that tries to improve roaming-abilities of madwifi. My software is based on a packetinjection-patch for monitormode, that aircrack-ng provides (I use madwifi 0.9.2 with madwifi-ng-r1816-patch).

Now I reached a point, where I definitely need to acknowledge wireless packets on my own. The driver won't do it for me, since the packets, that I want to acknowledge are destined for a MAC-address, that my card does not provide. The corresponding address is on LAN-side behind the machine, that my program is running on.

So if I start acknowledging packets for a different MAC, the accesspoint, that I am talking to, won't accept these acknowledges. It just keeps sending the packets on and on, since it "believes" the frame not being acknowledged yet.

If I sniff my genereated acknowledgement-packets with wireshark, they looks just like they would be copies of those acknowledgment packets, that a WLAN-card in station-mode provides, meaning where an accesspoint doesn't pump out packets again and again.

I read in the IEEE802.11-standard, that an acknowledgement-packet has a CRC-unit at its end (32bit of data) and I tried to generate such a packet on my own and put it at the end of my generated acknowledgement-packet. But still, there is no effect, the accesspoint keeps sending its packet like they wouldn't have been acknowledged yet.

By the way: shouldn't this CRC32-stuff be done by the driver itself? I mean, if I send packets with the source MAC being the MAC of the physical card in use, everything works fine, but if I send packets with a different MAC as source, it stops working.

Keep in mind: the acknowledgment-packet doesn't even contain the sender's address!

Any suggestions?


Thanks a lot for reading and in advance for every little piece of help!

Dennis

I believe the acknowledgement packets are sent by the MAC controller chip,
and not by the driver since they are time sensitive packets. Most likely,
the packets you are sending are not getting there in time, and the retries
are happening before your ACK is even sent. I guess you could try setting
the ACK timeout to a really long value, but I'm not convinced that would be
enough. I don't think I've ever heard of anyone successfully sending ACK
packets from driver code.

Good luck,

-Herb


-----Original Message-----
From: madwifi-devel-bounces@...
[mailto:madwifi-devel-bounces@...] On Behalf Of Dennis
Borgmann
Sent: Wednesday, January 03, 2007 2:15 PM
To: madwifi-devel@...
Subject: [Madwifi-devel] acknowledging frames for spoofed MACs

Dear list-members,

I am working on a little program, that tries to improve roaming-abilities of
madwifi. My software is based on a packetinjection-patch for monitormode,
that aircrack-ng provides (I use madwifi 0.9.2 with madwifi-ng-r1816-patch).

Now I reached a point, where I definitely need to acknowledge wireless
packets on my own. The driver won't do it for me, since the packets, that I
want to acknowledge are destined for a MAC-address, that my card does not
provide. The corresponding address is on LAN-side behind the machine, that
my program is running on.

So if I start acknowledging packets for a different MAC, the accesspoint,
that I am talking to, won't accept these acknowledges. It just keeps sending
the packets on and on, since it "believes" the frame not being acknowledged
yet.

If I sniff my genereated acknowledgement-packets with wireshark, they looks
just like they would be copies of those acknowledgment packets, that a
WLAN-card in station-mode provides, meaning where an accesspoint doesn't
pump out packets again and again.

I read in the IEEE802.11-standard, that an acknowledgement-packet has a
CRC-unit at its end (32bit of data) and I tried to generate such a packet on
my own and put it at the end of my generated acknowledgement-packet. But
still, there is no effect, the accesspoint keeps sending its packet like
they wouldn't have been acknowledged yet.

By the way: shouldn't this CRC32-stuff be done by the driver itself? I mean,
if I send packets with the source MAC being the MAC of the physical card in
use, everything works fine, but if I send packets with a different MAC as
source, it stops working.

Keep in mind: the acknowledgment-packet doesn't even contain the sender's
address!

Any suggestions?


Thanks a lot for reading and in advance for every little piece of help!

Dennis

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Madwifi-devel mailing list
Madwifi-devel@...
https://lists.sourceforge.net/lists/listinfo/madwifi-devel

Has any user, or developer gotten Ad-hoc mode to work reliably? Since 
the change to the 'next generation',
and even in the old tree shortly before 'the big switch', I have not 
gotten a reliable driver for Ad-hoc.
The only version that works reliably, and here means 'being able to give 
reasonable performance for
'streaming' data', not just a small ping packet ever second, was a very 
early BSD branch version.

The most recent version does not crash my kernel, so that ancient bug 
has been fixed, but now
the driver basically dribbles out packets, and then after a few 100K 
bytes worth, pretty much stops
completely.

My test 'stream' program basically uses UDP and smashes packets out with 
a software time
delay between packets I can get a reasonably accurate 'bitrate' and not 
swamp the network stack.
Basically this 'works' with not only my old BSD madwifi driver in Adhoc 
mode, it also simulates
streaming bit rates for video applications. The reason for the software 
delay is that there is no
really good way to rate limit accurately without puting in a hardware 
timer interrupt handler and
manage the packets in side the kernel (don't tell me about 'shaping' 
most of the shaping is done
via tossing packets, not making sure they only are presented, with no 
losses, at a certain rate.
For those trying to simulate a video converter synch'd to a standard 
broadcast analog video
stream you'll know what a I mean.)

What is sort of astonishing is that Ad-hoc is appears to still be 
broken, or not well documented.
What is astonishing is that few have commented on it, as it appears that 
most people seem to be
most interested in setting up an AP+STATION which can be bought for 
bargin prices almost
anywhere, and the 'really different' configurations, such as Ad-hoc, are 
almost unused.

Anyway, so much for my New Year's rant, and my 'every six months' check 
on the status
of Ad-hoc and 'Madwifi Next Generation'.

John Clark.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<img alt="underwrite" src="cid:part1.08030703.05020209@..."
 height="310" width="561"><br>
This suggests the individual may have seeded the hamburger. 5 TD is a
disappointment.<br>
Just in case you think that you'll be ripped off by offering guarantees,
research have shown that this rarely happens as 99.<br>
As the Customer Lifetime Value will have a significant impact on your
bottomline, my advice is that you be prudent and conservative in your
estimation.<br>
It's the potential contribution of your customers to your business over
a period of time.<br>
In reality, it is our own stories we tell: how we missed a diagnosis, or
got one right; how we failed a patient, or helped her recover a piece of
her life.<br>
You may spend more like making stronger and more attractive offers than
your competition in acquiring new customers now who'll be your money
spinners tomorrow.<br>
Started in 1995 as an informal collaboration among a handful of C.<br>
Why is it so important to you and your business? Address the need for a
product or service that's not being addressed by mainstream
providers.<br>
Superior customer serviceIn addition to a viable business plan, a
superior customer service will be key to your success.<br>
Started in 1995 as an informal collaboration among a handful of C.<br>
As enthusiasm for the program grew, four affiliates in state health
departments opened in California, Connecticut, Minnesota and Oregon. I
am one of the people who have had little to no problems and have had
fine dealer service.<br>
Why would you want to spend time re-inventing the wheel when you can
learn from those who've already been there and done it successfully.<br>
It's also a fact that a "me too" business will eventually go to the
wall.<br>
</body>
</html>

Hi Everyone,

Im Milan, Computer Engineering student and im working on implementing 802.21=
. I decided to use madwifi since its supporting many wlan
devices. But i need ur help. Im not a very good kernel programer, in fact it=
s the 1st time :-P
Ok what i need help in is to have a char-device driver as kernel module rece=
iving packets from the madwifi. From these packets i have to
extract all the radiotap header information for example into an enumeration=20=
structure.

i know i ask alot, but help would be appreciated.

Thanx in advance

Milan

Hello!

Sorry for answering late.  It's hard for me sometimes to keep up with
the e-mail.

On Sat, 2006-12-02 at 23:56 +0100, Maciek Jedynak wrote:
> Thanks for your answer, Pavel.
>         
>         You can try fixed addresses to make sure it's not a DHCP
>         problem.
> 
> Unfortunately fixed  IP didn't work either. After zillion of attempts
> I obtained dhcp  address once. After that  connection last for around
> one minute and ping lost about 90% of packages. I also tried other AP,
> with no success. So, I think it is rather hardware-driver-kernel
> related problem. 

I agree.  You may want to check if the packets are lost on the way to
the AP or back.  You'll need an AP where you can capture the packets, or
you can do it using a sniffer.
> 
>         If it doesn't help, the standard way to debug such problems is
>         to sniff
>         packets on on the air using another system with a card in
>         monitor mode. 
>         You can also use the sniffer on the VAP interface.
> 
> I will try it; in the meantime could you let me know abot the
> follwing:
> 
> - why didn't you refer to debug logs which I mentioned? Is there any
> way these could be helpful to solve the problem? After all these are
> >fatal< errors on the level of hardware layer, so why would I expect
> dhcp to work? What other debug messages would be helpful in this
> case ? 

There were no logs attached to your original message.  The line you
quoted comes from ath_printrxbuf().  See the source for interpretation.

> - are there any x86_64 related issues, which might be a case here ?
> (like kernel config, etc).

I have no idea.  I haven't heard of any problems like yours.  I verified
the MadWifi sources with sparse some time ago, so I'm confident that the
trivial porting errors have been caught.  That still leaves non-trivial
problems.

> - is AR5005G supported by madwifi, or should one be lucky to get it
> working? I saw no AH_SUPPORT_AR5005 defined in the code. Do you have
> any plans to work on this particular chipset? 

I have no plans to work on any particular chipsets.

-- 
Regards,
Pavel Roskin