Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

On Thu, 10 Sep 2015, John kerry wrote: Yes after reset we are to able to reconnect, I understand using wired connection we can configure but we need to configure using wireless only. Is there anyway that we can avoid the Wi-Fi reset? No, if you tell it to reconfigure wifi and apply the

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

Where its applying the settings, except resetting the radio(s) we can do everything . I Know it involves the resetting but we can comment that resetting part. Could please tell where this part of code exist On Thu, Sep 10, 2015 at 3:12 PM, David Lang wrote: > On Thu, 10 Sep 2015,

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

(Resend of a previous patch affected by gmail's editor line wrapping) This is a git patch for the firewall3 git repo at git://nbd.name/firewall3.git. Basically it prevents zone_wan_prerouting rules to affect traffic towards IP addresses that are not used for masquerading LAN private IP space

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

Hi, i dont want to ruin the fun but this is not devel chat, but user level support. please move it to the normal mailing list or the forum. this ML is for openwrt developemnt related issues John On 10/09/2015 09:50, John kerry wrote: > Where its applying the settings, except resetting

Re: [OpenWrt-Devel] Question about run more than once ubus_invoke_async in the sametime

Hi, Following this thread: https://lists.openwrt.org/pipermail/openwrt-devel/2015-April/032335.html I know how to use ubus with threading by call ubus_invoke_async() instead ubus_invoke(). In ubus example: static struct ubus_request req; ubus_invoke_async(ctx, id, "hello", b.head, );

Re: [OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

Hi, On Thu, Sep 10, 2015 at 3:00 PM, Dmitry Ivanov wrote: > Bridge hairpin mode must be off by default when multicast_to_unicast is > off. Enabling this mode leads to broadcast frames such as ARP and DHCP > being retransmitted back to AP in WDS configurations. > >

Re: [OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

On 2015-09-10 15:00, Dmitry Ivanov wrote: > Bridge hairpin mode must be off by default when multicast_to_unicast is > off. Enabling this mode leads to broadcast frames such as ARP and DHCP > being retransmitted back to AP in WDS configurations. > > Signed-off-by: Dmitry Ivanov

Re: [OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

Hi Dmitry, On Thu, Sep 10, 2015 at 04:00:39PM +0300, Dmitry Ivanov wrote: > [...] Enabling this mode leads to broadcast frames such as ARP and DHCP > being retransmitted back to AP in WDS configurations. Could you eloborate a little more on this? For a normal bridge-on-AP setting this should be

[OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

Bridge hairpin mode must be off by default when multicast_to_unicast is off. Enabling this mode leads to broadcast frames such as ARP and DHCP being retransmitted back to AP in WDS configurations. Signed-off-by: Dmitry Ivanov --- system-linux.c | 7 +++ 1 file changed, 3

[OpenWrt-Devel] [PATCH][netifd] Do not enable multicast_to_unicast by default

Do not enable multicast_to_unicast by default. Duplicate broadcast and multicast frames may cause problems in WDS setup. Wireless clients cannot obtain IP address etc. Signed-off-by: Dmitry Ivanov --- scripts/netifd-wireless.sh | 2 +- system-linux.c | 7 +++ 2

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix ar724x clock calculation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Weijie Gao wrote: > Signed-off-by: Weijie Gao > > According to the AR7242 datasheet section 2.8, AR724X CPUs use a 40MHz > input clock as the REF_CLK instead of 5MHz. > > The correct CPU PLL calculation

Re: [OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

Felix, this patch resolves duplicate packet issue in WDS setup. Thanks! On Thu, 10 Sep 2015 15:37:35 +0200 Felix Fietkau wrote: > On 2015-09-10 15:00, Dmitry Ivanov wrote: > > Bridge hairpin mode must be off by default when multicast_to_unicast is > > off. Enabling this mode

Re: [OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

Hi Linus! In WDS mode, we have problems with ARP, DHCP and some other protocols utilizing broadcast frames. So I think it's better to disable multicast_to_unicast by default in both netifd and script. On Thu, Sep 10, 2015 at 4:39 PM, Linus Lüssing wrote: > Hi Dmitry, >

Re: [OpenWrt-Devel] x86-64: /proc is not being mounted

It seems that preinit is not running after the first boot. I don't know why... On 11 September 2015 at 00:53, Carlos Ferreira wrote: > I have a custom build for x86_64 where CONFIG_PROC_FS is active (y) at the > kernel configuration. /etc/fstabs has nothing and is

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

IMHO, I would avoid "normal releases" rule as, at some time in future, OpenWRT might hopefully hit T..T.. name. Trunk, unstable or anything like this might be better. Regards, Em qui, 10 de set de 2015 às 17:58, escreveu: > How about Trusty Trunk.. no cocktail though.. so

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

On 11/09/2015 07:18, Rafał Miłecki wrote: > On 9 September 2015 at 17:24, Tobias Welz wrote: >> BTW: Why does the trunk has to be "renamed". The trunk is always recent, so >> it could also have a persistent name like "Bleeding Edge" (BTW: is this a >> cocktail?) and it would be

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

On 9 September 2015 at 17:24, Tobias Welz wrote: > BTW: Why does the trunk has to be "renamed". The trunk is always recent, so > it could also have a persistent name like "Bleeding Edge" (BTW: is this a > cocktail?) and it would be always clear, that you are on the trunk. Similar

[OpenWrt-Devel] [PATCH] [package] firewall: Remove src_port from firewall.config to receive dhcpv6 replies

Seems like my second try was again whitespace broken. Sorry for the noise. Remove src_port from firewall.config to receive dhcpv6 replies. Fixes #20295. Signed-off-by: Anselm Eberhardt --- package/network/config/firewall/files/firewall.config | 1 - 1 file

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

Just following up with the T... T... idea - I found some T T Cocktails: Tahitian Tea Tahitian Treat Tanqueray Tonic Tanzanian Tonic Am 09.09.2015 um 19:57 schrieb Hannu Nyman: Tobias Welz wrote at Wed Sep 9 17:24:14 CEST 2015: > So I absolutely vote for some clear consistent naming of the

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

How about Trusty Trunk.. no cocktail though.. so far.. ede On 10.09.2015 22:08, Tobias Welz wrote: > Just following up with the T... T... idea - I found some T T Cocktails: > > Tahitian Tea > Tahitian Treat > Tanqueray Tonic > Tanzanian Tonic > > > > Am 09.09.2015 um 19:57 schrieb Hannu