[OpenWrt-Devel] ISC-DHCP server removed from Chaos Calmer packages, why?
Greetings! I was curious to the reason why the ISC-DHCP server seems to have been removed from Chaos Calmer packages; tried to find info in mailing list archive and by general googling but was unable to. Anyone know why it was removed? BACKGROUND: Dnsmasq (at least on Barrier Breaker) isn't too fast on handling multiple parallel DHCP requests. I understood the isc-dhcp-server-ipv4 would be better suited for this and more performant and was researching using/switching to it. Has the DHCP functionality of Dnsmasq possibly been improved in Chaos Calmer? Any other comments/suggestions? Best regards, -Janne Cederberg Finland ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Translating LuCI? (https://luci.subsignal.org/pootle/ down)
Greetings! TL;DR: Anyone able to write a short description on LuCI translation process and tools needed? LONGER EXPLANATION: I'm hoping to create a Finnish translation for the LuCI interface. However I can't find the instructions for the translation process as https://luci.subsignal.org/pootle/ has been down (502 Bad Gateway on Nginx) for several days. 1) Anyone involved with the https://luci.subsignal.org/pootle/ site to be able to aid in getting back up-n-running? 2) As an alternative to #1, is someone on the list able to describe the translation process? I'm suspected the translations to be use GNU Gettext based on the translation file extension .lmo (which I guessed to means LuCI mo) but when I renamed one of them to .mo and tried msgunfmt filename.mo it got the response that the file is not in GNU .mo format. I then took a look at the file in a hex editor and noticed it seems to contain HTML with nullbyte delimiters or something in that fashion. Anyone able help? Thank you in advance, Janne Cederberg Helsinki, Finland ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Translating LuCI? (https://luci.subsignal.org/pootle/ down)
Hey Christian! Thank you for the info, helps a lot! I'm familiar with Poedit and po/mo files so will be a breeze :) Thanks again! -Janne On Apr 2, 2015 8:03 PM, Christian Schoenebeck christian.schoeneb...@gmail.com wrote: Hi Janne, from my knowledge pottle is down since LuCI moved to GitHub. inside luci/modules/[package] and luci/applications/[application] on source tree you should find a po directory where translations are stored. Inside there is a templates/[file].pot This is the catalog (master) the translation based on. There are also directorys for every translated language. In there are stored the final .po files. This .po files are translated/compiled into the needed .lmo files during compilation of LuCI. There are a lot of tools on the web handling .pot and .po files. I personally use poedit on my Xubuntu. To publish the final .po file use the standard contribution methods and guidelines of LuCI project on GitHub at https://github.com/openwrt/luci Does this help ? Christian Am 02.04.2015 um 10:28 schrieb Janne Cederberg: Greetings! TL;DR: Anyone able to write a short description on LuCI translation process and tools needed? LONGER EXPLANATION: I'm hoping to create a Finnish translation for the LuCI interface. However I can't find the instructions for the translation process as https://luci.subsignal.org/pootle/ has been down (502 Bad Gateway on Nginx) for several days. 1) Anyone involved with the https://luci.subsignal.org/pootle/ site to be able to aid in getting back up-n-running? 2) As an alternative to #1, is someone on the list able to describe the translation process? I'm suspected the translations to be use GNU Gettext based on the translation file extension .lmo (which I guessed to means LuCI mo) but when I renamed one of them to .mo and tried msgunfmt filename.mo it got the response that the file is not in GNU .mo format. I then took a look at the file in a hex editor and noticed it seems to contain HTML with nullbyte delimiters or something in that fashion. Anyone able help? Thank you in advance, Janne Cederberg Helsinki, Finland ___ 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
Re: [OpenWrt-Devel] Multiple OpenWrt devices collectively managed?
Cool, this sparked a conversation :) Yes, the background of the question was not a mesh network but a network where all APs could be connected to the same switch for example and from there to a DHCP server. A controller would control which channels the APs operate on to minimize interference a) from each other and b) from possible other networks. David Lang stated exactly what I was attempting to convey. So there's the auto mode in OpenWrt but that only considers the state of the wifi spectrum at the ifup of the wifi adapter, correct? So if things drastically change later, the AP would stay on the same channel and not switch. I haven't used but understood that for example Cisco enterprice APs can be controller-managed and the controller can tell an individual or multiple APs to switch channels to actively avoid bad channels. What ideas the switch algorithm actually is based upon/using I personally have no clue of atm. Just started looking into the issue a few days ago. Personally I'm familiar and semi-fluent with Ansible, used it in one project so far. I was thinking the same thing David mentioned, namely, that determining channel change criterion is probably not trivial. Are you guys familiar with Cisco Meraki? -Janne 2015-03-23 21:45 GMT+02:00 David Lang da...@lang.hm: On Mon, 23 Mar 2015, Bastian Bittorf wrote: * David Lang da...@lang.hm [23.03.2015 20:19]: question is around having something to automatically assign channels amoung the different APs to minimize interference between the APs and between the APs and other things in the area. we just use hostapd athXk acs-survey/channel=auto...why dont you? For one thing I hadn't heard of it before now :-) I would need to test and see what it recommends in real-world conditions. It seems designed for setting up a single AP (although it really shouldn't try every 2.4GHz channel), but when trying to pick channels for a bunch of APs in an area, I see nothing in the documentation that would prevent every AP from picking the same channel because it was marginally better when everything is quiet. Then when you start to see heavy usage, the situaion will have changed drastically and you would have to take time away from servicing clients to scan other channels (during which time you are not transmitting normally, so any other APs doing a survey during the same time would get a faulty view of what the conditions are), and would the system converge to a stable setup, or would it always be shifting traffic. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multiple OpenWrt devices collectively managed?
Oh, sorry Bastian I forgot to comment on your suggestion earlier! Question: how does that constant restarting affect network QoS/throughput? -Janne 2015-03-23 23:17 GMT+02:00 Bastian Bittorf bitt...@bluebottle.com: * Janne Cederberg janne.cederb...@gmail.com [23.03.2015 22:13]: So there's the auto mode in OpenWrt but that only considers the state of the wifi spectrum at the ifup of the wifi adapter, correct? So if things drastically change later, the AP would stay on the same channel and not switch. what we do in our custom solution: restart the wifi after the last station has left. that triggers often and reshuffles the channels... bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Multiple OpenWrt devices collectively managed?
Greetings all! Been searching around and found for example OpenWISP but thought I'd ask the list as well: is there some opensource management software for OpenWrt that could control a set of multiple OpenWrt AP's on the same SSID; so basically controlling their channels based on channel use and actively avoiding crowded/DOS'sed channels for example? Best regards, Janne Cederberg ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Kind request to commit http://patchwork.ozlabs.org/patch/449868/
Greetings all! On thursday I provided this patch regarding the Hornet-UB board; the commit was accepted: http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=beed4d82d6a0154b0cd5f7b84e2180215ace6718 I ended up making a mistake on it though: changed the WPS LED related active_low value as well which I shouldn't have. I sent a patch for it here: http://patchwork.ozlabs.org/patch/449868/ Could blogic (who accepted the prev commit) or someone else someone kindly commit this small but significant change? Thank you :) Br, Janne Cederberg ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Fix duplicate tickets 14136 and 15282 (Hornet UB GPIO WPS/Reset)
As a clarification to the previous patch, when I refer to [the] above
change, I wrote the text from the point of view of the following Trac
pages:
https://dev.openwrt.org/ticket/14136
https://dev.openwrt.org/ticket/15282
and was referring to the solution presented on those tickets and
claiming them as incomplete and my patch as resolving the issue.
Best regards,
-Janne Cederberg
2015-03-11 20:48 GMT+02:00 Janne Cederberg janne.cederb...@gmail.com:
This problem has existed at least since Attitude Adjustment and
is also present in trunk. Basically on the Hornet-UB board the
functionality of RESET and WPS have switched places.
There are two tickets about the issue at dev.openwrt.org,
The solution suggested on them both is incomplete though
and introduces the following proglem:
Patching as suggested on #14136/#15282 will result in a situation
where simply pressing the RESET button on the bottom will cause
FACTORY RESET to be run. This is due to GPIO high/low state being
incorrect as a result of the above change and virtually the RESET
button is in the pressed-down state the entire time. When it is
then physically pressed, that causes the opposite, release, to be
triggered and since to the board it seemed that the button was
pressed long before it was released, the FACTORY RESET results.
The attached patch works as expected. I have verified both the
incorrect functionality as well as after fixing the issue as
described in the patch and flashing the resulting firmware to a
Hornet-UB board.
Signed-off-by: Janne Cederberg janne.cederb...@gmail.com
---
target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
index 22b1e09..b36c511 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
@@ -28,8 +28,8 @@
#define HORNET_UB_GPIO_LED_WAN 17
#define HORNET_UB_GPIO_LED_WPS 27
-#define HORNET_UB_GPIO_BTN_RESET 11
-#define HORNET_UB_GPIO_BTN_WPS 12
+#define HORNET_UB_GPIO_BTN_RESET 12
+#define HORNET_UB_GPIO_BTN_WPS 11
#define HORNET_UB_GPIO_USB_POWER 26
@@ -64,7 +64,7 @@ static struct gpio_led hornet_ub_leds_gpio[] __initdata = {
{
.name = alfa:blue:wps,
.gpio = HORNET_UB_GPIO_LED_WPS,
- .active_low = 1,
+ .active_low = 0,
},
};
@@ -75,7 +75,7 @@ static struct gpio_keys_button hornet_ub_gpio_keys[]
__initdata = {
.code = KEY_WPS_BUTTON,
.debounce_interval = HORNET_UB_KEYS_DEBOUNCE_INTERVAL,
.gpio = HORNET_UB_GPIO_BTN_WPS,
- .active_low = 1,
+ .active_low = 0,
},
{
.desc = Reset button,
@@ -83,7 +83,7 @@ static struct gpio_keys_button hornet_ub_gpio_keys[]
__initdata = {
.code = KEY_RESTART,
.debounce_interval = HORNET_UB_KEYS_DEBOUNCE_INTERVAL,
.gpio = HORNET_UB_GPIO_BTN_RESET,
- .active_low = 0,
+ .active_low = 1,
}
};
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] Fix duplicate tickets 14136 and 15282 (Hornet UB GPIO WPS/Reset)
This problem has existed at least since Attitude Adjustment and
is also present in trunk. Basically on the Hornet-UB board the
functionality of RESET and WPS have switched places.
There are two tickets about the issue at dev.openwrt.org,
The solution suggested on them both is incomplete though
and introduces the following proglem:
Patching as suggested on #14136/#15282 will result in a situation
where simply pressing the RESET button on the bottom will cause
FACTORY RESET to be run. This is due to GPIO high/low state being
incorrect as a result of the above change and virtually the RESET
button is in the pressed-down state the entire time. When it is
then physically pressed, that causes the opposite, release, to be
triggered and since to the board it seemed that the button was
pressed long before it was released, the FACTORY RESET results.
The attached patch works as expected. I have verified both the
incorrect functionality as well as after fixing the issue as
described in the patch and flashing the resulting firmware to a
Hornet-UB board.
Signed-off-by: Janne Cederberg janne.cederb...@gmail.com
---
target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
index 22b1e09..b36c511 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c
@@ -28,8 +28,8 @@
#define HORNET_UB_GPIO_LED_WAN 17
#define HORNET_UB_GPIO_LED_WPS 27
-#define HORNET_UB_GPIO_BTN_RESET 11
-#define HORNET_UB_GPIO_BTN_WPS 12
+#define HORNET_UB_GPIO_BTN_RESET 12
+#define HORNET_UB_GPIO_BTN_WPS 11
#define HORNET_UB_GPIO_USB_POWER 26
@@ -64,7 +64,7 @@ static struct gpio_led hornet_ub_leds_gpio[] __initdata = {
{
.name = alfa:blue:wps,
.gpio = HORNET_UB_GPIO_LED_WPS,
- .active_low = 1,
+ .active_low = 0,
},
};
@@ -75,7 +75,7 @@ static struct gpio_keys_button hornet_ub_gpio_keys[]
__initdata = {
.code = KEY_WPS_BUTTON,
.debounce_interval = HORNET_UB_KEYS_DEBOUNCE_INTERVAL,
.gpio = HORNET_UB_GPIO_BTN_WPS,
- .active_low = 1,
+ .active_low = 0,
},
{
.desc = Reset button,
@@ -83,7 +83,7 @@ static struct gpio_keys_button hornet_ub_gpio_keys[]
__initdata = {
.code = KEY_RESTART,
.debounce_interval = HORNET_UB_KEYS_DEBOUNCE_INTERVAL,
.gpio = HORNET_UB_GPIO_BTN_RESET,
- .active_low = 0,
+ .active_low = 1,
}
};
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Fix duplicate tickets 14136 and 15282 (Hornet UB GPIO WPS/Reset)
I have a flash image built based on Barrier Breaker's trunk as of today + this patch...in case you Josh or someone else is interested. -Janne 2015-03-11 21:10 GMT+02:00 Joshua Judson Rosen jro...@harvestai.com: On 2015-03-11 14:48, Janne Cederberg wrote: This problem has existed at least since Attitude Adjustment and is also present in trunk. Basically on the Hornet-UB board the functionality of RESET and WPS have switched places. There are two tickets about the issue at dev.openwrt.org, The solution suggested on them both is incomplete though and introduces the following proglem: Patching as suggested on #14136/#15282 will result in a situation where simply pressing the RESET button on the bottom will cause FACTORY RESET to be run. This is due to GPIO high/low state being incorrect as a result of the above change and virtually the RESET button is in the pressed-down state the entire time. When it is then physically pressed, that causes the opposite, release, to be triggered and since to the board it seemed that the button was pressed long before it was released, the FACTORY RESET results. The attached patch works as expected. Interesting--I don't have a good excuse for why I missed that fact myself, but thanks a bunch for picking the issue/patch up and running with it! I'm still doing a bunch of work with the Hornet-UB devices, so I'll be quite delighted if this makes it into a release :) -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
