date:20151126

Re: [OpenWrt-Devel] [PATCH] oxnas: fix the incorrect board names

2015-11-26 Thread Daniel Golle

Somehow it seems like the wrong patch got committed instead of this
one...

On Sun, Nov 22, 2015 at 02:35:30PM +0100, Daniel Golle wrote:
> On Sun, Nov 08, 2015 at 04:12:30AM +0800, Shonn Lu wrote:
> > Signed-off-by: Shonn Lu 
> Acked-by: Daniel Golle 
> 
> > ---
> >  target/linux/oxnas/base-files/etc/board.d/01_leds | 2 +-
> >  target/linux/oxnas/base-files/etc/diag.sh | 4 ++--
> >  target/linux/oxnas/base-files/lib/oxnas.sh| 6 +++---
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/target/linux/oxnas/base-files/etc/board.d/01_leds 
> > b/target/linux/oxnas/base-files/etc/board.d/01_leds
> > index 17e37cd..f075764 100755
> > --- a/target/linux/oxnas/base-files/etc/board.d/01_leds
> > +++ b/target/linux/oxnas/base-files/etc/board.d/01_leds
> > @@ -14,7 +14,7 @@ case $board in
> > kd20)
> > ucidef_set_led_default "power" "power" "kd20:blue:status" "1"
> > ;;
> > -   pogoplugpro | pogoplugv3)
> > +   pogoplug-pro | pogoplug-v3)
> > ucidef_set_led_default "power" "power" "pogoplug:blue:internal" 
> > "1"
> > ;;
> >  
> > diff --git a/target/linux/oxnas/base-files/etc/diag.sh 
> > b/target/linux/oxnas/base-files/etc/diag.sh
> > index 5370696..8f484ae 100644
> > --- a/target/linux/oxnas/base-files/etc/diag.sh
> > +++ b/target/linux/oxnas/base-files/etc/diag.sh
> > @@ -6,13 +6,13 @@
> >  
> >  get_status_led() {
> > case $(oxnas_board_name) in
> > -   stg212)
> > +   stg-212)
> > status_led="zyxel:blue:status"
> > ;;
> > kd20)
> > status_led="kd20:blue:status"
> > ;;
> > -   pogoplugpro | pogoplugv3)
> > +   pogoplug-pro | pogoplug-v3)
> > status_led="pogoplug:blue:internal"
> > ;;
> > esac
> > diff --git a/target/linux/oxnas/base-files/lib/oxnas.sh 
> > b/target/linux/oxnas/base-files/lib/oxnas.sh
> > index 1a04d55..2a07928 100755
> > --- a/target/linux/oxnas/base-files/lib/oxnas.sh
> > +++ b/target/linux/oxnas/base-files/lib/oxnas.sh
> > @@ -14,16 +14,16 @@ oxnas_board_detect() {
> >  
> > case "$machine" in
> > *"MitraStar Technology Corp. STG-212"*)
> > -   name="stg212"
> > +   name="stg-212"
> > ;;
> > *"Shuttle KD20"*)
> > name="kd20"
> > ;;
> > *"Pogoplug Pro"*)
> > -   name="pogoplugpro"
> > +   name="pogoplug-pro"
> > ;;
> > *"Pogoplug V3"*)
> > -   name="pogoplugv3"
> > +   name="pogoplug-v3"
> > ;;
> > esac
> >  
> > -- 
> > 1.9.1
> > ___
> > 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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] oxnas: set irq of usb to cpu1

2015-11-26 Thread Daniel Golle

Hi!

This was committed in r47618 though it is buggy (see below) and not
clear whether manually setting irq-affinity is at all feasible.
Please revert.

Cheers

Daniel

On Mon, Nov 23, 2015 at 04:24:02PM +0100, Daniel Golle wrote:
> On Mon, Nov 23, 2015 at 02:30:34PM +0800, Shonn Lu wrote:
> > Signed-off-by: Shonn Lu 
> > ---
> >  .../linux/oxnas/base-files/init.d/set-irq-affinity | 22 
> > ++
> >  1 file changed, 22 insertions(+)
> >  create mode 100755 target/linux/oxnas/base-files/init.d/set-irq-affinity
> > 
> > diff --git a/target/linux/oxnas/base-files/init.d/set-irq-affinity 
> > b/target/linux/oxnas/base-files/init.d/set-irq-affinity
> > new file mode 100755
> > index 000..8ab066f
> > --- /dev/null
> > +++ b/target/linux/oxnas/base-files/init.d/set-irq-affinity
> > @@ -0,0 +1,22 @@
> > +#!/bin/sh /etc/rc.common
> > +
> > +START=99
> > +
> > +get_irq() {
> > +   local name="$1"
> > +   grep -m 1 "$name" /proc/interrupts | cut -d: -f1 | sed 's, *,,'
> > +}
> > +
> > +set_irq_affinity() {
> > +   local name="$1"
> > +   local val="$2"
> > +   local irq="$(get_irq "$name")"
> > +   [ -n "$irq" ] || return
> > +   echo "$val" > "/proc/irq/$irq/smp_affinity"
> > +}
> > +
> > +start() {
> > +   set_irq_affinity ehci_hcd 2
> > +   set_irq_affinity xhci_hcd 2
> > +   set_irq_affinity sata 2
> > +}
> 
> I'm sorry to be such a pain, however, now that I have a closer look I
> realize that naming is 'ehci_hcd' but 'xhci-hcd' (note: '-' vs. '_')
> Maybe
> 
>   set_irq_affinity ehci 2
>   set_irq_affinity xhci 2
> 
> is the safest for now and allows for kernel's driver naming to
> eventually get unified in the future...
> 
> 
> Cheers
> 
> 
> Daniel
> ___
> 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] SVN to GIT transition / paid patch-checking

