Menu
▾
▴
airjack-user-devel — development related questions, only for developers using the airjack suit
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(21) |
Aug
(30) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|
|
From: Pawel M. <pm...@et...> - 2003-09-25 09:27:00
|
Does AJ always pass the FCS field to userspace (in monitor, mode 5)? It seems that for data frames it does, but for other frames it does not. Am I wrong? BTW, what about AJ2? Any news ? :) |
|
From: Andre L. <an...@cl...> - 2003-08-26 20:36:53
|
Whens it coming? ;) Andre Ludwig |
|
From: Abaddon <ab...@80...> - 2003-08-19 19:57:38
|
there are actually lots and lots of mistakes in that header file, I have
a much newer one thats written from scratch (this one is based on my old
airids project), the overlays and separate structs for each part of the
frame are stupid the way they're done now in 80211.h, I've been using a
much better one at my job (but they own that work) for years now...I
need to re-write it I suppose...
on a more personal note, never let the mentally ill stay in your house
uninvited, and damn sure don't let them if they say they're "cleaning"
your place...so my weekend was fun, how was yours?...
--Abaddon
On Sun, 2003-08-17 at 03:58, Jesse Gonzalez wrote:
> I found a little bug in 80211.h while writing a utility. Here is the patc=
h:
>=20
> *** 80211.h Thu Aug 7 09:04:40 2003
> --- 80211.h_ Thu Aug 14 16:41:01 2003
> ***************
> *** 585,593 ****
>=20
>=20
> struct mgt_probe_resp_one {
> struct a3_80211 pp1_mac_hdr;
> ! __u8 pp1_timestamp;
> __u16 pp1_beacon_interval;
> struct cap_info pp1_cap;
> struct element_id pp1_ssid_id;
> };
> --- 585,593 ----
>=20
>=20
> struct mgt_probe_resp_one {
> struct a3_80211 pp1_mac_hdr;
> ! __u8 pp1_timestamp[8];
> __u16 pp1_beacon_interval;
> struct cap_info pp1_cap;
> struct element_id pp1_ssid_id;
> };
>=20
>=20
>=20
> ***********************
> * Jesse Gonzalez *
> * University of Idaho *
> ***********************
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Airjack-user-devel mailing list
> Air...@li...
> https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
|
|
From: Joshua W. <Jos...@jw...> - 2003-08-18 11:33:04
|
Jesse, The obvious answer begs asking: are you running this program as root? -Joshua Wright Senior Network and Security Architect Johnson & Wales University Jos...@jw...=20 http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 > While testing a simple utility I wrote on a laptop at work on my home > laptop, I find I fail when calling get_socket() (the same as seen in > set_channel.c). I believe I have traced the problem to=20 > airjack_ioctl(). > Could someone please tell me why the following always returns -EPERM >=20 > /* only net admins can use this interface */ > if(!capable(CAP_NET_ADMIN)) { > return(-EPERM); > } >=20 > From what I have read everything should be fine since I am=20 > running this as > root, correct? >=20 > I am running the utility on a laptop running gentoo 1.4.3. |
|
From: Jesse G. <jgo...@se...> - 2003-08-17 09:40:53
|
While testing a simple utility I wrote on a laptop at work on my home
laptop, I find I fail when calling get_socket() (the same as seen in
set_channel.c). I believe I have traced the problem to airjack_ioctl().
Could someone please tell me why the following always returns -EPERM
/* only net admins can use this interface */
if(!capable(CAP_NET_ADMIN)) {
return(-EPERM);
}
From what I have read everything should be fine since I am running this as
root, correct?
I am running the utility on a laptop running gentoo 1.4.3.
***********************
* Jesse Gonzalez *
* University of Idaho *
***********************
|
|
From: Jesse G. <jgo...@se...> - 2003-08-17 08:58:42
|
I found a little bug in 80211.h while writing a utility. Here is the patch:
*** 80211.h Thu Aug 7 09:04:40 2003
--- 80211.h_ Thu Aug 14 16:41:01 2003
***************
*** 585,593 ****
struct mgt_probe_resp_one {
struct a3_80211 pp1_mac_hdr;
! __u8 pp1_timestamp;
__u16 pp1_beacon_interval;
struct cap_info pp1_cap;
struct element_id pp1_ssid_id;
};
--- 585,593 ----
struct mgt_probe_resp_one {
struct a3_80211 pp1_mac_hdr;
! __u8 pp1_timestamp[8];
__u16 pp1_beacon_interval;
struct cap_info pp1_cap;
struct element_id pp1_ssid_id;
};
***********************
* Jesse Gonzalez *
* University of Idaho *
***********************
|
|
From: Abaddon <ab...@80...> - 2003-08-13 16:11:14
|
its not going to work on a/g until I get aj-2 out, the excuse for the day on that one is college transfer applications...I've been slacking I admit, and as such I am way behind (people in town, releases due at work, transfering universities, general lazyness)... --Abaddon On Wed, 2003-08-13 at 04:01, Pawel Matusz wrote: > Did anybody have any experience with running airjack with some a or g > cards? If yes, could you please tell me on what card did it work, so I > could buy one that works for sure? >=20 > Regards, >=20 > Pawel >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Airjack-user-devel mailing list > Air...@li... > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel |
|
From: Joshua W. <Jos...@jw...> - 2003-08-13 12:08:35
|
Pawel, There is no AirJack v1 support for 802.11a or 802.11g right now - just = Prism2 802.11b cards. The new AirJack v2 will have hooks to support = 802.11a and 802.11g and 802.11zspQd - but they will still need = development by people who can develop the hardware-specific hooks (and = aren't under NDA with Broadcom/Atheros/Agere/etc). -Joshua Wright Senior Network and Security Architect Johnson & Wales University Jos...@jw...=20 http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 > -----Original Message----- > From: air...@li... > [mailto:air...@li...]On Behalf Of > Pawel Matusz > Sent: Wednesday, August 13, 2003 5:02 AM > To: airjack-user-devel > Subject: [Airjack-user-devel] Supported 802.11 a/g cards >=20 >=20 > Did anybody have any experience with running airjack with some a or g > cards? If yes, could you please tell me on what card did it work, so I > could buy one that works for sure? >=20 > Regards, >=20 > Pawel >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet > _072303_01/01 > _______________________________________________ > Airjack-user-devel mailing list > Air...@li... > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel >=20 |
|
From: Pawel M. <pm...@et...> - 2003-08-13 09:04:32
|
Did anybody have any experience with running airjack with some a or g cards? If yes, could you please tell me on what card did it work, so I could buy one that works for sure? Regards, Pawel |
|
From: Abaddon <ab...@80...> - 2003-08-08 15:53:31
|
yeah, that happens to me sometimes too, i think its a related issue to the one that Andreas Greulich posted to the list regarding v0.6.6-alpha...I'll see if I can get to the bottom of this, I've known about this part of it for some time, but it worked for me, and until I had this mailing list I didn't have other people wanting it working...I'll get back to you on what I find, because I don't want this on aj-2 as well... --Abaddon On Fri, 2003-08-08 at 10:23, Pawel Matusz wrote: > Just some info: in ver 0.6.5 I sent several thousands of frames (in > non-blocking socket mode, monitor, prism mode 5) and all worked > fine. Well, almost, because from time to time I get an EWOULDBLOCK errno > when trying to send and I have to reopen the socket again and all is OK > again for some time (intil I have to do it again). I've seen that the=20 > same was done in e.g. monkey-jack. Any idea why this might happen?=20 > But I didn't check ver. 0.6.6... >=20 > Regards, >=20 > Pawel >=20 >=20 > On 8 Aug 2003, Abaddon wrote: >=20 > > damn, I let that old __func__ bug creep its way back in...older version= s > > of gcc let you get away with this (wrongfully), and I was lazy...I > > suppose I'll put up a v0.6.7 today, but first I'd like to look into the > > problems you're having sending the traffic...I assume its because I'm > > doing something crazy/wrong with my queues... > >=20 > > I'm going to need a volunteer or two to help me test this out as almost > > all the places I sit down to code have lots and lots of traffic, so it > > always works for me...if you wanna help find me on aim as > > abaddon314159... > >=20 > > --Abaddon > >=20 > > On Fri, 2003-08-08 at 05:13, Andreas.Greulich@ISB.admin.ch wrote: > > > Thanks, 0.6.6 works great, no retry problem anymore! > > >=20 > > > Only one slight detail, I think there's a syntax error, at least my c= ompiler > > > couldn't compile line 1288 of airjack.c, which was > > >=20 > > > printk(KERN_ERR "airjack_cs: " __func__ ": failed to set wep > > > flags.\n"); > > >=20 > > > and I thik should be > > >=20 > > > printk(KERN_ERR "airjack_cs: %s: failed to set wep flags.\n", > > > __func__); > > >=20 > > > At least that compiled for me :-) > > >=20 > > > Note that I found that I can only inject one packet while being in mo= nitor > > > mode. All further packet injections within the same process (stopping= and > > > restarting the program allows one injection again) seem to be ignored= (no > > > error message is given, but the packets don't appear on the WLAN). I = have to > > > clear monitor mode before each injection and set it again afterwards,= then > > > it's working. Unfortunately I'm loosing some packets this way due to = the > > > time delay before and after each injection. Is this a known problem? = Or am I > > > doing something wrong? Maybe it could be some deadlock problem? It is= no > > > problem with retries this time, at least not obviously. But maybe the= card > > > just rejects to send out any further packets without having got a > > > acknowledgment for the first one (which is ignored in monitor mode), = even if > > > retries are set to 0...? But then, it works after restarting the prog= ram for > > > one more frame, so there must be a way to reset the card somehow. Any= ideas? > > >=20 > > > Thanks, Andy > > >=20 > > >=20 > > > ------------------------------------------------------- > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites includin= g > > > Data Reports, E-commerce, Portals, and Forums are available now. > > > Download today and enter to win an XBOX or Visual Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303= _01/01 > > > _______________________________________________ > > > Airjack-user-devel mailing list > > > Air...@li... > > > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Airjack-user-devel mailing list > Air...@li... > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel |
|
From: Pawel M. <pm...@et...> - 2003-08-08 15:23:22
|
Just some info: in ver 0.6.5 I sent several thousands of frames (in non-blocking socket mode, monitor, prism mode 5) and all worked fine. Well, almost, because from time to time I get an EWOULDBLOCK errno when trying to send and I have to reopen the socket again and all is OK again for some time (intil I have to do it again). I've seen that the same was done in e.g. monkey-jack. Any idea why this might happen? But I didn't check ver. 0.6.6... Regards, Pawel On 8 Aug 2003, Abaddon wrote: > damn, I let that old __func__ bug creep its way back in...older versions > of gcc let you get away with this (wrongfully), and I was lazy...I > suppose I'll put up a v0.6.7 today, but first I'd like to look into the > problems you're having sending the traffic...I assume its because I'm > doing something crazy/wrong with my queues... > > I'm going to need a volunteer or two to help me test this out as almost > all the places I sit down to code have lots and lots of traffic, so it > always works for me...if you wanna help find me on aim as > abaddon314159... > > --Abaddon > > On Fri, 2003-08-08 at 05:13, Andreas.Greulich@ISB.admin.ch wrote: > > Thanks, 0.6.6 works great, no retry problem anymore! > > > > Only one slight detail, I think there's a syntax error, at least my compiler > > couldn't compile line 1288 of airjack.c, which was > > > > printk(KERN_ERR "airjack_cs: " __func__ ": failed to set wep > > flags.\n"); > > > > and I thik should be > > > > printk(KERN_ERR "airjack_cs: %s: failed to set wep flags.\n", > > __func__); > > > > At least that compiled for me :-) > > > > Note that I found that I can only inject one packet while being in monitor > > mode. All further packet injections within the same process (stopping and > > restarting the program allows one injection again) seem to be ignored (no > > error message is given, but the packets don't appear on the WLAN). I have to > > clear monitor mode before each injection and set it again afterwards, then > > it's working. Unfortunately I'm loosing some packets this way due to the > > time delay before and after each injection. Is this a known problem? Or am I > > doing something wrong? Maybe it could be some deadlock problem? It is no > > problem with retries this time, at least not obviously. But maybe the card > > just rejects to send out any further packets without having got a > > acknowledgment for the first one (which is ignored in monitor mode), even if > > retries are set to 0...? But then, it works after restarting the program for > > one more frame, so there must be a way to reset the card somehow. Any ideas? > > > > Thanks, Andy > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Airjack-user-devel mailing list > > Air...@li... > > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel > |
|
From: Abaddon <ab...@80...> - 2003-08-08 15:05:05
|
damn, I let that old __func__ bug creep its way back in...older versions of gcc let you get away with this (wrongfully), and I was lazy...I suppose I'll put up a v0.6.7 today, but first I'd like to look into the problems you're having sending the traffic...I assume its because I'm doing something crazy/wrong with my queues... I'm going to need a volunteer or two to help me test this out as almost all the places I sit down to code have lots and lots of traffic, so it always works for me...if you wanna help find me on aim as abaddon314159... --Abaddon On Fri, 2003-08-08 at 05:13, Andreas.Greulich@ISB.admin.ch wrote: > Thanks, 0.6.6 works great, no retry problem anymore! >=20 > Only one slight detail, I think there's a syntax error, at least my compi= ler > couldn't compile line 1288 of airjack.c, which was >=20 > printk(KERN_ERR "airjack_cs: " __func__ ": failed to set wep > flags.\n"); >=20 > and I thik should be >=20 > printk(KERN_ERR "airjack_cs: %s: failed to set wep flags.\n", > __func__); >=20 > At least that compiled for me :-) >=20 > Note that I found that I can only inject one packet while being in monito= r > mode. All further packet injections within the same process (stopping and > restarting the program allows one injection again) seem to be ignored (no > error message is given, but the packets don't appear on the WLAN). I have= to > clear monitor mode before each injection and set it again afterwards, the= n > it's working. Unfortunately I'm loosing some packets this way due to the > time delay before and after each injection. Is this a known problem? Or a= m I > doing something wrong? Maybe it could be some deadlock problem? It is no > problem with retries this time, at least not obviously. But maybe the car= d > just rejects to send out any further packets without having got a > acknowledgment for the first one (which is ignored in monitor mode), even= if > retries are set to 0...? But then, it works after restarting the program = for > one more frame, so there must be a way to reset the card somehow. Any ide= as? >=20 > Thanks, Andy >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Airjack-user-devel mailing list > Air...@li... > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel |
|
From: Rager, A. (Anton) <ar...@av...> - 2003-08-08 13:20:46
|
I found the same thing when there is only a small amount of 802.11 = traffic coming in at the same time. There are two reliable ways I found = to to deal with this: 1 - close the sock and reopen between injected frames [you will have 3-4 = secs between frames this way, so is real slow] 2 - ifconfig down aj0 will flush all the frames out the int [should be = able to down the int from the code as well?]. On a really busy network [defcon for example ;)] this doesn't seem to be = an issue, and the frames get sent out without the close or ifconfig down = stuff. My wepwedgie preso at defcon worked poorly in the lab/hotel, but = was great during the preso demo due to all the traffic at the con. BTW -- I finally got around to uploading the alpha wepwedgie code that = does shared-key-auth PRGA unrolling and WEPed IP injection with the = PRGA. Framework is there for a portscanner, but I still need to write = the responder code to automate the entire process and correlate the = results. see: sourceforge.net/projects/wepwedgie Anton Rager ar...@av... -----Original Message----- From: Andreas.Greulich@ISB.admin.ch [mailto:Andreas.Greulich@ISB.admin.ch] Sent: Friday, August 08, 2003 4:13 AM To: air...@li... Subject: [Airjack-user-devel] Airjack 0.6.6 and injection in monitor mode (Was: thousand of ret ries...) Thanks, 0.6.6 works great, no retry problem anymore! Only one slight detail, I think there's a syntax error, at least my = compiler couldn't compile line 1288 of airjack.c, which was printk(KERN_ERR "airjack_cs: " __func__ ": failed to set wep flags.\n"); and I thik should be printk(KERN_ERR "airjack_cs: %s: failed to set wep flags.\n", __func__); At least that compiled for me :-) Note that I found that I can only inject one packet while being in = monitor mode. All further packet injections within the same process (stopping = and restarting the program allows one injection again) seem to be ignored = (no error message is given, but the packets don't appear on the WLAN). I = have to clear monitor mode before each injection and set it again afterwards, = then it's working. Unfortunately I'm loosing some packets this way due to the time delay before and after each injection. Is this a known problem? Or = am I doing something wrong? Maybe it could be some deadlock problem? It is no problem with retries this time, at least not obviously. But maybe the = card just rejects to send out any further packets without having got a acknowledgment for the first one (which is ignored in monitor mode), = even if retries are set to 0...? But then, it works after restarting the program = for one more frame, so there must be a way to reset the card somehow. Any = ideas? Thanks, Andy ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Airjack-user-devel mailing list Air...@li... https://lists.sourceforge.net/lists/listinfo/airjack-user-devel |
|
From: Andreas.Greulich@ISB.admin.ch - 2003-08-08 10:17:19
|
Thanks, 0.6.6 works great, no retry problem anymore!
Only one slight detail, I think there's a syntax error, at least my compiler
couldn't compile line 1288 of airjack.c, which was
printk(KERN_ERR "airjack_cs: " __func__ ": failed to set wep
flags.\n");
and I thik should be
printk(KERN_ERR "airjack_cs: %s: failed to set wep flags.\n",
__func__);
At least that compiled for me :-)
Note that I found that I can only inject one packet while being in monitor
mode. All further packet injections within the same process (stopping and
restarting the program allows one injection again) seem to be ignored (no
error message is given, but the packets don't appear on the WLAN). I have to
clear monitor mode before each injection and set it again afterwards, then
it's working. Unfortunately I'm loosing some packets this way due to the
time delay before and after each injection. Is this a known problem? Or am I
doing something wrong? Maybe it could be some deadlock problem? It is no
problem with retries this time, at least not obviously. But maybe the card
just rejects to send out any further packets without having got a
acknowledgment for the first one (which is ignored in monitor mode), even if
retries are set to 0...? But then, it works after restarting the program for
one more frame, so there must be a way to reset the card somehow. Any ideas?
Thanks, Andy
|
|
From: Abaddon <ab...@80...> - 2003-08-07 14:50:59
|
thanks for testing that last fix for the retransmits problem, im posting v0.6.5-alpha to sf.net right now... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-08-07 14:45:39
|
done, also, I'm not too worried about that calculation, being that the
only cards AirJack-1 supports (to my knowledge) are 5V pcmcia cards, so
I should have been leaning toward that in the first place...thanks, I'm
going to put that on sourceforge right now...
--Abaddon
On Thu, 2003-08-07 at 08:43, Pawel Matusz wrote:
> Hi,
>=20
> I couldn't successfully run my Linksys WPC11 v3 card using the
> airjack driver. /var/log/messages reported:
>=20
> airjack_cs: RequestConfiguration: Bad Vcc
>=20
> The card has to have VCC set to 50 (5V) but the VCC calculation
> procedure in aj returned 41, so it was finally set to 33 (3.3V) which is
> incorrect for this card. I'd suggest a correction in airjack.c:
>=20
> Instead of
>=20
> if((link->conf.Vcc <=3D 55) && (link->conf.Vcc >=3D 45)) {
> link->conf.Vcc =3D 50;
> } else {
> link->conf.Vcc =3D 33;=20
> }
>=20
> (which is there twice, probably unnecessarily?) add something like:
>=20
> if (link->conf.Vcc>40 && conf.Vcc<51) link->conf.Vcc=3Dconf.Vcc;
>=20
> I'm not sure if this is 100% safe, maybe a calculation similar as in the
> wlan-ng driver (file prism2sta.c) would be better...
>=20
> Anyway, after such a correction Linksys is initialized correctly.
>=20
> Regards,
>=20
> Pawel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Airjack-user-devel mailing list
> Air...@li...
> https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
|
|
From: Abaddon <ab...@80...> - 2003-08-07 14:41:11
|
yeah, thats what the patch i posted yesterday did... ;)...that was the
third of the three ways to do it...
--Abaddon
On Thu, 2003-08-07 at 01:55, Andreas.Greulich@ISB.admin.ch wrote:
> Hi,
>=20
> Thanks for this very detailed information! Actually, meanwhile I foudn
> another way to solve the problem, namely to set the retry count to 0. I h=
ad
> to change airjack.c and airjack.h though to fit my needs, had also to che=
ck
> the hostap sources. It's a very messy hack, but maybe it's useful for oth=
ers
> (Pawel?), but I don't know if it works for all setups.
>=20
> In airjack.h, I added a line
>=20
> ---------
> #define HFA384X_RID_CNFALTRETRYCOUNT ((__u16)0xFC32)
> ---------
>=20
> (just behind the "#define HFA384X_RID_CNFMAXDATALEN ((__u16)0xFC07)" entr=
y,
> but it doesn't matter where exactly)
>=20
> and in airjack.c, within the airjack_ioctl function, just before the "/* =
set
> the channel */" comment (use teh search function, it is around line 985, =
but
> I had to change some #includes as well to make airjack work with SuSE Lin=
ux,
> so the line numbers are no longer precise), I added the short fragment (s=
ame
> pattern as setting the channel or mode, just without keeping information
> within ai as well):
>=20
> ---------
> rid.len =3D sizeof(rid)/2 - 1;
> rid.rid =3D HFA384X_RID_CNFALTRETRYCOUNT;
> rid.word =3D 0;
> if(hfa384x_write_rid(ai, HFA384X_RID_CNFALTRETRYCOUNT, &rid, sizeof(rid=
),
> HFA384X_BAP1) !=3D SUCCESS) {
> enable_mac(ai);
> local_irq_enable();
> printk(KERN_ERR "airjack_cs: %s: failed to set retry count.\n",
> __func__);
> return(-EIO);
> }
> ---------
>=20
> Now you only need to make sure to call the SIOCAJSMODE ioctl at least onc=
e
> (for example by setting the channel), and it will also set the retry coun=
t
> to 0 (of course it is always 0 now, I didn't extend the API for this
> purpose... for my project I don't need retries at all :-). at least in my
> case, this seems to do the job.
>=20
> I hope it was ok I changed this and described it here.. I know one should
> not change others code, but the changes are really minimal and could help
> one or another until the new version comes out. And of course I don't knw=
o
> if this might break in one or another case...
>=20
> Andy
>=20
> PS: I noticed that in the tc_tx_ctl field, you already set bit 5 (which
> hostap seems to use as indication to use the alternatice retry count), us=
ing
> the macro "HFA384X_TX_RETRYSTRAT_SET(3)". But latter also sets bit 6, and=
I
> couldn't find any information in the hostap sources what bit 6 is used fo=
r
> (and I have no other docs)... is there some specific reason you used (3) =
and
> not (1)? Well, (3) works fine, just curious *g*
|
|
From: Pawel M. <pm...@et...> - 2003-08-07 13:43:49
|
Hi,
I couldn't successfully run my Linksys WPC11 v3 card using the
airjack driver. /var/log/messages reported:
airjack_cs: RequestConfiguration: Bad Vcc
The card has to have VCC set to 50 (5V) but the VCC calculation
procedure in aj returned 41, so it was finally set to 33 (3.3V) which is
incorrect for this card. I'd suggest a correction in airjack.c:
Instead of
if((link->conf.Vcc <= 55) && (link->conf.Vcc >= 45)) {
link->conf.Vcc = 50;
} else {
link->conf.Vcc = 33;
}
(which is there twice, probably unnecessarily?) add something like:
if (link->conf.Vcc>40 && conf.Vcc<51) link->conf.Vcc=conf.Vcc;
I'm not sure if this is 100% safe, maybe a calculation similar as in the
wlan-ng driver (file prism2sta.c) would be better...
Anyway, after such a correction Linksys is initialized correctly.
Regards,
Pawel
|
|
From: Pawel M. <pm...@et...> - 2003-08-07 13:41:39
|
I've checked the patch (actually v0.6.5-alpha) on my SMC2632W and Linksys WPC11 v3 and it seems to work fine! No more unnecessary retransmits. Pawel -----Original Message----- From: Abaddon [mailto:ab...@80...] Sent: Wednesday, August 06, 2003 6:50 PM To: Pawel Matusz Cc: airjack-user-devel Subject: Re: [Airjack-user-devel] Packet injection: thousands of retriessent as well (Retry bit se t in 802.11 frame)? >attached is a patch from v0.6.4-alpha to what will probably be >v0.6.5-alpha if it works, it _should_ fix this version on some firmware >versions, problem is i dont know what versions it works on (if any), so >can I get you guys to try this out at some point, load the new version, >put the card in monitor mode, then try to transmit, see if you get >retries, and see if you get as many retries... >post results to the list if you would...thanks... >to apply the patch cd into the airjack v0.6.4-alpha dir and run this >command: >gunzip airjack-v0.6.4-alpha-testing.patch.gz >patch -p1 <airjack-v0.6.4-alpha-testing.patch >then rebuild and reinstall airjack, restart card services then send some >traffic in monitor mode... >thanks...stuff like this is easiest to resolve in aj-1 because its only >going to come up again in aj-2 otherwise... >--Abaddon |
|
From: Andreas.Greulich@ISB.admin.ch - 2003-08-07 06:59:08
|
Hi,
Thanks for this very detailed information! Actually, meanwhile I foudn
another way to solve the problem, namely to set the retry count to 0. I had
to change airjack.c and airjack.h though to fit my needs, had also to check
the hostap sources. It's a very messy hack, but maybe it's useful for others
(Pawel?), but I don't know if it works for all setups.
In airjack.h, I added a line
---------
#define HFA384X_RID_CNFALTRETRYCOUNT ((__u16)0xFC32)
---------
(just behind the "#define HFA384X_RID_CNFMAXDATALEN ((__u16)0xFC07)" entry,
but it doesn't matter where exactly)
and in airjack.c, within the airjack_ioctl function, just before the "/* set
the channel */" comment (use teh search function, it is around line 985, but
I had to change some #includes as well to make airjack work with SuSE Linux,
so the line numbers are no longer precise), I added the short fragment (same
pattern as setting the channel or mode, just without keeping information
within ai as well):
---------
rid.len = sizeof(rid)/2 - 1;
rid.rid = HFA384X_RID_CNFALTRETRYCOUNT;
rid.word = 0;
if(hfa384x_write_rid(ai, HFA384X_RID_CNFALTRETRYCOUNT, &rid, sizeof(rid),
HFA384X_BAP1) != SUCCESS) {
enable_mac(ai);
local_irq_enable();
printk(KERN_ERR "airjack_cs: %s: failed to set retry count.\n",
__func__);
return(-EIO);
}
---------
Now you only need to make sure to call the SIOCAJSMODE ioctl at least once
(for example by setting the channel), and it will also set the retry count
to 0 (of course it is always 0 now, I didn't extend the API for this
purpose... for my project I don't need retries at all :-). at least in my
case, this seems to do the job.
I hope it was ok I changed this and described it here.. I know one should
not change others code, but the changes are really minimal and could help
one or another until the new version comes out. And of course I don't knwo
if this might break in one or another case...
Andy
PS: I noticed that in the tc_tx_ctl field, you already set bit 5 (which
hostap seems to use as indication to use the alternatice retry count), using
the macro "HFA384X_TX_RETRYSTRAT_SET(3)". But latter also sets bit 6, and I
couldn't find any information in the hostap sources what bit 6 is used for
(and I have no other docs)... is there some specific reason you used (3) and
not (1)? Well, (3) works fine, just curious *g*
|
|
From: Abaddon <ab...@80...> - 2003-08-06 20:20:34
|
attached is a patch from v0.6.4-alpha to what will probably be
v0.6.5-alpha if it works, it _should_ fix this version on some firmware
versions, problem is i dont know what versions it works on (if any), so
can I get you guys to try this out at some point, load the new version,
put the card in monitor mode, then try to transmit, see if you get
retries, and see if you get as many retries...
post results to the list if you would...thanks...
to apply the patch cd into the airjack v0.6.4-alpha dir and run this
command:
gunzip airjack-v0.6.4-alpha-testing.patch.gz
patch -p1 <airjack-v0.6.4-alpha-testing.patch
then rebuild and reinstall airjack, restart card services then send some
traffic in monitor mode...
thanks...stuff like this is easiest to resolve in aj-1 because its only
going to come up again in aj-2 otherwise...
--Abaddon
On Wed, 2003-08-06 at 09:45, Pawel Matusz wrote:
> Hi,
>
> I'm in a need for such a fix (setting the retry counter to 0). I'm
> developing a tool to test wireless devices and need to have comlete
> control over what is received (i.e. receive all frames) and what is sent
> (I cannot send "extra" beacons as in mode 6). Airjack is really _great_
> for what I need to do, if only the retransmit problem would be fixed.
>
> What card did you use, the one on which changing the RID worked? I have an
> SMC2632W and Linksys WPC11v3.
>
> Have your morning coffee first :)
>
> Regards,
>
> Pawel
>
> On 6 Aug 2003, Abaddon wrote:
>
> > well you're half correct about why its happening...that is, the control
> > frames are not getting to the part of the firmware that determines if it
> > was a successful transmit or if it needs to send a retry...it misses it
> > because you're in monitor mode...at this point there are some choices on
> > how to fix this, each with different disadvantages...
> >
> > first thing you can do, which is the easiest and if compatible with what
> > you're trying to do, its the safest (from a card stability
> > standpoint)...take the card out of monitor mode and put it into mode
> > 5...this is some sort of debug mode as best i can tell, it will not send
> > out beacons in this mode but you can still choose the channel you are
> > associated to, you can also receive a large amount of the traffic you
> > would otherwise have to be in monitor mode to get...try and see if mode
> > 5 with monitor mode turned off works for you...
> >
> > if mode 5 doesn't work for you (that is to say if you cant receive the
> > traffic you're looking for in mode 5 with monitor mode off), then try
> > mode 6 no monitor mode, there is a side effect in mode 6 that the card
> > is now in hostap mode and will send out beacons (probably with essid of
> > "airjack")...
> >
> > if even that doesn't work for you, here is what you're going to have to
> > do, and millage will vary with firmware versions and the alignment of
> > the planets and all that...ok, you're going to go to mode 5, but turn
> > _on_ monitor mode...now in monitor mode (as best i know) there is
> > nothing you can do to tell the card that the control frames have been
> > sent to you, and thus the frame got through...so you're going to have to
> > ignore the error, and make the card ignore it...to do this there is an
> > RID (thats fancy wireless driver developer speak for config parameter on
> > the card) that will tell you how many retries to send before declaring
> > it a lost cause (which it really isn't, but it will think it didn't get
> > through)...unfortunately ive not had coffee yet this morning, so i dont
> > remember the RID, ill go look back at my notes and see what it is for
> > you, and if the first two things don't work out then post again to the
> > list for me and I'll release a version with a fix to the retry
> > thing...however even with that some cards/firmware versions I've found
> > send some retries anyways...
> >
> > --Abaddon
> >
> >
> > On Wed, 2003-08-06 at 08:45, Andreas.Greulich@ISB.admin.ch wrote:
> > > Hi all,
> > >
> > > I just started playing around with frame injection using Airjack and
> > > basically it's working (actually the first time I managed to inject frames
> > > on a WLAN, thanks for the great program!). However I got a weird problem: my
> > > card (or airjack itself?) is sending out the same injected frames several
> > > thousand times, all but the first frames got re Retry bit set! Actually the
> > > PC is frozen for a few seconds due to this. To be more precise: Laptop1 is
> > > associated to an AP which interconnects to an Ethernet. On the Ethernet
> > > there's a target PC. Laptop2 is trying to inject an IP packet, forging
> > > source MAC of Laptop1 and directed to the PC (idea behind: trying to "ride"
> > > on an associated station). I use the following data to inject:
> > >
> > > 08 01 02 01 00 05 5d f1 e2 cf 00 02 2d 50 aa 1a
> > > 00 01 02 b7 12 04 00 00 aa aa 03 00 00 00 08 00
> > > 45 00 00 18 12 34 00 00 80 3c 89 56 c0 a8 0e eb
> > > c0 a8 0e e4 74 65 73 74 00 00 00 00
> > >
> > > human readable:
> > > data frame, data subtype, To-DS (08 01),
> > > BSSID 0:5:5d:f1:e2:cf (MAC of AP),
> > > source 0:2:2d:50:aa:1a (MAC of Laptop1)
> > > dest 0:1:2:b7:12:04 (MAC of PC on Ethernet)
> > > seq-# 0000
> > > SNAP-hdr for IP (aa aa 03 00 00 00 08 00)
> > > IP-packet from 192.168.14.235 (Laptop1) to 192.168.14.228 (PC), protocol
> > > 60, containing payload "test"
> > >
> > > If I use a third laptop sniffing on the WLAN interface (using hostap), I get
> > > the following tcpdump output ("tcpdump -XX -v -e -i wlan0"):
> > >
> > > 14:58:50.642583 Retry BSSID:00:05:5d:f1:e2:cf SA:00:02:2d:50:aa:1a
> > > DA:00:01:02:b7:12:04 LLC, dsap 0xaa, ssap 0xaa, cmd 0x03,
> > > snap ip IP (tos 0x0, ttl 128, id 4660, offset 0, flags [none], length: 24)
> > >
> > > 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> > > 0x0000 0809 0201 0005 5df1 e2cf 0002 2d50 aa1a ......].....-P..
> > > 0x0010 0001 02b7 1204 c000 aaaa 0300 0000 0800 ................
> > > 0x0020 4500 0018 1234 0000 803c 8956 c0a8 0eeb E....4...<.V....
> > > 0x0030 c0a8 0ee4 7465 7374 0000 0000 ....test....
> > > This packet is seen several thousand times within a second! Note that the
> > > only differences to the original frames are the sequence number (which, as I
> > > understand, can't be faked because of firmware limitations), and the Retry
> > > bit (0809 instead of 0801). Actually the 0801-version appears on the WLAN as
> > > well, but tcpdump often looses this one because the WLAN is overloaded (at
> > > least that's my interpretation).
> > >
> > > The basic thing is working though (so I don't think it's a problem with the
> > > frame structure): after injection, I can actually see the frame on the
> > > Ethernet ("tcpdump -XX -e" on PC):
> > > 15:15:47.397285 00:02:2d:50:aa:1a > 00:01:02:b7:12:04, ethertype IPv4,
> > > length 1514: IP 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> > > 0x0000 0001 02b7 1204 0002 2d50 aa1a 0800 4500 ........-P....E.
> > > 0x0010 0018 1234 0000 803c 8956 c0a8 0eeb c0a8 ...4...<.V......
> > > 0x0020 0ee4 7465 7374 0000 0000 0000 0000 0000 ..test..........
> > > 0x0030 0000 0000 0000 0000 0000 0000 cf53 1539 .............S.9
> > > 0x0040 38be 2079 4e90 4be7 f10a 1dd6 432f f7d8 8..yN.K.....C/..
> > > 0x0050 9b5b 131a 0b4b 326e 9c5b 7cdd 8a57 de05 .[...K2n.[|..W..
> > > Actually, it even appears twice - probably due to the retry-problem. So the
> > > AP was actually bridging the packet as planned.
> > >
> > > To my setup:
> > > - SuSE Linux 8.2 (2.4.20-4GB)
> > > - Airjack 0.6.3 Alpha (is there a newer version available somewhere?)
> > > - D-Link DWL-650 for injection (Prism2 chipset, "Link DWL-650 11Mbps WLAN
> > > Card" version 01.02)
> > >
> > > Main structure of the program:
> > > - initialize socket as in essid_jack.c
> > > - set monitor mode and channel
> > > - write(sockfd,&frame,len) with the above data (which I actually constructed
> > > using libnet)
> > >
> > > Note that I was using a3_80211 as header for data-packets, not a4_80211. I
> > > can post the full program if this is of interest or help.
> > >
> > > I also had the idea the problem might be that the card is not seeing the
> > > acknowledge control frames (the ones starting with "d400 0000") from the AP
> > > because these are directed to the faked MAC address instead of the "real"
> > > MAC address of the card. But even if I try to use the "correct" MAC-address
> > > as source address, I get this effect (plus the packet is not seen on the LAN
> > > segment because the station is not associated).
> > >
> > > Thanks in advance if anyone can help me, and sorry if this is a dumb
> > > question... :-)
> > >
> > > Andy
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > > Data Reports, E-commerce, Portals, and Forums are available now.
> > > Download today and enter to win an XBOX or Visual Studio .NET.
> > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > > _______________________________________________
> > > Airjack-user-devel mailing list
> > > Air...@li...
> > > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Airjack-user-devel mailing list
> Air...@li...
> https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
|
|
From: Abaddon <ab...@80...> - 2003-08-06 20:04:52
|
on a side note, I don't suppose any of you know of any tricks to getting the Microsoft development tool, especially driver development tools (the DDK and all that jazz) without paying them for them (or much)...does that DDK thats cheap come with a compiler for windows?... any Microsoft gurus in our midst?...the windows port is still a long ways off...I'm going to have everything else working before I open that can of worms, but I'd like to get started on know more of what I'm doing on windows (which is to say, know anything at all about windows)... so any pointers in that area would be greatly appreciated... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-08-06 14:57:17
|
I've used old linksys cards and my old belkin cards, but i think its a
firmware issue when it doesnt work...
let me check to see which RID it was and ill add that in the cards
initial config and post the patch (and put a new version on the site)...
--Abaddon
p.s. morning sucks...
On Wed, 2003-08-06 at 09:45, Pawel Matusz wrote:
> Hi,
>=20
> I'm in a need for such a fix (setting the retry counter to 0). I'm
> developing a tool to test wireless devices and need to have comlete
> control over what is received (i.e. receive all frames) and what is sent
> (I cannot send "extra" beacons as in mode 6). Airjack is really _great_
> for what I need to do, if only the retransmit problem would be fixed.
>=20
> What card did you use, the one on which changing the RID worked? I have a=
n
> SMC2632W and Linksys WPC11v3.
>=20
> Have your morning coffee first :)
>=20
> Regards,
>=20
> Pawel
>=20
> On 6 Aug 2003, Abaddon wrote:
>=20
> > well you're half correct about why its happening...that is, the control
> > frames are not getting to the part of the firmware that determines if i=
t
> > was a successful transmit or if it needs to send a retry...it misses it
> > because you're in monitor mode...at this point there are some choices o=
n
> > how to fix this, each with different disadvantages...
> >=20
> > first thing you can do, which is the easiest and if compatible with wha=
t
> > you're trying to do, its the safest (from a card stability
> > standpoint)...take the card out of monitor mode and put it into mode
> > 5...this is some sort of debug mode as best i can tell, it will not sen=
d
> > out beacons in this mode but you can still choose the channel you are
> > associated to, you can also receive a large amount of the traffic you
> > would otherwise have to be in monitor mode to get...try and see if mode
> > 5 with monitor mode turned off works for you...
> >=20
> > if mode 5 doesn't work for you (that is to say if you cant receive the
> > traffic you're looking for in mode 5 with monitor mode off), then try
> > mode 6 no monitor mode, there is a side effect in mode 6 that the card
> > is now in hostap mode and will send out beacons (probably with essid of
> > "airjack")...
> >=20
> > if even that doesn't work for you, here is what you're going to have to
> > do, and millage will vary with firmware versions and the alignment of
> > the planets and all that...ok, you're going to go to mode 5, but turn
> > _on_ monitor mode...now in monitor mode (as best i know) there is
> > nothing you can do to tell the card that the control frames have been
> > sent to you, and thus the frame got through...so you're going to have t=
o
> > ignore the error, and make the card ignore it...to do this there is an
> > RID (thats fancy wireless driver developer speak for config parameter o=
n
> > the card) that will tell you how many retries to send before declaring
> > it a lost cause (which it really isn't, but it will think it didn't get
> > through)...unfortunately ive not had coffee yet this morning, so i dont
> > remember the RID, ill go look back at my notes and see what it is for
> > you, and if the first two things don't work out then post again to the
> > list for me and I'll release a version with a fix to the retry
> > thing...however even with that some cards/firmware versions I've found
> > send some retries anyways...
> >=20
> > --Abaddon
> >=20
> >=20
> > On Wed, 2003-08-06 at 08:45, Andreas.Greulich@ISB.admin.ch wrote:
> > > Hi all,
> > >=20
> > > I just started playing around with frame injection using Airjack and
> > > basically it's working (actually the first time I managed to inject f=
rames
> > > on a WLAN, thanks for the great program!). However I got a weird prob=
lem: my
> > > card (or airjack itself?) is sending out the same injected frames sev=
eral
> > > thousand times, all but the first frames got re Retry bit set! Actual=
ly the
> > > PC is frozen for a few seconds due to this. To be more precise: Lapto=
p1 is
> > > associated to an AP which interconnects to an Ethernet. On the Ethern=
et
> > > there's a target PC. Laptop2 is trying to inject an IP packet, forgin=
g
> > > source MAC of Laptop1 and directed to the PC (idea behind: trying to =
"ride"
> > > on an associated station). I use the following data to inject:
> > >=20
> > > 08 01 02 01 00 05 5d f1 e2 cf 00 02 2d 50 aa 1a=20
> > > 00 01 02 b7 12 04 00 00 aa aa 03 00 00 00 08 00=20
> > > 45 00 00 18 12 34 00 00 80 3c 89 56 c0 a8 0e eb=20
> > > c0 a8 0e e4 74 65 73 74 00 00 00 00=20
> > >=20
> > > human readable:
> > > data frame, data subtype, To-DS (08 01),
> > > BSSID 0:5:5d:f1:e2:cf (MAC of AP),=20
> > > source 0:2:2d:50:aa:1a (MAC of Laptop1)
> > > dest 0:1:2:b7:12:04 (MAC of PC on Ethernet)
> > > seq-# 0000
> > > SNAP-hdr for IP (aa aa 03 00 00 00 08 00)
> > > IP-packet from 192.168.14.235 (Laptop1) to 192.168.14.228 (PC), pro=
tocol
> > > 60, containing payload "test"
> > >=20
> > > If I use a third laptop sniffing on the WLAN interface (using hostap)=
, I get
> > > the following tcpdump output ("tcpdump -XX -v -e -i wlan0"):
> > >=20
> > > 14:58:50.642583 Retry BSSID:00:05:5d:f1:e2:cf SA:00:02:2d:50:aa:1a=20
> > > DA:00:01:02:b7:12:04 LLC, dsap 0xaa, ssap 0xaa, cmd 0x03,=20
> > > snap ip IP (tos 0x0, ttl 128, id 4660, offset 0, flags [none], leng=
th: 24)
> > >=20
> > > 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> > > 0x0000 0809 0201 0005 5df1 e2cf 0002 2d50 aa1a ......]....=
.-P..
> > > 0x0010 0001 02b7 1204 c000 aaaa 0300 0000 0800 ...........=
.....
> > > 0x0020 4500 0018 1234 0000 803c 8956 c0a8 0eeb E....4...<.=
V....
> > > 0x0030 c0a8 0ee4 7465 7374 0000 0000 ....test...=
.
> > > This packet is seen several thousand times within a second! Note that=
the
> > > only differences to the original frames are the sequence number (whic=
h, as I
> > > understand, can't be faked because of firmware limitations), and the =
Retry
> > > bit (0809 instead of 0801). Actually the 0801-version appears on the =
WLAN as
> > > well, but tcpdump often looses this one because the WLAN is overloade=
d (at
> > > least that's my interpretation).=20
> > >=20
> > > The basic thing is working though (so I don't think it's a problem wi=
th the
> > > frame structure): after injection, I can actually see the frame on th=
e
> > > Ethernet ("tcpdump -XX -e" on PC):
> > > 15:15:47.397285 00:02:2d:50:aa:1a > 00:01:02:b7:12:04, ethertype IP=
v4,=20
> > > length 1514: IP 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> > > 0x0000 0001 02b7 1204 0002 2d50 aa1a 0800 4500 ........-P.=
...E.
> > > 0x0010 0018 1234 0000 803c 8956 c0a8 0eeb c0a8 ...4...<.V.=
.....
> > > 0x0020 0ee4 7465 7374 0000 0000 0000 0000 0000 ..test.....=
.....
> > > 0x0030 0000 0000 0000 0000 0000 0000 cf53 1539 ...........=
..S.9
> > > 0x0040 38be 2079 4e90 4be7 f10a 1dd6 432f f7d8 8..yN.K....=
.C/..
> > > 0x0050 9b5b 131a 0b4b 326e 9c5b 7cdd 8a57 de05 .[...K2n.[|=
..W..
> > > Actually, it even appears twice - probably due to the retry-problem. =
So the
> > > AP was actually bridging the packet as planned.
> > >=20
> > > To my setup:
> > > - SuSE Linux 8.2 (2.4.20-4GB)
> > > - Airjack 0.6.3 Alpha (is there a newer version available somewhere?)
> > > - D-Link DWL-650 for injection (Prism2 chipset, "Link DWL-650 11Mbps =
WLAN
> > > Card" version 01.02)
> > >=20
> > > Main structure of the program:
> > > - initialize socket as in essid_jack.c
> > > - set monitor mode and channel
> > > - write(sockfd,&frame,len) with the above data (which I actually cons=
tructed
> > > using libnet)
> > >=20
> > > Note that I was using a3_80211 as header for data-packets, not a4_802=
11. I
> > > can post the full program if this is of interest or help.
> > >=20
> > > I also had the idea the problem might be that the card is not seeing =
the
> > > acknowledge control frames (the ones starting with "d400 0000") from =
the AP
> > > because these are directed to the faked MAC address instead of the "r=
eal"
> > > MAC address of the card. But even if I try to use the "correct" MAC-a=
ddress
> > > as source address, I get this effect (plus the packet is not seen on =
the LAN
> > > segment because the station is not associated).
> > >=20
> > > Thanks in advance if anyone can help me, and sorry if this is a dumb
> > > question... :-)
> > >=20
> > > Andy
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Free pre-built ASP.NET sites includin=
g
> > > Data Reports, E-commerce, Portals, and Forums are available now.
> > > Download today and enter to win an XBOX or Visual Studio .NET.
> > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303=
_01/01
> > > _______________________________________________
> > > Airjack-user-devel mailing list
> > > Air...@li...
> > > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Airjack-user-devel mailing list
> Air...@li...
> https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
|
|
From: Pawel M. <pm...@et...> - 2003-08-06 14:45:54
|
Hi,
I'm in a need for such a fix (setting the retry counter to 0). I'm
developing a tool to test wireless devices and need to have comlete
control over what is received (i.e. receive all frames) and what is sent
(I cannot send "extra" beacons as in mode 6). Airjack is really _great_
for what I need to do, if only the retransmit problem would be fixed.
What card did you use, the one on which changing the RID worked? I have an
SMC2632W and Linksys WPC11v3.
Have your morning coffee first :)
Regards,
Pawel
On 6 Aug 2003, Abaddon wrote:
> well you're half correct about why its happening...that is, the control
> frames are not getting to the part of the firmware that determines if it
> was a successful transmit or if it needs to send a retry...it misses it
> because you're in monitor mode...at this point there are some choices on
> how to fix this, each with different disadvantages...
>
> first thing you can do, which is the easiest and if compatible with what
> you're trying to do, its the safest (from a card stability
> standpoint)...take the card out of monitor mode and put it into mode
> 5...this is some sort of debug mode as best i can tell, it will not send
> out beacons in this mode but you can still choose the channel you are
> associated to, you can also receive a large amount of the traffic you
> would otherwise have to be in monitor mode to get...try and see if mode
> 5 with monitor mode turned off works for you...
>
> if mode 5 doesn't work for you (that is to say if you cant receive the
> traffic you're looking for in mode 5 with monitor mode off), then try
> mode 6 no monitor mode, there is a side effect in mode 6 that the card
> is now in hostap mode and will send out beacons (probably with essid of
> "airjack")...
>
> if even that doesn't work for you, here is what you're going to have to
> do, and millage will vary with firmware versions and the alignment of
> the planets and all that...ok, you're going to go to mode 5, but turn
> _on_ monitor mode...now in monitor mode (as best i know) there is
> nothing you can do to tell the card that the control frames have been
> sent to you, and thus the frame got through...so you're going to have to
> ignore the error, and make the card ignore it...to do this there is an
> RID (thats fancy wireless driver developer speak for config parameter on
> the card) that will tell you how many retries to send before declaring
> it a lost cause (which it really isn't, but it will think it didn't get
> through)...unfortunately ive not had coffee yet this morning, so i dont
> remember the RID, ill go look back at my notes and see what it is for
> you, and if the first two things don't work out then post again to the
> list for me and I'll release a version with a fix to the retry
> thing...however even with that some cards/firmware versions I've found
> send some retries anyways...
>
> --Abaddon
>
>
> On Wed, 2003-08-06 at 08:45, Andreas.Greulich@ISB.admin.ch wrote:
> > Hi all,
> >
> > I just started playing around with frame injection using Airjack and
> > basically it's working (actually the first time I managed to inject frames
> > on a WLAN, thanks for the great program!). However I got a weird problem: my
> > card (or airjack itself?) is sending out the same injected frames several
> > thousand times, all but the first frames got re Retry bit set! Actually the
> > PC is frozen for a few seconds due to this. To be more precise: Laptop1 is
> > associated to an AP which interconnects to an Ethernet. On the Ethernet
> > there's a target PC. Laptop2 is trying to inject an IP packet, forging
> > source MAC of Laptop1 and directed to the PC (idea behind: trying to "ride"
> > on an associated station). I use the following data to inject:
> >
> > 08 01 02 01 00 05 5d f1 e2 cf 00 02 2d 50 aa 1a
> > 00 01 02 b7 12 04 00 00 aa aa 03 00 00 00 08 00
> > 45 00 00 18 12 34 00 00 80 3c 89 56 c0 a8 0e eb
> > c0 a8 0e e4 74 65 73 74 00 00 00 00
> >
> > human readable:
> > data frame, data subtype, To-DS (08 01),
> > BSSID 0:5:5d:f1:e2:cf (MAC of AP),
> > source 0:2:2d:50:aa:1a (MAC of Laptop1)
> > dest 0:1:2:b7:12:04 (MAC of PC on Ethernet)
> > seq-# 0000
> > SNAP-hdr for IP (aa aa 03 00 00 00 08 00)
> > IP-packet from 192.168.14.235 (Laptop1) to 192.168.14.228 (PC), protocol
> > 60, containing payload "test"
> >
> > If I use a third laptop sniffing on the WLAN interface (using hostap), I get
> > the following tcpdump output ("tcpdump -XX -v -e -i wlan0"):
> >
> > 14:58:50.642583 Retry BSSID:00:05:5d:f1:e2:cf SA:00:02:2d:50:aa:1a
> > DA:00:01:02:b7:12:04 LLC, dsap 0xaa, ssap 0xaa, cmd 0x03,
> > snap ip IP (tos 0x0, ttl 128, id 4660, offset 0, flags [none], length: 24)
> >
> > 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> > 0x0000 0809 0201 0005 5df1 e2cf 0002 2d50 aa1a ......].....-P..
> > 0x0010 0001 02b7 1204 c000 aaaa 0300 0000 0800 ................
> > 0x0020 4500 0018 1234 0000 803c 8956 c0a8 0eeb E....4...<.V....
> > 0x0030 c0a8 0ee4 7465 7374 0000 0000 ....test....
> > This packet is seen several thousand times within a second! Note that the
> > only differences to the original frames are the sequence number (which, as I
> > understand, can't be faked because of firmware limitations), and the Retry
> > bit (0809 instead of 0801). Actually the 0801-version appears on the WLAN as
> > well, but tcpdump often looses this one because the WLAN is overloaded (at
> > least that's my interpretation).
> >
> > The basic thing is working though (so I don't think it's a problem with the
> > frame structure): after injection, I can actually see the frame on the
> > Ethernet ("tcpdump -XX -e" on PC):
> > 15:15:47.397285 00:02:2d:50:aa:1a > 00:01:02:b7:12:04, ethertype IPv4,
> > length 1514: IP 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> > 0x0000 0001 02b7 1204 0002 2d50 aa1a 0800 4500 ........-P....E.
> > 0x0010 0018 1234 0000 803c 8956 c0a8 0eeb c0a8 ...4...<.V......
> > 0x0020 0ee4 7465 7374 0000 0000 0000 0000 0000 ..test..........
> > 0x0030 0000 0000 0000 0000 0000 0000 cf53 1539 .............S.9
> > 0x0040 38be 2079 4e90 4be7 f10a 1dd6 432f f7d8 8..yN.K.....C/..
> > 0x0050 9b5b 131a 0b4b 326e 9c5b 7cdd 8a57 de05 .[...K2n.[|..W..
> > Actually, it even appears twice - probably due to the retry-problem. So the
> > AP was actually bridging the packet as planned.
> >
> > To my setup:
> > - SuSE Linux 8.2 (2.4.20-4GB)
> > - Airjack 0.6.3 Alpha (is there a newer version available somewhere?)
> > - D-Link DWL-650 for injection (Prism2 chipset, "Link DWL-650 11Mbps WLAN
> > Card" version 01.02)
> >
> > Main structure of the program:
> > - initialize socket as in essid_jack.c
> > - set monitor mode and channel
> > - write(sockfd,&frame,len) with the above data (which I actually constructed
> > using libnet)
> >
> > Note that I was using a3_80211 as header for data-packets, not a4_80211. I
> > can post the full program if this is of interest or help.
> >
> > I also had the idea the problem might be that the card is not seeing the
> > acknowledge control frames (the ones starting with "d400 0000") from the AP
> > because these are directed to the faked MAC address instead of the "real"
> > MAC address of the card. But even if I try to use the "correct" MAC-address
> > as source address, I get this effect (plus the packet is not seen on the LAN
> > segment because the station is not associated).
> >
> > Thanks in advance if anyone can help me, and sorry if this is a dumb
> > question... :-)
> >
> > Andy
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Airjack-user-devel mailing list
> > Air...@li...
> > https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
>
|
|
From: Abaddon <ab...@80...> - 2003-08-06 14:15:17
|
well you're half correct about why its happening...that is, the control
frames are not getting to the part of the firmware that determines if it
was a successful transmit or if it needs to send a retry...it misses it
because you're in monitor mode...at this point there are some choices on
how to fix this, each with different disadvantages...
first thing you can do, which is the easiest and if compatible with what
you're trying to do, its the safest (from a card stability
standpoint)...take the card out of monitor mode and put it into mode
5...this is some sort of debug mode as best i can tell, it will not send
out beacons in this mode but you can still choose the channel you are
associated to, you can also receive a large amount of the traffic you
would otherwise have to be in monitor mode to get...try and see if mode
5 with monitor mode turned off works for you...
if mode 5 doesn't work for you (that is to say if you cant receive the
traffic you're looking for in mode 5 with monitor mode off), then try
mode 6 no monitor mode, there is a side effect in mode 6 that the card
is now in hostap mode and will send out beacons (probably with essid of
"airjack")...
if even that doesn't work for you, here is what you're going to have to
do, and millage will vary with firmware versions and the alignment of
the planets and all that...ok, you're going to go to mode 5, but turn
_on_ monitor mode...now in monitor mode (as best i know) there is
nothing you can do to tell the card that the control frames have been
sent to you, and thus the frame got through...so you're going to have to
ignore the error, and make the card ignore it...to do this there is an
RID (thats fancy wireless driver developer speak for config parameter on
the card) that will tell you how many retries to send before declaring
it a lost cause (which it really isn't, but it will think it didn't get
through)...unfortunately ive not had coffee yet this morning, so i dont
remember the RID, ill go look back at my notes and see what it is for
you, and if the first two things don't work out then post again to the
list for me and I'll release a version with a fix to the retry
thing...however even with that some cards/firmware versions I've found
send some retries anyways...
--Abaddon
On Wed, 2003-08-06 at 08:45, Andreas.Greulich@ISB.admin.ch wrote:
> Hi all,
>=20
> I just started playing around with frame injection using Airjack and
> basically it's working (actually the first time I managed to inject frame=
s
> on a WLAN, thanks for the great program!). However I got a weird problem:=
my
> card (or airjack itself?) is sending out the same injected frames several
> thousand times, all but the first frames got re Retry bit set! Actually t=
he
> PC is frozen for a few seconds due to this. To be more precise: Laptop1 i=
s
> associated to an AP which interconnects to an Ethernet. On the Ethernet
> there's a target PC. Laptop2 is trying to inject an IP packet, forging
> source MAC of Laptop1 and directed to the PC (idea behind: trying to "rid=
e"
> on an associated station). I use the following data to inject:
>=20
> 08 01 02 01 00 05 5d f1 e2 cf 00 02 2d 50 aa 1a=20
> 00 01 02 b7 12 04 00 00 aa aa 03 00 00 00 08 00=20
> 45 00 00 18 12 34 00 00 80 3c 89 56 c0 a8 0e eb=20
> c0 a8 0e e4 74 65 73 74 00 00 00 00=20
>=20
> human readable:
> data frame, data subtype, To-DS (08 01),
> BSSID 0:5:5d:f1:e2:cf (MAC of AP),=20
> source 0:2:2d:50:aa:1a (MAC of Laptop1)
> dest 0:1:2:b7:12:04 (MAC of PC on Ethernet)
> seq-# 0000
> SNAP-hdr for IP (aa aa 03 00 00 00 08 00)
> IP-packet from 192.168.14.235 (Laptop1) to 192.168.14.228 (PC), protoco=
l
> 60, containing payload "test"
>=20
> If I use a third laptop sniffing on the WLAN interface (using hostap), I =
get
> the following tcpdump output ("tcpdump -XX -v -e -i wlan0"):
>=20
> 14:58:50.642583 Retry BSSID:00:05:5d:f1:e2:cf SA:00:02:2d:50:aa:1a=20
> DA:00:01:02:b7:12:04 LLC, dsap 0xaa, ssap 0xaa, cmd 0x03,=20
> snap ip IP (tos 0x0, ttl 128, id 4660, offset 0, flags [none], length: =
24)
>=20
> 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> 0x0000 0809 0201 0005 5df1 e2cf 0002 2d50 aa1a ......].....-P.=
.
> 0x0010 0001 02b7 1204 c000 aaaa 0300 0000 0800 ...............=
.
> 0x0020 4500 0018 1234 0000 803c 8956 c0a8 0eeb E....4...<.V...=
.
> 0x0030 c0a8 0ee4 7465 7374 0000 0000 ....test....
> This packet is seen several thousand times within a second! Note that the
> only differences to the original frames are the sequence number (which, a=
s I
> understand, can't be faked because of firmware limitations), and the Retr=
y
> bit (0809 instead of 0801). Actually the 0801-version appears on the WLAN=
as
> well, but tcpdump often looses this one because the WLAN is overloaded (a=
t
> least that's my interpretation).=20
>=20
> The basic thing is working though (so I don't think it's a problem with t=
he
> frame structure): after injection, I can actually see the frame on the
> Ethernet ("tcpdump -XX -e" on PC):
> 15:15:47.397285 00:02:2d:50:aa:1a > 00:01:02:b7:12:04, ethertype IPv4,=20
> length 1514: IP 192.168.14.235 > 192.168.14.228: ipv6-opts 4
> 0x0000 0001 02b7 1204 0002 2d50 aa1a 0800 4500 ........-P....E=
.
> 0x0010 0018 1234 0000 803c 8956 c0a8 0eeb c0a8 ...4...<.V.....=
.
> 0x0020 0ee4 7465 7374 0000 0000 0000 0000 0000 ..test.........=
.
> 0x0030 0000 0000 0000 0000 0000 0000 cf53 1539 .............S.=
9
> 0x0040 38be 2079 4e90 4be7 f10a 1dd6 432f f7d8 8..yN.K.....C/.=
.
> 0x0050 9b5b 131a 0b4b 326e 9c5b 7cdd 8a57 de05 .[...K2n.[|..W.=
.
> Actually, it even appears twice - probably due to the retry-problem. So t=
he
> AP was actually bridging the packet as planned.
>=20
> To my setup:
> - SuSE Linux 8.2 (2.4.20-4GB)
> - Airjack 0.6.3 Alpha (is there a newer version available somewhere?)
> - D-Link DWL-650 for injection (Prism2 chipset, "Link DWL-650 11Mbps WLAN
> Card" version 01.02)
>=20
> Main structure of the program:
> - initialize socket as in essid_jack.c
> - set monitor mode and channel
> - write(sockfd,&frame,len) with the above data (which I actually construc=
ted
> using libnet)
>=20
> Note that I was using a3_80211 as header for data-packets, not a4_80211. =
I
> can post the full program if this is of interest or help.
>=20
> I also had the idea the problem might be that the card is not seeing the
> acknowledge control frames (the ones starting with "d400 0000") from the =
AP
> because these are directed to the faked MAC address instead of the "real"
> MAC address of the card. But even if I try to use the "correct" MAC-addre=
ss
> as source address, I get this effect (plus the packet is not seen on the =
LAN
> segment because the station is not associated).
>=20
> Thanks in advance if anyone can help me, and sorry if this is a dumb
> question... :-)
>=20
> Andy
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Airjack-user-devel mailing list
> Air...@li...
> https://lists.sourceforge.net/lists/listinfo/airjack-user-devel
|