Re: [zd1211-devs] Unencrypted packet interface
Jon Smirl wrote: If you send UDP packets out on a multicast (or broadcast address) under 802.11 there is no MAC level ACK. UDP packets never have TCP level ACKs. So the question is, if an 802.11 device is associated to an AP, can you use the existing API to send out packets with a NULL essid. If you can do this you don't need to write any new code for the driver. This is sort of like being in ad hoc and infrastructure mode at the same time. Hi Jon - For reasons that can best be summed up under privacy, part of what is needed is to completely lose all station identifier information in the public unencrypted network. Another issue is that the unencrypted channel needs to operate even if the main device is unassociated. For example if you travel with your laptop and there are no APs, there's no reason you shouldn't still be able to use the unencrypted channel with any nearby devices, eg, in an airport waiting lounge. I found a way to send unencrypted packets through the 80211 stack, associated or not, but some small driver patching is still required, I will report more shortly. -Andy - 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.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
[zd1211-devs] Random register corruption bug in reset_mode()?
Hi folks -
static int reset_mode(struct zd_mac *mac)
{
struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
struct zd_ioreq32 ioreqs[3] = {
{ CR_RX_FILTER, STA_RX_FILTER },
{ CR_SNIFFER_ON, 0U },
};
if (ieee-iw_mode == IW_MODE_MONITOR) {
ioreqs[0].value = 0x;
ioreqs[1].value = 0x1;
ioreqs[2].value = ENC_SNIFFER;
}
return zd_iowrite32a(mac-chip, ioreqs, 3);
}
Seems that ioreqs[2].addr is never prepared to anything, and
ioreqs[2].value is never set if you are not in Monitor mode... but you
always call zd_iowrite32a() to do 3 actions... so I guess you write a
random register with a random value every time you call this, since it
is all on the stack and there is no zeroing on allocation...
-Andy
-
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.phpp=sourceforgeCID=DEVDEV
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Unencrypted packet interface
On 1/11/07, Andy Green [EMAIL PROTECTED] wrote: Jon Smirl wrote: If you send UDP packets out on a multicast (or broadcast address) under 802.11 there is no MAC level ACK. UDP packets never have TCP level ACKs. So the question is, if an 802.11 device is associated to an AP, can you use the existing API to send out packets with a NULL essid. If you can do this you don't need to write any new code for the driver. This is sort of like being in ad hoc and infrastructure mode at the same time. Hi Jon - For reasons that can best be summed up under privacy, part of what is needed is to completely lose all station identifier information in the public unencrypted network. Another issue is that the unencrypted channel needs to operate even if the main device is unassociated. For example if you travel with your laptop and there are no APs, there's no reason you shouldn't still be able to use the unencrypted channel with any nearby devices, eg, in an airport waiting lounge. That is just a description of how ad hoc mode works. Ad hoc is a standard part of 802.11. I found a way to send unencrypted packets through the 80211 stack, associated or not, but some small driver patching is still required, I will report more shortly. -Andy -- Jon Smirl [EMAIL PROTECTED] - 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.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Random register corruption bug in reset_mode()?
The vendor driver is here:
http://dsd.object4.net/zd1211-vendor/releases/
You can compare how they did things.
There have been reports of the driver garbling frames with kismet.
This may be the source.
On 1/11/07, Andy Green [EMAIL PROTECTED] wrote:
Hi folks -
static int reset_mode(struct zd_mac *mac)
{
struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
struct zd_ioreq32 ioreqs[3] = {
{ CR_RX_FILTER, STA_RX_FILTER },
{ CR_SNIFFER_ON, 0U },
};
if (ieee-iw_mode == IW_MODE_MONITOR) {
ioreqs[0].value = 0x;
ioreqs[1].value = 0x1;
ioreqs[2].value = ENC_SNIFFER;
}
return zd_iowrite32a(mac-chip, ioreqs, 3);
}
Seems that ioreqs[2].addr is never prepared to anything, and
ioreqs[2].value is never set if you are not in Monitor mode... but you
always call zd_iowrite32a() to do 3 actions... so I guess you write a
random register with a random value every time you call this, since it
is all on the stack and there is no zeroing on allocation...
-Andy
-
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.phpp=sourceforgeCID=DEVDEV
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
--
Jon Smirl
[EMAIL PROTECTED]
-
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.phpp=sourceforgeCID=DEVDEV
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Random register corruption bug in reset_mode()?
Jon Smirl wrote: There have been reports of the driver garbling frames with kismet. This may be the source. Probably not the source of that problem, since reset_mode isn't called very often. Bad data in Monitor mode sounds like frames that didn't pass their CRC check being passed through. -Andy - 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.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Random register corruption bug in reset_mode()?
On 1/11/07, Andy Green [EMAIL PROTECTED] wrote: Jon Smirl wrote: There have been reports of the driver garbling frames with kismet. This may be the source. Probably not the source of that problem, since reset_mode isn't called very often. Bad data in Monitor mode sounds like frames that didn't pass their CRC check being passed through. Did the vendor source show you have to fix the bug? -Andy -- Jon Smirl [EMAIL PROTECTED] - 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.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Random register corruption bug in reset_mode()?
Jon Smirl wrote:
There have been reports of the driver garbling frames with kismet.
This may be the source.
Probably not the source of that problem, since reset_mode isn't called
very often. Bad data in Monitor mode sounds like frames that didn't
pass their CRC check being passed through.
Did the vendor source show you have to fix the bug?
There doesn't seem to be an equivalent function in the vendor tree.
Attached is my guess at what was intended.
-Andy
--- zd_mac.c.orig 2007-01-11 19:28:03.0 +
+++ zd_mac.c 2007-01-11 19:28:53.0 +
@@ -171,15 +171,18 @@
struct zd_ioreq32 ioreqs[3] = {
{ CR_RX_FILTER, STA_RX_FILTER },
{ CR_SNIFFER_ON, 0U },
+ { CR_ENCRYPTION_TYPE, 0 }
};
+ int nRegs=2;
if (ieee-iw_mode == IW_MODE_MONITOR) {
ioreqs[0].value = 0x;
ioreqs[1].value = 0x1;
ioreqs[2].value = ENC_SNIFFER;
+ nRegs=3;
}
- return zd_iowrite32a(mac-chip, ioreqs, 3);
+ return zd_iowrite32a(mac-chip, ioreqs, nRegs);
}
int zd_mac_open(struct net_device *netdev)
-
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.phpp=sourceforgeCID=DEVDEV___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Random register corruption bug in reset_mode()?
On 07-01-11 19:34 Andy Green wrote:
There doesn't seem to be an equivalent function in the vendor tree.
Attached is my guess at what was intended.
Andy, thank you for finding this. Based on the current logic this
is the right fix:
Subject: [PATCH] zd1211rw: Fixed array size issue in reset_mode
Andy Green found this issue.
---
zd_mac.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/zd_mac.c b/zd_mac.c
index 10339f5..7f0c3bc 100644
--- a/zd_mac.c
+++ b/zd_mac.c
@@ -157,7 +157,7 @@ void zd_mac_clear(struct zd_mac *mac)
static int reset_mode(struct zd_mac *mac)
{
struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
- struct zd_ioreq32 ioreqs[3] = {
+ struct zd_ioreq32 ioreqs[] = {
{ CR_RX_FILTER, STA_RX_FILTER },
{ CR_SNIFFER_ON, 0U },
};
@@ -165,10 +165,9 @@ static int reset_mode(struct zd_mac *mac
if (ieee-iw_mode == IW_MODE_MONITOR) {
ioreqs[0].value = 0x;
ioreqs[1].value = 0x1;
- ioreqs[2].value = ENC_SNIFFER;
}
- return zd_iowrite32a(mac-chip, ioreqs, 3);
+ return zd_iowrite32a(mac-chip, ioreqs, ARRAY_SIZE(ioreqs));
}
int zd_mac_open(struct net_device *netdev)
--
Uli Kunitz
-
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.phpp=sourceforgeCID=DEVDEV
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