2015-11-26 Thread bkil

Hello,

Sorry for my late input.

I'd been considering starting a funded, but non-profit fork with close
upstream collaboration just for the above reasons and for reasons even
beyond that. I'm delighted that others came to a similar conclusion.

Start seems probable (early?) next year. I welcome any input relating
to this topic.

Regards,
bkil

On Tue, Oct 13, 2015 at 5:10 PM, Bastian Bittorf  wrote:
> * Daniel Golle  [13.10.2015 16:53]:
>> If you want an industry-driven fork, go ahead. But don't force that
>> model upon an existing community without understanding how major parts
>> of that said community is operating.
>
> What I see since a long time, is that there is simply not
> enough manpower for reviewing patches and "simple" maintainance
> work (trac, buildbots) and this more and more leads to an unhappy
> community and overloaded devs.
>
> commercial pressure is'nt good, i agree - but maybe there is
> a way to have at least 1 fulltime or 2 parttime devs.
>
> bye, bastian
> ___
> 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] fstools: factory reset on power failure during startup

2015-11-26 Thread Florian Eckert

Hi,

I am using openwrt CC and an ubifs filesystem on top of ubi.
If I plug off the power during startup, some times my configuration
get lost and i am back to factory reset.

In the package fstools there is the bin "mount_root" it is called
twice during startup.
1. S10boot at line 10
2. S95done at line 6

this calles edit the ./fs_state link

S10boot/S95done:
---
Because ubifs is doing filesystem handling in a background process
"ubi_bgt0d", could it be possible,
that (see code) ./.fs_state is not rewritten written anymore?
So that at next boot the system thinks he is in upgrade mode?

If I add a sleep(10) between unlink and symlink function call i can
reproduce the failure if i unplug the power.
I think the first think what should be done is to call
"snprintf(valstr, sizeof(valstr), "%d", state);" before "unlink(path).

Or this this a deeper Problem?

int fs_state_set(const char *dir, enum fs_state state)
{
char valstr[16];
char *path;

->path = alloca(strlen(dir) + 1 + sizeof("/.fs_state"));
->sprintf(path, "%s/.fs_state", dir);
->unlink(path);
->snprintf(valstr, sizeof(valstr), "%d", state);

return symlink(valstr, path);
}

Regards
Flo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] fstools: factory reset on power failure during startup

2015-11-26 Thread John Crispin



On 26/11/2015 09:24, Florian Eckert wrote:
> Hi,
> 
> I am using openwrt CC and an ubifs filesystem on top of ubi.
> If I plug off the power during startup, some times my configuration
> get lost and i am back to factory reset.
> 
> In the package fstools there is the bin "mount_root" it is called
> twice during startup.
> 1. S10boot at line 10
> 2. S95done at line 6
> 
> this calles edit the ./fs_state link
> 
> S10boot/S95done:
> ---
> Because ubifs is doing filesystem handling in a background process
> "ubi_bgt0d", could it be possible,
> that (see code) ./.fs_state is not rewritten written anymore?
> So that at next boot the system thinks he is in upgrade mode?
> 
> If I add a sleep(10) between unlink and symlink function call i can
> reproduce the failure if i unplug the power.
> I think the first think what should be done is to call
> "snprintf(valstr, sizeof(valstr), "%d", state);" before "unlink(path).
> 
> Or this this a deeper Problem?

interesting bug. felix recently added this "i crashed during firstboot,
lets retry" feature recently but it seesm that this works well on
classical (spi-)nor flash but fails on nand/ubi.

i've made a note and will look at this, however i am porting a new
target today so might not happen till start of the week. (unless felix
has time to look at it beforehand)

John

> 
> int fs_state_set(const char *dir, enum fs_state state)
> {
> char valstr[16];
> char *path;
> 
> ->path = alloca(strlen(dir) + 1 + sizeof("/.fs_state"));
> ->sprintf(path, "%s/.fs_state", dir);
> ->unlink(path);
> ->snprintf(valstr, sizeof(valstr), "%d", state);
> 
> return symlink(valstr, path);
> }
> 
> Regards
> Flo
> ___
> 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] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

2015-11-26 Thread Hans Dedecker

Friendly ping for feedback or alternative suggestions to fix the problem

Thx,
Hans

