Re: [OpenWrt-Devel] Setting fragmentation threshold in atheros and ar71xx?
On 10/24/2013 01:59 PM, Ben West wrote: 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? IIRC fragmentation is disallowed in the driver when running 802.11N -- Ben West http://gowasabi.net b...@gowasabi.net mailto: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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] strict_strtoul is obsolete, use kstrtoul instead
Signed-off-by: Jonathan Bither jonbit...@gmail.com
---
.../linux/generic/files/drivers/net/phy/rtl8366_smi.c | 2 +-
target/linux/generic/patches-3.10/863-gpiommc.patch| 18 +-
.../patches-3.10/864-gpiommc_configfs_locking.patch| 2 +-
target/linux/generic/patches-3.3/863-gpiommc.patch | 18 +-
.../patches-3.3/864-gpiommc_configfs_locking.patch | 2 +-
target/linux/generic/patches-3.6/863-gpiommc.patch | 18 +-
.../patches-3.6/864-gpiommc_configfs_locking.patch | 2 +-
target/linux/generic/patches-3.7/863-gpiommc.patch | 18 +-
.../patches-3.7/864-gpiommc_configfs_locking.patch | 2 +-
target/linux/generic/patches-3.8/863-gpiommc.patch | 18 +-
.../patches-3.8/864-gpiommc_configfs_locking.patch | 2 +-
target/linux/generic/patches-3.9/863-gpiommc.patch | 18 +-
.../patches-3.9/864-gpiommc_configfs_locking.patch | 2 +-
.../patches-3.8/0007-Add-ili8960-lcd-driver.patch | 2 +-
14 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
b/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
index e2b4f02..699234d 100644
--- a/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
+++ b/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
@@ -743,7 +743,7 @@ static ssize_t rtl8366_write_debugfs_reg(struct file *file,
buf[len - 1] = '\0';
- if (strict_strtoul(buf, 16, data)) {
+ if (kstrtoul(buf, 16, data)) {
dev_err(smi-parent, Invalid reg value %s\n, buf);
} else {
err = rtl8366_smi_write_reg(smi, reg, data);
diff --git a/target/linux/generic/patches-3.10/863-gpiommc.patch
b/target/linux/generic/patches-3.10/863-gpiommc.patch
index a9101f4..00f7c8d 100644
--- a/target/linux/generic/patches-3.10/863-gpiommc.patch
+++ b/target/linux/generic/patches-3.10/863-gpiommc.patch
@@ -357,7 +357,7 @@
+ unsigned long data;
+
+ if (attr == gpiommc_attr_register) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -378,7 +378,7 @@
+ }
+
+ if (attr == gpiommc_attr_DI) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -389,7 +389,7 @@
+ goto out;
+ }
+ if (attr == gpiommc_attr_DO) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -400,7 +400,7 @@
+ goto out;
+ }
+ if (attr == gpiommc_attr_CLK) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -411,7 +411,7 @@
+ goto out;
+ }
+ if (attr == gpiommc_attr_CS) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -422,7 +422,7 @@
+ goto out;
+ }
+ if (attr == gpiommc_attr_CS_activelow) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -433,7 +433,7 @@
+ goto out;
+ }
+ if (attr == gpiommc_attr_spimode) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -457,7 +457,7 @@
+ goto out;
+ }
+ if (attr == gpiommc_attr_spidelay) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
@@ -468,7 +468,7 @@
+ goto out;
+ }
+ if (attr == gpiommc_attr_max_bus_speed) {
-+ err = strict_strtoul(page, 10, data);
++ err = kstrtoul(page, 10, data);
+ if (err)
+ goto out;
+ err = -EINVAL;
diff --git
a/target/linux/generic/patches-3.10/864-gpiommc_configfs_locking.patch
b/target/linux/generic/patches-3.10/864-gpiommc_configfs_locking.patch
index d4201eb..92815d9 100644
--- a/target/linux/generic/patches-3.10/864-gpiommc_configfs_locking.patch
+++ b/target/linux/generic/patches-3.10/864-gpiommc_configfs_locking.patch
@@ -37,7 +37,7 @@ does not lock access between files
Re: [OpenWrt-Devel] LUCI works extremely slow...
On 06/11/2013 03:34 PM, Ben West wrote: 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. IIRC there are a couple memory leaks with that ethernet driver. I've been meaning to rebase my git and submit some patches for that target shortly. My understanding is that the memory requirement is a hard limit. On Tue, Jun 11, 2013 at 4:13 AM, Wojciech Kromer wojciech.kro...@dgt.com.pl mailto:wojciech.kro...@dgt.com.pl wrote: My understanding is that OpenWRT Attitude Adjustment, along with current versions of trunk, are not expected to run in any reliable way under less than 32MB of RAM. In particular, the v3.x kernel is not supported for so little memory, and the OpenWRT dev community likewise doesn't support it. Hi Ben What you means is v3.x kernel don't support 32MB RAM? not the issue of LUCI? Everything else works fine, and I can see some devices with same hardware on openwrt supported list. Also new gargoyle works pretty good. During LUCI operations filesystem is heavly used, I can see a 50-90% CPU usage in [spi0] kernel process. Using precompiled version helps a little, but it's still unusable. Best regards. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net mailto: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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostapd doubts
Adhoc is configured by the 'iw' utility in the mac80211.sh script. On Tue 07 May 2013 09:10:11 AM EDT, Francisco Cuesta wrote: Thanks Felix for clarifying my newbie doubts!! Secondly, could someone point me out where in hostapd code is distinguished between adhoc mode and ap mode? Easy: AP mode uses it, Ad-Hoc mode doesn't. So, where is the ad-hoc mode configured then? Is it done in the proprietary driver (in my case ath9k) or it is done in the kernel? Thanks again 2013/5/7 Felix Fietkau n...@openwrt.org: On 2013-05-07 9:21 AM, Francisco Cuesta wrote: Hello, I have some doubts concerning to the hostapd package, working with Attitude Adjustment openwrt version. So, I would appreciate if someone might clarify them to me. Firstly, I have noticed that apart from the hostapd package included on package/hostapd directory, there is another small version of hostapd located in the drivers of the linux kernel (linux-3-3.8/drivers/net/wireless/hostap). Just because the name is similar doesn't mean that it's connected to hostapd :) My question is, if I had to change the main hostapd package, should I change the kernel version of hostap too? Might there be any kind of incompatibility if I only change the package and not the one in the kernel? I ask this, because I'm not sure whether they make use of each other or not. There's no connection between the two, so no compatibility issues. Secondly, could someone point me out where in hostapd code is distinguished between adhoc mode and ap mode? Easy: AP mode uses it, Ad-Hoc mode doesn't. - Felix ___ 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
Re: [OpenWrt-Devel] LTS Kernel
May be the completely wrong idea, but what if there was an OpenWRT-Kernel GIT repository holding the branches and modifications required for each arch. Would allow easy updates and backports from a Trunk branch to an LTS one. On 04/03/2013 12:31 PM, Bruno Wolff III wrote: On Wed, Apr 03, 2013 at 18:16:05 +0200, Rafał Miłecki zaj...@gmail.com wrote: Ohh, so there is policy of *not* doing *fixes* updates of the kernel? So we don't update for example from 3.4.30 to 3.4.38 after branching? If so, I had no idea about that, but it sounds pretty wrong. Minor (fixes) updates usually contain regression and security fixes. I wouldn't say policy as much as observed behavior. ___ 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
Re: [OpenWrt-Devel] LTS Kernel
On 04/03/2013 01:44 PM, Nick Podolak wrote: On Wed, Apr 3, 2013 at 12:36 PM, Jonathan Bither jonbit...@gmail.com mailto:jonbit...@gmail.com wrote: May be the completely wrong idea, but what if there was an OpenWRT-Kernel GIT repository holding the branches and modifications required for each arch. Would allow easy updates and backports from a Trunk branch to an LTS one. On 04/03/2013 12:31 PM, Bruno Wolff III wrote: On Wed, Apr 03, 2013 at 18:16:05 +0200, Rafał Miłecki zaj...@gmail.com mailto:zaj...@gmail.com wrote: Ohh, so there is policy of *not* doing *fixes* updates of the kernel? So we don't update for example from 3.4.30 to 3.4.38 after branching? If so, I had no idea about that, but it sounds pretty wrong. Minor (fixes) updates usually contain regression and security fixes. I wouldn't say policy as much as observed behavior. _ openwrt-devel mailing list openwrt-devel@lists.openwrt.__org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/__mailman/listinfo/openwrt-devel https://lists.openwrt.org/mailman/listinfo/openwrt-devel _ openwrt-devel mailing list openwrt-devel@lists.openwrt.__org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/__mailman/listinfo/openwrt-devel https://lists.openwrt.org/mailman/listinfo/openwrt-devel Jon, That basically exists today already in the buildroot system. It's just not a plain git repo. The patches folders in target/generic and then for each target/arch are numerous but relatively organized. Oh I know. I just meant that it may be easier to manage. and cherry-pick Rafa, Imre, Bruno, I'm not convinced that it makes sense to target an LTS kernel every release either, but I firmly believe that an LTS kernel should be targeted at least once every 2 years or so. A policy like this makes it easier to pull upstream *fixes*, in theory, for both maintainers and tinkerers even if that isn't the current modus operandi. ___ 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
Re: [OpenWrt-Devel] compcache / ramzswap / zram / frontswap
Hauke, I tested this patch today and just wanted to give some feedback. The patch applies cleanly and installs everything correctly, however it does not activate the swap on boot up. Executing '/etc/init.d/zram start' successfully starts. There is also a uci error when starting when the 'zram_size_mb' is not set. On 01/03/2013 03:17 PM, Hauke Mehrtens wrote: On 12/31/2012 05:07 PM, Bastian Bittorf wrote: since 2 years we are using zram[0] in our production networks and we love it. i like to kick out the package compcache which is very outdated and just use the mainline implementation. at the moment we are manually go into kernel_menuconfig and switch on: General setup: --- [*] Support for paging of anonymous memory (swap) Device Drivers --- Staging drivers --- [*] Compressed RAM block device support which means: CONFIG_FRONTSWAP is not set CONFIG_SWAP=y CONFIG_HIBERNATION is not set CONFIG_MTD_SWAP is not set CONFIG_ZRAM=y CONFIG_ZRAM_DEBUG is not set CONFIG_ZSMALLOC=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y also we use our own rc-file, so we can do /etc/init.d/zram start|stop https://github.com/bittorf/kalua/blob/master/openwrt-addons/etc/init.d/zram IMHO it should be a menuconfig-entry in base-system, because it is fundamental for all 16mb routers. What i need for baking a Makefile is a hint for a package which a) activates some symbols in kernel-config b) enforces building and loading of a kmodule c) has an rc-file I'am new to Make, so please help 8-) Also i like to have feedback. For the motivation, the output of a WRT54G running 3.6.11: root@openwrt:~ free total used free shared buffers Mem: 1300411420 15840 696 -/+ buffers: 10724 2280 Swap: 6140 584 5556 bye, bastian [0] https://code.google.com/p/compcache/ Nice work Bastian. I would not add it as a global option, but as a module, so it could also be used by someone not building his own image, but using a prebuild image, with kernel 3.6.11 I had a problem building this as a module. The swap utils e.g. from busybox are also needed, this increases the busybox binary by 3.2K uncompressed. CONFIG_BUSYBOX_CONFIG_MKSWAP=y CONFIG_BUSYBOX_CONFIG_SWAPONOFF=y Attached is a patch adding zram as a module. The default image without zram should be 3.2K bigger (uncompressed) but there are no more influences to a image without zram support. Bastian could you test this and give feedback? Hauke ___ 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
Re: [OpenWrt-Devel] tune kernel commandline for headless/embedded systems / oops=panic panic=10 / panic_on_oom=1
Bastian, I currently use these settings on all of my devices as well. Perhaps the simplest way to apply these values without having to modify each target/sub-target is to put a patch under 'target/linux/generic/patches-*' for the kernel that sets these values to defaults within the kernel. On 01/03/2013 05:57 AM, Bastian Bittorf wrote: oops=panic panic=10 / panic_on_oom=1 Reply-To: X-Editor: vi http://ex-vi.sourceforge.net/ In our production networks we had issues that some device needed a manual restart, because there where hanging/panic/oopsing during boot-time. We added to the kernel-commandline the args: 'oops=panic panic=10' like mentioned in this post: https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016430.html Now its much better, nearly no manual restarts are needed. I like to discuss that these changes are a good idea for everybody and should be standard for headless/embedded systems in production. If you care about patching away errors, developers (serial attached) can choose to not include it. also an init/rc-script after boot can switch this behaviour off. While we are at this point: 'panic_on_oom' is IMHO also a good choice. bye, bastian ___ 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
Re: [OpenWrt-Devel] OpenWrt hang when turn wifi on
Nguyen, I apologize I just now got to look at the log. The image is showing that it was created almost 1 year ago. This system is actually still running Madwifi. Perhaps the device didn't actually upgrade with your new image. On 12/14/2012 09:06 PM, Nguyễn Hồng Quân wrote: Hello Jonathan, Here is my dmesg output before I enable wifi On Fri 14 Dec 2012 09:07:57 PM ICT, Jonathan Bither wrote: Hello Nguyen, Would you be able to provide me with a 'dmesg' prior to starting wifi? On 12/14/2012 03:46 AM, Nguyễn Hồng Quân wrote: Hello, I'm building OpenWrt for Fonera router (FON2100) (Atheros target). By default, Wifi is off. But when I turn on the Wifi, OpenWrt freezes. There is even not output to Terminal (I flash firmware via serial cable). Did I build the firmware wrong or something else? Any help? Thanks. -- 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
Re: [OpenWrt-Devel] OpenWrt hang when turn wifi on
Hello Nguyen, Would you be able to provide me with a 'dmesg' prior to starting wifi? On 12/14/2012 03:46 AM, Nguyễn Hồng Quân wrote: Hello, I'm building OpenWrt for Fonera router (FON2100) (Atheros target). By default, Wifi is off. But when I turn on the Wifi, OpenWrt freezes. There is even not output to Terminal (I flash firmware via serial cable). Did I build the firmware wrong or something else? Any help? Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostapd ACS integration
Felix,
Thanks for this, there was actually a discussion about this yesterday
on linux-wireless, and as such I cc'd the included individuals on the
reply (Hope no one minds). I will be testing this on my local branches
today and I will report my findings. Would you be interested in sending
this to linux-wireless to get feedback and hopefully get this merged?
Thanks,
On 12/14/2012 01:12 AM, Felix Liao wrote:
The attachment is the all in one patch for hostapd 1.0 based on
*acs-all-in-one-v7.patch*
http://mirror.sit.wisc.edu/pub/linux/kernel/people/mcgrof/patches/hostapd/acs-all-in-one-v7.patch.
- Felix
*From:*Felix Liao
*Sent:* Friday, December 14, 2012 2:08 PM
*To:* 'openwrt-devel@lists.openwrt.org'
*Subject:* RE: hostapd ACS integration
Hello guys,
I had using Luis's ACS patch for a long time, I patched this patch on
the hostapd 1.0 source code, and made some fixes for it too.
The fix below change a bug when we check the secondary_channel, and
avoid accessing the NULL pointer.
I also attach the all in one patch based on hostapd 1.0 in this mail,
you can take a try.
diff --git a/acs-all-in-one-v7.patch b/acs-for-hostapd-1.0.patch
index 0695b6f..33def5e 100644
--- a/acs-all-in-one-v7.patch
+++ b/acs-for-hostapd-1.0.patch
@@ -46,6 +46,10 @@ index 86f6811..887744b 100644
+ unsigned int i;
+ struct hostapd_channel_data *chan;
+
++ if (primary == 0)
++ channel = iface-conf-channel +
++ iface-conf-secondary_channel * 4;
++
+ for (i = 0; i iface-current_mode-num_channels; i++) {
+ chan = iface-current_mode-channels[i];
+ if (chan-chan == channel) {
@@ -96,8 +100,6 @@ index 86f6811..887744b 100644
+
+static void hostapd_notify_bad_chans(struct hostapd_iface *iface)
+{
-+ iface-current_mode = NULL;
-+
+ hostapd_logger(iface-bss[0], NULL,
+ HOSTAPD_MODULE_IEEE80211,
+ HOSTAPD_LEVEL_WARNING,
@@ -109,6 +111,8 @@ index 86f6811..887744b 100644
+ hostapd_logger(iface-bss[0], NULL, HOSTAPD_MODULE_IEEE80211,
+ HOSTAPD_LEVEL_WARNING,
+ Hardware does not support configured channel);
++
++ iface-current_mode = NULL;
+}
/**
Thanks,
- Felix
___
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
Re: [OpenWrt-Devel] hostapd ACS integration
On 12/13/2012 10:05 AM, Johannes Reichhardt wrote: Hi, I'm a noob to openwrt and I can't get Automatic Channel Selection to run. I'm working with this patch. http://mirror.sit.wisc.edu/pub/linux/kernel/people/mcgrof/patches/hostapd/acs-all-in-one-v7.patch From reading some mail-lists and on boards it sounds pretty easy. Hostapd: version: 20120910 git: git://w1.fi/srv/git/hostap.git openwrt/project/openwrt/package/network/services/hostapd/ I placed the patch in: openwrt/project/openwrt/package/network/services/hostapd/patches/xxx-acs-all-in-one-v7.patch I also tried the older versions and ex- and included the other patches. Here is the Make/Patch error: http://pastebin.com/X94K9rjK _Does somebody know how to handle that? Or is there a patched version with acs support in any repository?_ _ _ _Thanks to all!_ _ _ _Cheers,_ _Jones_ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Johannes, Funny that you should mention this. The question about the status of ACS was recently brought up again on the linux-wireless mailing list the other day. They stated that the last patch-set was v8 and would need to be refreshed and updated to work with the current hostapd. I intend to reply to the original question and see if I may be of any help with testing and implementation. Jonathan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostapd ACS integration
Johannes, You're very welcome. Unfortunately I don't recall which revision the patch-set was for. I replied to the linux-wireless list asking if the person requesting the status intends to refresh and finish the implementation. In the event that he does not, I will refresh the patches and place them on a github branch to receive feedback and tests without spamming the mailing-list. Hopefully since multiple people are expressing interest and willing to test we'll get further than previous attempts. Thanks, On 12/13/2012 10:29 AM, Johannes Reichhardt wrote: Hi Jonathan, Thanx that you'll forward the last state to me :) Yeah after I sent the mail I found the v8 of the patch. But it's also not working. Do you know in which hostapd version the v8 patch worked last? Cheers Johannes From: Jonathan Bither jonbit...@gmail.com mailto:jonbit...@gmail.com Reply-To: OpenWrt Development List openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org Date: Thursday, December 13, 2012 4:22 PM To: openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] hostapd ACS integration On 12/13/2012 10:05 AM, Johannes Reichhardt wrote: Hi, I'm a noob to openwrt and I can't get Automatic Channel Selection to run. I'm working with this patch. http://mirror.sit.wisc.edu/pub/linux/kernel/people/mcgrof/patches/hostapd/acs-all-in-one-v7.patch From reading some mail-lists and on boards it sounds pretty easy. Hostapd: version: 20120910 git: git://w1.fi/srv/git/hostap.git openwrt/project/openwrt/package/network/services/hostapd/ I placed the patch in: openwrt/project/openwrt/package/network/services/hostapd/patches/xxx-acs-all-in-one-v7.patch I also tried the older versions and ex- and included the other patches. Here is the Make/Patch error: http://pastebin.com/X94K9rjK _Does somebody know how to handle that? Or is there a patched version with acs support in any repository?_ _ _ _Thanks to all!_ _ _ _Cheers,_ _Jones_ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.orghttps://lists.openwrt.org/mailman/listinfo/openwrt-devel Johannes, Funny that you should mention this. The question about the status of ACS was recently brought up again on the linux-wireless mailing list the other day. They stated that the last patch-set was v8 and would need to be refreshed and updated to work with the current hostapd. I intend to reply to the original question and see if I may be of any help with testing and implementation. Jonathan ___ 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
Re: [OpenWrt-Devel] [PATCH v2 1/1] atheros: Revert Add leds back after migration to sysfs
@Karl, Thank you, I will try to get ahold of one of those boards. @Hanno, This was intended to only fix the booting. I'll repost and include the gpio changes as well. I cloned the OpenWRT git onto github where I was going to start work on the updates for the atheros targets. Once they've all been tested on various pieces of hardware i'll submit them to openwrt-devel as patch-sets. Feel free to test and submit any merge requests prior to me submitting to openwrt-devel. https://github.com/JB1tz/openwrt-atheros Feel free to disregard this current patch so that we can try to merge everything at once. On 11/21/2012 06:27 PM, Karl P wrote: It's a dragino http://www.dragino.com/ They're also sold by flukso: https://www.flukso.net/ It's an ar2317. AA and trunk are the same, as this leds change went into trunk before AA was pulled as a separate branch. I only first tried this board out with backfire, and the wlan led worked out of the box. I added the sysfs support in AA/trunk, but I didn't change any of the gpio board setup. I also don't have any other atheros boards to try out. If you're planning on doing more work to clean this up, then sure, go ahead, but in that case, can it all go in together? Does it have to go in part now, and part later? Cheers, Karl Palsson On 11/21/2012 10:29 PM, Jonathan Bither wrote: Karl, I remember attitude adjustment not booting as well with flash errors, however I can try to rebuild an older backfire checkout and reflash the device to log the behavior. The revert was intended to be temporary to fix the regression with devices not booting. I plan on submitting additional patches that fix the intended behavior. Care to share the model of your device so that I may get one in to work with? Thanks, Jonathan Bither On 11/21/2012 05:02 PM, Karl P wrote: I'm still against reverting. What's really needed here is support for different atheros devices, not just outright dropping led support. Currently, the gpio setup is fixed for all devices, which clearly isn't ok. Sure, I admit that not booting your device is worse than my leds not working, but tossing it all out doesn't really seem like the right way forward. What was the backfire behaviour on your device? Ours had a working wifi light, and the gpio hasn't changed, so I'm surprised that it's only _just_ started being problems. Cheers, Karl P On 11/21/2012 09:03 PM, Jonathan Bither wrote: v2: explicitly unset CONFIG_LEDS_GPIO It causes flash access errors on devices that use a non-standard gpio line line to control the spi flash chip select. Fixes a handful of open tickets. First resolved in changeset # 16765 Signed-off-by: Jonathan Bither jonbit...@gmail.com --- 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
Re: [OpenWrt-Devel] [PATCH 1/1] atheros: Revert Add leds back after migration to sysfs
Please disregard. Did not fix the issue. Fixing properly now. On 11/20/2012 03:21 PM, Jonathan Bither wrote: It causes flash access errors on devices that use a non-standard gpio line line to control the spi flash chip select. First resolved in changeset # 16765 Signed-off-by: Jonathan Bither jonbit...@gmail.com --- target/linux/atheros/base-files/etc/uci-defaults/leds | 11 --- target/linux/atheros/config-3.3 |1 - 2 files changed, 12 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..d9722be 100644 --- a/target/linux/atheros/config-3.3 +++ b/target/linux/atheros/config-3.3 @@ -70,7 +70,6 @@ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/1] atheros: Revert Add leds back after migration to sysfs
v2: explicitly unset CONFIG_LEDS_GPIO It causes flash access errors on devices that use a non-standard gpio line line to control the spi flash chip select. Fixes a handful of open tickets. First resolved in changeset # 16765 Signed-off-by: Jonathan Bither jonbit...@gmail.com --- 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 -- 1.7.10.4 ___ 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
Karl, I remember attitude adjustment not booting as well with flash errors, however I can try to rebuild an older backfire checkout and reflash the device to log the behavior. The revert was intended to be temporary to fix the regression with devices not booting. I plan on submitting additional patches that fix the intended behavior. Care to share the model of your device so that I may get one in to work with? Thanks, Jonathan Bither On 11/21/2012 05:02 PM, Karl P wrote: I'm still against reverting. What's really needed here is support for different atheros devices, not just outright dropping led support. Currently, the gpio setup is fixed for all devices, which clearly isn't ok. Sure, I admit that not booting your device is worse than my leds not working, but tossing it all out doesn't really seem like the right way forward. What was the backfire behaviour on your device? Ours had a working wifi light, and the gpio hasn't changed, so I'm surprised that it's only _just_ started being problems. Cheers, Karl P On 11/21/2012 09:03 PM, Jonathan Bither wrote: v2: explicitly unset CONFIG_LEDS_GPIO It causes flash access errors on devices that use a non-standard gpio line line to control the spi flash chip select. Fixes a handful of open tickets. First resolved in changeset # 16765 Signed-off-by: Jonathan Bither jonbit...@gmail.com --- 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] [PATCH 1/1] atheros: Revert Add leds back after migration to sysfs
It causes flash access errors on devices that use a non-standard gpio line line to control the spi flash chip select. First resolved in changeset # 16765 Signed-off-by: Jonathan Bither jonbit...@gmail.com --- target/linux/atheros/base-files/etc/uci-defaults/leds | 11 --- target/linux/atheros/config-3.3 |1 - 2 files changed, 12 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..d9722be 100644 --- a/target/linux/atheros/config-3.3 +++ b/target/linux/atheros/config-3.3 @@ -70,7 +70,6 @@ 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 -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] atheros: Revert Add leds back after migration to sysfs
This also effects attitude adjustment, preventing many devices from booting. http://pastebin.com/EHCr6iZ9 On 11/20/2012 03:21 PM, Jonathan Bither wrote: It causes flash access errors on devices that use a non-standard gpio line line to control the spi flash chip select. First resolved in changeset # 16765 Signed-off-by: Jonathan Bither jonbit...@gmail.com --- target/linux/atheros/base-files/etc/uci-defaults/leds | 11 --- target/linux/atheros/config-3.3 |1 - 2 files changed, 12 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..d9722be 100644 --- a/target/linux/atheros/config-3.3 +++ b/target/linux/atheros/config-3.3 @@ -70,7 +70,6 @@ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] hostapd: updated dynamic vlan support
Confirmed operation today.
Acked-by: Jonathan Bitherjonbit...@gmail.com
On 11/13/2012 09:14 AM, Jonathan Bither wrote:
I use this feature often. I'll try to test this today and ack it if it
works for me.
On 10/16/2012 05:30 PM, Zenon Mousmoulas wrote:
This is based on the patches submitted by Matthew Bowman:
http://patchwork.openwrt.org/patch/1258/
http://patchwork.openwrt.org/patch/1261/
More recently hostapd has added support for setting the VLAN naming
scheme (eth0.11 vs. vlan11), in commit
a00237ceb8644fc270efd9fc0d0f8d0465db8410 upstream. So the updated patch
(620-dynamic_vlan-correct_bridge_interface_names.patch) only corrects
the bridge interface names (br-vlan11 vs. brvlan11).
Rather than shipping a default hostapd VLAN file, one is created at
runtime based on the wi-fi ifname.
Should this be accepted (hopefully!), I suppose the additional UCI
options would need to be documented; on the wiki? where else?
Signed-off-by: Zenon Mousmoulas zmo...@noc.grnet.gr
---
package/network/services/hostapd/files/hostapd.sh | 17
+
...namic_vlan-correct_bridge_interface_names.patch | 20
2 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644
package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index d60c26f..a462fe2 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -2,6 +2,7 @@ hostapd_set_bss_options() {
local var=$1
local vif=$2
local enc wep_rekey wpa_group_rekey wpa_pair_rekey
wpa_master_rekey wps_possible
+local vlan_enable ifname vlan_file vlan_interface vlan_naming
config_get enc $vif encryption
config_get wep_rekey$vif wep_rekey# 300
@@ -112,6 +113,22 @@ hostapd_set_bss_options() {
[ -n $wpa_group_rekey ] append $var
wpa_group_rekey=$wpa_group_rekey $N
[ -n $wpa_pair_rekey ] append $var
wpa_ptk_rekey=$wpa_pair_rekey$N
[ -n $wpa_master_rekey ] append $var
wpa_gmk_rekey=$wpa_master_rekey $N
+config_get vlan_enable $vif vlan_enable 0
+case $vlan_enable in
+1|2)
+append $var dynamic_vlan=$vlan_enable $N
+config_get ifname $vif ifname
+config_get vlan_file $vif vlan_file
/var/run/hostapd.${ifname}.vlan
+[ $vlan_file =
/var/run/hostapd.${ifname}.vlan ] cat $vlan_file -EOF
+* ${ifname}.#
+EOF
+append $var vlan_file=$vlan_file $N
+config_get vlan_interface $vif vlan_interface
eth0
+append $var
vlan_tagged_interface=$vlan_interface $N
+config_get vlan_naming $vif vlan_naming 1
+append $var vlan_naming=$vlan_naming $N
+;;
+esac
;;
*wep*)
config_get key $vif key
diff --git
a/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
b/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
new file mode 100644
index 000..ff87d3d
--- /dev/null
+++
b/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
@@ -0,0 +1,20 @@
+--- a/src/ap/vlan_init.c2012-10-14 22:30:08.0 +0300
b/src/ap/vlan_init.c2012-10-14 23:51:12.0 +0300
+@@ -493,7 +493,7 @@
+ while (vlan) {
+ if (os_strcmp(ifname, vlan-ifname) == 0) {
+
+-os_snprintf(br_name, sizeof(br_name), brvlan%d,
++os_snprintf(br_name, sizeof(br_name), br-vlan%d,
+ vlan-vlan_id);
+
+ if (!br_addbr(br_name))
+@@ -550,7 +550,7 @@
+
+ while (vlan) {
+ if (os_strcmp(ifname, vlan-ifname) == 0) {
+-os_snprintf(br_name, sizeof(br_name), brvlan%d,
++os_snprintf(br_name, sizeof(br_name), br-vlan%d,
+ vlan-vlan_id);
+
+ if (vlan-clean DVLAN_CLEAN_WLAN_PORT)
___
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
Re: [OpenWrt-Devel] [PATCH] [package] hostapd: updated dynamic vlan support
I use this feature often. I'll try to test this today and ack it if it
works for me.
On 10/16/2012 05:30 PM, Zenon Mousmoulas wrote:
This is based on the patches submitted by Matthew Bowman:
http://patchwork.openwrt.org/patch/1258/
http://patchwork.openwrt.org/patch/1261/
More recently hostapd has added support for setting the VLAN naming
scheme (eth0.11 vs. vlan11), in commit
a00237ceb8644fc270efd9fc0d0f8d0465db8410 upstream. So the updated patch
(620-dynamic_vlan-correct_bridge_interface_names.patch) only corrects
the bridge interface names (br-vlan11 vs. brvlan11).
Rather than shipping a default hostapd VLAN file, one is created at
runtime based on the wi-fi ifname.
Should this be accepted (hopefully!), I suppose the additional UCI
options would need to be documented; on the wiki? where else?
Signed-off-by: Zenon Mousmoulas zmo...@noc.grnet.gr
---
package/network/services/hostapd/files/hostapd.sh | 17 +
...namic_vlan-correct_bridge_interface_names.patch | 20
2 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644
package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index d60c26f..a462fe2 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -2,6 +2,7 @@ hostapd_set_bss_options() {
local var=$1
local vif=$2
local enc wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey
wps_possible
+ local vlan_enable ifname vlan_file vlan_interface vlan_naming
config_get enc $vif encryption
config_get wep_rekey$vif wep_rekey# 300
@@ -112,6 +113,22 @@ hostapd_set_bss_options() {
[ -n $wpa_group_rekey ] append $var
wpa_group_rekey=$wpa_group_rekey $N
[ -n $wpa_pair_rekey ] append $var
wpa_ptk_rekey=$wpa_pair_rekey$N
[ -n $wpa_master_rekey ] append $var
wpa_gmk_rekey=$wpa_master_rekey $N
+ config_get vlan_enable $vif vlan_enable 0
+ case $vlan_enable in
+ 1|2)
+ append $var dynamic_vlan=$vlan_enable
$N
+ config_get ifname $vif ifname
+ config_get vlan_file $vif vlan_file
/var/run/hostapd.${ifname}.vlan
+ [ $vlan_file = /var/run/hostapd.${ifname}.vlan ]
cat $vlan_file -EOF
+ * ${ifname}.#
+ EOF
+ append $var vlan_file=$vlan_file
$N
+ config_get vlan_interface $vif
vlan_interface eth0
+ append $var
vlan_tagged_interface=$vlan_interface $N
+ config_get vlan_naming $vif
vlan_naming 1
+ append $var vlan_naming=$vlan_naming
$N
+ ;;
+ esac
;;
*wep*)
config_get key $vif key
diff --git
a/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
b/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
new file mode 100644
index 000..ff87d3d
--- /dev/null
+++
b/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
@@ -0,0 +1,20 @@
+--- a/src/ap/vlan_init.c 2012-10-14 22:30:08.0 +0300
b/src/ap/vlan_init.c 2012-10-14 23:51:12.0 +0300
+@@ -493,7 +493,7 @@
+ while (vlan) {
+ if (os_strcmp(ifname, vlan-ifname) == 0) {
+
+- os_snprintf(br_name, sizeof(br_name), brvlan%d,
++ os_snprintf(br_name, sizeof(br_name), br-vlan%d,
+ vlan-vlan_id);
+
+ if (!br_addbr(br_name))
+@@ -550,7 +550,7 @@
+
+ while (vlan) {
+ if (os_strcmp(ifname, vlan-ifname) == 0) {
+- os_snprintf(br_name, sizeof(br_name), brvlan%d,
++ os_snprintf(br_name, sizeof(br_name), br-vlan%d,
+ vlan-vlan_id);
+
+ if (vlan-clean DVLAN_CLEAN_WLAN_PORT)
___
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] Atheros target development questions
Good morning list, I was writing to ask if there is a current maintainer for the Atheros target that I may contact. The reason that I ask is because I was contacted about a patch that I had submitted prior in regards to allowing various EnGenius devices to successfully reboot without a kernel hang. The patch didn't receive feedback and was never accepted. I know that most maintainers have moved on to more common and higher performance chipsets as of late, however there are still a lot of ar231x and ar531x chipsets still in the field. I will be required to maintain updates on these chipsets for my company and as such I would like to find the best way to submit various patches to the target with the highest probability of getting accepted. Would me cloning the OpenWRT mirror on github and submitting pull requests be sufficient, or would each patch source have to be sent through the mailing list? Currently the target is setup through patch sets. I know that this was intended so that the platform could ultimately be mainlined into the kernel easily. I ask if I may break apart the patch sets into the 'files-3.x' overlay layout temporarily as other targets have, so that I may be able to submit various patches in a more timely manner as opposed to patching patch sets. These could just as easily be transferred into patch form again in the event of a push to get the target mainlined. On my TODO: Remove duplicate code between the ar231x and ar531x platforms. Address all gpio/led polling flash errors. Determine the hardware limitation of the CPU processing/Ethernet speed. Add ethtool support to the Ethernet driver. Add BQL to the Ethernet driver. Rewrite sections of the Ethernet driver for maximum performance. Add gpio detection mechanisms to address EnGenius products cleanly. Any feedback is greatly appreciated. Thanks, Jonathan Bither ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Atheros target development questions
Thanks, I'll setup my git environment again and merge them all into branches and split the patches. On 11/09/2012 07:22 AM, John Crispin wrote: On 09/11/12 13:16, Karl Palsson wrote: On Fri, Nov 09, 2012 at 06:11:47AM -0500, Jonathan Bither wrote: Good morning list, I was writing to ask if there is a current maintainer for the Atheros target that I may contact. The reason that I ask is because I was contacted about a patch that I had submitted prior in regards to allowing various EnGenius devices to successfully reboot without a kernel hang. The patch didn't receive feedback and was never accepted. I know that most maintainers have moved on to more common and higher performance chipsets as of late, however there are still a lot of ar231x and ar531x chipsets still in the field. I will be required to maintain updates on these chipsets for my company and as such I would like to find the best way to submit various patches to the target with the highest probability of getting accepted. Would me cloning the OpenWRT mirror on github and submitting pull requests be sufficient, or would each patch source have to be sent through the mailing list? I can't speak for the maintainer or OpenWRT development team, but we still use ar2317 platforms here, and I'm more than happy to help out with testing these devices. Unfornately, we _only_ have ar2317, so I can't help with verifying any of the unification code. Sincerely, Karl P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hi, go ahead with your proposed idea and mail the patches to the -devel mailinglist please. John ___ 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
Re: [OpenWrt-Devel] [PATCH] Add support for TP-Link WA7510N
On 10/25/2012 09:31 PM, Stefan Helmert wrote: From Stefan Helmert helst_lis...@aol.de It is mostly the same as wr841nd. WLAN and LAN are working. LAN-Led ist working. WLAN signal strength Leds are not working yet. I imagine that you can actually get the signal leds operating correctly if you add the configuration for the package rssileds. When I get time I wanted to do the same for various ubiquiti devices. http://wiki.openwrt.org/toh/tp-link/tl-wa7510n?s[]=wa7510n Signed-off-by: Stefan Helmert helst_lis...@aol.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add support for TP-Link WA7510N
On 10/26/2012 09:49 AM, Stefan Helmert wrote: I hope this will work. You should know, the leds on ubiquity devices are connected to the ar7240 main-controller. On TL-WA7510N they are connected to ar9280 wlan-device as gpio-device. I imagine that the leds are wired directly to the ar7240 by way of GPIO and can be controlled as such. Please can you tell me more about rssileds. Daniel Golle introduced a daemon that polls the wireless driver's stats and can adjust external leds to represent their quality. Here's where it's introduced and the commit log explains it in greater detail. https://dev.openwrt.org/browser/trunk/package/rssileds/src/rssileds.c?rev=33163 Am 26.10.2012 15:40, schrieb Jonathan Bither: I imagine that you can actually get the signal leds operating correctly if you add the configuration for the package rssileds. When I get time I wanted to do the same for various ubiquiti devices. ___ 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
Re: [OpenWrt-Devel] [PATCH] Add support for TP-Link WA7510N
On 10/26/2012 10:44 AM, Stefan Helmert wrote: The leds are connected to the ar9280 on WA7510N. The wlan-chip does also have gpio-support. I checked it out. The only way to control the leds is to use the ath9k gpio functionality. I hope rssileds will support this directly. I will read about it. The only led which is connected to the ar7240 is the lan-led. The source that you linked to is rather old. I just checked out wireless-testing again and it looks as though the gpio initialization only will poll for 1 led. May I ask how you have verified that the led is wired to the ar9280? Also do you have the boot log of OpenWRT loading on this device? Am 26.10.2012 16:06, schrieb Jonathan Bither: On 10/26/2012 09:49 AM, Stefan Helmert wrote: I hope this will work. You should know, the leds on ubiquity devices are connected to the ar7240 main-controller. On TL-WA7510N they are connected to ar9280 wlan-device as gpio-device. I imagine that the leds are wired directly to the ar7240 by way of GPIO and can be controlled as such. Please can you tell me more about rssileds. Daniel Golle introduced a daemon that polls the wireless driver's stats and can adjust external leds to represent their quality. Here's where it's introduced and the commit log explains it in greater detail. https://dev.openwrt.org/browser/trunk/package/rssileds/src/rssileds.c?rev=33163 Am 26.10.2012 15:40, schrieb Jonathan Bither: I imagine that you can actually get the signal leds operating correctly if you add the configuration for the package rssileds. When I get time I wanted to do the same for various ubiquiti devices. ___ 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
Re: [OpenWrt-Devel] [PATCH] Add leds back after migration to sysfs
I can confirm that this issue effects EnGenius ECB-3500 as well. On 08/27/2012 09: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 ka...@tweak.net.au wrote: From: Karl Palsson ka...@remake.is atheros trunk moved to full sysfs gpiolib, but the leds were forgotten. This restores the wlan led that was missing after switching from backfire to trunk. Signed-off-by: Karl Palsson ka...@remake.is --- .../linux/atheros/base-files/etc/uci-defaults/leds | 11 +++ target/linux/atheros/config-3.3|1 + 2 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 target/linux/atheros/base-files/etc/uci-defaults/leds diff --git a/target/linux/atheros/base-files/etc/uci-defaults/leds b/target/linux/atheros/base-files/etc/uci-defaults/leds new file mode 100644 index 000..076a04b --- /dev/null +++ b/target/linux/atheros/base-files/etc/uci-defaults/leds @@ -0,0 +1,11 @@ +#!/bin/sh +# Copyright 2012 OpenWrt.org +# + +. /lib/functions/uci-defaults.sh + +ucidef_set_led_netdev wlan wlan wlan wlan0 + +ucidef_commit_leds + +exit 0 diff --git a/target/linux/atheros/config-3.3 b/target/linux/atheros/config-3.3 index be0c74a..c3713b3 100644 --- a/target/linux/atheros/config-3.3 +++ b/target/linux/atheros/config-3.3 @@ -70,6 +70,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_IP17XX_PHY=y CONFIG_IRQ_CPU=y CONFIG_IRQ_FORCED_THREADING=y +CONFIG_LEDS_GPIO=y CONFIG_MDIO_BOARDINFO=y CONFIG_MIPS=y CONFIG_MIPS_L1_CACHE_SHIFT=5 -- 1.7.2.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath5k and txpower
When I rebuilt the other day my ar2315 would not boot due to jffs2 errors. I haven't checked to see if it was something in my tree, but just thought i'd let you know. I can rebuilt with a clean true today and watch serial to see if the issue persists. On 08/24/2012 01:02 PM, Ben West wrote: My problem is likely unrelated, but could you (Tobias) say precisely what revision of trunk you are using? Freshly compiled trunk r33202 w/ default config does not appear to boot at all on my OM1P (ar2315 chipset), i.e. no response on eth0. However, I don't think the bugs mentioned w/ compat-wireless in this thread could cause that. On Sat, Aug 4, 2012 at 7:34 PM, Tobias Diedrich ranma+open...@tdiedrich.de wrote: Compiling OpenWRT from trunk, I've found that there are issues with setting txpower on AR2417: - No txpower setting in LuCI gui - iw phy phy0 info shows 0dBm for all channels regardless of regdomain [9.332000] cfg80211: Calling CRDA to update world regulatory domain [9.34] cfg80211: World regulatory domain updated: [9.344000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [9.352000] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.36] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.364000] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.372000] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.38] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) root@OpenWrt:/# iw phy phy0 info Wiphy phy0 Band 1: Frequencies: * 2412 MHz [1] (0.0 dBm) * 2417 MHz [2] (0.0 dBm) * 2422 MHz [3] (0.0 dBm) * 2427 MHz [4] (0.0 dBm) * 2432 MHz [5] (0.0 dBm) * 2437 MHz [6] (0.0 dBm) * 2442 MHz [7] (0.0 dBm) * 2447 MHz [8] (0.0 dBm) * 2452 MHz [9] (0.0 dBm) * 2457 MHz [10] (0.0 dBm) * 2462 MHz [11] (0.0 dBm) * 2467 MHz [12] (0.0 dBm) * 2472 MHz [13] (0.0 dBm) * 2484 MHz [14] (disabled) One issue seems to be fallout from http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de AFAICS max_power for the channels is never set and thus min(chan-max_power, chan-max_reg_power) is 0. This patch tries to fix this (but is probably wrong :)) After applying this patch iw phy phy0 info looks good, but WiFi Analyzer on my phone still shows a very weak signal for the AP. Until I do this: root@OpenWrt:/# iw phy phy0 set txpower fixed 0 root@OpenWrt:/# iw phy phy0 set txpower auto And then the signal strength is good. iw phy phy0 set txpower fixed|limit still doesn't accept values above 0 for some reason though. Index: compat-wireless-2012-07-16/drivers/net/wireless/ath/ath5k/base.c === --- compat-wireless-2012-07-16.orig/drivers/net/wireless/ath/ath5k/base.c 2012-08-05 01:42:19.141413438 +0200 +++ compat-wireless-2012-07-16/drivers/net/wireless/ath/ath5k/base.c 2012-08-05 01:44:19.957568271 +0200 @@ -325,6 +325,8 @@ if (!ath5k_is_standard_channel(ch, band)) continue; + channels[count].max_power = AR5K_TUNE_MAX_TXPOWER; + count++; } -- Tobias PGP: http://8ef7ddba.uguu.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Time Division Multiple Access (TDMA)
Nico, I too have been interested in experimenting with TDMA. When I looked a while ago the most helpful information that I saw was that TDMA support is apparently included in freebsd. You may want to take a look at how it is implemented over there. http://fxr.watson.org/fxr/source/net80211/ieee80211_tdma.c On 07/13/2012 12:04 AM, Nicolás Echániz wrote: Are there any current implementations or active development around TDMA in OpenWRT? I've been doing some research and found a few projects and papers, usually using OpenWRT as experimental platform and heavily based on modified mdwifi drivers. Two examples: - jaldimac - srawan I've written to the developers of these projects and they are both abandoned and in a non-usable state. Other developments in the area are closed source, like : karlnet TurboCell or Ubiquiti's and Mikrotik's implementations. And other related projects seem to be abandoned also: fractel, 2P, WiLDnet, wiccp So... anyone knows of current work on the subject in the OpenWRT camp? Cheers, NicoEchániz ___ 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] [PATCH] atheros: Fix compilation
With our recent switch to the 3.3 kernel target, some headers were occidentally omitted. Signed-off-by: Jonathan Bither jonbit...@gmail.com --- a/target/linux/atheros/patches-3.3/100-board.patch +++ b/target/linux/atheros/patches-3.3/100-board.patch @@ -2884,10 +2884,13 @@ +#endif --- /dev/null +++ b/arch/mips/include/asm/mach-ar231x/ar231x.h -@@ -0,0 +1,54 @@ +@@ -0,0 +1,57 @@ +#ifndef __AR531X_H +#define __AR531X_H + ++#include linux/types.h ++#include linux/io.h ++ +#define AR531X_MISC_IRQ_BASE 0x20 +#define AR531X_GPIO_IRQ_BASE 0x30 + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add Patch in package/mac80211 for AP and Mesh to operate simultaneously in Single Radio
Have you tried submitting this to linux-wireless?
On 03/02/2012 11:52 AM, Yeoh Chun-Yeow wrote:
Hi, all
This is mainly for ath5k.
Regards,
Chun-Yeow
On Sat, Mar 3, 2012 at 12:50 AM, Yeoh Chun-Yeow yeohchuny...@gmail.com
mailto:yeohchuny...@gmail.com wrote:
This patch allows the possibility of having the mesh point and AP to
be operated
simultaneously in one single radio. Previously, mesh point fails to
generate the
mesh beacon if virtual AP is created for the same radio.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
mailto:yeohchuny...@gmail.com
---
Index: package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
===
--- package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
(revision 0)
+++ package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
(revision 0)
@@ -0,0 +1,52 @@
+--- a/drivers/net/wireless/ath/ath5k/ath5k.h
b/drivers/net/wireless/ath/ath5k/ath5k.h
+@@ -1320,6 +1320,7 @@ struct ath5k_hw {
+ struct ieee80211_vif*bslot[ATH_BCBUF];
+ u16 num_ap_vifs;
+ u16 num_adhoc_vifs;
++ u16 num_mesh_vifs;
+ unsigned intbhalq, /* SW q for outgoing
beacons */
+ bmisscount, /* missed beacon
transmits */
+ bintval,/* beacon interval
in TU */
+--- a/drivers/net/wireless/ath/ath5k/base.c
b/drivers/net/wireless/ath/ath5k/base.c
+@@ -1867,7 +1867,8 @@ ath5k_beacon_send(struct ath5k_hw *ah)
+ ah-bmisscount = 0;
+ }
+
+- if ((ah-opmode == NL80211_IFTYPE_AP ah-num_ap_vifs +
ah-num_adhoc_vifs 1) ||
++ if ((ah-opmode == NL80211_IFTYPE_AP ah-num_ap_vifs
++ + ah-num_adhoc_vifs + ah-num_mesh_vifs 1) ||
+ ah-opmode == NL80211_IFTYPE_MESH_POINT) {
+ u64 tsf = ath5k_hw_get_tsf64(ah);
+ u32 tsftu = TSF_TO_TU(tsf);
+@@ -1952,7 +1953,8 @@ ath5k_beacon_update_timers(struct ath5k_
+ u64 hw_tsf;
+
+ intval = ah-bintval AR5K_BEACON_PERIOD;
+- if (ah-opmode == NL80211_IFTYPE_AP ah-num_ap_vifs +
ah-num_adhoc_vifs 1) {
++ if (ah-opmode == NL80211_IFTYPE_AP ah-num_ap_vifs
++ + ah-num_mesh_vifs + ah-num_adhoc_vifs 1) {
+ intval /= ATH_BCBUF;/* staggered multi-bss
beacons */
+ if (intval 15)
+ ATH5K_WARN(ah, intval %u is too low, min 15\n,
+--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+@@ -129,6 +129,8 @@ ath5k_add_interface(struct ieee80211_hw
+ ah-num_ap_vifs++;
+ else if (avf-opmode == NL80211_IFTYPE_ADHOC)
+ ah-num_adhoc_vifs++;
++ else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
++ ah-num_mesh_vifs++;
+ }
+
+ /* Any MAC address is fine, all others are included through the
+@@ -170,6 +172,8 @@ ath5k_remove_interface(struct ieee80211_
+ ah-num_ap_vifs--;
+ else if (avf-opmode == NL80211_IFTYPE_ADHOC)
+ ah-num_adhoc_vifs--;
++ else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
++ ah-num_mesh_vifs--;
+
+ ath5k_update_bssid_mask_and_opmode(ah, NULL);
+ mutex_unlock(ah-lock);
___
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
Re: [OpenWrt-Devel] wifi detect returns nothing (openwrt trunk with RB411 R52 (lspci lists radio as AR5413 802.11abg)
Hanno, Do we happen to have a list of known issues so that we can work on getting them resolved instead of reverting back to mac80211? On 02/27/2012 03:15 PM, Hanno Schupp wrote: I am not a developer, but I can tell you the ath9k is for b/g/n cards, so that may be the reason. You should use either ath5k or madwifi driver. Personally I found many issues with ath5k integration into openwrt still unresolved in terms of card and device recognition and am consequently in the process to downgrade to madwifi again. Madwifi is no longer developed by the linux open driver project as opposed to ath5k, but the focus and interest of the OpenWrt community has moved on from atheros to ar71xx architecture and thus to ath9k fair and square. As soon as trunk switched one day from madwifi to ath5k on the legacy atheros architecture I started encountering issues - but this is my experience, others may have a different view. On 28 February 2012 09:08, Brian Hutchinsonb.hutch...@gmail.com wrote: Hi, These boxes use to be working but I recently upgraded them to the latest trunk and now my wireless cards are no longer detected. No /etc/config/wireless and trying to generate the file with wifi detect does nothing. Not sure what is going on since everything looks OK. lsmod output is at the end of the email. If I recall, the last build that was working used madwifi and the version I built from trunk uses ath9k. In make menuconfig I remember there was an option for madwifi but I didn't include it as I didn't think it was needed anymore. Did I need that??? Regards, Brian root@OpenWrt:/etc/config# lsmod Module Size Used byTainted: G ath9k 88800 0 ohci_hcd 15760 0 ledtrig_usbdev 2032 0 nf_nat_irc 784 0 nf_conntrack_irc2464 1 nf_nat_irc nf_nat_ftp 976 0 nf_conntrack_ftp4416 1 nf_nat_ftp ipt_MASQUERADE 976 1 iptable_nat 2112 1 nf_nat 9904 4 nf_nat_irc,nf_nat_ftp,ipt_MASQUERADE,iptable_nat xt_conntrack2048 3 xt_CT 1216 0 xt_NOTRACK 448 0 iptable_raw 560 1 xt_state 608 0 nf_conntrack_ipv4 3872 6 iptable_nat,nf_nat nf_defrag_ipv4 624 1 nf_conntrack_ipv4 nf_conntrack 36624 12 nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,xt_conntrack,xt_CT,xt_NOTRACK,xt_state,nf_conntrack_ipv4 ehci_hcd 32544 0 pppoe 7472 0 pppox 1152 1 pppoe ipt_REJECT 1808 2 xt_TCPMSS 1824 0 ipt_LOG 6048 0 xt_comment 400 0 xt_multiport1104 0 xt_mac 528 0 xt_limit 944 1 iptable_mangle 832 1 iptable_filter 624 1 ip_tables 8864 4 iptable_nat,iptable_raw,iptable_mangle,iptable_filter xt_tcpudp 1632 3 x_tables 1 18 ipt_MASQUERADE,iptable_nat,xt_conntrack,xt_CT,xt_NOTRACK,iptable_raw,xt_state,ipt_REJECT,xt_TCPMSS,ipt_LOG,xt_comment,xt_multiport,xt_mac,xt_limit,iptable_mangle,iptable_filter,ip_tables,xt_tcpudp ppp_async 5952 0 ppp_generic18544 3 pppoe,pppox,ppp_async slhc4368 1 ppp_generic ath9k_common1152 1 ath9k ath9k_hw 347344 2 ath9k,ath9k_common ath14112 3 ath9k,ath9k_common,ath9k_hw mac80211 233280 1 ath9k usbcore98336 4 ohci_hcd,ledtrig_usbdev,ehci_hcd usb_common 480 1 usbcore nls_base4560 1 usbcore crc_ccitt944 1 ppp_async cfg80211 134320 3 ath9k,ath,mac80211 compat 688 0 arc4 768 0 aes_generic29808 0 crypto_algapi 8976 2 arc4,aes_generic leds_gpio 1552 0 gpio_button_hotplug 3184 0 ___ 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
Re: [OpenWrt-Devel] wifi detect returns nothing (openwrt trunk with RB411 R52 (lspci lists radio as AR5413 802.11abg)
If you wanted immediate relief you could also just select the right driver for your card ;-). Ath5k is the replacement for Madwifi. By selecting ath5k in trunk your radios should operate fine. On 02/27/2012 04:08 PM, Brian Hutchinson wrote: So if I want immediate relief from this, I should drop back to Backfire and turn on madwifi in makemenuconfig? About the only Atheros boxes I have to test with are these two RB411's (one with regular R52 radio and one with the high power version of the R52 radio) and a Buffalo WZR-HP-G300NH (which runs fine with trunk). I would like to work on this problem for trunk. I haven't had the RB411's long and I sure would like to be able to rely on future OpenWRT support. I'm kind of bummed it sounds like nobody cares about supporting this hardware going forward! Regards, Brian ___ 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
Re: [OpenWrt-Devel] Sysupgrade bounty
Philip, I would love to try to help you. Would you be able to catch me up on what you have tried or the configuration that you are using so I can have a starting point? On 02/20/2012 04:09 AM, Philip Prindeville wrote: Ok, I'll put $500 USD of my own money toward the sysupgrade port to x86 if it can work demonstrably on Alix hardware. I've also been told by a couple of hardware vendors that one or both will donate a platform to this project. -Philip ___ 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
Re: [OpenWrt-Devel] Sysupgrade x86 bounty
I have a couple alix's in the office I can play with to try to help. On 02/10/2012 06:11 PM, Philip Prindeville wrote: Sysupgrade currently doesn't allow updating software in place without clobbering the existing config (stored on the ext4 overlay filesystem that immediately follows the jffs2 filesystem). I've spoken to various interested parties using x86 hardware, and we'd like to see if anyone is interested in doing bounty work to support sysupgrade on x86. Thanks, -Philip ___ 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
Re: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support
Hano,
Thank you for reviewing the patch, especially since it was my first
submission. This patch was based off of the trunk branch. I have tested this
patch with both Madwifi as well as ath5k. Since this patch was my first
submission I only submitted the version for 2.6.37. I was hoping for feedback
or suggestions so that I could clean it up and submit a V2 with 2.6.38. I have
tested this patch with the following boards: ECB-3500, EAP-3660, EOA-3630,
EOC-2611P, EOC-1650, EOC-5611P. EnGenius had provided me with one of each to
test with. The radio information can be actually be pulled from the
boardconfig, so that the device can be checked in the kernel regardless of
radio driver. Unfortunately the ECB-3500, EAP-3660, EOA-3630, EOC-2611P all
share the same radio information while having different GPIO outputs for their
leds. As of yet I have not found a way to identify them apart as to properly
register the correct GPIOs to leds. If you are interested I am happy to try to
clean
up the patch for a resubmission.
On 02/05/2012 12:26 AM, Hanno Schupp wrote:
Hi Jonathan,
Thank you for this patch. I am currently using a simplified version of what
you are doing in an approach that relies on compiling a specific version of
the firmware for the different models
(https://dev.openwrt.org/attachment/ticket/6202/100-board-trunk-b18541.patch
) as it hard codes the different value.
Your patch is of course much more elegant, but I wonder what OpenWrt version
and what wireless driver you are using, as in my experience the radio
information is only available when using the madwifi driver, not with ath5k.
Q: Which wireless river are you using, ath5k or madwifi?
Q: Are you compiling in trunk or with backfire?
Also, the Atheros platform seems to hold patches both for 2.6.37 and 2.6.38
kernels. It is not clear to me when what kernel is used.
Q: Your patch addresses 2.6.37 kernel only; is that sufficient?
Last but not least, my patch works with 1650 only. 2611p still does not
recover from soft reboot and hangs although AR2315_RESET_GPIO is set to 0
just as much as for EOC-1650.
Q: Which of the units ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650,
EOC-5611P have you actually tested?
Q: In particular, can you confirm your patch works with EOC-2611P?
Thanks very much in advance for your input.
Hanno
-Original Message-
From: openwrt-devel-boun...@lists.openwrt.org
[mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jonathan
Bither
Sent: Friday, 23 December 2011 9:32 a.m.
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support
Attached is a patch for trunk which fixes gpio assignments for EnGenius
devies on the ar231x platform. This patch fixes rebooting as well the reset
button for the following devices:
ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650, EOC-5611P
Signed-off-by: Jonathan Bither jonbit...@gmail.com
Index: target/linux/atheros/patches-2.6.37/400-engenius-support.patch
===
--- target/linux/atheros/patches-2.6.37/400-engenius-support.patch
(revision 0)
+++ target/linux/atheros/patches-2.6.37/400-engenius-support.patch
(revision 0)
@@ -0,0 +1,159 @@
+--- a/arch/mips/include/asm/mach-ar231x/ar231x_platform.h
b/arch/mips/include/asm/mach-ar231x/ar231x_platform.h
+@@ -66,6 +66,15 @@
+
+ /* radio calibration data */
+ const char *radio;
++
++/* Reset GPIO */
++u32 resetGpio;
++
++/* Reset Button GPIO */
++u32 resetButtonGpio;
++
++/* EnGenius AP Workaround */
++int EnGenius;
+ };
+
+ /*
+--- a/arch/mips/ar231x/ar2315.c
b/arch/mips/ar231x/ar2315.c
+@@ -554,8 +554,8 @@
+ ar2315_led_data.num_leds = 0;
+ for(i = 1; i 8; i++)
+ {
+-if((i == AR2315_RESET_GPIO) ||
+- (i == ar231x_board.config-resetConfigGpio))
++if((i == ar231x_board.resetGpio) ||
++ (i == ar231x_board.resetButtonGpio))
+ continue;
+
+ if(i == ar231x_board.config-sysLedGpio) @@ -610,11 +610,11
@@
+ /* Cold reset does not work on the AR2315/6, use the GPIO reset bits
a workaround.
+ * give it some time to attempt a gpio based hardware reset
+ * (atheros reference design workaround) */
+-gpio_direction_output(AR2315_RESET_GPIO, 0);
++gpio_request(ar231x_board.resetGpio, );
++gpio_direction_output(ar231x_board.resetGpio, 0);
+ mdelay(100);
+
+-/* Some boards (e.g. Senao EOC-2610) don't implement the reset logic
+- * workaround. Attempt to jump to the mips reset location -
++/* Attempt to jump to the mips reset location -
+ * the boot loader itself might be able to recover the system */
+ mips_reset_vec();
+ }
+--- a/arch/mips/ar231x/reset.c
b/arch/mips/ar231x/reset.c
+@@ -13,12 +13,12 @@
+ #include
Re: [OpenWrt-Devel] Init Script to Foreground
Why not add a pre-init hook? On 01/17/2012 02:02 PM, Pawel Pastuszak wrote: Ok, but i am looking for it to go into the foreground and i want to lock the console access till it finished running it then reboot. Pawel On Tue, Jan 17, 2012 at 1:52 PM, Luka Perkov open...@lukaperkov.net mailto:open...@lukaperkov.net wrote: On Tue, Jan 17, 2012 at 01:42:13PM -0500, Pawel Pastuszak wrote: Hello everybody, I have an odd question i am trying to find an way to have my init script on power up to take over the console so the process can be interrupted. It's pretty much if an flag is set to x in kernel arguments then do y but i want y to be the foreground process. What i notice all Init script are executed in background. Any thoughts for any one? If your script is in the foreground and does not finish your openwrt will not boot completely. That is especialy the case when you boot openwrt for the first time after flashing it on the device. Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto: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
Re: [OpenWrt-Devel] Init Script to Foreground
You can probably have a hook similar to the failsafe hook that does echo 1 /tmp/pawelhook and have your init script read it and do whatever you want. On 01/17/2012 02:10 PM, Pawel Pastuszak wrote: Need dhcp up first and everything mounted. So if there is an easy flag for that then i think pre-init would solve my issue. Pawel On Tue, Jan 17, 2012 at 2:05 PM, Jonathan Bither jonbit...@gmail.com mailto:jonbit...@gmail.com wrote: Why not add a pre-init hook? On 01/17/2012 02:02 PM, Pawel Pastuszak wrote: Ok, but i am looking for it to go into the foreground and i want to lock the console access till it finished running it then reboot. Pawel On Tue, Jan 17, 2012 at 1:52 PM, Luka Perkov open...@lukaperkov.net mailto:open...@lukaperkov.net mailto:open...@lukaperkov.net mailto:open...@lukaperkov.net__ wrote: On Tue, Jan 17, 2012 at 01:42:13PM -0500, Pawel Pastuszak wrote: Hello everybody, I have an odd question i am trying to find an way to have my init script on power up to take over the console so the process can be interrupted. It's pretty much if an flag is set to x in kernel arguments then do y but i want y to be the foreground process. What i notice all Init script are executed in background. Any thoughts for any one? If your script is in the foreground and does not finish your openwrt will not boot completely. That is especialy the case when you boot openwrt for the first time after flashing it on the device. Luka _ openwrt-devel mailing list openwrt-devel@lists.openwrt.__org mailto:openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.__openwrt.org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/__mailman/listinfo/openwrt-devel https://lists.openwrt.org/mailman/listinfo/openwrt-devel _ openwrt-devel mailing list openwrt-devel@lists.openwrt.__org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/__mailman/listinfo/openwrt-devel https://lists.openwrt.org/mailman/listinfo/openwrt-devel _ openwrt-devel mailing list openwrt-devel@lists.openwrt.__org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/__mailman/listinfo/openwrt-devel 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
Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package
That's a pretty neat example and idea behind it. Perhaps it would be beneficial to apply the same concept to the mac80211 stack that once loaded would expose /dev/iwrandom? Jonathan, On 01/12/2012 12:07 PM, g@free.fr wrote: - Mail original - De: Roman Yeryominleroi.li...@gmail.com À: Florian Fainelliflor...@openwrt.org Cc: OpenWrt Development Listopenwrt-devel@lists.openwrt.org Envoyé: Jeudi 12 Janvier 2012 17:29:26 Objet: Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package On 12 January 2012 18:02, Florian Fainelliflor...@openwrt.org wrote: Although I've done this on ramips platform and didn't face any issues I think that, potentially, a better source or entropy would be radio noise. Of cause if it's possible to get. Indeed, using entropy from Wi-Fi cards would also be a good idea since it's less predictable. As you say, using radio noise would be even better. -- So, the question is if it's possible to get some noise signals/info from the wireless chips. Maybe anyone have done this before? Regards, Roman I find only this old example http://www.freewebs.com/pmutaf/iwrandom.html Gilles ___ 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
Re: [OpenWrt-Devel] [PATCH] ar71xx TCP/IPsec unaligned instructions
On a side note would the unaligned patch in the ar71xx target benefit the atheros target? On 01/04/2012 10:58 AM, Markus Stockhausen wrote: Hello, attached an extension to the already existing patch that will fix some more unaligned accesses on ar71xx devices. First patch location during establishing of tcp recv operations. The second one is only relevant for IPsec tunnels. In my setup this results in the following numbers: - Without patch: Normal transmission of 400MB between router and client ~ 140k mem faults Encrpyted transmission of 200MB between router and client ~ 600k mem faults With patch: Normal transmission of 400MB between router and client ~ No more mem faults Encrpyted transmission of 200MB between router and client ~ 480k mem faults Signed-off-by: markus dot stockhausen at collogia dot de Best regards. Markus ___ 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] [PATCH] Add EnGenius ar231x support
Attached is a patch for trunk which fixes gpio assignments for EnGenius
devies on the ar231x platform. This patch fixes rebooting as well the
reset button for the following devices:
ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650, EOC-5611P
Signed-off-by: Jonathan Bither jonbit...@gmail.com
Index: target/linux/atheros/patches-2.6.37/400-engenius-support.patch
===
--- target/linux/atheros/patches-2.6.37/400-engenius-support.patch
(revision 0)
+++ target/linux/atheros/patches-2.6.37/400-engenius-support.patch
(revision 0)
@@ -0,0 +1,159 @@
+--- a/arch/mips/include/asm/mach-ar231x/ar231x_platform.h
b/arch/mips/include/asm/mach-ar231x/ar231x_platform.h
+@@ -66,6 +66,15 @@
+
+ /* radio calibration data */
+ const char *radio;
++
++ /* Reset GPIO */
++ u32 resetGpio;
++
++ /* Reset Button GPIO */
++ u32 resetButtonGpio;
++
++ /* EnGenius AP Workaround */
++ int EnGenius;
+ };
+
+ /*
+--- a/arch/mips/ar231x/ar2315.c
b/arch/mips/ar231x/ar2315.c
+@@ -554,8 +554,8 @@
+ ar2315_led_data.num_leds = 0;
+ for(i = 1; i 8; i++)
+ {
+- if((i == AR2315_RESET_GPIO) ||
+- (i == ar231x_board.config-resetConfigGpio))
++ if((i == ar231x_board.resetGpio) ||
++ (i == ar231x_board.resetButtonGpio))
+ continue;
+
+ if(i == ar231x_board.config-sysLedGpio)
+@@ -610,11 +610,11 @@
+ /* Cold reset does not work on the AR2315/6, use the GPIO reset bits
a workaround.
+* give it some time to attempt a gpio based hardware reset
+* (atheros reference design workaround) */
+- gpio_direction_output(AR2315_RESET_GPIO, 0);
++ gpio_request(ar231x_board.resetGpio, );
++ gpio_direction_output(ar231x_board.resetGpio, 0);
+ mdelay(100);
+
+- /* Some boards (e.g. Senao EOC-2610) don't implement the reset logic
+- * workaround. Attempt to jump to the mips reset location -
++ /* Attempt to jump to the mips reset location -
+* the boot loader itself might be able to recover the system */
+ mips_reset_vec();
+ }
+--- a/arch/mips/ar231x/reset.c
b/arch/mips/ar231x/reset.c
+@@ -13,12 +13,12 @@
+ #include ar231x.h
+ #include devices.h
+
+-#define AR531X_RESET_GPIO_IRQ
(AR531X_GPIO_IRQ(ar231x_board.config-resetConfigGpio))
++#define AR531X_RESET_GPIO_IRQ
(AR531X_GPIO_IRQ(ar231x_board.resetButtonGpio))
+
+ struct event_t {
+ struct work_struct wq;
+ int set;
+- unsigned long jiffies;
++ unsigned long jiffies, jiffies_prev;
+ };
+
+ static struct timer_list rst_button_timer;
+@@ -68,8 +68,14 @@
+ add_msg(skb, PATH=/sbin:/bin:/usr/sbin:/usr/bin);
+ add_msg(skb, SUBSYSTEM=button);
+ add_msg(skb, BUTTON=reset);
+- add_msg(skb, (event-set ? ACTION=pressed : ACTION=released));
+- sprintf(buf, SEEN=%ld, (event-jiffies - seen)/HZ);
++
++ /* EnGenius input level is reversed */
++ if (ar231x_board.EnGenius)
++ add_msg(skb, (event-set ? ACTION=released :
ACTION=pressed));
++ else
++ add_msg(skb, (event-set ? ACTION=pressed :
ACTION=released));
++
++ sprintf(buf, SEEN=%lu, (event-jiffies - event-jiffies_prev)/HZ);
+ add_msg(skb, buf);
+ snprintf(buf, 128, SEQNUM=%llu, uevent_next_seqnum());
+ add_msg(skb, buf);
+@@ -103,6 +109,7 @@
+
+ event-set = 0;
+ event-jiffies = jiffies;
++ event-jiffies_prev = seen;
+ INIT_WORK(event-wq, hotplug_button);
+ schedule_work(event-wq);
+ }
+@@ -144,7 +151,7 @@
+ {
+ seen = jiffies;
+
+- if (ar231x_board.config-resetConfigGpio == 0x)
++ if (ar231x_board.resetButtonGpio == 0x)
+ return -ENODEV;
+
+ init_timer(rst_button_timer);
+--- a/arch/mips/ar231x/board.c
b/arch/mips/ar231x/board.c
+@@ -23,6 +23,7 @@
+ #include asm/io.h
+
+ #include ar231x_platform.h
++#include ar2315_regs.h
+ #include devices.h
+ #include ar5312.h
+ #include ar2315.h
+@@ -138,6 +139,8 @@
+ u8 *board_data;
+ u8 *radio_data;
+ u8 *mac_addr;
++ u16 *radio_info;
++ u16 vendor, id, subvendor, subid;
+ u32 offset;
+
+ ar231x_board.config = NULL;
+@@ -190,11 +193,42 @@
+
+ radio_data = board_data + 0x100 + ((rcfg - bcfg) 0xfff);
+ ar231x_board.radio = radio_data;
++ ar231x_board.EnGenius = 0;
++ ar231x_board.resetGpio = AR2315_RESET_GPIO;
++ ar231x_board.resetButtonGpio = ar231x_board.config-resetConfigGpio;
+ offset = radio_data - board_data;
+ printk(KERN_INFO Radio config found at offset 0x%x(0x%x)\n, rcfg -
bcfg, offset);
+ rcfg_size = BOARD_CONFIG_BUFSZ - offset;
+ memcpy(radio_data, rcfg, rcfg_size);
+
++ /* If we have radio information try to identify the board */
++ radio_info = (u16 *) ar231x_board.radio;
++ if (radio_info) {
++ vendor
