[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 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 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
[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] 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
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 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
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 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] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
; is > >> also reported as being used: > >> 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) > >> > >> > >> I have no idea why but there seems to be a bug in the code parsing the > DFS > >> regulations, limiting 2.4Ghz to lot lower values than allowed. Changing > it > >> to DFS-FCC works for using the applicaple output power but does not seem > >> to be in compliance which German law. > >> > >> Do you have an idea where the problem could be? I'm happy to try out > more > >> builds and future versions. > >> > >> 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 (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] [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 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 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 >> <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 > >> 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) > >> >>
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 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&postdays=0&postorder=asc&start=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 ___ 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 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] TDMA implementation for OpenWRT
This was an experimental implementation done years ago, unfortunately now marked abandoned: https://github.com/shaddi/jaldimac Hardware vendors with proprietary TDMA implementations (e.g. UBNT) are generally not forthcoming about details of these implementations, partly because such implementations aren't 802.11 compliant. I'd also recommend also searching history of this list. This question reoccurs, most recently last month. https://lists.openwrt.org/pipermail/openwrt-devel/2017-February/thread.html#42702 https://lists.openwrt.org/pipermail/openwrt-devel/2015-February/031370.html On Tue, Mar 21, 2017 at 3:31 PM, Guillermo Nardoni - GERYON < guille...@geryon.com.ar> wrote: > Hello everyone. > > > > I know it is a killed topic but I actually want to know if there is/will > be an OpenWRT TDMA implementation. > > > > > > Thanks in advance.- > > > > Best Regards, > > Guillermo Nardoni > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -- Ben West 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] 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 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] 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 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 > > 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
[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] 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 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-wireless&m=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] Preferred next steps for restoring functionality to atheros platform (Engenius, Open Mesh)?
control the spi flash chip select. Fixes a handful of open tickets. > First resolved in changeset # 16765 > > Signed-off-by: Jonathan Bither > --- > target/linux/atheros/base-files/etc/uci-defaults/leds | 11 --- > target/linux/atheros/config-3.3 |4 ++-- > 2 files changed, 2 insertions(+), 13 deletions(-) > delete 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 > 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] Preferred next steps for restoring functionality to atheros platform (Engenius, Open Mesh)?
Hi Felix, Thank you for the response. My responses inline below. On Thu, Apr 11, 2013 at 9:49 AM, Felix Fietkau wrote: > On 2013-04-11 6:10 AM, Ben West wrote: > > Hi All, > > > > I just successfully flashed trunk r36255 onto an AR2315-based > > Engenius/Senao EOC-1650, and an Engenius EOC-2611P, albeit with the > > following patches and modifications: > > > > target/linux/atheros/config-3.8 (disable gpiolib related options that > > interfere with SPI flash chip select) > How does it interfere with the flash chip reset? Which GPIO pin is > causing issues? > I do not know (yet) which GPIO the Engenius devices use for chip select, or if indeed that is the root problem. The schematics for these boards are not available, nor the pinout of Atheros SoC BGA (at least from my searching). My presumption of Engenius using non-standard GPIO for chip select comes from this statement from Jonathan Bither made on this listserv, which itself repeats a comment by nbd in changeset 16765. https://lists.openwrt.org/piperm9whicail/openwrt-devel/2012-November/017469.html https://dev.openwrt.org/changeset/16765 The statements about chip select could be incorrect, but the patch disabling CONFIG_LEDS_GPIO does work-around the boot problem. Given the symptoms described above in ticket # 11969, where might you recommend I start looking? > > > target/linux/atheros/base-files/etc/uci-defaults/01_leds (comment out > > ucidef commands for LEDs) > > https://dev.openwrt.org/ticket/11969 > > > > target/linux/atheros/patches-3.8/100-board.patch (change from GPIO 5 to > > GPIO 0 for soft reboot) > > https://dev.openwrt.org/ticket/6202 > > > > Finally, kmod-leds-gpio must /not/ be enabled in .config before building. > Why? > > I do agree, on reflection, that whether the kmods-leds-gpio package is enabled or not likely becomes moot after disabling CONFIG_LEDS_GPIO in the target kernel config. I had not yet had the chance to specifically try rebuilding the image with CONFIG_LEDS_GPIO disabled but kmod-leds-gpio enabled. > > Also, a /subset/ of these modifications (disabled CONFIG_LEDS_GPIO in > > target/atheros/config-3.8) was required for trunk to boot on an Open > > Mesh OM1P, too. Otherwise, it failed with squashfs errors, similar to > > those described in issue #11969 above. * > > > > These modifications do address the symptoms, but they neglect the > > underlying issue that certain atheros-based boards, like the Engenius > > devices, appear to use different GPIO assignments for soft reset and > > chip select. > Before you attempt to address the root causes, please do some more > research on what the *exact* root causes are, especially the ones that > you worked around by disabling GPIO/LED access. > Information about the AR231x-generation Engenius products seems scant, and so I posted to this list in case other list members could be help with such research. The tickets and changeset cited above contain the most current information about this older Engenius platform that I've been able to find thus far. > > > I can submit patches containing these modifications, but they would be > > specific to these boards and presumably rejected on those grounds. > > Likewise, these mods also completely disable any soft control of LEDs. > Correct, such patches would not be accepted. > > > Previous discussion on this topic indicated the preferred approach is to > > migrate the atheros platform to board-specific target profiles, like how > > was done with ar71xx. > > > > What is the best way to begin here? Is there information available on > > how board-specific target profiles are defined? > Board specific target profiles are not a suitable way to deal with this > problem. With platforms like ar71xx, the same build works on all common > devices (through kernel command line patching). > ar71xx is not a good example on where a platform rework should go, the > use of Device Tree is preferred, and it has been implemented in the > ramips and lantiq platforms. If you want to do a proper rework of the > target, those are good examples to look at. > Thank you very much for the pointer to Device Tree in the ramips and lantiq platforms. That helps greatly. > > - 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/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 wrote: > * Sivateja Patibandla [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
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 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] 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 here<https://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 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 > >> 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 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 >>> &
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 wrote: > Thank you for responding. Below is the diff of the curl Makefile, against > that included in the Attitude Adjustment v12.09 packages > here<https://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 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 >> >>> 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.
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 > https://lists.openwrt.org/**mailman/listinfo/openwrt-devel<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...
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 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] 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 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 cyassl<http://www.yassl.com/yaSSL/Docs-cyassl-manual-4-features.html>would 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 > > 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
[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] 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 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 > path"trunk/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 > >> 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 >> >>> 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.h 2013-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 wrote: >>> >>>> Thank you for responding. Below is the diff of the curl Makefile, >>>> against that included in the Attitude Adjustment v12.09 packages >>>> here<https://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. >&
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 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] [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 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] 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] [OpenWrt-Users] unknown network field 'beacon_int" and wpa_supplicant
mode=1 > scan_ssid=0 > ssid="mesh.test" > bssid=02:16:c8:6e:0f:1e > key_mgmt=WPA-PSK > proto=RSN > frequency=2472 > fixed_freq=1 > beacon_interval=1000 > > htmode=HT20 > > psk="1234567890" > > > Linux version 3.3.8 (cmsv@net) (gcc version 4.6.3 20120201 (prerelease) > (Linaro GCC 4.6-2012.02) ) #1 Thu Jun 27 22:23:26 EDT 2013 > DISTRIB_ID="OpenWrt" > DISTRIB_RELEASE="Attitude Adjustment" > DISTRIB_REVISION="r37034" > DISTRIB_CODENAME="attitude_adjustment" > DISTRIB_TARGET="ar71xx/generic" > DISTRIB_DESCRIPTION="OpenWrt Attitude Adjustment 12.09" > > > > Conclusion: > It does seem that wpa_supplicant is not compatible with option > beacon_int . However if i remove this option from the configuration or > specify it as option beacon_interval; then wpa_supplicant works for the > specified interface. > > Is this a bug, incompatibility or something 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] [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 wrote:
> wpa_supplicant expects beacon_int instead of beacon_interval in its config
> file.
>
> Signed-off-by: Bruno Randolf
> ---
> 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 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
>&
[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] 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 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
Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?
0.0 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 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 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
[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] 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 wrote: > 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] 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] 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 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 > <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
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
ated_anon:0 [315651.47] active_file:1421 inactive_file:1233 isolated_file:0 [315651.47] unevictable:0 dirty:0 writeback:0 unstable:0 [315651.47] free:68 slab_reclaimable:385 slab_unreclaimable:2131 [315651.47] mapped:574 shmem:48 pagetables:72 bounce:0 [315651.47] 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.47] lowmem_reserve[]: 0 0 [315651.47] 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.47] 2715 total pagecache pages [315651.47] 13 pages in swap cache [315651.47] Swap cache stats: add 41, delete 28, find 3/7 [315651.47] Free swap = 3004kB [315651.47] Total swap = 3068kB [315651.47] 8192 pages RAM [315651.47] 876 pages 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 siz
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 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: Un
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
> --- /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 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 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 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 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] [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 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] ?[ ` 1w>s>?
> ???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 migh
[OpenWrt-Devel] Documentation available for freifunk-watchdog service?
Might anyone know if updated and/or translated documentation for the freifunk-watchdog service is available somewhere? All I can find is the somewhat outdated German wiki page below: http://wiki.freifunk.net/Kamikaze/LuCI/Watchdog -- 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 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 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 >> 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] [PATCH] Add leds back after migration to sysfs
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 wrote: > From: Karl Palsson > > 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 > --- > .../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
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 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 wrote: >> > From: Karl Palsson >> > >> > 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 >> > --- >> > .../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] 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 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 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] 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] 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 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] 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 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 > https://lists.openwrt.org/**mailman/listinfo/openwrt-devel<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] atheros: Restructure target and cleanup
Hello, My apologies for replying to an old thread, but I am curious if the collection of patches which Jonathan assembled in the quoted text below have been committed in some form to trunk yet. On Tue, Dec 4, 2012 at 11:58 AM, Jonathan Bither wrote: > List, > On IRC jow suggested that I submit the large patch set as a tar.gz file > due to the size of the patches. > > These are just a preliminary cleanup of the target so that subsequent > patches will be will be easier to test and apply as discussed previously. > https://lists.openwrt.org/**pipermail/openwrt-devel/2012-** > November/017311.html<https://lists.openwrt.org/pipermail/openwrt-devel/2012-November/017311.html> > > tar patch contents: > 0001-atheros-The-mips-timer-**library-has-been-updated.-Thi.**patch > (Tested on ar2315) > 0002-atheros-Move-**architecture-code-out-of-**patches-and-in.patch > (No functional change) > 0003-atheros-Formatting-**cleanup-according-to-http-www.**ker.patch > (No functional change) > > ___ > 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] 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
[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
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 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
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 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
[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] 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 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] 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
[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] 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 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] Some atheros devices not loading kernel modules at boot, but work fine under AA
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 ___ 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 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
Re: [OpenWrt-Devel] Nanostation M2 - does it have a new soc chip from 2014?
eard 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
[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
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 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
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=products&advAction=&cat=1&catalogId=500201&cutTape=&inStock=&langId=-1&myCatalog=&npi=&proto=®ionalStock=&rohs=&searchType=&storeId=500201&term=dm355&topSellers= 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 wrote: > On Tue, Jan 17, 2012 at 8:33 PM, Ben West 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 > > 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 wrote: > AP mode? > > On Thu, Jan 19, 2012 at 2:42 PM, Ben West 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=products&advAction=&cat=1&catalogId=500201&cutTape=&inStock=&langId=-1&myCatalog=&npi=&proto=®ionalStock=&rohs=&searchType=&storeId=500201&term=dm355&topSellers= > > > > 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
[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] 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 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
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 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<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] 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 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 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, 1