> Hi,
>
> The problem occurs in the following scenario where two hosts A and B are in
> use on the lan and connected to a router which is doing masquerade on the
> wan link.
> Host A has a private IP@ (eg 192.168.1.10/24) while host B has a public IP@
> (eg 172.18.16.240/24); the router has a public IP@ on the wan in the same
> subnet as host B (eg 172.18.16.245/24).
> A redirect rule is defined on the router to forward tcp service 8080 to
> host A port 80 and translates into following iptables nat rules :
>
> Chain delegate_prerouting (1 references)
>  pkts bytes target prot opt in out source
> destination
> 268 prerouting_rule  all  --  *  *   0.0.0.0/00.0.0.0/0   
>  /* user chain for prerouting */
> 132 zone_lan_prerouting  all  --  br-lan *   0.0.0.0/0
>0.0.0.0/0
> 0 0 zone_wan_prerouting  all  --  pppoe-wan *   0.0.0.0/0
>  0.0.0.0/0
>
> chain zone_wan_prerouting (1 references)
>  pkts bytes target prot opt in out source
> destination
> 0 0 prerouting_wan_rule  all  --  *  *   0.0.0.0/0
>0.0.0.0/0/* user chain for prerouting */
> 0 0 DNAT   tcp  --  *  *   0.0.0.0/00.0.0.0/0
> tcp spt:8080 /* @redirect[0] */ to:192.168.1.10:80
>
>
> TCP traffic on pppoe-wan interface with as destination port 172.18.16.245
> will be redirected to 192.168.1.10 as expected but if host B runs a similar
> tcp service on port 8080 it will be unreachable as traffic directed to
> 172.18.16.240 will also be re-directed to 192.168.1.10.
> The patch tries to fix this issue by using the wan IP address in the
> zone_wan_prerouting lookup; in this case traffic destined for 172.18.16.240
> will not be redirected.
> Chain delegate_prerouting (1 references)
>  pkts bytes target prot opt in out source
> destination
> 187 prerouting_rule  all  --  *  *   0.0.0.0/00.0.0.0/0   
>  /* user chain for prerouting */
> 187 zone_lan_prerouting  all  --  br-lan *   0.0.0.0/0
>0.0.0.0/0
> 0 0 zone_wan_prerouting  all  --  pppoe-wan *   0.0.0.0/0
>  172.18.16.245
>
> Chain zone_wan_prerouting (1 references)
>  pkts bytes target prot opt in out source
> destination
> 0 0 prerouting_wan_rule  all  --  *  *   0.0.0.0/0
>0.0.0.0/0/* user chain for prerouting */
> 0 0 DNAT   tcp  --  *  *   0.0.0.0/00.0.0.0/0
> tcp spt:8080 /* @redirect[0] */ to:192.168.1.10:80
>
> Output of  fw3 print diff before/after the patch
>
> < iptables -t nat -D delegate_prerouting -i pppoe-wan -j zone_wan_prerouting
> < iptables -t nat -A delegate_prerouting -i pppoe-wan -j zone_wan_prerouting
> ---
> >* iptables -t nat -D delegate_prerouting -i pppoe-wan -d
> *172.18.16.245/255.255.255.255 -j zone_wan_prerouting
> >* iptables -t nat -A delegate_prerouting -i pppoe-wan -d
> *172.18.16.245/255.255.255.255 -j zone_wan_prerouting
>
> Bye,
> Hans
>
> On Thu, Oct 1, 2015 at 10:05 PM, Jo-Philipp Wich  > wrote:
>
> >* Hi,
> *>>* wouldn't this break port forwards to hosts not being within the range of
> *>* the on-link lan subnet?
> *>>* I also read the patch description three times and still am not sure what
> *>* that change attempts to achive.
> *>>* Can you further explain the problem please and provide a before/after
> *>* "fw3 print" diff so that I better understand your proposed solution?
> *
>
> >* ~ Jow
> *>>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

2015-11-26 Thread Jo-Philipp Wich

Hi,

did you consider to simply add "src_dport" to the redirect rule?

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

2015-11-26 Thread Jo-Philipp Wich

> did you consider to simply add "src_dport" to the redirect rule?
Or rather, "src_dip" in this case as it is about redirecting the proper
wan ip.

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] fstools: factory reset on power failure during startup

2015-11-26 Thread Felix Fietkau

On 2015-11-26 09:24, Florian Eckert wrote:
> Hi,
> 
> I am using openwrt CC and an ubifs filesystem on top of ubi.
> If I plug off the power during startup, some times my configuration
> get lost and i am back to factory reset.
> 
> In the package fstools there is the bin "mount_root" it is called
> twice during startup.
> 1. S10boot at line 10
> 2. S95done at line 6
> 
> this calles edit the ./fs_state link
> 
> S10boot/S95done:
> ---
> Because ubifs is doing filesystem handling in a background process
> "ubi_bgt0d", could it be possible,
> that (see code) ./.fs_state is not rewritten written anymore?
> So that at next boot the system thinks he is in upgrade mode?
> 
> If I add a sleep(10) between unlink and symlink function call i can
> reproduce the failure if i unplug the power.
> I think the first think what should be done is to call
> "snprintf(valstr, sizeof(valstr), "%d", state);" before "unlink(path).
> 
> Or this this a deeper Problem?
I think you're right that there's a race here. When I wrote this code,
I never actually intended for the file to get re-written after the
first boot, it seems that I simply forgot to add the necessary check
for it.
Please test if this fstools patch fixes the problem:
---
--- a/libfstools/overlay.c
+++ b/libfstools/overlay.c
@@ -311,6 +311,9 @@ int fs_state_set(const char *dir, enum fs_state state)
char valstr[16];
char *path;
 
+   if (fs_state_get(dir) == state)
+   return 0;
+
path = alloca(strlen(dir) + 1 + sizeof("/.fs_state"));
sprintf(path, "%s/.fs_state", dir);
unlink(path);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath9k-htc init

