Re: [OpenWrt-Devel] [solved] Linksys E1700 firmware upload throws "incorrect Firmware"
Yep, newer stock firmwares now frequently include locks against flashing 3rd party firmware. A common approach thus far, as you found, is indeed to downgrade to the stock firmware to an older version, but I understand that option also is being gradually trimmed away on newly sold products. On Thu, May 19, 2016 at 1:57 PM, Andreas Schlager <andreas.schla...@sbg.at> wrote: > Hi List, > > finally I managed to flash the OpenWRT firmware to the Linksys E1700 > router. > The problem is, that starting with Linksys firmware revision 1.0.01 and > above the firmware upgrade process aborts with "incorrect Firmware" when > trying to upload the OpenWRT firmware. > > I googled around and finally got a hit in a dd-wrt thread ( > https://www.dd-wrt.com/phpBB2/viewtopic.php?t=277324=0=asc=30 > ) > > So I downloaded the initial Linksys FW version 1.0.00 (get > FW_E1700_v1.0.00.081_20131220.bin at https://db.tt/m95cTvHq) and > downgraded the E1700 from FW 1.0.02 (which my device was shipped) to 1.0.00. > > Then it accepted the OpenWRT firmware without troubles. > > Many thanks to you all for this exciting piece of software! > > Kind regards, > > -Andreas. > > - > "Sed quis custodiet ipsos custodes?" > (Wer, außer den Wächtern selbst, wacht über die Wächter?) > --Juvenal. > > Am 2016-05-18 um 21:58 schrieb Andreas Schlager: > > Dear list members, > > I'm coming to you with an installation problem on my brand new Linksys > E1700 devices, but I think this is the right forum for this. Also > because the WIKI entries for the E1700 router tells to report a working > device - which unfortunately is not the case... > > I tried it with uploading the OpenWRT firmware via the origina Linksys > Web-Interface, but after 15% it states "Incorrect Firmware". Only an OK > button, no ignore or something else. > > Then I fiddled around with tftp/tftpd, but it seems that this device > doesn't send tftp requests when booting, nor when reset-button is > pressed. Also an upload via tftp to the device failed. > The device still is useable, the stock firmware works. Additionally I > tried to upload the original Linksys FW, what worked. > > This is the image I > tried:https://downloads.openwrt.org/snapshots/trunk/ramips/mt7620/openwrt-ramips-mt7620-e1700-squashfs-factory.bin > > Any ideas highly appreciated > Many thanks in advance! > > -Andreas. > > > > > ___ > openwrt-devel mailing > listopenwrt-devel@lists.openwrt.orghttps://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -- Ben West <b...@gowasabi.net> b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New Ubiquiti AC products locked against 3rd party firmware?
I'm forwarding a post from listserv discussing the proposed FCC regulations that would (indirectly) compel firmware lockdown. This person is reporting a new Ubiquiti AC AP where there the bootloader does an RSA signature check on the firmware image. Could anyone else confirm if they've observed the same, and if it now prevents loading OpenWRT, etc? Or at least, confirm if the RSA signature checking by the bootloader was not present before? -- Forwarded message -- From: Andrew Margarit | Cucumber WiFI <and...@polkaspots.com> Date: Fri, Nov 27, 2015 at 7:59 AM Subject: Re: [FCC] New AP with the lockdown To: f...@lists.prplfoundation.org Hi there, Just to let you know, I've been looking at the Ubiquiti new AC APs, and it looks like they added a RSA check in the bootloader. Firmware Version: BZ.qca956x.v3.4.7.3284.150911.1650 RSA Signed Firmware. Verfiying please wait... Decrypted hash: f8 2b 45 72 9f e4 5f 46 a0 96 43 37 57 4f 49 ab 43 dc 1e 8c Image hash: f8 2b 45 72 9f e4 5f 46 a0 96 43 37 57 4f 49 ab 43 dc 1e 8c All fun and good! .. -- Andrew Margarit Wi-FI Chief | Cucumber Tony and...@polkaspots.com cucumberwifi.io twitter/cucumbertony ___ FCC mailing list f...@lists.prplfoundation.org http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/fcc -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
You can look up your respective country's spectrum regulations. It is possible prior versions OpenWRT didn't fully conform to each regulatory domain and were fixed in more recent versions (just as the converse is possible). For example, for the USA, here is a table of power limits for the 2.4GHz and 5GHz bands. Channels 36-48 are limited to 16dBm transmitter power. http://www.air802.com/fcc-rules-and-regulations.html On Thu, Jul 30, 2015 at 3:32 AM, Nicola von Thadden n...@vthadden.de wrote: Hi, I also thought to have used 20dBm or 23dBm in earlier releases (AA). Is there a way to find out to which txpower levels the 5Ghz transceiver is limited? I think the driver reads them out, maybe there is a way to print them on the cmd? But my main problem is the 17dBm on 2.4Ghz when setting DFS-ETSI countries. I don't think that it is a problem of the hardware but of the software parsing the regdom. Maybe there is a fixed limit of 17dBm on non-DFS channels, even when DFS is not required, which is not very useful. Does anyone have an idea where that could be set? My search in the source code had no results until now, where it could be. Thanks Nico On 07/29/2015 06:21 PM, Atanas Vladimirov wrote: https://dev.openwrt.org/ticket/20201 On BB I used 20dBm for both 2.4 and 5GHz on the same router. Sent with AquaMail for Android http://www.aqua-mail.com On 29 юли 2015 г. 18:40:10 Ben West b...@gowasabi.net wrote: This is what I observe running Barrier Breaker on UBNT M5 products, too. I believe the 17dBm limit is intentional, i.e. per regulation. The 30dBm tx power limit applies to channels 149 and above, I believe. Also (kind of off-topic): Do you know why 5Ghz channels 36-48 are forced to be 17dBm only on the WNDR3800? I found two possible explanations: either because of the factory calibration On Wed, Jul 29, 2015 at 10:25 AM, Gerald Matzka mgeral...@yahoo.de mailto:mgeral...@yahoo.de wrote: Well, it looks like the txpower of your wdnr3800 is limited to 17dBm because of the hardware reg-domain settings. Kind regards, ... sent from my iPhone Am 29.07.2015 um 10:43 schrieb Nicola von Thadden n...@vthadden.de mailto:n...@vthadden.de: Hi, I have this strange behaviour down below, for which I also opened a ticket because I think this should not be like that ;) Does anyone have an idea where the problem could originate from and how to fix it? Thanks Nico On 07/29/2015 12:37 AM, OpenWrt wrote: #20222: 2.4Ghz limited to 50mW in DFS-ETSI --+-- Reporter: nicoduck | Owner: developers Type: defect| Status: new Priority: normal| Milestone: Chaos Calmer (trunk) Component: kernel|Version: Trunk Keywords: wndr3800 | --+-- I have got a Netgear WNDR 3800 running with openwrt since quite a while. I now upgraded to the latest version (trunk) and wanted to use WLAN within the regulations here in Germany but also wanted to max out the output power (within the regulations). Switching the country to Germany limits the maximum output power to 17dBm, although it does show as being limited on 20dBm: root@OpenWrt:/# iwinfo wlan0 txpower 0 dBm ( 1 mW) 1 dBm ( 1 mW) 2 dBm ( 1 mW) 3 dBm ( 1 mW) 4 dBm ( 2 mW) 5 dBm ( 3 mW) 6 dBm ( 3 mW) 7 dBm ( 5 mW) 8 dBm ( 6 mW) 9 dBm ( 7 mW) 10 dBm ( 10 mW) 11 dBm ( 12 mW) 12 dBm ( 15 mW) 13 dBm ( 19 mW) 14 dBm ( 25 mW) 15 dBm ( 31 mW) 16 dBm ( 39 mW) * 17 dBm ( 50 mW) 18 dBm ( 63 mW) 19 dBm ( 79 mW) 20 dBm ( 100 mW) What I did: reset the device, flash it with various builts from trunk and try to figure out what was going on. I now modified my regdb and was able to isolate the source of the problem: country DE: DFS-ETSI # entries 279004 and 280006 (2400 - 2483.5 @ 40), (100 mW) # entry 303005 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW # entries 304002 and 305002 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW # entries 308002, 309001 and 310003 (5470 - 5725 @ 160), (500 mW), DFS # 60 gHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) Thas does not work and has the mentioned behaviour, 2.4Ghz is limited at 17dBm. It also does not depend on which values are set
Re: [OpenWrt-Devel] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
because of the factory calibration (is it possible to get them in a human readable form somehow? The hexdump is not really readable and I have not been able to find the code which pases them) or because these channels are considered as edge-channels and someone thought it would be safe to limit the power, to not disturb any other systems running on even lower channels. The latter explanation is kind of weird because it would make no sense to limit these 4 channels but no other ones. I find it especially strange because that is typically the job of regulatory authorities, to define those power levels. -- Ticket URL: https://dev.openwrt.org/ticket/20222 OpenWrt http://openwrt.org Opensource Wireless Router Technology ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc3
I'm curious if others are affected by this issue: https://dev.openwrt.org/ticket/19085 https://dev.openwrt.org/ticket/19579 CC r46069 periodically fails with tx timeout on the eth0 interface on a UBNT Rocket M5, with reboot being the only resolution. The same device flashed to latest BB does not see ethernet tx timeouts, despite heavy load testing. It this issue happens to occur on other devices, I would imagine this to be potentially quite serious. On Thu, Jul 16, 2015 at 9:39 AM, Steven Barth cy...@openwrt.org wrote: The OpenWrt developers are proud to announce the third release candidate of OpenWrt Chaos Calmer. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - CHAOS CALMER (15.05 RC3) - * 1 1/2 oz GinShake with a glassful * 1/4 oz Triple Sec of broken ice and pour * 3/4 oz Lime Juice unstrained into a goblet. * 1 1/2 oz Orange Juice * 1 tsp. Grenadine Syrup - - http://downloads.openwrt.org/chaos_calmer/15.05-rc3/ ** Improvements since RC 2 ** * brcmfmac: support for BCM43602 * mt76: updated version with new firmware support, TX DMA fixes * Updated 3.18 to 3.18.18 * Fixed image builder generation * Various security updates (e.g. openssl, curl) * Minor fixes ** Improvements since RC 1 ** * Fixed broken ImageBuilders for most targets * Updated 3.18 to 3.18.14 * Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling * Images (special format) for Asus brcm47xx and bcm53xx devices * Improved stability of sysupgrade on brcm47xx and bcm53xx * Added HTTPS enforcement option to uhttpd * Fixed umask issue * Added support for a few new boards ** Highlights since Barrier Breaker ** * Linux kernel updated to version 3.18 * Improved Security Features - Rewritten package signing architecture based on ed25519 - Added support for jails - Added support for hardened builds * Improved Networking Support - Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, ...) - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050] - Netfilter performance enhancements (conntrack route cache) - Improved support for self-managing networks [draft-ietf-homenet-hncp] - Better multi-core support for the network stack - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning technologies [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6] - Improved network auto-setup capable of detecting and bootstrapping IPv4-only, 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT and combinations without explicit configuration [based on RFC 7084] - Added support for Smart Queue Management (SQM) QoS, AQM and Traffic Shaping - Improved support for DNSSEC * Platform and Driver Support - Added support for feeds of externally maintained targets - New mt7621 subtarget for Mediatek 11ac SoC - New mt76 mac80211 based wifi driver for MTK 11ac cores. - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices - New mxs target for Freescale i.MX23/28 family and various boards - New sunxi target for AllWinner A10/A13/A20 family and various boards - brcm2708: support for Raspberry Pi 2 - brcm63xx: support for BCM6318 and BCM63268 family - brcm63xx: improved fallback sprom support with bcma support - New ipq806x target for QCA IPQ806x SoC family * Known Issues - KALLSYMS is active causing some devices to fail And lots and lots of other advancements... As always a big thank you goes to all our active package maintainers, testers, supporters and documenters. Have fun! The OpenWrt developer team ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HT modes apparently not working in adhoc under Barrier Breaker
Following up that I've verified this changeset presently in trunk/Chaos
Calmer resolves the HT mode issue in Barrier Breaker. Would it be possible
to backport this changeset?
https://dev.openwrt.org/changeset/44100/
On Sat, Jun 27, 2015 at 3:46 PM, Ben West b...@gowasabi.net wrote:
This is the /etc/config/wireless I'm using on a UBNT M5 radio running
Barrier Breaker r45620:
config wifi-device radio0
option type mac80211
option channel 36
option hwmode 11a
option path 'pci:00/:00:00.0'
option htmode HT20
option country 'US'
option beacon_int '500'
list basic_rate '12000 18000 24000 36000 48000 54000'
option diversity '1'
option doth '0'
option disabled 0
config wifi-iface wlan0
option device radio0
option network 'mesh'
option mode 'adhoc'
option mcast_rate '12000'
option ssid MyMesh
option bssid '02:CA:FF:EE:BA:BE'
option encryption 'psk2+aes'
option key '...'
... and this is the /var/run/wpa_supplicant-wlan0.conf generated when
using packages hostapd, hostapd-common, and wpa-supplicant:
ap_scan=2
network={
scan_ssid=0
ssid=MyMesh
key_mgmt=WPA-PSK
mode=1
fixed_freq=1
frequency=5180
mode=1
psk=...
proto=RSN
bssid=02:CA:FF:EE:BA:BE
beacon_int=500
mcast_rate=12
}
Running iw wlan0 station dump confirms no HT modes appear on links to
other stations. By comparison, the same radio and same wireless config
under Chaos Calmer r46069 sees this /var/run/wpa_supplicant-wlan0.conf
generated:
ap_scan=2
network={
scan_ssid=0
ssid=MyMesh
key_mgmt=WPA-PSK
mode=1
fixed_freq=1
frequency=5180
mode=1
psk=...
proto=RSN
bssid=02:CA:FF:EE:BA:BE
mcast_rate=12
htmode=HT20
}
The station dump on the radio running Chaos Calmer does show HT modes in
use.
--
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
--
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] HT modes apparently not working in adhoc under Barrier Breaker
This is the /etc/config/wireless I'm using on a UBNT M5 radio running
Barrier Breaker r45620:
config wifi-device radio0
option type mac80211
option channel 36
option hwmode 11a
option path 'pci:00/:00:00.0'
option htmode HT20
option country 'US'
option beacon_int '500'
list basic_rate '12000 18000 24000 36000 48000 54000'
option diversity '1'
option doth '0'
option disabled 0
config wifi-iface wlan0
option device radio0
option network 'mesh'
option mode 'adhoc'
option mcast_rate '12000'
option ssid MyMesh
option bssid '02:CA:FF:EE:BA:BE'
option encryption 'psk2+aes'
option key '...'
... and this is the /var/run/wpa_supplicant-wlan0.conf generated when using
packages hostapd, hostapd-common, and wpa-supplicant:
ap_scan=2
network={
scan_ssid=0
ssid=MyMesh
key_mgmt=WPA-PSK
mode=1
fixed_freq=1
frequency=5180
mode=1
psk=...
proto=RSN
bssid=02:CA:FF:EE:BA:BE
beacon_int=500
mcast_rate=12
}
Running iw wlan0 station dump confirms no HT modes appear on links to
other stations. By comparison, the same radio and same wireless config
under Chaos Calmer r46069 sees this /var/run/wpa_supplicant-wlan0.conf
generated:
ap_scan=2
network={
scan_ssid=0
ssid=MyMesh
key_mgmt=WPA-PSK
mode=1
fixed_freq=1
frequency=5180
mode=1
psk=...
proto=RSN
bssid=02:CA:FF:EE:BA:BE
mcast_rate=12
htmode=HT20
}
The station dump on the radio running Chaos Calmer does show HT modes in
use.
--
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] beacon_int not working in Chaos Calmer in adhoc
I've been trying out CC on an adhoc mesh of three UBNT M5 radios, and I've
been unable to specify the beacon interval in /etc/config/wireless.
Here is the /etc/config/wireless I'm using:
config wifi-device radio0
option type mac80211
option channel 36
option hwmode 11a
option path 'pci:00/:00:00.0'
option htmode HT20
option country 'US'
option beacon_int '500'
list basic_rate '12000 18000 24000 36000 48000 54000'
option diversity '1'
option doth '0'
option disabled 0
config wifi-iface wlan0
option device radio0
option network 'mesh'
option mode 'adhoc'
option mcast_rate '12000'
option ssid MyMesh
option bssid '02:CA:FF:EE:BA:BE'
option encryption 'psk2+aes'
option key '...'
Under Chaos Calmer v46069 using packages hostapd, hostapd-common, and
wpa-supplicant, this is the /tmp/run/wpa_supplicant-wlan0.conf generated:
ap_scan=2
network={
scan_ssid=0
ssid=MyMesh
key_mgmt=WPA-PSK
mode=1
fixed_freq=1
frequency=5180
mode=1
psk=...
proto=RSN
bssid=02:CA:FF:EE:BA:BE
mcast_rate=12
htmode=HT20
}
By comparison, the same radios and same wireless config file, flashed with
Barrier Breaker r45620, have this /var/run/wpa_supplicant-wlan0.conf
generated:
ap_scan=2
network={
scan_ssid=0
ssid=MyMesh
key_mgmt=WPA-PSK
mode=1
fixed_freq=1
frequency=5180
mode=1
psk=...
proto=RSN
bssid=02:CA:FF:EE:BA:BE
beacon_int=500
mcast_rate=12
}
--
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Bump up to olsrd v0.6.8 on Barrier Breaker?
Would it be possible to push olsrd on Barrier Breaker up to to v0.6.8, i.e. same as in trunk/CC? The current version 0.6.6.2 is now EOL. https://github.com/openwrt-routing/packages/blob/for-14.07/olsrd/Makefile -- Forwarded message -- From: Ferry Huberts maili...@hupie.com Date: Wed, May 27, 2015 at 8:26 AM Subject: [Olsr-users] [ANNOUNCE - v1] olsrd v0.6.7 is End-Of-Life To: olsr-...@lists.olsr.org, Olsr-users olsr-us...@lists.olsr.org olsrd v1 branch release-0.6.7 is End-Of-Life and is removed. Users of olsrd v1 0.6.7 are strongly urged to move to a newer version. -- Ferry Huberts -- Olsr-users mailing list olsr-us...@lists.olsr.org https://lists.olsr.org/mailman/listinfo/olsr-users -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Support for DFS 5470 - 5725MHz DFS channels in US?
Thank you for researching the issue upstream! This message look like the relevant patch for reverting the exclusion of those bands for US: http://lists.infradead.org/pipermail/wireless-regdb/2015-January/000728.html On Tue, Feb 10, 2015 at 1:03 AM, Dirk Neukirchen dirkneukirc...@web.de wrote: On 10.02.2015 05:32, Ben West wrote: I found on a UBNT Nanostation running BB r43824 that apparently only a subset of the DFS 5.8GHz channels are enabled. This matches the channel definitions in the reg DB file: https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/files/regdb.txt What is the reason for keeping channels 5470 - 5725 disabled, when that range is enabled, for example, for country DE? People are operating UBNT products with stock firmware on these bands in the US. Different countries different regulatory rules. Upstream commit that removes 5470-5725 is: 31dc1c5eca29d039ac8f26340defe44bd7e497c1 This seems to be reverted by upstream with wireless-regdb (master-2015-01-30) [1] Updating the regdb should fix this. (I find no QCA feedback why this was introduced on the ML) [2] [1] http://marc.info/?l=linux-wirelessm=142263098201163 [2] http://lists.infradead.org/pipermail/wireless-regdb/2015-January/000717.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Support for DFS 5470 - 5725MHz DFS channels in US?
I found on a UBNT Nanostation running BB r43824 that apparently only a subset of the DFS 5.8GHz channels are enabled. Frequencies: * 5180 MHz [36] (17.0 dBm) * 5200 MHz [40] (17.0 dBm) * 5220 MHz [44] (17.0 dBm) * 5240 MHz [48] (17.0 dBm) * 5260 MHz [52] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 730 sec) * 5280 MHz [56] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 730 sec) * 5300 MHz [60] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 730 sec) * 5320 MHz [64] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 730 sec) * 5500 MHz [100] (disabled) * 5520 MHz [104] (disabled) * 5540 MHz [108] (disabled) * 5560 MHz [112] (disabled) * 5580 MHz [116] (disabled) * 5600 MHz [120] (disabled) * 5620 MHz [124] (disabled) * 5640 MHz [128] (disabled) * 5660 MHz [132] (disabled) * 5680 MHz [136] (disabled) * 5700 MHz [140] (disabled) * 5745 MHz [149] (30.0 dBm) * 5765 MHz [153] (30.0 dBm) * 5785 MHz [157] (30.0 dBm) * 5805 MHz [161] (30.0 dBm) * 5825 MHz [165] (30.0 dBm) This matches the channel definitions in the reg DB file: https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/files/regdb.txt What is the reason for keeping channels 5470 - 5725 disabled, when that range is enabled, for example, for country DE? People are operating UBNT products with stock firmware on these bands in the US. This table below represents my current understanding of permissible use of the DFS channels in the US: *Point-to-MultiPoint* *Band* *Lower Frequency* *Upper Frequency* *FCC Reg* *Max Power (dBm)* *Notes* 900 MHz 902.0MHz 928.0MHz Part 15.247 (b)(3) , (b)(4) 36dBm 2.4 GHz 2400.0MHz 2483.5MHz Part 15.247 (b)(3) , (b)(4) 36dBm 5.1 GHz UNII Low 5150.0MHz 5250.0MHz Part 15.407 (a)(1), (e) 36dBm 5.3 GHz UNII Mid 5250.0MHz 5350.0MHz Part 15.407 (a)(2), (h)(2) 30dBm Requires DFS radar det. 5.4 GHz UNII DFS 5470.0MHz 5725.0MHz Part 15.407 (a)(2), (h)(2) 30dBm Requires DFS radar det. 5.8 GHz UNII Upper 5725.0MHz 5875.5MHz Part 15.247 (b)(3) , (b)(4) 36dBm Part 15.407 (a)(3) -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubiquiti Nanostation LOCO M5
I've been flashing the Nanostation Loco M5's just fine with the Nanostation M image for 3 years without issue, and I never tried the Bullet M image. Although, the Loco M5's I've flashed are at least 1.5years old at present. Can you try flashing openwrt-ar71xx-generic-ubnt-nano-m-squashfs-factory.bin instead? Also, I'm flashing current versions of AA compiled from the code provided via SVN, rather than the pre-compiled images. On Wed, Sep 24, 2014 at 11:21 AM, Bill bmoff...@ayrstone.com wrote: I just got 5 LOCO M5 units that won't run OpenWRT. They are datestamped 1422K; when I try to flash them, they give me: received ERROR code=2, msg=Firmware check failed I am using the Bullet M image (openwrt-ar71xx-generic-ubnt- bullet-m-squashfs-factory.bin), flashing with tftp in binary mode. I have one other LOCO M5 with datestamp 1340K that works fine - flashes fine every time. But the new units won't take the firmware at all. I assume UBNT did something in the bootloader that is disabling OpenWRT. Any help will be welcome. I can open one up and attach a serial cable, but I'm not sure what I'd look for or what I'd do about it... Thanks, Bill ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IEEE 802.11 TDMA mode support in OpenWRT
In an old thread on the Battlemesh listserv about strategies for dealing with a mix of strong / weak clients for PtMP, someone offered this pointer for JaldMAC, an open 802.11 polling implementation in ath9k: http://matthias.vallentin.net/papers/nsdr10.pdf https://github.com/shaddi/jaldimac/commits/master Unfortunately, that repo has sat idle for over 2 years, and I believe it it was more a proof of concept rather than a usable implementation. Also, i believe TDMA requires very tight synchronization between all radios, hence the inclusion of GPS modules on proprietary implementations. On Thu, Jul 3, 2014 at 11:02 AM, Fernando Frediani fhfredi...@gmail.com wrote: Hi all, Is anyone aware of any implementation of TDMA mode support in OpenWRT (similar to Ubiquiti's AirMAX, Deliberant's iPoll or MikroTik's NV2, etc) Would that have to be implemented having in mind the radio driver or could it possible also be implemented in any router ? This is certanlly something significant for more throughput demanding and crowded environments. Best regards, Fernando ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Nanostation M2 - does it have a new soc chip from 2014?
So this would mean Nanostation M5's have a chipset/motherboard change, and to date no one has had the opportunity to test OpenWRT on them, correct? Thanks for your diligence. On Tue, Jun 10, 2014 at 5:12 PM, valent.turko...@gmail.com valent.turko...@gmail.com wrote: I got a batch of 10 Nanostation loco M2 devices and can confim that they run OpenWrt without problem. I have updated OpenWrt Wiki with all information I have found out so far: http://wiki.openwrt.org/toh/ubiquiti/nanostationm2 On Thu, Jun 5, 2014 at 12:35 AM, Moses F supp...@ubnt.com wrote: ## Please do not write below this line ## Your request (115726) has been updated. You can add a comment by replying to this email. *Moses F.* (Ubiquiti Networks) Jun 04 15:35 Hi Valent, Thanks for you patience. Here is the information you are looking for: The new firmware xw runs on the following board (except Rocket ti). system type : Atheros AR934x cpu model : MIPS 74Kc V4.12 Hope that's helpful. If you have any other questions, please let us know! I'm setting this ticket to solved for now, but if you have any additional questions, feel free to reply to this email at any time and it'll automatically reopen the ticket. Thanks! Moses F. Ubiquiti Networks *Moses F.* (Ubiquiti Networks) Jun 03 17:50 Hi Valent, The NanoStationM2 still runs on the older board. That's the reason there is no XW firmware. I'm still awaiting the information regarding the newer motherboard. Thanks for your patience! Moses F. Ubiquiti Networks *valent.turkovic* Jun 03 11:41 Hi Mozes, I'm also looking at Nanostation M2 download page: http://www.ubnt.com/download#NanoStation:M2 And here only XM AirOS image is listed, there is no XV image like on Nanostation M5 download page: http://www.ubnt.com/download#NanoStation:M5 Why? *valent.turkovic* Jun 03 05:47 Thanks for confirming that Nanostatio Loco M2 devices have changed. From what I saw it looks like you have changed SoC (main chip). From what I found out so far it looks like old chip was ar724x and new one is ar934x This is a really SIGNIFICANT change! I have stopped my order of 50 Nanostation M2 Loco devices because of this! I need OpenWrt support because AirOS doesn't support OLSR and BATMAN routing protocols, which we use in our community wifi network. There are hundreds of wifi communities like ours, with many thousands Ubiquiti devices, and we need 100% rock-solid support of OpenWrt running on your hardware. Ubiquiti has stopped delivering SDK so there is no more option to use AirOS + OLSR or BATMAN, now our only option is to completely replace AirOS with OpenWrt. So this change is a really big impact on all of us who can't use your hardware unless we have routing protocols our networks use! So please take OpenWrt support seriously, we are a base custome for your devices, which your marketing and develpment departements seam to not get or care about. Which is a shame because you are turning away your years long and loyal customers away by these kind of action. Please forward this message to your supperiors and ask them to join in the discussion on OpenWrt development mailing list or to provide direct emails on which they team leads can be contacted. Have a nice day. *Moses F.* (Ubiquiti Networks) Jun 02 16:58 Hi Valent, Thanks for getting in touch with us! Yes, we have come up with the new board for these devices. Just for easy understanding the devices with the xw firmware run on the latest motherboard. eg: http://www.ubnt.com/download#NanoStation:M5. You'll see two firmware here. The xw is for new board and the xm for the older devices. I'm not sure about the chip-set. I'll get the information and get back to you. Thanks for your patience! Moses F. Ubiquiti Networks *valent.turkovic* Jun 02 16:30 I have heard from guys at Wlan Slovenia that you have changed chip on new models of Nanostation M2 from Atheros ar71xx to Atheros ar934x Could you please confirm or deny this information. Has there been any change in SoC that is used in Nanostation M2 and M2 Loco devices? Cheers, Valent. This email is a service from Ubiquiti Networks. Message-Id:1Q2V5JR6_538f9f164c0e1_1f103f8ead8c9ea417314f_sprut -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Some atheros devices not loading kernel modules at boot, but work fine under AA
Aha, nevermind, false alarm. Looks like the failing reflashed nodes were carrying over /etc/init.d/boot from AA (which is incompatible with trunk). On Fri, May 16, 2014 at 7:32 PM, Ben West b...@gowasabi.net wrote: With one exception, all the OM1P and EOC-1650 units (atheros / ath5k) I've tried flashing with trunk r40746 do not load most of their kernel modules at boot. So no radio, zram, etc. Example errors seen in logread: Fri May 16 03:01:32 2014 user.emerg syslog: zram_applicable: [ERROR] device '/dev/zram0' not found Fri May 16 03:01:32 2014 daemon.crit zram_applicable: [ERROR] device '/dev/zram0' not found Fri May 16 03:01:34 2014 user.emerg syslog: Error: Failed to connect to ubus Fri May 16 03:01:38 2014 user.emerg syslog: this file has been obseleted. please call /sbin/block mount directly Fri May 16 03:01:39 2014 user.err syslog: /dev/mtdblock2 is already mounted Fri May 16 03:01:39 2014 user.emerg syslog: block: /dev/mtdblock2 is already mounted Of particular curiosity is that one EOC-1650 *does* to boot up r40746 just fine, with all kernel modules, radio and zram included. No observable difference in that device's partition table vs. that of failing units. Also, all failing devices boot up AA r40431 w/o problem, suggesting the issue is not with flash errors on specific units. Could this indicate a race condition when the kernel tries to load modules? I've filed a ticket with more details: https://dev.openwrt.org/ticket/16513 -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mac80211 on trunk not loading on atheros target: ls: /sys/class/ieee80211: No such file or directory
I'm trying load ath5k / mac80211 drivers on an Engenius EOC-1650, compiled from trunk r40735. However, wifi detect fails with the following: ls: /sys/class/ieee80211: No such file or directory A caveat is that this particular device has odd GPIO issues, whereby Attitude Adjustment had to have SYSFS config disabled and board config file patched as shown below to let the device to boot from flash. This patch didn't interfere with the radio drivers loading on AA r40431 with kernel 3.3.8. Could it nevertheless be causing problems for trunk with kernel 3.10? diff --git a/target/linux/atheros/config-3.10 b/target/linux/atheros/config-3.10 index e6ab73b..57f5177 100644 --- a/target/linux/atheros/config-3.10 +++ b/target/linux/atheros/config-3.10 @@ -44,7 +44,6 @@ CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GPIOLIB=y CONFIG_GPIO_DEVRES=y -CONFIG_GPIO_SYSFS=y # CONFIG_HAMRADIO is not set CONFIG_HARDWARE_WATCHPOINTS=y CONFIG_HAS_DMA=y diff --git a/target/linux/atheros/patches-3.10/100-board.patch b/target/linux/atheros/patches-3.10/100-board.patch index 96be80d..2d8ed85 100644 --- a/target/linux/atheros/patches-3.10/100-board.patch +++ b/target/linux/atheros/patches-3.10/100-board.patch @@ -1010,7 +1010,7 @@ +#define AR2315_GPIO_INT_LVL_HIGH 2 /* High Level Triggered */ +#define AR2315_GPIO_INT_LVL_EDGE 3 /* Edge Triggered */ + -+#define AR2315_RESET_GPIO 5 ++#define AR2315_RESET_GPIO 0 +#define AR2315_NUM_GPIO 22 + +/* @@ -2607,10 +2607,10 @@ + (i == ar231x_board.config-resetConfigGpio)) + continue; + -+ if(i == ar231x_board.config-sysLedGpio) ++ if(i == 2) + strcpy(led_names[led], wlan); + else -+ sprintf(led_names[led], gpio%d, i); ++ continue; + + ar2315_leds[led].name = led_names[led]; + ar2315_leds[led].gpio = i; -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mac80211 on trunk not loading on atheros target: ls: /sys/class/ieee80211: No such file or directory
Sorry to cause troubles. The bot at patchwork.openwrt.org added the diff content from my previous email to the patch queue, but this was not intended as a patch submission. http://patchwork.openwrt.org/patch/5387/ This diff output should not be applied as a patch to trunk! It was only included for illustration. Unfortunately, my login password to patchwork is missing, so I can't mark this patch as non-applicable. Could someone else see about that? (P.S. How does one get his/her login account at patchwork.openwrt.orgreset?) On Fri, May 9, 2014 at 12:40 PM, Ben West b...@gowasabi.net wrote: I'm trying load ath5k / mac80211 drivers on an Engenius EOC-1650, compiled from trunk r40735. However, wifi detect fails with the following: ls: /sys/class/ieee80211: No such file or directory A caveat is that this particular device has odd GPIO issues, whereby Attitude Adjustment had to have SYSFS config disabled and board config file patched as shown below to let the device to boot from flash. This patch didn't interfere with the radio drivers loading on AA r40431 with kernel 3.3.8. Could it nevertheless be causing problems for trunk with kernel 3.10? ... -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Update cyassl on AA to v2.8.0, and curl too?
I noticed that some SSL connections made via curl+cyassl v2.6.0 to Amazon AWS on a patched instance of AA began failing earlier this week with the following error: SSL_connect failed with error -112: mp_exptmod error state I'm guessing this might have been triggered by an internal update Amazon made to their stack to address the Heartbleed exploit (even tho not directly related). Copying over the cyassl and curl packages from trunk and trunk packages, respectively, seems to resolve the problem. Would it possible to sync the AA version of cyassl and curl with those from trunk? They're working fine for me under AA r40431. -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenSSL vulnerability
About the exploit: http://heartbleed.com/ The fixed version (released recently) is 1.01g+: https://www.openssl.org/news/secadv_20140407.txt Trunk appears to be using 1.01f: https://dev.openwrt.org/browser/trunk/package/libs/openssl/Makefile AA is on 1.01e https://dev.openwrt.org/browser/tags/attitude_adjustment_12.09/package/openssl/Makefile?rev=40420 -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Collision between named interfaces in /etc/config/network and wifi indentifiers in /etc/config/wireless
Sorry for not specifying. This was observed on AA r39154 and r39928. Something I'm also looking into is whether olsrd (in my case v0.6.5-4) may be what gets confused, i.e. besides netifd. Especially since this problem only seems to occur at bootup on repeater nodes in an OLSR-managed mesh, not on the gateway nodes. That is, I would see a repeater node respond to ping on its configured eth0 IP address for ~10sec briefly at boot and then go silent, suggesting something like a race condition at bootup. Adding the conflicting interface identifiers to /etc/config/wireless on a device that its already powered and out of bootup, and then issuing wifi restart does not trigger the failure. Pointing to a problem with bootup. On Thu, Mar 20, 2014 at 9:20 AM, Felix Fietkau n...@openwrt.org wrote: On 2014-03-19 20:22, Ben West wrote: I believe I discovered that interfaces in /etc/config/network and /etc/config/wireless sharing the same identifier causes a collision of some sort that can disable all the device's network interfaces, i.e. such that it no longer even responds to ping on eth0. Possibly, this is intentional? AA or trunk? At least in AA, wifi was still being set up by scripts that load both the network config and the wireless config into one context, which is probably causing these issues. In trunk, wireless is being configured by netifd, which passes the full config to the scripts, so it should be fixed there. - Felix -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Collision between named interfaces in /etc/config/network and wifi indentifiers in /etc/config/wireless
I believe I discovered that interfaces in /etc/config/network and /etc/config/wireless sharing the same identifier causes a collision of some sort that can disable all the device's network interfaces, i.e. such that it no longer even responds to ping on eth0. Possibly, this is intentional? For example, in /etc/config/network: config interface '*mesh*' option proto 'static' option ipaddr '5.X.X.X' option dns '208.67.222.222 208.67.222.220' option netmask '255.0.0.0' option broadcast '255.255.255.255' And then this VIF in /etc/config/wireless: config wifi-iface *mesh* option network 'mesh' option mode 'adhoc' option device 'radio0' option ssid 'MyMesh' option bssid '02:CA:FF:EE:BA:BE' option encryption 'psk2' option key 'averystrongkey' The collision was happening on repeater nodes in an OLSR-managed adhoc network, not on gateway nodes oddly enough. The repeater nodes in question had 3 wireless VIFs, the adhoc IF, a public AP running coovachill, and a private AP with WPA2 security. Changing the identifier in /etc/config/wireless from *mesh* to *wmesh*, i.e. anything besides mesh, seemed to resolve the problem. config wifi-iface *wmesh* option network 'mesh' option mode 'adhoc' option device 'radio0' option ssid 'MyMesh' option bssid '02:CA:FF:EE:BA:BE' option encryption 'psk2' option key 'averystrongkey' The wiki about /etc/config/wireless doesn't appear to make explicitly clear that interface identifiers should not be the same as the 'network' property for that interface. http://wiki.openwrt.org/doc/uci/wireless -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Correct use of basic_rate parameter for ath9k / 802.11n?
Thanks for the clarification. The basic rates vs. supported rates were a bit ambiguous to me. My underlying motivation was to disable lower 2.4GHz bitrates, i.e. 1 through 5.5Mbit/s, to conserve airtime. Is such a hotplug script nevertheless the best to disable such low rates? (Or likewise any patch to allow specification of supported rates via UCI?) On Fri, Mar 7, 2014 at 12:24 PM, Felix Fietkau n...@openwrt.org wrote: On 2014-03-04 18:20, Ben West wrote: To follow up, here it seems that setting the basic_rate option in /etc/config/wireless under AA r39154 has no effect on the rate mask, at least when queried via /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/rc_rateidx_mask_2ghz As a work-around, I'm using this hotplug script in /etc/hotplug.d/iface to disable the slower legacy 2.4GHz rates: #!/bin/sh . /lib/functions.sh . /lib/functions/network.sh # Disable legacy 2.4GHz low bitrates if [ ifup = $ACTION ]; then case $DEVICE in wlan*) logger setting bitrate for device $DEVICE on interface $INTERFACE iw $DEVICE set bitrates legacy-2.4 6 9 11 12 18 24 36 48 54 ;; br-*) #Bridged interfage, check if any wifi interface is member for i in $(ls /sys/class/net/$DEVICE/brif); do case $i in wlan*) logger setting bitrate for device $i on interface $INTERFACE iw $i set bitrates legacy-2.4 6 9 11 12 18 24 36 48 54 ;; esac done ;; esac fi Should values specified as basic_rate appear in the wifi interface's rate mask? No, the set of basic rates is different from the set of supported (or used) rates - basic rates are considered mandatory, but do not describe the entire rate set. Feel free to send a patch to allow configuring supported rates. - Felix -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Correct use of basic_rate parameter for ath9k / 802.11n?
To follow up, here it seems that setting the basic_rate option in /etc/config/wireless under AA r39154 has no effect on the rate mask, at least when queried via /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/rc_rateidx_mask_2ghz As a work-around, I'm using this hotplug script in /etc/hotplug.d/iface to disable the slower legacy 2.4GHz rates: #!/bin/sh . /lib/functions.sh . /lib/functions/network.sh # Disable legacy 2.4GHz low bitrates if [ ifup = $ACTION ]; then case $DEVICE in wlan*) logger setting bitrate for device $DEVICE on interface $INTERFACE iw $DEVICE set bitrates legacy-2.4 6 9 11 12 18 24 36 48 54 ;; br-*) #Bridged interfage, check if any wifi interface is member for i in $(ls /sys/class/net/$DEVICE/brif); do case $i in wlan*) logger setting bitrate for device $i on interface $INTERFACE iw $i set bitrates legacy-2.4 6 9 11 12 18 24 36 48 54 ;; esac done ;; esac fi Should values specified as basic_rate appear in the wifi interface's rate mask? On Wed, Feb 26, 2014 at 3:59 PM, Ben West b...@gowasabi.net wrote: I'm curious about the correct use of basic_rate parameter in /etc/config/wireless for 802.11n operation on ath9k. Specifically, I'm looking for the ability to disable low bitrates (e.g. 1Mbit/s) to conserve airtime. http://wiki.openwrt.org/doc/uci/wireless#common.options1 Searching the forum yields usage like this, but that appears to be for 802.11g operation: option basic_rate '1000 2000 5500 11000' Does the basic_rate list have to be populated for all values from 2000 to 30, i.e. when using HT40 modes, to exclude 1Mbit/s? Thank you. -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Correct use of basic_rate parameter for ath9k / 802.11n?
I'm curious about the correct use of basic_rate parameter in /etc/config/wireless for 802.11n operation on ath9k. Specifically, I'm looking for the ability to disable low bitrates (e.g. 1Mbit/s) to conserve airtime. http://wiki.openwrt.org/doc/uci/wireless#common.options1 Searching the forum yields usage like this, but that appears to be for 802.11g operation: option basic_rate '1000 2000 5500 11000' Does the basic_rate list have to be populated for all values from 2000 to 30, i.e. when using HT40 modes, to exclude 1Mbit/s? Thank you. -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Short preamble for adhoc?
I noticed that my UBNT Nanostation M gear running AA r39154, both 5.8GHz and 2.8GHz flavors, seem to be selecting long preambles for themselves for adhoc mode. Specifying short_preamble = 1 in the VIF's entry in /etc/config/wireless appears to have no effect. I do observe the 2.8GHz Nanostations using short preambles with clients in AP mode. Enabling encryption on these VIFs does not appear to affect whether short preambles are or are not used on the interface. This presumably rules out the possibility that hostapd/wpa_supplicant is forcing long preambles. Are short preambles not possible in adhoc, i.e. not allowed per 802.11 protocol spec, and/or does the mac80211 library itself perhaps enforce long preambles? Thanks. -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Problem of connectivity with adhoc using wpa
Sorry for not including this explicitly. My setup:
For all interfaces involved: option encryption 'psk2'
wpad - 20130807-1
DISTRIB_REVISION=r38347
DISTRIB_CODENAME=attitude_adjustment
DISTRIB_TARGET=ar71xx/generic
Again, I've compiled in the mac80211 and hostapd packages Felix provided
here:
http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary
I don't see any significant-looking updates made to hostapd in trunk since
last month, but I can update my firmware images to the AA r38863 revision
that Felix mentions.
For the instance where wpa_supplicant crashed on one of my nodes, killing
its IBSS-RSN interface, here are the log entries retrieved from the crash
file:
LOAD:77EF1000 0FFA C WPA: Key negotiation completed with
06:02:6f:76:13:5d [PTK=CCMP GTK=CCMP]
wlan0-2: WPA: Key negotiation completed with 06:02:6f:76:13:5d [PTK=CCMP
GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:6f:76:13:5d [GTK=CCMP]
wlan0-2: WPA: Group rekeying completed with 06:02:
LOAD:77EF2010 0021 C Resource temporarily unavailable
This was on a node in a 2-node mesh, and those log entries show the
crashing node renegotiating keys with its neighboring node. Of interest is
that wpa_supplicant / wpad may have been renegotiating keys repeatedly
before crashing. Not sure if this is normal for IBSS-RSN, or if it
suggests wpa_supplicat was stuck in a loop.
On Tue, Nov 19, 2013 at 5:49 PM, cmsv c...@wirelesspt.net wrote:
Hello Ben
Right now i am using:
AA r38621
wpad - 20130807-1
horst - git-1http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary from
http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary which replaced
all files from AA mac80211 and hostapd directories.
On 11/18/2013 12:56 PM, Ben West wrote:
Hi cmsv,
Are still having problems with the recurring IBSS split detected issue?
Not at the moment. Horst is not detecting IBSS splits and i have ran
several iperf tests in order to abuse all the avalable bandwidth between
routers. I am however still running tests.
I'm operating a couple dozen UBNT Nanostation Loco M2 units as nodes in
several WPA2-encrypted adhoc meshes (with each node additionally
broadcasting a public AP and private WPA2 AP as virtual interfaces, for
3 VIFs total). Meshes range from 2 to 4 nodes each.
I am using tp-link and d-link routers all atheros.
Only adhoc is encrypted with wpa2 (pks2)
2 to 4 routers.
I'm not seeing the IBSS split problem you describe, although I am having
issues with wpad crashing sporadically, either taking out the node's
IBSS-RSN interface or its private AP, either way requiring reboot to
recover. That is, in my instances where a node drops off a mesh, it is
because that node's wpa_supplicant process crashed, killing its adhoc
VIF.
I have not seen this issue but i have another issue in hands which
forces me to cold reboot some routers.
It is described here:
http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg20575.html
The causes the ath9k 9 router to freeze but i do believe that it is
related to tcp traffic and iptables since i have found a work around to
prevent the router to freeze. I will post later my conclusions regarding
this issue.
I also noticed another very strange occurrence related to the freezes.
# ls
%
77000
770?H?H?H?H?H?H?H?H?H?H?H?H$
9?}
Enter
Z^B{[2]+:
bin
dev
etc
lib
mnt
overlay
proc
rom
root
r?[J??[J[12Du
r?[J??[J?
sbin
sys
tmp
usr
var
www
?^@^@^@^@^@^A[
?^@^@^??1000]
?
?
?0?s
?L?00] ?[
?L?00] ?[ ` 1ws?
???z
?}i???~??kX??^@^@~@^B^@^H!B?^H^H
?j?j?j?j?j??i??%R?
I have not found out why i get these files in /
Al this only happens with AR9***
You might look for crash files files from wpa_supplicant or hostapd in
/tmp on problems nodes. The two crash files I've recovered thus far
seem to suggest a buffer overflow in wpad, although I do not know if
that actually triggered by other processes consuming all available RAM,
or something in wpad itself.
What wpad release are you using ?
My nodes are running AA r38347, patched with the mac80211 and hostapd
packages provided in same nbd repo that you quoted:
http://nbd.name
Re: [OpenWrt-Devel] [PATCH] atheros: /etc/diag.sh for FON2201
There a couple threads on this list over the past 2 years about the need
for device-specific targets for atheros, due to certain manufacturers'
differing GPIO assignments for reset, flash CS, etc. I have to apply
roughly similar patches to Attitude Adjustment for it to boot correctly on
Engenius EOC-1650 and Open Mesh OM1P, albeit each with mutually exclusive
GPIO assignments. Looks like FON2201 has its own GPIO assignment for the
power LED.
How does one start a new device-specific target for the atheros platform?
On Sun, Nov 10, 2013 at 1:13 PM, Daniel Gimpelevich
dan...@gimpelevich.san-francisco.ca.us wrote:
In Backfire, the power LED worked normally on the Fonera+, but in
Barrier Breaker, it's unused. I can't seem to find a way to
differentiate among hardware in the atheros target, so I'm submitting a
FIXME patch to be further patched with info from other devices.
Signed-off-by: Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us
--- /dev/null 2013-11-09 12:36:28.330833697 -0800
+++ b/target/linux/atheros/base-files/etc/diag.sh 2013-11-10
07:34:45.372612754 -0800
@@ -0,0 +1,27 @@
+#!/bin/sh
+# Copyright (C) 2013 OpenWrt.org
+
+. /lib/functions/leds.sh
+
+set_state() {
+ status_led=gpio4
+
+ [ -d /sys/class/leds/gpio4/ ]
+ [ -d /sys/class/leds/gpio7/ ] {
+
+ case $1 in
+ preinit)
+ led_timer gpio7 200 200
+ status_led_off
+ ;;
+ failsafe)
+ status_led_blink_failsafe
+ led_off gpio7
+ ;;
+ done)
+ status_led_on
+ led_off gpio7
+ ;;
+ esac
+ }
+}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Problem of connectivity with adhoc using wpa
Hi cmsv, Are still having problems with the recurring IBSS split detected issue? I'm operating a couple dozen UBNT Nanostation Loco M2 units as nodes in several WPA2-encrypted adhoc meshes (with each node additionally broadcasting a public AP and private WPA2 AP as virtual interfaces, for 3 VIFs total). Meshes range from 2 to 4 nodes each. I'm not seeing the IBSS split problem you describe, although I am having issues with wpad crashing sporadically, either taking out the node's IBSS-RSN interface or its private AP, either way requiring reboot to recover. That is, in my instances where a node drops off a mesh, it is because that node's wpa_supplicant process crashed, killing its adhoc VIF. You might look for crash files files from wpa_supplicant or hostapd in /tmp on problems nodes. The two crash files I've recovered thus far seem to suggest a buffer overflow in wpad, although I do not know if that actually triggered by other processes consuming all available RAM, or something in wpad itself. My nodes are running AA r38347, patched with the mac80211 and hostapd packages provided in same nbd repo that you quoted: http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary On Fri, Nov 1, 2013 at 9:50 PM, cmsv c...@wirelesspt.net wrote: Here's an update detected with horst regarding my testing. Although using the git files from trunk to replace mac80211 and hostapd did solve the problem mentioned before; i found another issue that does not happen with mac80211 and hostapd from current stable AA which in its turn suffers from other problems. Right now: DISTRIB_REVISION=r38621 plus http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary (wpa_suplicant.sh is not patched with Bruno's beacon_int patch and his patch fails to apply The routers suffer from IBSS network splits which are detected with horst with the follwoing IBSS Split detected (2 nodes) TSF outputs for the other router Also horst is only able to obtain the nodes ip's if adhoc is not encrypted. This happens every 10 seconds either having adhoc with PSK2 or without encryption. Batman-adv as well as L3 protocols are able to communicate between routers. This new problem does not happen with current stable AA mac80211 and hostapd. This article seems to identify the issue: http://wiki.villagetelco.org/index.php/Information_about_cell-id_splitting,_stuck_beacons,_and_failed_IBSS_merges ! Cmsv On 10/20/2013 05:37 PM, cmsv wrote: Hello Felix I replaced mac80211 and hostapd from AA tree by the ones from your git and recompiled a new image. The problem with adhoc and wpa that i described no longer happens and both routers are able to communicate with each other with regardless of which one starts or restarts the network; the wifi interface or reboots. On 10/19/2013 01:38 PM, Felix Fietkau wrote: On 2013-10-19 7:30 PM, cmsv wrote: I have recently experienced a problem when using wpa encryption on adhoc interfaces. Description: When both routers power up at the same time everything works without problems and bother can see and communicate with each other on layer 2 (batman-adv) and layer 3; however if one reboots or restarts the wireless interface; communication is no longer possible and both routers stop seeing each other in both layers. Rebooting both at the same time gets them to work again with each other. Someone mentioned that this might be caused due to the latest hostpad not being pulled. Any feedback is welcome. On both routers: option encryption 'psk2' wpad 20130405-1 DISTRIB_REVISION=r38401 DISTRIB_CODENAME=attitude_adjustment DISTRIB_TARGET=ar71xx/generic Here's a backport of mac80211+hostapd: http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary git://nbd.name/aa-mac80211.git Please try integrating that into your build tree and see if it fixes the issue. This problem is solved with the provided solution. There is still something that also changed and maybe is related to part of the described problem above. http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg20204.html mac80211.git also does not output the mac address to the wireless config. - Felix ___ openwrt-users mailing list openwrt-us...@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] atheros: /etc/diag.sh for FON2201
Unfortunately, firstboot is not an option for me with the EOC-1650 and OM1P. Both devices require mutually exclusive patches just to boot in the first place, I believe due to different flash CS pin on each. I have to compile seperate rootfs images for each device time. On Mon, Nov 18, 2013 at 11:00 AM, Jo-Philipp Wich j...@openwrt.org wrote: How does one start a new device-specific target for the atheros platform? One approach that might work is trying to identify the board by its radio, then apply the required configuration on firstboot. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] atheros: /etc/diag.sh for FON2201
Also, apologies for confusing typo: compile separate rootfs images for each device type. On Mon, Nov 18, 2013 at 11:58 AM, Ben West b...@gowasabi.net wrote: Unfortunately, firstboot is not an option for me with the EOC-1650 and OM1P. Both devices require mutually exclusive patches just to boot in the first place, I believe due to different flash CS pin on each. I have to compile seperate rootfs images for each device time. On Mon, Nov 18, 2013 at 11:00 AM, Jo-Philipp Wich j...@openwrt.org wrote: How does one start a new device-specific target for the atheros platform? One approach that might work is trying to identify the board by its radio, then apply the required configuration on firstboot. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
reserved [315651.47] 2389 pages shared [315651.47] 5924 pages non-shared [315651.47] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [315651.47] cache: kmalloc-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0 [315651.47] node 0: slabs: 0, objs: 0, free: 0 [315651.72] ath: skbuff alloc of size 1926 failed [315651.73] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315651.73] Call Trace:[8027a0b8] 0x8027a0b8 [315651.73] [8027a0b8] 0x8027a0b8 [315651.73] [800b041c] 0x800b041c [315651.73] [800b2680] 0x800b2680 [315651.73] [800d69a4] 0x800d69a4 [315651.73] [8019ee50] 0x8019ee50 [315651.73] [8027b574] 0x8027b574 [315651.73] [80072c24] 0x80072c24 [315651.73] [801e853c] 0x801e853c [315651.73] [81bb80c0] 0x81bb80c0 [315651.73] [800d804c] 0x800d804c [315651.73] [80de51f4] 0x80de51f4 [315651.73] [801e7c44] 0x801e7c44 [315651.73] [8027a2a0] 0x8027a2a0 [315651.73] [81bb80c0] 0x81bb80c0 [315651.73] [80de65b0] 0x80de65b0 [315651.73] [80de4628] 0x80de4628 [315651.73] [80076ec8] 0x80076ec8 [315651.73] [80077340] 0x80077340 [315651.73] [8027d8cc] 0x8027d8cc [315651.73] [800955b0] 0x800955b0 [315651.73] [80077468] 0x80077468 [315651.73] [800773f0] 0x800773f0 [315651.73] [800773f0] 0x800773f0 [315651.73] [8008a940] 0x8008a940 [315651.73] [80064b90] 0x80064b90 [315651.73] [8008a8b8] 0x8008a8b8 [315651.73] [80064b80] 0x80064b80 [315651.73] [315651.73] Mem-Info: [315651.73] Normal per-cpu: [315651.73] CPU0: hi:0, btch: 1 usd: 0 [315651.73] active_anon:325 inactive_anon:475 isolated_anon:0 [315651.73] active_file:1421 inactive_file:1233 isolated_file:0 [315651.73] unevictable:0 dirty:0 writeback:0 unstable:0 [315651.73] free:68 slab_reclaimable:385 slab_unreclaimable:2131 [315651.73] mapped:574 shmem:48 pagetables:72 bounce:0 [315651.73] Normal free:272kB min:720kB low:900kB high:1080kB active_anon:1300kB inactive_anon:1900kB active_file:5684kB inactive_file:4932kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:2296kB shmem:192kB slab_reclaimable:1540kB slab_unreclaimable:8524kB kernel_stack:344kB pagetables:288kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no [315651.73] lowmem_reserve[]: 0 0 [315651.73] Normal: 2*4kB 21*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 272kB [315651.73] 2715 total pagecache pages [315651.73] 13 pages in swap cache [315651.73] Swap cache stats: add 41, delete 28, find 3/7 [315651.73] Free swap = 3004kB [315651.73] Total swap = 3068kB [315651.73] 8192 pages RAM [315651.73] 876 pages reserved [315651.73] 2389 pages shared [315651.73] 5924 pages non-shared [315651.73] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [315651.73] cache: kmalloc-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0 [315651.73] node 0: slabs: 0, objs: 0, free: 0 ... [315653.02] ath: skbuff alloc of size 1926 failed [315653.03] ath: skbuff alloc of size 1926 failed [315653.03] ath: skbuff alloc of size 1926 failed [315653.04] ath: skbuff alloc of size 1926 failed [315653.04] ath: skbuff alloc of size 1926 failed [315653.05] ath: skbuff alloc of size 1926 failed [315653.05] ath: skbuff alloc of size 1926 failed [315653.06] ath: skbuff alloc of size 1926 failed [315653.06] ath: skbuff alloc of size 1926 failed [315653.07] ath: skbuff alloc of size 1926 failed [315653.07] ath: skbuff alloc of size 1926 failed ... [315653.37] ieee80211 phy0: failed to reallocate TX buffer [316015.39] ath: phy0: Failed to stop TX DMA, queues=0x004! [316016.62] ath: phy0: Failed to stop TX DMA, queues=0x004! [316017.64] ath: phy0: Failed to stop TX DMA, queues=0x004! ... On Sat, Nov 9, 2013 at 12:38 PM, Bastian Bittorf bitt...@bluebottle.comwrote: * Ben West b...@gowasabi.net [09.11.2013 19:22]: anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then we have zram active on all nodes but tweaked the 'swappiness' value to 0 - the default is 65. the higher the number, the more likely the kernel swaps out. if set to 0 zram is only used if the is no other possibility. ofcourse: if swapping begins, the box freezes for some seconds but it does not die. the kernel likes to swap out processes which are not in use, e.g. uhttpd or dropbear. olsrd or other active processes are very unlikely to be swapped - the kernel is smart somehow 8-) bye, bastian
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
Hmm, actually I discovered that wpa_supplicant apparently wrote a 240Kbyte dump file on this device, with approximately the same timestamp as when the memory errors started appearing in dmesg. /tmp/wpa_supplicant.1625.11.1384060826.core I've retained the dump file, if anyone perhaps wants it. Likewise, I'd be curious if anyone else has seen such a dump file appear before, as this is my first. (Or at least it is the first where I had a chance to inspect /tmp before rebooting.) On Mon, Nov 11, 2013 at 12:49 PM, Ben West b...@gowasabi.net wrote: Thank you Bastian for the recommendation to look into the swappiness parameter. I had previously been curious whether I could integrate the *mlock* tool to tell kernel explicitly which processes to not swap out (e.g. olsrd, wpa_supplicant). I also just discovered a Nanostation M mesh node running r38347 which had recently suffered memory exhaustion, although it thankfully remained in a controllable/recoverable state. This device had 3Mbytes of compressed swap available, and I'm quoting relevant portions of dmesg below for the list's reference. It appears that an initial page allocation failure occurred at 315650.43, causing subsequent failures in the mac80211 TX buffer, etc. dmesg shows nothing immediately preceding timestamp 315650.43 to suggest a specific cause. I am assuming incidents like these are occurring due to an ill-behaved process (or processes) attempting to allocate several MBytes for itself, failing that, and also causing memory errors for random resident processes in consequence. The only recovery I know for these incidents is to just reboot. [315650.43] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315650.43] Call Trace:[8027a0b8] 0x8027a0b8 [315650.43] [8027a0b8] 0x8027a0b8 [315650.43] [800b041c] 0x800b041c [315650.43] [800b2680] 0x800b2680 [315650.43] [800931b4] 0x800931b4 [315650.43] [800d69a4] 0x800d69a4 [315650.43] [8027b574] 0x8027b574 [315650.43] [800d7134] 0x800d7134 [315650.43] [80d2020c] 0x80d2020c [315650.43] [801e8d90] 0x801e8d90 [315650.43] [80d202b8] 0x80d202b8 [315650.43] [80d21608] 0x80d21608 [315650.43] [80de087c] 0x80de087c [315650.43] [800a4d1c] 0x800a4d1c [315650.43] [801f3e1c] 0x801f3e1c [315650.43] [80207648] 0x80207648 [315650.43] [800b2be8] 0x800b2be8 [315650.43] [8020793c] 0x8020793c [315650.43] [800d6790] 0x800d6790 [315650.43] [801ef644] 0x801ef644 [315650.43] [800929c8] 0x800929c8 [315650.43] [80077340] 0x80077340 [315650.43] [8027d8cc] 0x8027d8cc [315650.43] [800955b0] 0x800955b0 [315650.43] [80077468] 0x80077468 [315650.43] [800773f0] 0x800773f0 [315650.43] [800773f0] 0x800773f0 [315650.43] [8008a940] 0x8008a940 [315650.43] [80064b90] 0x80064b90 [315650.43] [8008a8b8] 0x8008a8b8 [315650.43] [80064b80] 0x80064b80 [315650.43] [315650.43] Mem-Info: [315650.43] Normal per-cpu: [315650.43] CPU0: hi:0, btch: 1 usd: 0 [315650.43] active_anon:325 inactive_anon:475 isolated_anon:0 [315650.43] active_file:1421 inactive_file:1233 isolated_file:0 [315650.43] unevictable:0 dirty:0 writeback:0 unstable:0 [315650.43] free:68 slab_reclaimable:385 slab_unreclaimable:2131 [315650.43] mapped:574 shmem:48 pagetables:72 bounce:0 [315650.43] Normal free:272kB min:720kB low:900kB high:1080kB active_anon:1300kB inactive_anon:1900kB active_file:5684kB inactive_file:4932kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:2296kB shmem:192kB slab_reclaimable:1540kB slab_unreclaimable:8524kB kernel_stack:344kB pagetables:288kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no [315650.43] lowmem_reserve[]: 0 0 [315650.43] Normal: 2*4kB 21*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 272kB [315650.43] 2715 total pagecache pages [315650.43] 13 pages in swap cache [315650.43] Swap cache stats: add 41, delete 28, find 3/7 [315650.43] Free swap = 3004kB [315650.43] Total swap = 3068kB [315650.43] 8192 pages RAM [315650.43] 876 pages reserved [315650.43] 2389 pages shared [315650.43] 5924 pages non-shared [315650.43] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [315650.43] cache: kmalloc-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0 [315650.43] node 0: slabs: 0, objs: 0, free: 0 [315650.70] ieee80211 phy0: failed to reallocate TX buffer [315650.70] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315650.70] Call Trace:[8027a0b8] 0x8027a0b8 [315650.70] [8027a0b8] 0x8027a0b8 [315650.70] [800b041c] 0x800b041c [315650.70] [800b2680] 0x800b2680 [315650.70] [800d69a4] 0x800d69a4 [315650.70
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
As someone who runs AA r38247 patched to include zram support, I can add anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then back in. For this reason, I only enable 3MBytes of swap, preferring not to depend on it for normal operation. Only enough so that a node can detect when it's in a low-memory state and do something to recover (e.g. reboot). I've not had opportunity to test whether this problem also happens with the newer kernel under BB. On Thu, Nov 7, 2013 at 4:10 PM, Hauke Mehrtens ha...@hauke-m.de wrote: On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Setting fragmentation threshold in atheros and ar71xx?
Hello, The wiki page for wireless settings appears to indicate that the frag setting (fragmentation threshold) is only understood by the madwifi driver: http://wiki.openwrt.org/doc/uci/wireless#madwifi.options1 However, setting this option does seem to work for atheros target running AA r38347, using mac80211 / ath5k driver: /etc/config/wireless: config wifi-device radio0 option type mac80211 option channel 7 option hwmode 11g option macaddr 00:XX:XX:XX:XX:XX option beacon_int 337 option rts 256 option frag 2346 option disabled 0 config wifi-iface option network 'mesh' option mode 'adhoc' option device 'radio0' option ssid 'MyMesh' option bssid '02:CA:FF:EE:BA:BE' root@OpenWRT:~# iwconfig ... wlan0 IEEE 802.11bg ESSID:MyMesh Mode:Ad-Hoc Frequency:2.442 GHz Cell: 02:CA:FF:EE:BA:BE Tx-Power=27 dBm RTS thr=256 B Fragment thr=2346 B Encryption key:off Power Management:off However, the frag option does not appear to work for ar71xx target, specifically for a AR7240 in a UBNT Nanostation Loco. Is setting the fragmentation threshold supported for ar71xx? -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] sysupgrade support for OM2P working in AA?
Hi Marek, This is the wiki page in question: http://wiki.openwrt.org/toh/openmesh/om2p#upgrading.openwrt Thank you for clarifying that sysupgrade does work! On Thu, Oct 17, 2013 at 6:17 AM, Marek Lindner mareklind...@neomailbox.chwrote: On Wednesday 16 October 2013 09:48:33 Ben West wrote: I noticed that my build tree for AA r38347 only produces the openwrt-ar71xx-generic-om2p-squashfs-factory.bin image for Open Mesh OM2P, not the sysupgrade image. The wiki page suggests these images are to be manually flashed to the device's partitions, instead of using sysypgrade: build_dir/linux-ar71xx_generic/vmlinux-om2p.uImage build_dir/linux-ar71xx_generic/root.squashfs What wiki would that be ? Do you have a link ? The revision history for this platform's upgrade script doesn't suggest anything has been intentionally disabled: https://dev.openwrt.org/log/branches/attitude_adjustment/target/linux/ar71xx /base-files/lib/upgrade Or should the factory image now be used when running sysupgrade on an OM2P? The OM2P build process generates generates a single image for sysupgrade and installations. In short: Yes, you can use the 'factory' image for sysupgrading. Since I only have one such device, I'm asking here first before possibly finding things out the hard way. ;) You will have a hard time bricking your node because you can always recover using ap51-flash. Cheers, Marek -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] sysupgrade support for OM2P working in AA?
I noticed that my build tree for AA r38347 only produces the openwrt-ar71xx-generic-om2p-squashfs-factory.bin image for Open Mesh OM2P, not the sysupgrade image. The wiki page suggests these images are to be manually flashed to the device's partitions, instead of using sysypgrade: build_dir/linux-ar71xx_generic/vmlinux-om2p.uImage build_dir/linux-ar71xx_generic/root.squashfs The revision history for this platform's upgrade script doesn't suggest anything has been intentionally disabled: https://dev.openwrt.org/log/branches/attitude_adjustment/target/linux/ar71xx/base-files/lib/upgrade Or should the factory image now be used when running sysupgrade on an OM2P? Since I only have one such device, I'm asking here first before possibly finding things out the hard way. ;) -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?
0( 0) 14387 31865 C 11 4.9 48.48.3 0( 0) 107143 238102 6 2.9 49.4 100.0 1( 1) 5839 20081 B 9 5.2 58.0 50.0 0( 0) 10665 38516 12 3.3 28.10.0 0( 0) 40247 120171 A P 1812.6 73.0 72.2 13( 18) 369301 883412 D 24 4.6 20.3 33.3 0( 0) 296475 1216256 36 0.08.30.0 0( 0) 37298 330903 48 0.09.30.0 0( 0) 13596 222798 54 0.07.70.0 0( 0) 34449 388569 Total packet count::ideal 8629 lookaround 958 On Sun, Oct 13, 2013 at 1:21 PM, Felix Fietkau n...@openwrt.org wrote: On 2013-10-13 7:49 PM, Ben West wrote: The devices in 'production' use are Engenius EOC-01650 and Open Mesh OM1Ps, both with Atheros SoC AR2315. These are gradually by being replaced by UBNT Nanostation Loco M2's, with SoC AR7240. The small adhoc network I was using for proving firmware, where the decrease in throughput was observed, is comprised of 3 EOC-1650's, hung up at various locations around my building. My simple speed test was just to wget a 500Mbyte file from a 100Mbit wired LAN connected to one of the nodes across the adhoc network to /dev/null. Indeed, iperf would be more precise, but wget seemed sufficient just to allow me to observe large differences in throughput, e.g. 1Mbit/s vs 3Mbit/s average. At any rate, is it preferred to compare throughput values I've observed using AA r36669 with those observed running AA r38346, or with throughput values measured using current trunk. I understand that since AA only receives a selection of backports from trunk, it can occasionally be a hodgepodge of working vs suboptimal code. You can use the full trunk backport by using the package from this repository: http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary I'd recommend comparing that with the older version. In addition to the different throughput values, please also provide rate control statistics from /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/*/rc_stats Thanks, - Felix -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?
Also, sorry for typo: transfers averaged to *415KBytes/sec* ... On Mon, Oct 14, 2013 at 10:55 AM, Ben West b...@gowasabi.net wrote: Hi Felix, I've tried testing both AA r38347 as-is, and also AA recompiled with the back-ported copies of hostapd and mac80211 packages that you provided on your git repo (thank you!). Unfortunately, in both instances, I saw the adhoc link between two Engenius EOC-1650 freeze entirely during a long wget transfer. That is, the transfer itself stalls, even ping packages don't pass. Several minutes after stopping the wget transfer, the adhoc returns to normal. Here are rate control stats on the remote node (i.e. the one not connected to a wired LAN) before and after attempting the long wget transfer: BEFORE root@WasabiNet-mushmaus:~# cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats rate throughput ewma prob this prob this succ/attempt success attempts 1 0.00.00.0 0( 5) 145783 2 0.7 37.30.0 0( 1) 548 956 P 5.5 4.9 91.3 100.0 1( 1) 158 395 D 11 6.0 59.1 100.0 0( 0) 267 643 6 1.8 30.60.0 0( 0) 231 508 9 3.3 37.20.0 0( 0) 349 727 12 4.6 39.3 33.3 0( 0) 6411106 C 18 6.0 34.80.0 0( 0) 351 698 B2410.6 46.9 100.0 1( 1) 63 326 36 4.6 14.20.0 0( 6) 156 627 48 0.00.10.0 0( 0) 7712441 A 5424.2 52.3 33.3 1( 3) 8422721 Total packet count::ideal 5951 lookaround 664 AFTER root@WasabiNet-mushmaus:~# cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats rate throughput ewma prob this prob this succ/attempt success attempts 1 0.00.00.0 0( 6) 18 25581 2 0.3 18.20.0 0( 0) 5641122 5.5 3.3 62.0 100.0 0( 0) 4761159 11 5.5 54.4 100.0 0( 0) 3391024 6 2.2 37.7 100.0 0( 0) 39005892 9 3.1 35.30.0 0( 0) 6141313 D 12 7.9 67.0 100.0 0( 0) 6601374 C 18 9.6 55.8 50.0 0( 0) 5361509 24 3.7 16.5 33.3 0( 0) 2641248 36 6.7 20.90.0 0( 0) 166 867 A P 4827.9 67.2 100.0 0( 0) 16825160 B5413.4 29.0 33.3 0( 0) 3788 10223 Total packet count::ideal 8510 lookaround 946 On both devices running AA r36669, long wget transfers work fine. In my instance, the transfers averaged to 415Bytes/sec over a single test that moved 2GBytes. For comparison, below are the rc_stats on this same device running AA r36669, before and after a successful long transfer. I do notice that r36669 reports 0 throughput at higher rates like 54Mbit/s, unlike r38347. Maybe throughput is being measured inaccurately? BEFORE root@WasabiNet-mushmaus:~# cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats rate throughput ewma prob this prob this succ/attempt success attempts 1 0.5 52.2 100.0 0( 0) 25 39 2 1.2 63.0 100.0 0( 0) 4 7 5.5 3.1 58.9 100.0 0( 0) 4 6 B P 11 8.7 86.0 100.0 0( 0) 10 11 6 4.0 66.8 100.0 0( 0) 5 6 9 4.7 52.50.0 0( 0) 79 167 C 12 7.3 62.2 100.0 0( 0) 4 11 A 1811.7 67.5 50.0 1( 2) 587 969 D 24 5.0 22.2 19.9 0( 0) 4 34 36 0.00.00.0 0( 0) 0 12 48 0.00.00.0 0( 0) 0 12 54 0.00.00.0 0( 0) 0 12 Total packet count::ideal 653 lookaround 72 AFTER root@WasabiNet-mushmaus:~# cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats rate throughput ewma prob
Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?
The devices in 'production' use are Engenius EOC-01650 and Open Mesh OM1Ps, both with Atheros SoC AR2315. These are gradually by being replaced by UBNT Nanostation Loco M2's, with SoC AR7240. The small adhoc network I was using for proving firmware, where the decrease in throughput was observed, is comprised of 3 EOC-1650's, hung up at various locations around my building. My simple speed test was just to wget a 500Mbyte file from a 100Mbit wired LAN connected to one of the nodes across the adhoc network to /dev/null. Indeed, iperf would be more precise, but wget seemed sufficient just to allow me to observe large differences in throughput, e.g. 1Mbit/s vs 3Mbit/s average. At any rate, is it preferred to compare throughput values I've observed using AA r36669 with those observed running AA r38346, or with throughput values measured using current trunk. I understand that since AA only receives a selection of backports from trunk, it can occasionally be a hodgepodge of working vs suboptimal code. Thank you. On Sat, Oct 12, 2013 at 9:22 AM, Felix Fietkau n...@openwrt.org wrote: On 2013-10-12 4:16 PM, Ben West wrote: Hello All, I operate a small adhoc meshing network in a residential neighborhood, presently based on AA r36669 running on a mixture of ar71xx and atheros devices. On a small test network comprised of three atheros nodes, which I use for proving out new firmware, I noticed that AA r38346 demonstrates dramatically worse throughput between nodes than the same firmware compiled from r36669, with the nodes at identical locations / spacings. I have not yet had the opportunity to test whether this apparent regression also occurs on ar71xx devices. Is there a preferred method for documenting or reporting speed regressions on the mac80211 library, considering that accurately measuring such can be so difficult? Would it be best for me to attempt the same throughput tests using firmware compiled against current trunk, to see if the regression is also present there? Yes. Please also mention the exact SoC and wifi chip types that you're using, and how much the throughput changed (mbit/s before/after), and how exactly you're doing the tests. - Felix -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?
Hello All, I operate a small adhoc meshing network in a residential neighborhood, presently based on AA r36669 running on a mixture of ar71xx and atheros devices. On a small test network comprised of three atheros nodes, which I use for proving out new firmware, I noticed that AA r38346 demonstrates dramatically worse throughput between nodes than the same firmware compiled from r36669, with the nodes at identical locations / spacings. I have not yet had the opportunity to test whether this apparent regression also occurs on ar71xx devices. Is there a preferred method for documenting or reporting speed regressions on the mac80211 library, considering that accurately measuring such can be so difficult? Would it be best for me to attempt the same throughput tests using firmware compiled against current trunk, to see if the regression is also present there? Thank you. -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 08/10] wpa_supplicant: fix beacon_int configuration option
Here is that same patch, but against current trunk.
On Thu, Oct 10, 2013 at 6:02 AM, Bruno Randolf b...@einfach.org wrote:
wpa_supplicant expects beacon_int instead of beacon_interval in its config
file.
Signed-off-by: Bruno Randolf b...@einfach.org
---
package/hostapd/files/wpa_supplicant.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/hostapd/files/wpa_supplicant.sh
b/package/hostapd/files/wpa_supplicant.sh
index 0b5e1d3..bd86801 100644
--- a/package/hostapd/files/wpa_supplicant.sh
+++ b/package/hostapd/files/wpa_supplicant.sh
@@ -119,13 +119,13 @@ wpa_supplicant_setup_vif() {
;;
esac
- local fixed_freq bssid1 beacon_interval brates mrate
+ local fixed_freq bssid1 beacon_int brates mrate
config_get ifname $vif ifname
config_get bridge $vif bridge
config_get ssid $vif ssid
config_get bssid $vif bssid
bssid1=${bssid:+bssid=$bssid}
- beacon_interval=${beacon_int:+beacon_interval=$beacon_int}
+ beacon_int=${beacon_int:+beacon_int=$beacon_int}
local br brval brsub brstr
[ -n $basic_rate_list ] {
@@ -163,7 +163,7 @@ network={
$proto
$freq
${fixed:+fixed_freq=1}
- $beacon_interval
+ $beacon_int
$brates
$mrate
$ht_str
--
1.8.1.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
fix_wpa_supplicant_beacon_int.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] unknown network field 'beacon_int and wpa_supplicant
Hi cmsv,
Bruno's patch seems to have had its tab spacing munged in transit, which is
why the patch failed. I'm attaching a Gzipped version of that same patch,
against AA r38347, which should apply cleanly to your build tree.
As for leaving beacon_int unspecified, that would tell the driver to use
whatever default interval it has defined, which is likely driver-specific
(and probably rather small, i.e. 10ms or 50ms).
Note that Bruno and I have both also submitted this as a patch against
current trunk, meaning hopefully this will eventually get ported into AA.
On Thu, Oct 10, 2013 at 6:07 AM, Bruno Randolf b...@einfach.org wrote:
On 10/10/2013 11:28 AM, cmsv wrote:
I have encountered the following error while trying to patch the file:
patching file attitude_adjustment/package/**hostapd/files/wpa_supplicant.
**sh
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 163.
2 out of 2 hunks FAILED -- saving rejects to file
attitude_adjustment/package/**hostapd/files/wpa_supplicant.**sh.rej
AA revision 38351
Hi,
Check the patch I just posted which is against current AA 12.09. If it
does not apply to your revision, the patch is simple enough so you can make
the same changes by hand.
bruno
On 10/10/2013 03:22 AM, Bruno Randolf wrote:
Hi, This is a patch against AA which fixes it for us:
wpa_supplicant: fix beacon_int configuration option
wpa_supplicant expects beacon_int instead of beacon_interval in its
config file.
diff --git a/package/hostapd/files/wpa_**supplicant.sh
b/package/hostapd/files/wpa_**supplicant.sh
index 0b5e1d3..bd86801 100644
--- a/package/hostapd/files/wpa_**supplicant.sh
+++ b/package/hostapd/files/wpa_**supplicant.sh
@@ -119,13 +119,13 @@ wpa_supplicant_setup_vif() {
;;
esac
- local fixed_freq bssid1 beacon_interval brates mrate
+ local fixed_freq bssid1 beacon_int brates mrate
config_get ifname $vif ifname
config_get bridge $vif bridge
config_get ssid $vif ssid
config_get bssid $vif bssid
bssid1=${bssid:+bssid=$bssid**}
- beacon_interval=${beacon_int:+**beacon_interval=$beacon_int}
+ beacon_int=${beacon_int:+**beacon_int=$beacon_int}
local br brval brsub brstr
[ -n $basic_rate_list ] {
@@ -163,7 +163,7 @@ network={
$proto
$freq
${fixed:+fixed_freq=1}
- $beacon_interval
+ $beacon_int
$brates
$mrate
$ht_str
On 10/10/2013 12:17 AM, Ben West wrote:
I believe this problem appeared on or about r36682, which coincides with
a hostapd update to AA. This suggests a regression in hostapd w/r/t/ to
beacon interval code.
I can confirm the same problem happens when attempting to specify
beacon_int on a single psk2-encrypted adhoc interface, not just with
multi-VAPs as with the original poster. My test was on an Engenius
EOC-1650, atheros platform, running Attitude Adjustment r38347 that I
compiled.
The error quoted below goes away when I comment out the beacon_int
line in /etc/config/wireless. Likewise, this wireless config, with the
beacon_int line, works just fine under Attitude Adjustment r36669,
before the hostapd update.
root@OpenWRT:~# wifi restart
command failed: Device or resource busy (-16)
Successfully initialized wpa_supplicant
Line 12: unknown network field 'beacon_interval'.
Line 33: failed to parse network block.
Failed to read or parse configuration
'/var/run/wpa_supplicant-**wlan0.conf'.
enable_mac80211(radio0): Failed to set up wpa_supplicant for interface
wlan0
root@OpenWRT:~# cat /etc/config/wireless
config wifi-device radio0
option type mac80211
option channel 4
option hwmode 11g
option macaddr 00:02:6F:XX:XX:XX
option beacon_int 337
option diversity 0
option disabled 0
config wifi-iface
option network 'mesh'
option mode 'adhoc'
option device 'radio0'
option ssid 'MyMesh'
option bssid '02:CA:FF:EE:BA:BF'
option hidden '0'
option encryption 'psk2'
option key 'blahblahblahblahblah'
root@OpenWRT:~# cat /var/run/wpa_supplicant-wlan0.**conf
ctrl_interface=/var/run/wpa_**supplicant-wlan0
ap_scan=2
network={
mode=1
scan_ssid=0
ssid=MyMesh
bssid=02:CA:FF:EE:BA:BF
key_mgmt=WPA-PSK
proto=RSN
frequency=2427
fixed_freq=1
beacon_interval=337
psk=blahblahblahblahblah
}
root@OpenWRT:~# cat /etc/openwrt_release
DISTRIB_ID=MyCustomWRT
DISTRIB_RELEASE=CustomV2.1
DISTRIB_REVISION=r38347
DISTRIB_CODENAME=pre-release
DISTRIB_TARGET=atheros/**generic
DISTRIB_DESCRIPTION=My Custom Release
On Fri, Jun 28, 2013 at 9:07 PM, cmsv c...@wirelesspt.net
mailto:c...@wirelesspt.net wrote:
Info:
http://wiki.openwrt.org/doc/**uci/wireless#wpa.enterprise.**
access.pointhttp://wiki.openwrt.org/doc/uci/wireless
Re: [OpenWrt-Devel] [OpenWrt-Users] unknown network field 'beacon_int and wpa_supplicant
was not updated to work with with wpa_supplicant ? Also; will this option work if specified as beacon_interval in /et/config/wireless ? The wiki describes it as beacon_int -- Site: http://wirelesspt.net Mesh: http://tinyurl.com/wirelesspt Admin: http://wirelesspt.net/wiki/Cmsv Twitter: http://twitter.com/wirelesspt Suporte técnico via sms: 91 19 11 798 Donativos/Paypal: http://tinyurl.com/doar-verba Chave publica PGP/SSH: http://wirelesspt.net/arquivos/pk Email assinado digitalmente pelo emissor assegurando autenticidade ___ openwrt-users mailing list openwrt-us...@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-users -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Possible hostapd / IBSS-RSN regression on Attitude Adjustment r36682
Hi Radu, My first recommendation would be to repeat your attempt using the *wpad*package on all nodes, instead of hostapd / wpa_supplicant. If you have the wpad package already compiled, you should just be able to remove hostapd and wpa_supplicant and then install wpad; both use same configuration for IBSS-RSN. A possible underlying cause is that AA r36682 coincides with a hostapdupdate in the OpenWRT source (likewise for wpa_supplicant, wpad, and their derivatives). Here are a couple posts to this listserv last month from Antonio Quartulli, who works with open-mesh.org and BATMAN, about the problem. He mentioned submitting patches to the hostapd/wap_supplicant list too. https://lists.openwrt.org/pipermail/openwrt-devel/2013-July/020685.html https://lists.openwrt.org/pipermail/openwrt-devel/2013-July/020689.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [B.A.T.M.A.N.] wpa/wpa2 adhoc + batman-adv not working
If it helps narrow down causes, I noticed that encrypted adhoc + wpa2 stopped working for me on AA r36682 (albeit not using batman). I had the same problem; unable to see any other stations on the adhoc mesh using 'iw wlan0 station dump.' r36682 does coincide with a hostapd update pushed to the AA branch, and the problem went away by reverting to r36681. On Mon, Jul 15, 2013 at 3:49 PM, cmsv c...@wirelesspt.net wrote: can you elaborate about the small change to mac8021 ? Regarding the IBSS-RSN Patches for wpa* try to push them but i am guessing that they will go to trunk or are there in chances of them going to Attitude adjustment? I can test and inform about it. Also if you know where i can get them i can also try to patch and try to see if they work properly. On 07/15/2013 03:52 AM, Antonio Quartulli wrote: On Sun, Jul 14, 2013 at 10:14:07PM -0400, cmsv wrote: Tested with: Attitude Adjustment r37270 Batman-adv 2013.2 (current stable release ) I have tested wpa* and it is currently not working with batman-adv. The ssid for the mesh is encrypted but batman-adv/batctl is unable to see/ping any nodes. I tested with wpa, wpa2 and without encryption. without encryption i was able to get the other nodes to join the mesh and have them communicate with each other. I believe someone has once mentioned about a patch that was related to this problem and i wonder if it is already included in these software releases or not and if other people are experiencing this same problem. Patches for making IBSS-RSN (WPA2 for ADHOC) work correctly are still pending on the hostapd/wpa_supplicant mailing list...I hope they get merged soon. If they are not merged in the upstream hostapd, I'll try to push them to openwrt. Also a small change to mac80211 is required (this has already been merged upstream) Cheers, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: [PATCH][include] Update CyaSSL library to last version 2.6.0
Thank you all for filling in details about remaining steps to get cyassl Makefile updated. Here are sizes of the compiled cyassl ipk under ar71xx platform: -rw-r--r-- 1 ben ben 105819 Jun 11 18:53 libcyassl_2.6.0-1_ar71xx.ipk ... and under atheros: -rw-r--r-- 1 ben ben 105826 Jun 6 14:10 libcyassl_2.6.0-1_atheros.ipk I'm assuming the ~40Kbyte size increase for my Massimo's instance results from our enabling additional options while compiling cyassl, for use with libcurl. Namely --enable-dtls and --enable-opensslextra. I have not had opportunity to verify cyassl still functions adequately with libcurl, with these options disabled. On Mon, Jun 17, 2013 at 6:47 AM, Sebastian Muszynski ba...@linkt.de wrote: Am Montag, 17. Juni 2013, 13:40:20 schrieb Felix Fietkau: On 2013-06-17 1:33 PM, Sebastian Muszynski wrote: Am Montag, 17. Juni 2013, 13:16:13 schrieb Felix Fietkau: On 2013-06-17 1:57 AM, Ben West wrote: I can confirm the 100-sizeof_long_long.patch patch for curl provided by Massimo does work fine for me under ar71xx and atheros platforms. That is, I can now successfully have libcurl link to cyassl instead of openssl. What additional steps are needed to close this thread, specifically to update the cyassl Makefile to pull version 2.6.0? A size comparison would be useful. CyaSSL: insgesamt 340 -rw-r--r-- 1 x x 43182 Jun 17 13:23 curl_7.29.0-1_ar71xx.ipk -rw-r--r-- 1 x x 123484 Jun 17 13:23 libcurl_7.29.0-1_ar71xx.ipk -rw-r--r-- 1 x x 101719 Jun 17 13:23 libcyassl_2.6.0-1_ar71xx.ipk -rw-r--r-- 1 x x 31580 Jun 17 13:23 libpthread_0.9.33.2-1_ar71xx.ipk -rw-r--r-- 1 x x 40643 Jun 17 13:23 zlib_1.2.7-1_ar71xx.ipk OpenSSL: -rw-r--r-- 1 x x 42620 Jun 16 00:40 curl_7.29.0-1_ar71xx.ipk -rw-r--r-- 1 x x 133415 Jun 16 00:39 libcurl_7.29.0-1_ar71xx.ipk -rw-r--r-- 1 x x 630003 Jun 16 00:30 libopenssl_1.0.1e-1_ar71xx.ipk -rw-r--r-- 1 x x 31285 Jun 16 00:14 libpthread_0.9.33.2-1_ar71xx.ipk -rw-r--r-- 1 x x 40219 Jun 16 00:18 zlib_1.2.7-1_ar71xx.ipk CyaSSL is pretty small, so you can use it on small flashs (4MB). Curl + OpenSSL does not fit usually. I meant a size comparison of old CyaSSL vs. new CyaSSL of course :) Ups. :-) -rw-r--r-- 1 x x 64570 Jun 16 00:29 libcyassl_1.6.5-2_ar71xx.ipk This is the filesize of the current version in trunk. Kind regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: [PATCH][include] Update CyaSSL library to last version 2.6.0
I can confirm the 100-sizeof_long_long.patch patch for curl provided by Massimo does work fine for me under ar71xx and atheros platforms. That is, I can now successfully have libcurl link to cyassl instead of openssl. What additional steps are needed to close this thread, specifically to update the cyassl Makefile to pull version 2.6.0? On Thu, May 23, 2013 at 3:17 PM, Massimo Vellucci vema...@gmail.com wrote: Hi, sorry for the delay, I found the problem about the curl library. There is a bug in configure.ac file of curl package. You have to add the file 100-sizeof_long_long.patch in the pathtrunk/feeds/packages/libs/curl/patches diff -u a/configure.ac b/configure.ac --- a/configure.ac 2013-02-06 10:47:19.0 +0100 +++ b/configure.ac 2013-05-23 22:00:59.233980076 +0200 @@ -2928,6 +2928,7 @@ AC_CHECK_SIZEOF(size_t) AC_CHECK_SIZEOF(long) +AC_CHECK_SIZEOF(long long) AC_CHECK_SIZEOF(int) AC_CHECK_SIZEOF(short) CURL_CONFIGURE_LONG Curl did not determine the size of the type long long that is a value necessary to CyaSSL. My libs/curl/Makefile --- libs/curl/Makefile +++ libs/curl/Makefile @@ -43,7 +43,7 @@ $(call Package/curl/Default) SECTION:=libs CATEGORY:=Libraries - DEPENDS:=+libopenssl +zlib + DEPENDS:=+libcyassl +zlib TITLE:=A client-side URL transfer library endef @@ -70,7 +70,8 @@ --enable-tftp \ --disable-verbose \ --with-random=/dev/urandom \ ---with-ssl=$(STAGING_DIR)/usr \ +--with-cyassl=$(STAGING_DIR)/usr \ +--without-ssl --without-ca-bundle \ --without-gnutls \ --without-krb4 \ @@ -81,7 +82,7 @@ $(call autoconf_bool,CONFIG_IPV6,ipv6) \ CONFIGURE_VARS += \ -LIBS=-lcrypto -lssl -lz \ +LIBS=-lcyassl -lz \ CC=$(filter-out ccache,$(TARGET_CC)) With these settings I was able to compile curl for atheros 71xx Bye Massimo 2013/5/21 Massimo Vellucci vema...@gmail.com I'm sorry but these days I have been very busy with work. I have not found the time to do the tests. I would like to remove OpenSSL from my application that I am developing and using CyaSSL. The problem of porting applications from OpenSSL to CyaSSL is requires a lot of work. The two libraries are not compatible 100% 2013/5/21 Ben West b...@gowasabi.net For an update, I have since been able to get libcurl to link to the new cyassl package, provided I explicitly insert sizeof_long definitions into libcurl header files, shown in the patch below. It is unusual that libcurl seems to require these additional defines to link to libcyassl.so, but uhttpd-mod-tls does not. I'm not sure if this patch resides properly with the package curl, perhaps accompanied by another patch that defines a new sub-package libcurl-cyassl. Massimo, are you using the newer version of cyassl for anything besides uhttpd? --- curl-7.29.0/include/curl/curl.h.201305182013-05-17 23:25:23.816083944 -0500 +++ curl-7.29.0/include/curl/curl.h2013-05-17 23:30:43.304082086 -0500 @@ -118,6 +118,13 @@ typedef void CURL; #endif #endif +/* These definitions needed for cyassl */ +/* The size of `long', as computed by sizeof. */ +#define SIZEOF_LONG 4 + +/* The size of `long long', as computed by sizeof. */ +#define SIZEOF_LONG_LONG 8 + #ifndef curl_socket_typedef /* socket typedef */ #if defined(WIN32) !defined(__LWIP_OPT_H__) On Fri, May 17, 2013 at 12:00 PM, Ben West b...@gowasabi.net wrote: Thank you for responding. Below is the diff of the curl Makefile, against that included in the Attitude Adjustment v12.09 packages herehttps://dev.openwrt.org/browser/branches/packages_12.09/libs/curl/Makefile . Note that the addition of -lm to libraries for curl to link to came from my own research in pending OpenWRT issues about compiling curl with cyassl. However, the error about long long size mismatch occurs whether libm.so is included or not. Index: libs/curl/Makefile === --- libs/curl/Makefile(revision 36652) +++ libs/curl/Makefile(working copy) @@ -43,7 +43,7 @@ $(call Package/curl/Default) SECTION:=libs CATEGORY:=Libraries - DEPENDS:=+libopenssl +zlib + DEPENDS:=+libcyassl +zlib TITLE:=A client-side URL transfer library endef @@ -70,7 +70,8 @@ --enable-tftp \ --disable-verbose \ --with-random=/dev/urandom \ ---with-ssl=$(STAGING_DIR)/usr \ +--with-cyassl=$(STAGING_DIR)/usr \ +--without-ssl --without-ca-bundle \ --without-gnutls \ --without-krb4 \ @@ -81,7 +82,7 @@ $(call autoconf_bool,CONFIG_IPV6,ipv6) \ CONFIGURE_VARS += \ -LIBS=-lcrypto -lssl -lz \ +LIBS=-lm -lcyassl -lz \ CC=$(filter-out ccache,$(TARGET_CC)) define Build/Compile On Fri, May 17, 2013 at 2:10 AM, Massimo Vellucci vema...@gmail.comwrote: CyaSSL must determine the environment to recognize the size
[OpenWrt-Devel] Possible hostapd / IBSS-RSN regression on Attitude Adjustment r36682
A TP-Link TL-MR3020 router on which I had installed custom-compiled Attitude Adjustment r36608 was participating in an IBSS-RSN encrypted adhoc wireless network. After refreshing my build tree to the most current AA (r36922), recompiling with the same package list and configuration, and reflashing the node, it dropped off the adhoc network entirely. That is, the TL-MR3020 running r36922 didn't see any of the other stations still running r36608 on its adhoc network, and vice versa. I reverted my build tree to immediately before this changeset: https://dev.openwrt.org/changeset/36682/branches/attitude_adjustment/package/hostapd ... and IBSS-RSN encryption returned with AA r36681. No changes were made to /etc/config/wireless or anywhere else, just reflashed the device with sysupgrade twice. Here is the /etc/config/wireless I am using on the TP-Link (other devices on the adhoc net use equivalent): config wifi-device radio0 option type mac80211 option channel 4 option hwmode 11ng option macaddr A0:F3:C1:XX:XX:XX option htmode HT20 list ht_capab SHORT-GI-20 list ht_capab SHORT-GI-40 list ht_capab RX-STBC1 list ht_capab DSSS_CCK-40 option beacon_int 997 # REMOVE THIS LINE TO ENABLE WIFI: option disabled 0 config wifi-iface option network 'mesh' option mode 'adhoc' option device 'radio0' option ssid 'MyMesh' option bssid '02:EE:EE:EE:EE:EE' option hidden '1' option encryption 'psk2' option key 'areallygoodpassword' config wifi-iface option device radio0 option network ap2 option mode ap option ssid 'private-ap' option key goodpassword option encryption psk option hidden '0' config wifi-iface option network 'ap1' option mode 'ap' option device 'radio0' option ssid 'public-ap' option hidden '1' option encryption none Has there been a regression in hostapd w/r/t IBSS-RSN support, or possibly a configuration change? P.S. I use the full hostapd and wpa_supplicant packages, not hostapd-mini or wpad-mini. -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LUCI works extremely slow...
Quoting from the supported hardware list, and likewise from the Attitude Adjustment announcement made earlier this year: Note that with the release of 'Attitude Adjustment (12.09 final)' on 25th April 2013, 'Lower end devices with only 16 MiB RAM will easily run out of Memory…'. http://wiki.openwrt.org/toh/start I do see that some device on that list are spec'ed at 16MB RAM, and I can only guess those are old entries. My own attempts to get recent versions of OpenWRT running on a FONera 2100 router, which has the same CPU and RAM capacity as your device, proved futile due to memory exhaustion and random kernel crashes. Even without the LUCI UI. My understanding is that the memory requirement is a hard limit. On Tue, Jun 11, 2013 at 4:13 AM, Wojciech Kromer wojciech.kro...@dgt.com.pl wrote: My understanding is that OpenWRT Attitude Adjustment, along with current versions of trunk, are not expected to run in any reliable way under less than 32MB of RAM. In particular, the v3.x kernel is not supported for so little memory, and the OpenWRT dev community likewise doesn't support it. Hi Ben What you means is v3.x kernel don't support 32MB RAM? not the issue of LUCI? Everything else works fine, and I can see some devices with same hardware on openwrt supported list. Also new gargoyle works pretty good. During LUCI operations filesystem is heavly used, I can see a 50-90% CPU usage in [spi0] kernel process. Using precompiled version helps a little, but it's still unusable. Best regards. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add elliptic curve crypto compilation options to openssl
Etienne, would you happen to know if the EC implementations in other embedded SSL implementations like cyasslhttp://www.yassl.com/yaSSL/Docs-cyassl-manual-4-features.htmlwould work with authsae? On Tue, May 28, 2013 at 12:11 PM, Etienne Champetier etienne.champet...@free.fr wrote: This patch adds EC compilation options to openssl OPENSSL_WITH_EC is needed for authsae (OPENSSL_WITH_EC2M isn't) Activating ec (but not ec2m) in openssl take 35Ko more on ar71xx (ipk size) Activating both take 52Ko. Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr diff --git a/package/libs/openssl/Config.in b/package/libs/openssl/Config.in index 70d520c..b8a3779 100644 --- a/package/libs/openssl/Config.in +++ b/package/libs/openssl/Config.in @@ -1,6 +1,15 @@ menu Configuration depends on PACKAGE_libopenssl +config OPENSSL_WITH_EC + bool + prompt Enable elliptic curve support + +config OPENSSL_WITH_EC2M +bool +depends on OPENSSL_WITH_EC +prompt Enable ec2m support + config OPENSSL_ENGINE_CRYPTO bool prompt Crypto acceleration support diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile index 0091579..8b0f524 100644 --- a/package/libs/openssl/Makefile +++ b/package/libs/openssl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openssl PKG_VERSION:=1.0.1e -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://www.openssl.org/source/ \ @@ -20,7 +20,8 @@ PKG_MD5SUM:=66bf6f10f060d561929de96f9dfe5b8c PKG_LICENSE:=SSLEAY OPENSSL PKG_LICENSE_FILES:=LICENSE PKG_BUILD_DEPENDS:=ocf-crypto-headers -PKG_CONFIG_DEPENDS:=CONFIG_OPENSSL_ENGINE_CRYPTO CONFIG_OPENSSL_ENGINE_DIGEST +PKG_CONFIG_DEPENDS:=CONFIG_OPENSSL_ENGINE_CRYPTO CONFIG_OPENSSL_ENGINE_DIGEST \ + OPENSSL_WITH_EC OPENSSL_WITH_EC2M include $(INCLUDE_DIR)/package.mk @@ -75,7 +76,7 @@ endef OPENSSL_NO_CIPHERS:= no-idea no-md2 no-mdc2 no-rc5 no-sha0 no-smime \ no-rmd160 no-aes192 no-ripemd no-camellia no-ans1 no-krb5 -OPENSSL_OPTIONS:= shared no-ec no-err no-hw no-threads zlib-dynamic no-sse2 +OPENSSL_OPTIONS:= shared no-err no-hw no-threads zlib-dynamic no-sse2 ifdef CONFIG_OPENSSL_ENGINE_CRYPTO OPENSSL_OPTIONS += -DHAVE_CRYPTODEV @@ -86,6 +87,14 @@ else OPENSSL_OPTIONS += no-engines endif +ifndef CONFIG_OPENSSL_WITH_EC + OPENSSL_OPTIONS += no-ec +endif + +ifndef CONFIG_OPENSSL_WITH_EC2M + OPENSSL_OPTIONS += no-ec2m +endif + ifeq ($(CONFIG_x86_64),y) OPENSSL_TARGET:=linux-x86_64 else ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LUCI works extremely slow...
My understanding is that OpenWRT Attitude Adjustment, along with current versions of trunk, are not expected to run in any reliable way under less than 32MB of RAM. In particular, the v3.x kernel is not supported for so little memory, and the OpenWRT dev community likewise doesn't support it. On Mon, Jun 10, 2013 at 11:20 AM, Wojciech Kromer wojciech.kro...@dgt.com.pl wrote: on small custom device with rt3052, 16MB RAM, 4MB SPI-FLASH Is it an known issue? Are there any advices? Best regards. __**_ openwrt-devel mailing list openwrt-devel@lists.openwrt.**org openwrt-devel@lists.openwrt.org https://lists.openwrt.org/**mailman/listinfo/openwrt-develhttps://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LUCI works extremely slow...
Hi Jinzcheng. Indeed, you are correct that LUCI's speed of operation would not be directly related to memory requirements for a v3.x kernel. Likewise, Manuel is correct that older versions of OpenWRT should run OK with 16MB RAM, e.g. Backfire v10.03.1 or so, and that pre-compiling LUCI's source files could yield some performance improvement. The OP didn't specify which version of OpenWRT he is using, and I assumed it was a newer one incorporating the v 3.x kernel. I responded, since I was suggesting the slow LUCI could also be due to the kernel leaving too little available RAM for lua and other application-layer elements. On Mon, Jun 10, 2013 at 6:51 PM, jinzhcheng bjzhoug...@126.com wrote: My understanding is that OpenWRT Attitude Adjustment, along with current versions of trunk, are not expected to run in any reliable way under less than 32MB of RAM. In particular, the v3.x kernel is not supported for so little memory, and the OpenWRT dev community likewise doesn't support it. Hi Ben What you means is v3.x kernel don't support 32MB RAM? not the issue of LUCI? -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: [PATCH][include] Update CyaSSL library to last version 2.6.0
For an update, I have since been able to get libcurl to link to the new cyassl package, provided I explicitly insert sizeof_long definitions into libcurl header files, shown in the patch below. It is unusual that libcurl seems to require these additional defines to link to libcyassl.so, but uhttpd-mod-tls does not. I'm not sure if this patch resides properly with the package curl, perhaps accompanied by another patch that defines a new sub-package libcurl-cyassl. Massimo, are you using the newer version of cyassl for anything besides uhttpd? --- curl-7.29.0/include/curl/curl.h.201305182013-05-17 23:25:23.816083944 -0500 +++ curl-7.29.0/include/curl/curl.h2013-05-17 23:30:43.304082086 -0500 @@ -118,6 +118,13 @@ typedef void CURL; #endif #endif +/* These definitions needed for cyassl */ +/* The size of `long', as computed by sizeof. */ +#define SIZEOF_LONG 4 + +/* The size of `long long', as computed by sizeof. */ +#define SIZEOF_LONG_LONG 8 + #ifndef curl_socket_typedef /* socket typedef */ #if defined(WIN32) !defined(__LWIP_OPT_H__) On Fri, May 17, 2013 at 12:00 PM, Ben West b...@gowasabi.net wrote: Thank you for responding. Below is the diff of the curl Makefile, against that included in the Attitude Adjustment v12.09 packages herehttps://dev.openwrt.org/browser/branches/packages_12.09/libs/curl/Makefile . Note that the addition of -lm to libraries for curl to link to came from my own research in pending OpenWRT issues about compiling curl with cyassl. However, the error about long long size mismatch occurs whether libm.so is included or not. Index: libs/curl/Makefile === --- libs/curl/Makefile(revision 36652) +++ libs/curl/Makefile(working copy) @@ -43,7 +43,7 @@ $(call Package/curl/Default) SECTION:=libs CATEGORY:=Libraries - DEPENDS:=+libopenssl +zlib + DEPENDS:=+libcyassl +zlib TITLE:=A client-side URL transfer library endef @@ -70,7 +70,8 @@ --enable-tftp \ --disable-verbose \ --with-random=/dev/urandom \ ---with-ssl=$(STAGING_DIR)/usr \ +--with-cyassl=$(STAGING_DIR)/usr \ +--without-ssl --without-ca-bundle \ --without-gnutls \ --without-krb4 \ @@ -81,7 +82,7 @@ $(call autoconf_bool,CONFIG_IPV6,ipv6) \ CONFIGURE_VARS += \ -LIBS=-lcrypto -lssl -lz \ +LIBS=-lm -lcyassl -lz \ CC=$(filter-out ccache,$(TARGET_CC)) define Build/Compile On Fri, May 17, 2013 at 2:10 AM, Massimo Vellucci vema...@gmail.comwrote: CyaSSL must determine the environment to recognize the size of the types, there is a conflict on the size of the long type. Can you attach the changes on curl makefile for using CyaSSL ? 2013/5/16 Ben West b...@gowasabi.net Thank you for sharing this patch! I'm trying this very patch to see if I can use cyassl with curl, instead of openssl. (cyassl v1.6.5 is apparently old enough that the current version of curl can no longer use libcyassl.so.) However, my build on ar71xx target fails when libcurl tries to link to libcyassl on the rather esoteric error bad math long / long long settings. Are there platform limitations to the new version of cyassl? OpenWrt-libtool: compile: mips-openwrt-linux-uclibc-gcc -DHAVE_CONFIG_H -I../include/curl -I../include -I../include -I../lib -I../lib -DCURL_HIDDEN_SYMBOLS -isystem /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -isystem /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/include -isystem /blah/blah/openwrt/staging_dir/toolchain-mips_r2_gcc-4.7-linaro_uClibc-0.9.33.2/usr/include -isystem /blah/blah/openwrt/staging_dir/toolchain-mips_r2_gcc-4.7-linaro_uClibc-0.9.33.2/include -I/blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -I/blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -fvisibility=hidden -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -funit-at-a-time -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -fpic -Wno-system-headers -MT libcurl_la-cyassl.lo -MD -MP -MF .deps/libcurl_la-cyassl.Tpo -c cyassl.c -fPIC -DPIC -o .libs/libcurl_la-cyassl.o In file included from /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/error.h:26:0, from /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/error.h:26, from cyassl.c:53: /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/types.h:274:6: error: #error bad math long / long long settings /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/types.h:276:1: error: expected identifier before '}' token make[5]: *** [libcurl_la-cyassl.lo] Error 1 The caveat, however, is that I'm trying to compile the newer cyassl for Attitude Adjustment v36608, not trunk. Not sure
Re: [OpenWrt-Devel] Fwd: [PATCH][include] Update CyaSSL library to last version 2.6.0
Thank you for responding. Below is the diff of the curl Makefile, against that included in the Attitude Adjustment v12.09 packages herehttps://dev.openwrt.org/browser/branches/packages_12.09/libs/curl/Makefile . Note that the addition of -lm to libraries for curl to link to came from my own research in pending OpenWRT issues about compiling curl with cyassl. However, the error about long long size mismatch occurs whether libm.so is included or not. Index: libs/curl/Makefile === --- libs/curl/Makefile(revision 36652) +++ libs/curl/Makefile(working copy) @@ -43,7 +43,7 @@ $(call Package/curl/Default) SECTION:=libs CATEGORY:=Libraries - DEPENDS:=+libopenssl +zlib + DEPENDS:=+libcyassl +zlib TITLE:=A client-side URL transfer library endef @@ -70,7 +70,8 @@ --enable-tftp \ --disable-verbose \ --with-random=/dev/urandom \ ---with-ssl=$(STAGING_DIR)/usr \ +--with-cyassl=$(STAGING_DIR)/usr \ +--without-ssl --without-ca-bundle \ --without-gnutls \ --without-krb4 \ @@ -81,7 +82,7 @@ $(call autoconf_bool,CONFIG_IPV6,ipv6) \ CONFIGURE_VARS += \ -LIBS=-lcrypto -lssl -lz \ +LIBS=-lm -lcyassl -lz \ CC=$(filter-out ccache,$(TARGET_CC)) define Build/Compile On Fri, May 17, 2013 at 2:10 AM, Massimo Vellucci vema...@gmail.com wrote: CyaSSL must determine the environment to recognize the size of the types, there is a conflict on the size of the long type. Can you attach the changes on curl makefile for using CyaSSL ? 2013/5/16 Ben West b...@gowasabi.net Thank you for sharing this patch! I'm trying this very patch to see if I can use cyassl with curl, instead of openssl. (cyassl v1.6.5 is apparently old enough that the current version of curl can no longer use libcyassl.so.) However, my build on ar71xx target fails when libcurl tries to link to libcyassl on the rather esoteric error bad math long / long long settings. Are there platform limitations to the new version of cyassl? OpenWrt-libtool: compile: mips-openwrt-linux-uclibc-gcc -DHAVE_CONFIG_H -I../include/curl -I../include -I../include -I../lib -I../lib -DCURL_HIDDEN_SYMBOLS -isystem /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -isystem /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/include -isystem /blah/blah/openwrt/staging_dir/toolchain-mips_r2_gcc-4.7-linaro_uClibc-0.9.33.2/usr/include -isystem /blah/blah/openwrt/staging_dir/toolchain-mips_r2_gcc-4.7-linaro_uClibc-0.9.33.2/include -I/blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -I/blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -fvisibility=hidden -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -funit-at-a-time -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -fpic -Wno-system-headers -MT libcurl_la-cyassl.lo -MD -MP -MF .deps/libcurl_la-cyassl.Tpo -c cyassl.c -fPIC -DPIC -o .libs/libcurl_la-cyassl.o In file included from /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/error.h:26:0, from /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/error.h:26, from cyassl.c:53: /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/types.h:274:6: error: #error bad math long / long long settings /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/types.h:276:1: error: expected identifier before '}' token make[5]: *** [libcurl_la-cyassl.lo] Error 1 The caveat, however, is that I'm trying to compile the newer cyassl for Attitude Adjustment v36608, not trunk. Not sure if that would make a difference for this error. On Sun, May 5, 2013 at 5:50 AM, Massimo Vellucci vema...@gmail.comwrote: Sorry I made a big mistake, I attached the wrong patch. For x86 you need to disable the PIC optimization otherwise you get an error at compile time. diff -r -u a/package/libs/cyassl/Makefile b/package/libs/cyassl/Makefile --- a/package/libs/cyassl/Makefile2013-03-21 08:08:18.0 +0100 +++ b/package/libs/cyassl/Makefile2013-05-05 10:27:06.0+0200 @@ -8,16 +8,14 @@ include $(TOPDIR)/rules.mk PKG_NAME:=cyassl -PKG_VERSION:=1.6.5 -PKG_RELEASE:=2 +PKG_VERSION:=2.6.0 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).zip PKG_SOURCE_URL:=http://www.yassl.com/ -PKG_MD5SUM:=98c2c6350acf1d089756a1de9ccb9903 +PKG_MD5SUM:=9c48fd4ab677c11b4612fb4eb15444d9 -PKG_FIXUP:=patch-libtool PKG_INSTALL:=1 -PKG_BUILD_PARALLEL:=1 include $(INCLUDE_DIR)/package.mk @@ -37,8 +35,12 @@ TARGET_CFLAGS += $(FPIC) CONFIGURE_ARGS += \ - --without-zlib \ - --enable-singleThreaded + --without-pic \ + --enable-dtls \ + --enable-static \ + --enable-opensslextra
Re: [OpenWrt-Devel] Fwd: [PATCH][include] Update CyaSSL library to last version 2.6.0
Thank you for sharing this patch! I'm trying this very patch to see if I can use cyassl with curl, instead of openssl. (cyassl v1.6.5 is apparently old enough that the current version of curl can no longer use libcyassl.so.) However, my build on ar71xx target fails when libcurl tries to link to libcyassl on the rather esoteric error bad math long / long long settings. Are there platform limitations to the new version of cyassl? OpenWrt-libtool: compile: mips-openwrt-linux-uclibc-gcc -DHAVE_CONFIG_H -I../include/curl -I../include -I../include -I../lib -I../lib -DCURL_HIDDEN_SYMBOLS -isystem /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -isystem /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/include -isystem /blah/blah/openwrt/staging_dir/toolchain-mips_r2_gcc-4.7-linaro_uClibc-0.9.33.2/usr/include -isystem /blah/blah/openwrt/staging_dir/toolchain-mips_r2_gcc-4.7-linaro_uClibc-0.9.33.2/include -I/blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -I/blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include -fvisibility=hidden -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -funit-at-a-time -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -fpic -Wno-system-headers -MT libcurl_la-cyassl.lo -MD -MP -MF .deps/libcurl_la-cyassl.Tpo -c cyassl.c -fPIC -DPIC -o .libs/libcurl_la-cyassl.o In file included from /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/error.h:26:0, from /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/error.h:26, from cyassl.c:53: /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/types.h:274:6: error: #error bad math long / long long settings /blah/blah/openwrt/staging_dir/target-mips_r2_uClibc-0.9.33.2/usr/include/cyassl/ctaocrypt/types.h:276:1: error: expected identifier before '}' token make[5]: *** [libcurl_la-cyassl.lo] Error 1 The caveat, however, is that I'm trying to compile the newer cyassl for Attitude Adjustment v36608, not trunk. Not sure if that would make a difference for this error. On Sun, May 5, 2013 at 5:50 AM, Massimo Vellucci vema...@gmail.com wrote: Sorry I made a big mistake, I attached the wrong patch. For x86 you need to disable the PIC optimization otherwise you get an error at compile time. diff -r -u a/package/libs/cyassl/Makefile b/package/libs/cyassl/Makefile --- a/package/libs/cyassl/Makefile2013-03-21 08:08:18.0 +0100 +++ b/package/libs/cyassl/Makefile2013-05-05 10:27:06.0 +0200 @@ -8,16 +8,14 @@ include $(TOPDIR)/rules.mk PKG_NAME:=cyassl -PKG_VERSION:=1.6.5 -PKG_RELEASE:=2 +PKG_VERSION:=2.6.0 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).zip PKG_SOURCE_URL:=http://www.yassl.com/ -PKG_MD5SUM:=98c2c6350acf1d089756a1de9ccb9903 +PKG_MD5SUM:=9c48fd4ab677c11b4612fb4eb15444d9 -PKG_FIXUP:=patch-libtool PKG_INSTALL:=1 -PKG_BUILD_PARALLEL:=1 include $(INCLUDE_DIR)/package.mk @@ -37,8 +35,12 @@ TARGET_CFLAGS += $(FPIC) CONFIGURE_ARGS += \ - --without-zlib \ - --enable-singleThreaded + --without-pic \ + --enable-dtls \ + --enable-static \ + --enable-opensslextra \ + --enable-singlethreaded \ + --disable-examples define Build/InstallDev $(INSTALL_DIR) $(1)/usr/include I'm sorry again for the mistake Massimo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram Init script
To amplify Bastian's advice and get zram working under trunk r36225, I specifically performed these steps: 1. make menuconfig 2. In menu screen that appear, select Base System - zram-swap 3. Exit menuconfig, saving configuration. 4. make kernel_menuconfig 5. General setup - Support for paging of anonymous memory (swap) 6. Exit kernel_menuconfig, saving configuration. On Thu, Mar 7, 2013 at 7:02 AM, Bastian Bittorf bitt...@bluebottle.comwrote: * Sivateja Patibandla patibandl...@vcu.edu [07.03.2013 13:49]: swapon: /dev/zram0: Function not implemented activate support for swapping in kernel. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Preferred next steps for restoring functionality to atheros platform (Engenius, Open Mesh)?
target/linux/atheros/base-files/etc/uci-defaults/leds diff --git a/target/linux/atheros/base-files/etc/uci-defaults/leds b/target/linux/atheros/base-files/etc/uci-defaults/leds deleted file mode 100644 index 076a04b..000 --- a/target/linux/atheros/base-files/etc/uci-defaults/leds +++ /dev/null @@ -1,11 +0,0 @@ -#!/bin/sh -# Copyright 2012 OpenWrt.org -# - -. /lib/functions/uci-defaults.sh - -ucidef_set_led_netdev wlan wlan wlan wlan0 - -ucidef_commit_leds - -exit 0 diff --git a/target/linux/atheros/config-3.3 b/target/linux/atheros/config-3.3 index 9f68b4e..39d8716 100644 --- a/target/linux/atheros/config-3.3 +++ b/target/linux/atheros/config-3.3 @@ -35,7 +35,7 @@ CONFIG_GENERIC_ATOMIC64=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CMOS_UPDATE=y -CONFIG_GENERIC_GPIO=y +# CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GPIOLIB=y @@ -70,7 +70,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_IP17XX_PHY=y CONFIG_IRQ_CPU=y CONFIG_IRQ_FORCED_THREADING=y -CONFIG_LEDS_GPIO=y +# CONFIG_LEDS_GPIO is not set CONFIG_MDIO_BOARDINFO=y CONFIG_MIPS=y CONFIG_MIPS_L1_CACHE_SHIFT=5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Evenly distribute bandwidth for users?
You may also want to look at tools like Coovachilli, wifidog, and nodogsplash if you want to constrain upload/download bandwidth for individual DHCP clients. These are the tools commonly used to manage bandwidth on public wifi hotspots. http://wiki.openwrt.org/doc/howto/wireless.hotspot http://wiki.openwrt.org/doc/howto/wireless.hotspot.wifidog http://wiki.openwrt.org/doc/howto/wireless.hotspot.nodogsplash http://www.coova.org/CoovaChilli Note that Coovachilli would require a RADIUS server running somewhere else in the cloud. However, do please note that RADIUS configuration is rarely 'plug-n-play,' and well outside the scope of this listserv. By comparison, wifidog and nodogsplash are stand-alone. QoS is more typically used to set device-wide bandwidth policies, less so per-user policies. On Fri, Jan 11, 2013 at 3:43 AM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hello, I'm looking for how to make the OpenWrt router automatically distribute bandwidth for users. For example, one user is downloading a big file and slow down Internet speed for others. I want to limit that downloading. I looked into QoS, but it seems that I have to specify a user (IP) to apply rule on. What I want is that the system can do this automatically. Is there any package available for this need? Thank you. -- Regards, Quân Y!IM: ng_hquan_vn GTalk: ng.hong.quan __**_ openwrt-devel mailing list openwrt-devel@lists.openwrt.**org openwrt-devel@lists.openwrt.org https://lists.openwrt.org/**mailman/listinfo/openwrt-develhttps://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WDR3600 802.11n HT40 performance
Likewise, I'm a bit curious about the 170Mbit/s throughput reported by iperf. A reported 300Mbit/s link speed is TX+RX aggregate, i.e. 150Mbit/s each for the TX and RX chains combined, and the actual throughput would be diminished both by imperfect wireless signal and protocol overhead(s). If I'm understanding things correctly ... 80Mbit/s sustained throughput is actually much closer to what I'd expect almost any firmware to achieve on a 5.8GHz MIMO point-to-point link. Can you reproduce the 170Mbit/s with tools besides iperf? For example, if the radios are connected to a GigE wired LAN on each end, can you push 100Mbit/s+ in HTTP traffic over the link? On Sat, Dec 22, 2012 at 12:17 PM, Felix Fietkau n...@openwrt.org wrote: On 2012-12-22 4:34 AM, Nicolás Echániz wrote: Here at QuintanaLibre we have been testing these new routers and we'd like to share some results, in case someone has any tips on how to improve performance. There's a blog post (spanish) on the tests here: http://blog.altermundi.net/article/performance-de-equipos-multi-banda-tl-wdr3600/ The important bit is that with the original firmware we get a throughput of 170 Mbits/sec, while with OpenWRT we get roughly 80 Mbits/sec. Links report: 300.0 MBit/s MCS 15 40Mhz short GI, but actual transfer rate seems low, at almost 100Mbits/s less than the results with the original firmware. One detail is that HT capabilities seem to be making no difference. These two different wireless settings (uci output) produce the exact same results: wireless.radio1.ht_capab = SHORT-GI-20 GI-40 TX-RX STBC-STBC1 DSSS_CCK-40 wireless.radio1.ht_capab = SHORT-GI-40 Changing modes from adhoc to ap/sta made no noticeable difference either. A few questions to figure out the cause of the performance delta: - How do you measure the throughput? - Are you using bridging between cable and wifi? - What is the system load in top while you're running the test? - Please show me the relevant output from /sys/kernel/debug/ieee80211/phy1/netdev:*/stations/*/rc_stats while running a throughput test. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Looking for Openwrt programmers to customize Open-Mesh router code
Although the general idea is certainly valid, and even though Open-Mesh.com is on-board, I would recommend doing to some research about whether Google itself might find issue with 3rd parties intercepting and modifying users' search queries sent to google.com. Especially since this has now been posted to an email list with public archives. Google is likely rather protective of the ad revenue streams they derive from analyzing users' search queries, so have those queries modified en-route might not sit well with them. -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/1] atheros: Revert Add leds back after migration to sysfs
Thank you for committing this patch into trunk/AA! -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Strange behaviour in Wi-Fi link adaptation
You may get more consistent throughput graphs if the wireless link is consistently moving a steady stream traffic. I.e. do the periods of low rates like 6Mbps correspond to times when the link was idle? I run Backfire 10.03.01 on a bunch of Ubiquiti M5 gear, also using the bundled ath9k driver, and I will routinely see low rates on those specific links that are idle, with the busy links ramping up to 200Mbit/s at times if the RSSI is good enough. (Also, I'm using HT modes to get double channel width, and thus higher data rates.) On Tue, Sep 18, 2012 at 3:55 PM, Dani Camps danicamp...@yahoo.com wrote: Dear all, I have OpenWrt Backfire (10.03.1, r29592), with kernel 2.6.32.27 and as wireless drivers ath9k. My problem is that I have been observing very erratic behaviours in the wireless link. Please, look at the graphic attached, the output corresponds to the wireless real-time graphs in Openwrt. The upper part is the RSSI received in the wireless router (I presume), as you can see is fairly constant. The lower graph is the actual rate that the router uses to send packets to my laptop over Wi-Fi. It is completely shaky oscillating from 54Mbps down to 6Mbps. Has someone experienced similar problems? The reason may be due to an unstable link adaptation algorithm being used in ath9k, does any one know if it is possible to select a different algorithm? It could also be that the link between the router and my laptop is unstable, but I doubt that as the reverse direction seems very stable (upper graph). Any help is appreciated. Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add leds back after migration to sysfs
Along with Jonathan's Engenius ECB-3500 and my Open Mesh OM1P, I think there is a very good chance this changeset will also affect FONera 2100, Engenius EOC-1650, Engenius EOC-2610, and maybe Engenius EOC 2611. What are next steps for supporting multiple board configs on atheros target? I.e. is this wiki page still reasonably up to date? http://wiki.openwrt.org/doc/devel/add.new.device On Mon, Aug 27, 2012 at 8:24 AM, Karl Palsson ka...@tweak.net.au wrote: I think this really just means that the Atheros platform needs to be broken up into separate boards, like ar71xx and other newer platforms. Currently a Atheros targets get the same init code, and clearly your board needs different init code to mine :) Cheers, Karl P On Sun, Aug 26, 2012 at 10:13:33PM -0500, Ben West wrote: This changeset on trunk appears to prevent booting up on a OM1P (Atheros AR2315). That is, freshly compiled r32884 boots fine on OM1P, but flashing the device with r32885+ leads to unresponsive eth0 interface on OM1P. I am lacking a TTL/serial cable, so I can't share more information. https://dev.openwrt.org/changeset/32885/trunk Removing the line CONFIG_LEDS_GPIO=y from target/linux/atheros/config-3.3 and recompiling leads to booting firmware again. Since this is related to kernel GPIO LED control, I posted a bug earlier this summer about a compile problem witnessed with kmod-leds-gpio package for ath5k, but I had no patch to offer. Perhaps, these problems are related? https://dev.openwrt.org/ticket/11797 If not related, I do see CONFIG_LEDS_GPIO being unset in this changeset from several years ago, with the comment specifically referring to flash access errors. Is changeset r32885 a regression then? https://dev.openwrt.org/changeset/16765/ On Fri, Jul 6, 2012 at 7:32 AM, Karl Palsson ka...@tweak.net.au wrote: From: Karl Palsson ka...@remake.is atheros trunk moved to full sysfs gpiolib, but the leds were forgotten. This restores the wlan led that was missing after switching from backfire to trunk. Signed-off-by: Karl Palsson ka...@remake.is --- .../linux/atheros/base-files/etc/uci-defaults/leds | 11 +++ target/linux/atheros/config-3.3|1 + 2 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 target/linux/atheros/base-files/etc/uci-defaults/leds diff --git a/target/linux/atheros/base-files/etc/uci-defaults/leds b/target/linux/atheros/base-files/etc/uci-defaults/leds new file mode 100644 index 000..076a04b --- /dev/null +++ b/target/linux/atheros/base-files/etc/uci-defaults/leds @@ -0,0 +1,11 @@ +#!/bin/sh +# Copyright 2012 OpenWrt.org +# + +. /lib/functions/uci-defaults.sh + +ucidef_set_led_netdev wlan wlan wlan wlan0 + +ucidef_commit_leds + +exit 0 diff --git a/target/linux/atheros/config-3.3 b/target/linux/atheros/config-3.3 index be0c74a..c3713b3 100644 --- a/target/linux/atheros/config-3.3 +++ b/target/linux/atheros/config-3.3 @@ -70,6 +70,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_IP17XX_PHY=y CONFIG_IRQ_CPU=y CONFIG_IRQ_FORCED_THREADING=y +CONFIG_LEDS_GPIO=y CONFIG_MDIO_BOARDINFO=y CONFIG_MIPS=y CONFIG_MIPS_L1_CACHE_SHIFT=5 -- 1.7.2.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath5k and txpower
My problem is likely unrelated, but could you (Tobias) say precisely what revision of trunk you are using? Freshly compiled trunk r33202 w/ default config does not appear to boot at all on my OM1P (ar2315 chipset), i.e. no response on eth0. However, I don't think the bugs mentioned w/ compat-wireless in this thread could cause that. On Sat, Aug 4, 2012 at 7:34 PM, Tobias Diedrich ranma+open...@tdiedrich.de wrote: Compiling OpenWRT from trunk, I've found that there are issues with setting txpower on AR2417: - No txpower setting in LuCI gui - iw phy phy0 info shows 0dBm for all channels regardless of regdomain [9.332000] cfg80211: Calling CRDA to update world regulatory domain [9.34] cfg80211: World regulatory domain updated: [9.344000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [9.352000] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.36] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.364000] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.372000] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.38] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) root@OpenWrt:/# iw phy phy0 info Wiphy phy0 Band 1: Frequencies: * 2412 MHz [1] (0.0 dBm) * 2417 MHz [2] (0.0 dBm) * 2422 MHz [3] (0.0 dBm) * 2427 MHz [4] (0.0 dBm) * 2432 MHz [5] (0.0 dBm) * 2437 MHz [6] (0.0 dBm) * 2442 MHz [7] (0.0 dBm) * 2447 MHz [8] (0.0 dBm) * 2452 MHz [9] (0.0 dBm) * 2457 MHz [10] (0.0 dBm) * 2462 MHz [11] (0.0 dBm) * 2467 MHz [12] (0.0 dBm) * 2472 MHz [13] (0.0 dBm) * 2484 MHz [14] (disabled) One issue seems to be fallout from http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de AFAICS max_power for the channels is never set and thus min(chan-max_power, chan-max_reg_power) is 0. This patch tries to fix this (but is probably wrong :)) After applying this patch iw phy phy0 info looks good, but WiFi Analyzer on my phone still shows a very weak signal for the AP. Until I do this: root@OpenWrt:/# iw phy phy0 set txpower fixed 0 root@OpenWrt:/# iw phy phy0 set txpower auto And then the signal strength is good. iw phy phy0 set txpower fixed|limit still doesn't accept values above 0 for some reason though. Index: compat-wireless-2012-07-16/drivers/net/wireless/ath/ath5k/base.c === --- compat-wireless-2012-07-16.orig/drivers/net/wireless/ath/ath5k/base.c 2012-08-05 01:42:19.141413438 +0200 +++ compat-wireless-2012-07-16/drivers/net/wireless/ath/ath5k/base.c 2012-08-05 01:44:19.957568271 +0200 @@ -325,6 +325,8 @@ if (!ath5k_is_standard_channel(ch, band)) continue; + channels[count].max_power = AR5K_TUNE_MAX_TXPOWER; + count++; } -- Tobias PGP: http://8ef7ddba.uguu.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath5k and txpower
Thank you, Jonathan. I should note that r33202 boots fine for me on ar71xx, if that helps narrow down a root cause. On Fri, Aug 24, 2012 at 12:15 PM, Jonathan Bither jonbit...@gmail.com wrote: When I rebuilt the other day my ar2315 would not boot due to jffs2 errors. I haven't checked to see if it was something in my tree, but just thought i'd let you know. I can rebuilt with a clean true today and watch serial to see if the issue persists. On 08/24/2012 01:02 PM, Ben West wrote: My problem is likely unrelated, but could you (Tobias) say precisely what revision of trunk you are using? Freshly compiled trunk r33202 w/ default config does not appear to boot at all on my OM1P (ar2315 chipset), i.e. no response on eth0. However, I don't think the bugs mentioned w/ compat-wireless in this thread could cause that. On Sat, Aug 4, 2012 at 7:34 PM, Tobias Diedrich ranma+open...@tdiedrich.de wrote: Compiling OpenWRT from trunk, I've found that there are issues with setting txpower on AR2417: - No txpower setting in LuCI gui - iw phy phy0 info shows 0dBm for all channels regardless of regdomain [9.332000] cfg80211: Calling CRDA to update world regulatory domain [9.34] cfg80211: World regulatory domain updated: [9.344000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [9.352000] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.36] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.364000] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.372000] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.38] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) root@OpenWrt:/# iw phy phy0 info Wiphy phy0 Band 1: Frequencies: * 2412 MHz [1] (0.0 dBm) * 2417 MHz [2] (0.0 dBm) * 2422 MHz [3] (0.0 dBm) * 2427 MHz [4] (0.0 dBm) * 2432 MHz [5] (0.0 dBm) * 2437 MHz [6] (0.0 dBm) * 2442 MHz [7] (0.0 dBm) * 2447 MHz [8] (0.0 dBm) * 2452 MHz [9] (0.0 dBm) * 2457 MHz [10] (0.0 dBm) * 2462 MHz [11] (0.0 dBm) * 2467 MHz [12] (0.0 dBm) * 2472 MHz [13] (0.0 dBm) * 2484 MHz [14] (disabled) One issue seems to be fallout from http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de AFAICS max_power for the channels is never set and thus min(chan-max_power, chan-max_reg_power) is 0. This patch tries to fix this (but is probably wrong :)) After applying this patch iw phy phy0 info looks good, but WiFi Analyzer on my phone still shows a very weak signal for the AP. Until I do this: root@OpenWrt:/# iw phy phy0 set txpower fixed 0 root@OpenWrt:/# iw phy phy0 set txpower auto And then the signal strength is good. iw phy phy0 set txpower fixed|limit still doesn't accept values above 0 for some reason though. Index: compat-wireless-2012-07-16/drivers/net/wireless/ath/ath5k/base.c === --- compat-wireless-2012-07-16.orig/drivers/net/wireless/ath/ath5k/base.c 2012-08-05 01:42:19.141413438 +0200 +++ compat-wireless-2012-07-16/drivers/net/wireless/ath/ath5k/base.c 2012-08-05 01:44:19.957568271 +0200 @@ -325,6 +325,8 @@ if (!ath5k_is_standard_channel(ch, band)) continue; + channels[count].max_power = AR5K_TUNE_MAX_TXPOWER; + count++; } -- Tobias PGP: http://8ef7ddba.uguu.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] dev.openwrt.org throwing 502 Bad Gateway errors
dev.openwrt.ort seems to be throwing 502 errors, at least for the past hour or so. https://dev.openwrt.org/browser/trunk https://dev.openwrt.org/browser/branches -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Throughput mesh testing problems
If the access points are very close together, you might also try turning down TX power on both ends. What is the dBm reported by iw station dump at each end? Anything below 60dBm might indicate the radios are talking way too loud. On Wed, Apr 18, 2012 at 7:09 PM, Ray Gibson rgib...@futurec.net wrote: Hello, I've just spent the last few hours reading many threads in the archives from this list. I'm hoping someone may be able to help me, else I think I have a batch of bad radios. Summary: hardware is two identical routerstation pros running OpenWRT bleeding edge from 2012-03-14 (with a compat-wireless from february I believe). SR71-A (ath9k) radio in each. I'm bringing up the interfaces in each like this: iw phy0 interface add wlan0 type mp iw phy0 set channel 36 HT40+ iw wlan0 set meshid TheMeshID ifconfig wlan0 up brctl addif br-lan wlan0 Running iperf in either direction produces a range of 13-16 Mbits/sec when I can point to countless examples in the mailing list archives that show people getting significantly higher bandwidth. While pushing my test through, an `iw dev wlan0 station dump` on either node often shows the bitrates at: 300.0 MBit/s MCS 15 40Mhz short GI I'm getting similar, if not poorer results on higher 5ghz channels (149+, 157+). Am I horribly misconfiguring something or is it my hardware? My antennas are 3x3 panels spaced about 10 meters apart. Thanks for any insight, -- Ray Gibson Future Concepts IS Inc. 909-593-6705 x2096 This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 USC 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This e-mail and any files transmitted with it are proprietary and intended for the sole use of the individual or entity to whom they are addressed. They are not to be viewed, shared, copied or forwarded, regardless to whom, without the expressed permission of Future Concepts I.S., Inc. If you have received this e-mail in error, please notify the sender and immediately delete it from your system. Thank you. __**_ openwrt-devel mailing list openwrt-devel@lists.openwrt.**org openwrt-devel@lists.openwrt.org https://lists.openwrt.org/**mailman/listinfo/openwrt-develhttps://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Throughput mesh testing problems
It if helps to have comparison, I'm running Backfire 10.03.1 on a collection of UBNT M5 2x2 MIMO gear in adhoc mode at HT speeds. Some quick-n-dirty tests doing downloads with curl are getting roughly 40Mbit/s between adjacent nodes. Although, I'm using adhoc mode instead of mesh mode. Here is what iw station dump on each node has to say about its neighbor: Station 00:15:6d:xx:xx:x1 (on wlan0) inactive time: 20 ms rx bytes: 1518147670 rx packets: 16222572 tx bytes: 2775534297 tx packets: 6183642 tx retries: 1190905 tx failed: 266 signal: -67 dBm signal avg: -66 dBm tx bitrate: 135.0 MBit/s MCS 7 40Mhz rx bitrate: 108.0 MBit/s MCS 11 40Mhz Station 00:15:6d:xx:xx:x2 (on wlan0) inactive time: 10 ms rx bytes: 3161319397 rx packets: 9430897 tx bytes: 315979120 tx packets: 2137676 tx retries: 211650 tx failed: 9140 signal: -70 dBm signal avg: -69 dBm tx bitrate: 108.0 MBit/s MCS 11 40Mhz rx bitrate: 135.0 MBit/s MCS 7 40Mhz On Wed, Apr 18, 2012 at 7:33 PM, Ray Gibson rgib...@futurec.net wrote: ** On 4/18/2012 5:15 PM, Ben West wrote: If the access points are very close together, you might also try turning down TX power on both ends. What is the dBm reported by iw station dump at each end? Anything below 60dBm might indicate the radios are talking way too loud. While they were sitting at -40 for a little while I turned the tx power on both sides way down to achieve about -62. I also have RF terminators I have tried with that bring it down into the -70's at close range. Each scenario seems to produce the same result. I seem to have an excessive amount of tx retries as well, I wonder if that has something to do with it? Which makes me think it's more of a hardware issue. I don't know. Thanks (and sorry for the company footer, I can't turn it off) On Wed, Apr 18, 2012 at 7:09 PM, Ray Gibson rgib...@futurec.net wrote: Hello, I've just spent the last few hours reading many threads in the archives from this list. I'm hoping someone may be able to help me, else I think I have a batch of bad radios. Summary: hardware is two identical routerstation pros running OpenWRT bleeding edge from 2012-03-14 (with a compat-wireless from february I believe). SR71-A (ath9k) radio in each. I'm bringing up the interfaces in each like this: iw phy0 interface add wlan0 type mp iw phy0 set channel 36 HT40+ iw wlan0 set meshid TheMeshID ifconfig wlan0 up brctl addif br-lan wlan0 Running iperf in either direction produces a range of 13-16 Mbits/sec when I can point to countless examples in the mailing list archives that show people getting significantly higher bandwidth. While pushing my test through, an `iw dev wlan0 station dump` on either node often shows the bitrates at: 300.0 MBit/s MCS 15 40Mhz short GI I'm getting similar, if not poorer results on higher 5ghz channels (149+, 157+). Am I horribly misconfiguring something or is it my hardware? My antennas are 3x3 panels spaced about 10 meters apart. Thanks for any insight, -- Ray Gibson Future Concepts IS Inc. 909-593-6705 x2096 This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 USC 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This e-mail and any files transmitted with it are proprietary and intended for the sole use of the individual or entity to whom they are addressed. They are not to be viewed, shared, copied or forwarded, regardless to whom, without the expressed permission of Future Concepts I.S., Inc. If you have received this e-mail in error, please notify the sender and immediately delete it from your system. Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing listopenwrt-devel@lists.openwrt.orghttps://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ray Gibson Future Concepts IS Inc.909-593-6705 x2096 This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 USC 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This e-mail and any files transmitted with it are proprietary and intended for the sole use of the individual or entity to whom they are addressed. They are not to be viewed, shared, copied or forwarded, regardless to whom, without the expressed permission of Future Concepts I.S., Inc. If you have received this e-mail in error, please notify the sender and immediately delete it from your system. Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org
Re: [OpenWrt-Devel] Anyone encounter problems with /dev/random on Mikrotik RB532
Thank you for the response that the warning from hostapd is normal. Could the lack of entropy still be causing NAT to randomly not work? On Thu, Mar 8, 2012 at 2:38 PM, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This random related message is perfectly normal. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ZGLgACgkQdputYINPTPN9fgCgoBK7OFEJLwBfxpMpxxKXG8Fz a9EAmweNf45mDmjlvUyd4TTyy2uArPS8 =VeQH -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Anyone encounter problems with /dev/random on Mikrotik RB532
I'm running a couple Mikrotik RB532 routerboards as broadband gateway routers under OpenWRT 10.03.1. One of the routers, despite several OS upgrades culminating in Backfire 10.03.1, has a very sporadic problem of NAT mysteriously not working after a reboot (i.e. traffic not forwarded from LAN to WAN and vice versa). The only resolution I could find was either to reboot the box again, or do /etc/init.d/network restart. Upon running /etc/init.d/network restart I saw this reported back: root@bluenoses:~# /etc/init.d/network restart iptables: No chain/target/match by that name. iptables: No chain/target/match by that name. ifconfig: SIOCSIFADDR: No such device udhcpc (v1.15.3) started Sending discover... Sending select for X.X.X.X... *(my dynamic public IP)* Lease of X.X.X.X obtained, lease time 3600 udhcpc: ifconfig eth1 X.X.X.X netmask 255.255.252.0 broadcast 255.255.255.255 udhcpc: setting default routers: X.X.X.1 *(my dynamic gateway)* udhcpc: setting dns servers: 208.67.222.222 208.67.220.220 Configuration file: /var/run/hostapd-ath0.conf Using interface ath0 with hwaddr 00:DE:AD:BE:EF:FF and ssid 'bluenoses' random: Cannot read from /dev/random: Resource temporarily unavailable random: Only 0/20 bytes of strong random data available from /dev/random random: Not enough entropy pool available for secure operations WPA: Not enough entropy in random pool for secure operations - update keys later when the first station connects Sure enough, looks like /dev/random provides no entopy: root@bluenoses:~# cat /proc/sys/kernel/random/entropy_avail 0 I found several tickets, including a (hopefully soon to be back-ported) package rng-tools intended to address problems with headless boxes not getting sufficient entropy from non-existent keyboard/mouse. https://dev.openwrt.org/ticket/10541 Has anyone encountered problems with insufficient entropy causing random NAT failures? -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Buying router SOC CPUs
Many moons ago I was working with a startup developing a small battery-powered device based around TI's DaVinci DM355 SoC. http://www.ti.com/product/tms320dm355 We tried to use the MMC/SDIO interface to talk to an SD form-factor 802.11 card (since the USB was already assigned elsewhere), but I could see that USB working well for a cheap Ra-Link card instead. As to your question about pricing reference, the DM355 runs roughly US$20/ea from AVNet, for example. http://avnetexpress.avnet.com/store/em/EMController/Processor/Multimedia-Misc/_/N-100230/Ne-10?action=productsadvAction=cat=1catalogId=500201cutTape=inStock=langId=-1myCatalog=npi=proto=regionalStock=rohs=searchType=storeId=500201term=dm355topSellers= We were able to get a tray of sample DM355's from AVnet, and it looks like they sell some of the pkg variants in qty 1. On Tue, Jan 17, 2012 at 8:02 PM, jonsm...@gmail.com jonsm...@gmail.comwrote: On Tue, Jan 17, 2012 at 8:33 PM, Ben West b...@gowasabi.net wrote: This unfortunately a common attitude from parts vendors, especially when you are not buying in qty 10k+. We are in the 2-4K volume range which is too low for them to apparently care about. If they'd just put the chips into a distributor and give us an accurate manual we'd probably never call the chip manufacturer. What is pricing like for the SOC chips? Would it be less that our $8.00 combo of lpc3130/USB wifi? USB wifi is flexible in that we can put in 11g, 11b, 5Ghz, etc sticks. lpc3130 is a very good chip for this since it has the integrated 480Mb USB PHY. You might try asking vendors for a tray of samples for testing purposes, e.g. a dozen chips. On Tue, Jan 17, 2012 at 7:16 PM, jonsm...@gmail.com jonsm...@gmail.com wrote: Are any of the router SOC CPUs easily available for purchase? We've tried to buy some buy nobody wants to talk to us. As a work around we are using a lpc3130 ($3.50) and an OEM USB wifi stick ($4.00 ralink). We have to go through FCC anyway because of the 2.4Ghz 802.15.4 radio. -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Jon Smirl jonsm...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Buying router SOC CPUs
The SD form-factor 802.11 card we were trying to integrate was based on ath5k, IIFC, which would support AP mode. I believe we got far enough to test in STA mode (i.e.. test the wifi link to a conventional base station). Although, SD format factor for peripherals is not ideal, and possibly obsolete by now. The thread author would need to check whether the ralink driver supports AP mode (which doesn't look hopeful from Googling). On Thu, Jan 19, 2012 at 3:09 PM, Mark Deneen mden...@gmail.com wrote: AP mode? On Thu, Jan 19, 2012 at 2:42 PM, Ben West b...@gowasabi.net wrote: Many moons ago I was working with a startup developing a small battery-powered device based around TI's DaVinci DM355 SoC. http://www.ti.com/product/tms320dm355 We tried to use the MMC/SDIO interface to talk to an SD form-factor 802.11 card (since the USB was already assigned elsewhere), but I could see that USB working well for a cheap Ra-Link card instead. As to your question about pricing reference, the DM355 runs roughly US$20/ea from AVNet, for example. http://avnetexpress.avnet.com/store/em/EMController/Processor/Multimedia-Misc/_/N-100230/Ne-10?action=productsadvAction=cat=1catalogId=500201cutTape=inStock=langId=-1myCatalog=npi=proto=regionalStock=rohs=searchType=storeId=500201term=dm355topSellers= We were able to get a tray of sample DM355's from AVnet, and it looks like they sell some of the pkg variants in qty 1. -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Buying router SOC CPUs
This unfortunately a common attitude from parts vendors, especially when you are not buying in qty 10k+. You might try asking vendors for a tray of samples for testing purposes, e.g. a dozen chips. On Tue, Jan 17, 2012 at 7:16 PM, jonsm...@gmail.com jonsm...@gmail.comwrote: Are any of the router SOC CPUs easily available for purchase? We've tried to buy some buy nobody wants to talk to us. As a work around we are using a lpc3130 ($3.50) and an OEM USB wifi stick ($4.00 ralink). We have to go through FCC anyway because of the 2.4Ghz 802.15.4 radio. -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Confirming txpower offsets for UBNT Nanostation M5 since r29424
I had been using a patched version of Backfire r25206 on some UBNT Nanostation and Bullet M5 units, and getting a generous 30dBm (aka 1000mW) reported back as default txpower: root@nsm5-b:~# iwlist txpower ... wlan0 unknown transmit-power information. Current Tx-Power=30 dBm (1000 mW) root@nsm5-b:~# iwconfig ... wlan0 IEEE 802.11an ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=30 dBm RTS thr:off Fragment thr:off Encryption key:off Power Management:on Upon upgrading to Backfire 10.03.1, I appear to only get maximum 22dBm txpower now on the Nanostation M5 I'm testing with. Some snooping suggests these UBNT units now have a txpower offset of 5 since r29424, i.e. such that setting output power 22dBm would actually yield 27dBm. https://dev.openwrt.org/changeset/29424 As for the wonderful 30dBm I was previously getting, research on the Nanostation M5 itself seems to imply its maximum possible txpower is indeed only 27dBm, suggesting the 30dBm figure was erroneous. http://www.ubnt.com/downloads/nanoM5_DS.pdf Could anyone on the list verify this from their own testing? Thanks. -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
