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
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 ==
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
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
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.
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
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.
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