2015-11-26 Thread Alexey Brodkin

Hi Jonas,

On Mon, 2015-11-23 at 16:48 +0100, Jonas Gorski wrote:
> On Mon, Nov 23, 2015 at 9:21 AM, Alexey Brodkin
>  wrote:
> > Hi Felix, Jonas,
> > 
> > While playing with my AXS101 board and USB WI-Fi dongles I bumped in
> > a couple of issues. Fortunately I found at least one dongle that
> > works quite nice. That's TP-Link TL-WN721N (or its WN722N sibling)
> > which is based on Atheros AR9271 chip even though it did require
> > one unexpected tweak.
> > 
> > For starters I just selected "kmod-ath9k-htc" in menuconfig and
> > on boot saw USB device recognized, its firmware was loaded,
> > "wifi detect" recognized it as well, see log below.
> > 
> > But then "wlan0" interface was not created on "wifi" command.
> > 
> > After some googling I somehow came to resolution that "hostapd"
> > package installation fixes this problem. And indeed once I got
> > image rebuilt with "CONFIG_PACKAGE_hostapd=y" all worked as expected
> > and I was able to use my board as a Wi-Fi access point.
> > 
> > So the question is if this is expected (requirement for "hostapd")
> > [for "ath9k_htc"]?
> 
> Yes, hostapd[-mini] (or wpad[-mini]) is required for AP mode, and
> wpasupplicant or wpad for encrypted STA mode.

Ooops I didn't realize that right away, indeed I'm trying to setup WiFi
AP and hostAPD (which is really just "host AP Daemon") or alike is a must.

The next question would be which option should I use then?
 1) good olde HostAPD
 2) its -mini sibling
 3) wpad
 4) its -mini sibling

> > Another minor issue is that USB dongle gets recognized a bit late
> > so that automatic "wifi detect" gets already executed and
> > "/etc/config/wireless" isn't created. That requires manual execution of
> > "wifi detect > /etc/config/wireless". Essentially extending delay in
> > "package/base-files/files/etc/init.d/boot" makes a difference:
> > -->8---
> > # allow wifi modules time to settle
> > sleep 15 # instead of 1
> > -->8---
> > but I'm not sure if we want to do that change for all devices.
> > Then if there's a better way to make auto population of
> > "/etc/config/wireless"?
> 
> Likely the firmware is loaded asynchronously, so the _probe function
> returns quickly. Our workaround in OpenWrt  for other drivers is to
> make the _probe function wait for the firmware to have loaded. and
> thus the wifi device registered in the linux kernel. This will ensure
> the wifi subsystem knows about it when wifi detect is called. This
> seems to be missing for ath9k-htc.

May I get a reference to an example of that workaround?

-Alexey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath9k-htc init

2015-11-26 Thread Jonas Gorski

On Thu, Nov 26, 2015 at 2:07 PM, Alexey Brodkin
 wrote:
> Hi Jonas,
>
> On Mon, 2015-11-23 at 16:48 +0100, Jonas Gorski wrote:
>> On Mon, Nov 23, 2015 at 9:21 AM, Alexey Brodkin
>>  wrote:
>> > Hi Felix, Jonas,
>> >
>> > While playing with my AXS101 board and USB WI-Fi dongles I bumped in
>> > a couple of issues. Fortunately I found at least one dongle that
>> > works quite nice. That's TP-Link TL-WN721N (or its WN722N sibling)
>> > which is based on Atheros AR9271 chip even though it did require
>> > one unexpected tweak.
>> >
>> > For starters I just selected "kmod-ath9k-htc" in menuconfig and
>> > on boot saw USB device recognized, its firmware was loaded,
>> > "wifi detect" recognized it as well, see log below.
>> >
>> > But then "wlan0" interface was not created on "wifi" command.
>> >
>> > After some googling I somehow came to resolution that "hostapd"
>> > package installation fixes this problem. And indeed once I got
>> > image rebuilt with "CONFIG_PACKAGE_hostapd=y" all worked as expected
>> > and I was able to use my board as a Wi-Fi access point.
>> >
>> > So the question is if this is expected (requirement for "hostapd")
>> > [for "ath9k_htc"]?
>>
>> Yes, hostapd[-mini] (or wpad[-mini]) is required for AP mode, and
>> wpasupplicant or wpad for encrypted STA mode.
>
> Ooops I didn't realize that right away, indeed I'm trying to setup WiFi
> AP and hostAPD (which is really just "host AP Daemon") or alike is a must.
>
> The next question would be which option should I use then?
>  1) good olde HostAPD
>  2) its -mini sibling
>  3) wpad
>  4) its -mini sibling

OpenWrt default is wpad-mini for wifi capable devices (which is just a
unified binary of hostapd and wpasupplicant to prevent code
duplication and save space). The non-mini versions add support for
enterprisey stuff like radius athentication, which aren't needed for
most home setups.


