While doing some experiments with the co-channel interference, (there is lot of interference in 2.4 GHz band) i was expecting an increase in the number of packets having CRC errors. I knew that theoretically, i should be seeing a lot more malformed packets in wireshark having CRC error. But as I did not see any such packets, I knew something was wrong.
Again, as I was using, madwifi-ng with the atheros card, looking into the driver code helped me. I came to know that packets with crc errors were being dropped by the driver itself. These packets were not propagated to the application( in my case, wireshark, thats why i was unable to see those packets). Here is the snapshot of the driver code, which was dropping the packets.
In file net80211/ieee80211_monitor.c
Function :ieee80211_input_monitor
-----------------------------------------------------------------------------------
/* Discard CRC errors if necessary */
if (ds->ds_rxstat.rs_status & HAL_RXERR_CRC) {
if (vap->iv_monitor_crc_errors == 0) continue;
}
-----------------------------------------------------------------------------------
What it means is, it will not process and continue to next packet if ds->ds_rxstat.rs_status has CRC error bit set to 1. We will still process the packet if vap->iv_monitor_crc_errors is a non-zero value. Now trying to find out where it is set, I came to know about some interesting proc entries. Lets concentrate on this issue first.
In file net80211/ieee80211_linux.c
This is the function which sets that value..
------------------------------------------------------------------------------------------------------------------
static int
IEEE80211_SYSCTL_DECL(ieee80211_sysctl_monitor_crc_errors, ctl, write, filp, buffer,
lenp, ppos)
{
struct ieee80211vap *vap = ctl->extra1;
u_int val;
int ret;
ctl->data = &val;
ctl->maxlen = sizeof(val);
if (write) {
ret = IEEE80211_SYSCTL_PROC_DOINTVEC(ctl, write, filp, buffer,
lenp, ppos);
if (ret == 0)
vap->iv_monitor_crc_errors = val;
} else {
val = vap->iv_monitor_crc_errors;
ret = IEEE80211_SYSCTL_PROC_DOINTVEC(ctl, write, filp, buffer,
lenp, ppos);
}
return ret;
}
-------------------------------------------------------------------------------------------------------------------
So setting proc entry monitor_crc_erros to 1, enables the propagation of these crc error packets to the application.
#echo ‘1′ > /proc/sys/net/ath0/monitor_crc_errors # Disable CRC error checking
Other interesting proc entries i found were:
#echo ‘1′ > /proc/sys/net/ath0/monitor_phy_errors # Disable PHY error checking
When packet is passed from driver to application, a header is appended to the packet, having information like noise, RSSI, signal strength, data rate,frame length, timestamps etc. I knew about only two headers, namely prism header and radiotap header before looking into the code. Browsing through the code helped me to understand this also.(Lucky me...). I had never seen radiotap header in any of my captures, so I was under impression that madwifi-ng driver always appends with prism header. I had seen radiotap header only with ath5k driver. Anyways, what i came to know after code browsing is:
You can send packets either with prism, radiotap or with no header at all (direct 802.11 packet). There is one more atheros descriptor, i donno what it is about. This is how you can tell driver to append a particular header.
echo ‘801′ > /proc/sys/net/ath1/dev_type # only 802.11 headers
echo ‘802′ > /proc/sys/net/ath1/dev_type # prism2 headers
echo ‘803′ > /proc/sys/net/ath1/dev_type # radiotap headers
echo ‘804′ > /proc/sys/net/ath1/dev_type # atheros descriptors
I can set which headers i want in my packet capture. When i set dev_type to 804, wireshark popped up a warning saying, "libpcap does not support arptype 804", so i dont know how and where this arptype is used.
Thats all for this post friends..... Happy Sniffing....
Again, as I was using, madwifi-ng with the atheros card, looking into the driver code helped me. I came to know that packets with crc errors were being dropped by the driver itself. These packets were not propagated to the application( in my case, wireshark, thats why i was unable to see those packets). Here is the snapshot of the driver code, which was dropping the packets.
In file net80211/ieee80211_monitor.c
Function :ieee80211_input_monitor
-----------------------------------------------------------------------------------
/* Discard CRC errors if necessary */
if (ds->ds_rxstat.rs_status & HAL_RXERR_CRC) {
if (vap->iv_monitor_crc_errors == 0) continue;
}
-----------------------------------------------------------------------------------
What it means is, it will not process and continue to next packet if ds->ds_rxstat.rs_status has CRC error bit set to 1. We will still process the packet if vap->iv_monitor_crc_errors is a non-zero value. Now trying to find out where it is set, I came to know about some interesting proc entries. Lets concentrate on this issue first.
In file net80211/ieee80211_linux.c
This is the function which sets that value..
------------------------------------------------------------------------------------------------------------------
static int
IEEE80211_SYSCTL_DECL(ieee80211_sysctl_monitor_crc_errors, ctl, write, filp, buffer,
lenp, ppos)
{
struct ieee80211vap *vap = ctl->extra1;
u_int val;
int ret;
ctl->data = &val;
ctl->maxlen = sizeof(val);
if (write) {
ret = IEEE80211_SYSCTL_PROC_DOINTVEC(ctl, write, filp, buffer,
lenp, ppos);
if (ret == 0)
vap->iv_monitor_crc_errors = val;
} else {
val = vap->iv_monitor_crc_errors;
ret = IEEE80211_SYSCTL_PROC_DOINTVEC(ctl, write, filp, buffer,
lenp, ppos);
}
return ret;
}
-------------------------------------------------------------------------------------------------------------------
So setting proc entry monitor_crc_erros to 1, enables the propagation of these crc error packets to the application.
#echo ‘1′ > /proc/sys/net/ath0/monitor_crc_errors # Disable CRC error checking
Other interesting proc entries i found were:
#echo ‘1′ > /proc/sys/net/ath0/monitor_phy_errors # Disable PHY error checking
When packet is passed from driver to application, a header is appended to the packet, having information like noise, RSSI, signal strength, data rate,frame length, timestamps etc. I knew about only two headers, namely prism header and radiotap header before looking into the code. Browsing through the code helped me to understand this also.(Lucky me...). I had never seen radiotap header in any of my captures, so I was under impression that madwifi-ng driver always appends with prism header. I had seen radiotap header only with ath5k driver. Anyways, what i came to know after code browsing is:
You can send packets either with prism, radiotap or with no header at all (direct 802.11 packet). There is one more atheros descriptor, i donno what it is about. This is how you can tell driver to append a particular header.
echo ‘801′ > /proc/sys/net/ath1/dev_type # only 802.11 headers
echo ‘802′ > /proc/sys/net/ath1/dev_type # prism2 headers
echo ‘803′ > /proc/sys/net/ath1/dev_type # radiotap headers
echo ‘804′ > /proc/sys/net/ath1/dev_type # atheros descriptors
I can set which headers i want in my packet capture. When i set dev_type to 804, wireshark popped up a warning saying, "libpcap does not support arptype 804", so i dont know how and where this arptype is used.
Thats all for this post friends..... Happy Sniffing....
