There is content regarding wireless:
Whereas throughput on Ethernet-connection could depend on limited CPU power alone, the throughput on a 802.11-connection depends on many more parameters.
Please read datagram.structures to make sure, we all talk about the same things. Thank you
|When you measure the throughput of an action (the copy of a file), what exactly are you measuring? The throughput of the payload, or the throughput of payload + overhead? For Ethernet the difference can be small, but for DSL-PPPoE or 802.11 the difference is bigger. So it's always good to know, what actually you are measuring. A good manual will tell you what a software is precisely doing.|
Whether an OEM firmware gives you better throughput then OpenWrt is a matter of SOFTWARE (since both run on the same hardware…). So ask yourself, what Operating System is used for the OEM firmware. Probably some sort of GNU/Linux. In Linux, drivers are part of Kernel. In OpenWrt we use quite new Kernel with even newer wireless drivers. So it IS possible, that OEM firmware gives you better throughput, but since both, OEM and OpenWrt, use Linux kernel and Linux drivers, well, …
The device overview shows that my devices are not connecting at full speeds. 802.11n throughput depends heavily on 40MHz Channel Width and additional antennas.
The iPad 1 is in compliance with 802.11n but delivers only slightly better performance than previous 802.11g.
40MHz in 2.4Ghz bands is often deactivated because of interference with other channels. There are only 3 20MHz channels without overlapping available in the 2.4.GHz band.
Yes, but cranking the power to the maximum won't help you any.
Background-1: You might transmit farther but the noise level will be higher (and will probably bleed into the neighbouring channels; that looks like this then) and your recieve sensitivity won't be improved any, limiting your distance. If you want better range go buy better antennae.
Background-2: Most wifi cards do not support high transmit power and high transmission speeds. See data sheets.
1. Regulatory data might be outdated or wrong
Fix regulatory bugs and report them to OpenWrt and/or upstream at: http://lists.infradead.org/pipermail/wireless-regdb
iw reg get
2. Hardware is not constructed or does not support high transmission power
2.a Hardware design (target market) plays a role
High tx power requires different hardware design (more costs not worth on consumer hardware). Most use cases do not need high tx power but can profit from better antenna or multiple APs.
2.b Hardware limits
see Background-1 & MCS ratings w. tx power on data sheets (example: WLM200N-23ESD). Setting higher limits can damage or shorten the lifespan of the hardware. Hardware quality varies in production process and individual calibration is costly. Use high tx power cards if you need them or can operate them in your regulatory domain. Some regulators might allow operation for radio amateur or via some license scheme.
3. Driver/Implementation limitations
The driver does not use some circuitry (on RX path: LNA, example) Factory firmware, OpenWrt and some vendor firmware based on OpenWrt could use different drivers. Each driver can interpret limits differently. Without measuring equipment the output power level could be reported wrong. Power management can influence neighbour APs (noise floor,hidden station).
4. Firmware/ART/caldata/EEPROM/OTP limitations
"Firmware" means the blobs loaded by fullmac devices (many 802.11ac chipsets) can introduce non changeable tx power or different tx power depending on driver.
"ART/caldata" means a dedicated partition on system flash containing data to setup ath9k (ART=atheros radio test) or other hardware (caldata = calibration data).
"EEPROM" means a dedicated chip contains the setup data (common on older devices).
"OTP" means the data for the setup is inside the main wlan chip.
Many countries enforce conformity tests (FCC, CE…) to ensure that the hardware operates within reasonable limits. Doing these conformity tests is often not done on very cheap hardware or the hardware is programmed and designed to operate at save values instead of operating at the "regulation border" at max. allowed txpower. Some regulation infos can be part of the ART/caldata/EEPROM/OTP.
Some devices contain multiple ARTs. Using high power tables can damage the device - see this commit
→CRDA (Central Regulatory Domain Agent) takes care of everything!
To not cause havoc in your neighborhood, and also to not break the law and pay a fine!, your IEEE 802.11 setup needs to obey the regulations for your current location. But you do NOT need to bother with all of this, because the CRDA takes care of this for you.
Any country has some kind of regulatory authority in charge of regulating the radio frequency spectrum as these differ from country to country. In case you want to inform/convince yourself of the current regulations, there probably is an official web page on the Internet with this information. For Germany, this is the ⇒"Bundesnetzagentur". AllgemeinZuteilungen is current valid law as pdf, concerning frequencies and the allowed maximum transmit power.
Ticket 9678: ar71xx: DE locate, but channel 12 and 13 are disabled wontfix This problem cannot be fixed in OpenWrt due to various obligations and agreements with vendors.
Wikipedia says "Most countries in world" allow channels 12 and 13
Workaound Solution: http://luci.subsignal.org/~jow/reghack/ + set your country in
OpenWrt Forum discussion to enable channels 12 and 13
Note: due to r31954 tweaking crda isn't longer an option.
Limitations when combining multiple wireless modes of operation at the same time do exist.
ifconfig wlan0 down iw phy phy0 interface add scan0 type station ifconfig scan0 up iwlist scan0 scan iw dev scan0 del ifconfig wlan0 up killall -HUP hostapd
opkg update opkg install iwinfo iwinfo wlan0 scan
# Proprietary Broadcom (wl) wl -i wl0 assoclist # Proprietary Atheros (madwifi) wlanconfig ath0 list sta # MAC80211 iw dev wlan0 station dump # Universal iwinfo wlan0/wl0/ath0 assoclist
A script that uses the above to display MAC address, and DHCP lease information (IP address, hostname):
cat > /etc/config/show_wifi_clients.sh << "EOF_DOCUMENT" #!/bin/sh # /etc/config/show_wifi_clients.sh # Shows MAC, IP address and any hostname info for all connected wifi devices # written for openwrt 12.09 Attitude Adjustment echo "# All connected wifi devices, with IP address," echo "# hostname (if available), and MAC address." echo -e "# IP address\tname\tMAC address" # list all wireless network interfaces # (for MAC80211 driver; see wiki article for alternative commands) for interface in `iw dev | grep Interface | cut -f 2 -s -d" "` do # for each interface, get mac addresses of connected stations/clients maclist=`iw dev $interface station dump | grep Station | cut -f 2 -s -d" "` # for each mac address in that list... for mac in $maclist do # If a DHCP lease has been given out by dnsmasq, # save it. ip="UNKN" host="" ip=`cat /tmp/dhcp.leases | cut -f 2,3,4 -s -d" " | grep $mac | cut -f 2 -s -d" "` host=`cat /tmp/dhcp.leases | cut -f 2,3,4 -s -d" " | grep $mac | cut -f 3 -s -d" "` # ... show the mac address: echo -e "$ip\t$host\t$mac" done done EOF_DOCUMENTMake it executable:
chmod ugo+rx /etc/config/show_wifi_clients.sh
Now run it:
wifi down && sleep 5 && wifi
Typically you will see something like this:
root@OpenWrt:~# iwconfig wlan0 mode master Error for wireless request "Set Mode" (8B06) : SET failed on device wlan0 ; Invalid argument.
It's documented here.