>> > Another minor issue is that USB dongle gets recognized a bit late
>> > so that automatic "wifi detect" gets already executed and
>> > "/etc/config/wireless" isn't created. That requires manual execution of
>> > "wifi detect > /etc/config/wireless". Essentially extending delay in
>> > "package/base-files/files/etc/init.d/boot" makes a difference:
>> > -->8---
>> > # allow wifi modules time to settle
>> > sleep 15 # instead of 1
>> > -->8---
>> > but I'm not sure if we want to do that change for all devices.
>> > Then if there's a better way to make auto population of
>> > "/etc/config/wireless"?
>>
>> Likely the firmware is loaded asynchronously, so the _probe function
>> returns quickly. Our workaround in OpenWrt  for other drivers is to
>> make the _probe function wait for the firmware to have loaded. and
>> thus the wifi device registered in the linux kernel. This will ensure
>> the wifi subsystem knows about it when wifi detect is called. This
>> seems to be missing for ath9k-htc.
>
> May I get a reference to an example of that workaround?

see

package/kernel/mac80211/patches/861-brcmfmac-register-wiphy-s-during-module_init.patch
package/kernel/mac80211/patches/921-ath10k_init_devices_synchronously.patch
package/kernel/mac80211/patches/940-mwl8k_init_devices_synchronously.patch


Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

2015-11-26 Thread Hans Dedecker

Thx for the feedback; will check if it fixes the issue

Hans

On Thu, Nov 26, 2015 at 1:56 PM, Jo-Philipp Wich  wrote:

> > did you consider to simply add "src_dport" to the redirect rule?
> Or rather, "src_dip" in this case as it is about redirecting the proper
> wan ip.
>
> ~ Jow
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] rtl8xxxu: Add new driver for Realtek WiFi USB devices

2015-11-26 Thread W. Michael Petullo

> This new driver supports RTL8723AU, RTL8188CU, RTL8188RU, RTL8191CU, and
> RTL8192CU and is taken from:
> https://git.kernel.org/cgit/linux/kernel/git/jes/linux.git/log/?h=rtl8723au-mac80211

Has there been any progress getting this merged?

-- 
Mike

:wq
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] rtl8xxxu: Add new driver for Realtek WiFi USB devices

2015-11-26 Thread Bruno Randolf

On 11/26/2015 04:04 PM, W. Michael Petullo wrote:
>> This new driver supports RTL8723AU, RTL8188CU, RTL8188RU, RTL8191CU, and
>> RTL8192CU and is taken from:
>> https://git.kernel.org/cgit/linux/kernel/git/jes/linux.git/log/?h=rtl8723au-mac80211
> 
> Has there been any progress getting this merged?

Yes, AFAIK rtl8xxxu has been merged into the next 4.4 kernel.

No idea if OpenWRT plans to update mac80211/backports to a newer version
any time soon, but that would be the most straightforward way to get
this driver into OpenWRT.

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] watchping

2015-11-26 Thread Bruno Randolf

Hi All,

Just FYI, finally I have been able to "liberate" my attempt at it into
GPL code and the 'pingcheck' recently got merged into OpenWRT packages:
https://github.com/br101/pingcheck

Greetings,
bruno


On 07/06/2015 07:54 PM, Bruno Randolf wrote:
> Hi Juliusz and all,
> 
> Exporting a route to a routing protocol was just one example of what
> could be done based on the fact that internet connectivity is available
> on an interface. There are other uses one could imagine:
>  - Activate a backup interface, say a 3G connection
>  - Announce a default GW or not (routing proto or DHCP).
>  - Check for firmware upgrades on a public server
>  - Start or reconfigure a service
> 
> Second, a default route is not enough: what counts is wether inernet
> connectivity is available thru that route. Sometimes a router announces
> a default route but is not connected itself, or problems exist
> "upstream". In that sense it's probably like your "babel-pinger" but
> more generic.
> 
> The mwan3 package seems do do a similar thing in a script. Do you think
> it could profit from a C-based ubus service? Would it make sense?
> 
> bruno
> 
> 
> 
> On 07/03/2015 09:19 PM, Juliusz Chroboczek wrote:
>> Hi Bruno,
>>
>>> Sometimes it's necessary to re-configure an OpenWRT system based on the
>>> fact wether Internet connectivity is available on a certain interface.
>> [...]
>>> One example where this is useful is: When Internet is available, we
>>> configure BATMAN to act as a gateway 'server', if not as a gateway
>>> 'client'.
>>
>> I think that a solution that relies on distribution scripts is inherently
>> brittle.  The routing daemon should be able to detect the current
>> configuration, in a distribution-independent manner, and automatically
>> adapt to the current situation.  This is what happens with babeld -- it is
>> able to automatically redistribute a kernel route (typically the default
>> route, but not necessarily) into the routing protocol.
>>
>> I know of three ways of automatically obtaining a default route, in
>> descending order of preference:
>>
>>   - if the other end of the Internet connection speaks RIP, RIPng or OSPF,
>> we run Quagga on the gateway and redistribute into Babel;
>>
>>   - if DHCPv4 is reliable (it usually is), then we simply redistribute the
>> DHCP-provided route into the routing protocol;
>>
>>   - if DHCPv4 is unreliable, we use the "babel-pinger" utility which
>> pings a remote host and installs a route depending on its availability.
>>
>> Additionally, there is some very promising but still experimental work to
>> provide a fully general and highly integrated solution in the "hnetd-full"
>> package.
>>
>> -- Juliusz
>> ___
>> 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] Add support for Huawei WS880

2015-11-26 Thread Prototik

---
 target/linux/bcm53xx/image/Makefile|  14 +++
 .../910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch | 115 +
 .../910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch | 115 +
 3 files changed, 244 insertions(+)
 create mode 100644 
target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
 create mode 100644 
target/linux/bcm53xx/patches-4.3/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index c9987dd..2b46988 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -133,6 +133,19 @@ define Device/smartrg-sr400ac
   IMAGE/trx := trx-serial
 endef
 
+define Device/huawei
+  IMAGES := trx
+  IMAGE/trx := trx-nand | asus-trx
+endef
+
+define HuaweiDevice
+  define Device/huawei-$(1)
+   $$(Device/huawei)
+   PRODUCTID := $(2)
+  endef
+  TARGET_DEVICES += huawei-$(1)
+endef
+
 TARGET_DEVICES += \
buffalo-wzr-1750dhp buffalo-wzr-600dhp2 buffalo-wzr-900dhp \
buffalo-wxr-1900dhp \
@@ -145,5 +158,6 @@ $(eval $(call AsusDevice,rt-ac87u,RT-AC87U))
 $(eval $(call AsusDevice,rt-n18u,RT-N18U))
 $(eval $(call LinksysDevice,ea6300-v1))
 $(eval $(call NetgearDevice,r7000,U12H270T00_NETGEAR))
+$(eval $(call HuaweiDevice,ws880,WS880))
 
 $(eval $(call BuildImage))
diff --git 
a/target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
 
b/target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
new file mode 100644
index 000..1a73e64
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
@@ -0,0 +1,115 @@
+From: Sergey Shatunov 
+Subject: [PATCH] ARM: BCM5301X: Add DT for Huawei WS880
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Sergey Shatunov 
+---
+--- a/arch/arm/boot/dts/Makefile
 b/arch/arm/boot/dts/Makefile
+@@ -59,6 +59,7 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
+   bcm4708-asus-rt-ac56u.dtb \
+   bcm4708-asus-rt-ac68u.dtb \
+   bcm4708-buffalo-wzr-1750dhp.dtb \
++  bcm4708-huawei-ws880.dtb \
+   bcm4708-linksys-ea6300-v1.dtb \
+   bcm4708-luxul-xwc-1000.dtb \
+   bcm4708-netgear-r6250.dtb \
+--- /dev/null
 b/arch/arm/boot/dts/bcm4708-huawei-ws880.dts
+@@ -0,0 +1,94 @@
++/*
++ * Broadcom BCM470X / BCM5301X ARM platform code.
++ * DTS for Huawei WS880
++ *
++ * Copyright (C) 2015 Sergey Shatunov 
++ *
++ * Licensed under the GNU/GPL. See COPYING for details.
++ */
++
++/dts-v1/;
++
++#include "bcm4708.dtsi"
++#include "bcm5301x-nand-cs0-bch8.dtsi"
++
++/ {
++  compatible = "huawei,ws880", "brcm,bcm4708";
++  model = "Huawei WS880 (BCM4708)";
++
++  chosen {
++  bootargs = "console=ttyS0,115200";
++  };
++
++  memory {
++  reg = <0x 0x0800>;
++  };
++
++  leds {
++  compatible = "gpio-leds";
++
++  wlan {
++  label = "bcm53xx:white:wlan";
++  gpios = < 0 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++
++  lan {
++  label = "bcm53xx:white:lan";
++  gpios = < 1 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++
++  wps {
++  label = "bcm53xx:white:wps";
++  gpios = < 6 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++
++  internet {
++  label = "bcm53xx:white:internet";
++  gpios = < 12 GPIO_ACTIVE_HIGH>;
++  linux,default-trigger = "default-on";
++  };
++
++  usb {
++  label = "bcm53xx:white:usb";
++  gpios = < 14 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++  };
++
++  gpio-keys {
++  compatible = "gpio-keys";
++  #address-cells = <1>;
++  #size-cells = <0>;
++
++  restart {
++  label = "Reset";
++  linux,code = ;
++  gpios = < 2 GPIO_ACTIVE_LOW>;
++  };
++
++  wps {
++  label = "WPS";
++  linux,code = ;
++  gpios = < 3 GPIO_ACTIVE_LOW>;
++  };
++
++  power {
++  label = "Power";
++  linux,code = ;
++  gpios = < 15 GPIO_ACTIVE_LOW>;
++  };
++  };
++  
++  nand@18028000 {
++  nandcs@0 {
++  nand-ecc-strength = <4>;
++  };
++  };
++};
++
++ {
++

[OpenWrt-Devel] [PATCH 2/2] CC: ar71xx: backport support for TP-LINK TL-WR841N/ND v10

2015-11-26 Thread Matteo Valentini

The TL-WR841N/ND v10 is mostly identical to the v9. Apart from some minor
changes, it contains a newer revision of the QCA9533 SoC and the CPU clock
is significantly higher.

Backport of r47263

Signed-off-by: Matteo Valentini 
---
 target/linux/ar71xx/image/Makefile | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index 95a7149..9c2c608 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -569,6 +569,13 @@ define Device/tl-wr841n-v9
 endif
 endef
 
+define Device/tl-wr841n-v10
+$(Device/tplink-4mlzma)
+BOARDNAME := TL-WR841N-v9
+DEVICE_PROFILE := TLWR841
+TPLINK_HWID := 0x08410010
+endef
+
 define Device/tl-wr842n-v2
 $(Device/tplink-8mlzma)
 BOARDNAME := TL-WR842N-v2
@@ -589,7 +596,7 @@ define Device/tl-wr847n-v8
 DEVICE_PROFILE := TLWR841
 TPLINK_HWID := 0x08470008
 endef
-TARGET_DEVICES += tl-wr841n-v8 tl-wr841n-v9 tl-wr842n-v2 tl-wr843nd-v1 
tl-wr847n-v8
+TARGET_DEVICES += tl-wr841n-v8 tl-wr841n-v9 tl-wr841n-v10 tl-wr842n-v2 
tl-wr843nd-v1 tl-wr847n-v8
 
 define Device/tl-wr941nd-v5
 $(Device/tplink-4mlzma)
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] CC: ar71xx: fix ath79_soc_rev value for QCA9531 ver. 2

2015-11-26 Thread Matteo Valentini

ath9k expects to get revision id 2 for the QCA9531 ver. 2 rev. 0. This
fixes the very low TX power on some devices like the TP-LINK
TL-WR841ND v10

As ath79_soc_rev is only used to get the revision number to ath9k on the
QCA9533, just set it to the expected value on the ver. 2.

Backport of r47262

Signed-off-by: Matteo Valentini 
---
 .../707-MIPS-ath79-add-support-for-QCA953x-SoC.patch  | 11 ---
 .../735-MIPS-ath79-add-support-for-QCA956x-SoC.patch  |  7 ---
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git 
a/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
 
b/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
index 5041619..f3b4446 100644
--- 
a/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
+++ 
b/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
@@ -292,12 +292,13 @@ meaning of the bits CPUCLK_FROM_CPUPLL and 
DDRCLK_FROM_DDRPLL is reversed.
  
id = ath79_reset_rr(AR71XX_RESET_REG_REV_ID);
major = id & REV_ID_MAJOR_MASK;
-@@ -151,6 +152,16 @@ static void __init ath79_detect_sys_type
+@@ -151,6 +152,17 @@ static void __init ath79_detect_sys_type
rev = id & AR934X_REV_ID_REVISION_MASK;
break;
  
 +  case REV_ID_MAJOR_QCA9533_V2:
 +  ver = 2;
++  ath79_soc_rev = 2;
 +  /* drop through */
 +
 +  case REV_ID_MAJOR_QCA9533:
@@ -309,9 +310,13 @@ meaning of the bits CPUCLK_FROM_CPUPLL and 
DDRCLK_FROM_DDRPLL is reversed.
case REV_ID_MAJOR_QCA9556:
ath79_soc = ATH79_SOC_QCA9556;
chip = "9556";
-@@ -169,9 +180,9 @@ static void __init ath79_detect_sys_type
+@@ -167,11 +179,12 @@ static void __init ath79_detect_sys_type
+   panic("ath79: unknown SoC, id:0x%08x", id);
+   }
  
-   ath79_soc_rev = rev;
+-  ath79_soc_rev = rev;
++  if (ver == 1)
++  ath79_soc_rev = rev;
  
 -  if (soc_is_qca955x())
 -  sprintf(ath79_sys_type, "Qualcomm Atheros QCA%s rev %u",
diff --git 
a/target/linux/ar71xx/patches-3.18/735-MIPS-ath79-add-support-for-QCA956x-SoC.patch
 
b/target/linux/ar71xx/patches-3.18/735-MIPS-ath79-add-support-for-QCA956x-SoC.patch
index 491a7aa..ab2bc38 100644
--- 
a/target/linux/ar71xx/patches-3.18/735-MIPS-ath79-add-support-for-QCA956x-SoC.patch
+++ 
b/target/linux/ar71xx/patches-3.18/735-MIPS-ath79-add-support-for-QCA956x-SoC.patch
@@ -519,7 +519,7 @@
return -ENODEV;
 --- a/arch/mips/ath79/setup.c
 +++ b/arch/mips/ath79/setup.c
-@@ -175,15 +175,30 @@ static void __init ath79_detect_sys_type
+@@ -176,6 +176,18 @@ static void __init ath79_detect_sys_type
rev = id & QCA955X_REV_ID_REVISION_MASK;
break;
  
@@ -538,8 +538,9 @@
default:
panic("ath79: unknown SoC, id:0x%08x", id);
}
- 
-   ath79_soc_rev = rev;
+@@ -183,9 +195,12 @@ static void __init ath79_detect_sys_type
+   if (ver == 1)
+   ath79_soc_rev = rev;
  
 -  if (soc_is_qca953x() || soc_is_qca955x())
 +  if (soc_is_qca953x() || soc_is_qca955x() || soc_is_qca9561())
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] bcm53xx: add support for Huawei WS880

2015-11-26 Thread Prototik

Signed-off-by: Prototik 
---
 target/linux/bcm53xx/image/Makefile|  14 +++
 .../910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch | 115 +
 .../910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch | 115 +
 3 files changed, 244 insertions(+)
 create mode 100644 
target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
 create mode 100644 
target/linux/bcm53xx/patches-4.3/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index c9987dd..2b46988 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -133,6 +133,19 @@ define Device/smartrg-sr400ac
   IMAGE/trx := trx-serial
 endef
 
+define Device/huawei
+  IMAGES := trx
+  IMAGE/trx := trx-nand | asus-trx
+endef
+
+define HuaweiDevice
+  define Device/huawei-$(1)
+   $$(Device/huawei)
+   PRODUCTID := $(2)
+  endef
+  TARGET_DEVICES += huawei-$(1)
+endef
+
 TARGET_DEVICES += \
buffalo-wzr-1750dhp buffalo-wzr-600dhp2 buffalo-wzr-900dhp \
buffalo-wxr-1900dhp \
@@ -145,5 +158,6 @@ $(eval $(call AsusDevice,rt-ac87u,RT-AC87U))
 $(eval $(call AsusDevice,rt-n18u,RT-N18U))
 $(eval $(call LinksysDevice,ea6300-v1))
 $(eval $(call NetgearDevice,r7000,U12H270T00_NETGEAR))
+$(eval $(call HuaweiDevice,ws880,WS880))
 
 $(eval $(call BuildImage))
diff --git 
a/target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
 
b/target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
new file mode 100644
index 000..1a73e64
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-4.1/910-ARM-BCM5301X-Add-DT-for-Huawei-WS880.patch
@@ -0,0 +1,115 @@
+From: Sergey Shatunov 
+Subject: [PATCH] ARM: BCM5301X: Add DT for Huawei WS880
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Sergey Shatunov 
+---
+--- a/arch/arm/boot/dts/Makefile
 b/arch/arm/boot/dts/Makefile
+@@ -59,6 +59,7 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
+   bcm4708-asus-rt-ac56u.dtb \
+   bcm4708-asus-rt-ac68u.dtb \
+   bcm4708-buffalo-wzr-1750dhp.dtb \
++  bcm4708-huawei-ws880.dtb \
+   bcm4708-linksys-ea6300-v1.dtb \
+   bcm4708-luxul-xwc-1000.dtb \
+   bcm4708-netgear-r6250.dtb \
+--- /dev/null
 b/arch/arm/boot/dts/bcm4708-huawei-ws880.dts
+@@ -0,0 +1,94 @@
++/*
++ * Broadcom BCM470X / BCM5301X ARM platform code.
++ * DTS for Huawei WS880
++ *
++ * Copyright (C) 2015 Sergey Shatunov 
++ *
++ * Licensed under the GNU/GPL. See COPYING for details.
++ */
++
++/dts-v1/;
++
++#include "bcm4708.dtsi"
++#include "bcm5301x-nand-cs0-bch8.dtsi"
++
++/ {
++  compatible = "huawei,ws880", "brcm,bcm4708";
++  model = "Huawei WS880 (BCM4708)";
++
++  chosen {
++  bootargs = "console=ttyS0,115200";
++  };
++
++  memory {
++  reg = <0x 0x0800>;
++  };
++
++  leds {
++  compatible = "gpio-leds";
++
++  wlan {
++  label = "bcm53xx:white:wlan";
++  gpios = < 0 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++
++  lan {
++  label = "bcm53xx:white:lan";
++  gpios = < 1 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++
++  wps {
++  label = "bcm53xx:white:wps";
++  gpios = < 6 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++
++  internet {
++  label = "bcm53xx:white:internet";
++  gpios = < 12 GPIO_ACTIVE_HIGH>;
++  linux,default-trigger = "default-on";
++  };
++
++  usb {
++  label = "bcm53xx:white:usb";
++  gpios = < 14 GPIO_ACTIVE_LOW>;
++  linux,default-trigger = "default-on";
++  };
++  };
++
++  gpio-keys {
++  compatible = "gpio-keys";
++  #address-cells = <1>;
++  #size-cells = <0>;
++
++  restart {
++  label = "Reset";
++  linux,code = ;
++  gpios = < 2 GPIO_ACTIVE_LOW>;
++  };
++
++  wps {
++  label = "WPS";
++  linux,code = ;
++  gpios = < 3 GPIO_ACTIVE_LOW>;
++  };
++
++  power {
++  label = "Power";
++  linux,code = ;
++  gpios = < 15 GPIO_ACTIVE_LOW>;
++  };
++  };
++  
++  nand@18028000 {
++  nandcs@0 {
++  nand-ecc-strength = <4>;
++

Re: [OpenWrt-Devel] [PATCH] oxnas: fix the incorrect board names

Re: [OpenWrt-Devel] [PATCH] oxnas: set irq of usb to cpu1

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[OpenWrt-Devel] fstools: factory reset on power failure during startup

Re: [OpenWrt-Devel] fstools: factory reset on power failure during startup

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

Re: [OpenWrt-Devel] fstools: factory reset on power failure during startup

Re: [OpenWrt-Devel] ath9k-htc init

Re: [OpenWrt-Devel] ath9k-htc init

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

Re: [OpenWrt-Devel] [PATCH] rtl8xxxu: Add new driver for Realtek WiFi USB devices

Re: [OpenWrt-Devel] [PATCH] rtl8xxxu: Add new driver for Realtek WiFi USB devices

Re: [OpenWrt-Devel] watchping

[OpenWrt-Devel] [PATCH] Add support for Huawei WS880

[OpenWrt-Devel] [PATCH 2/2] CC: ar71xx: backport support for TP-LINK TL-WR841N/ND v10

[OpenWrt-Devel] [PATCH 1/2] CC: ar71xx: fix ath79_soc_rev value for QCA9531 ver. 2

[OpenWrt-Devel] [PATCH v2] bcm53xx: add support for Huawei WS880

19 matches

Site Navigation

Mail list logo

Footer information