date:20150910

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

2015-09-10 Thread David Lang


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 settings, it needs to do 
what you told it to do, and that involves resetting the radio(s) to make sure 
they now do everything you told it to do.


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

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

2015-09-10 Thread John kerry

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, 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 settings, it needs to
> do what you told it to do, and that involves resetting the radio(s) to make
> sure they now do everything you told it to do.
>
> David Lang
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

2015-09-10 Thread John Crispin

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 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, 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 settings, it
> needs to do what you told it to do, and that involves resetting the
> radio(s) to make sure they now do everything you told it to do.
> 
> David Lang
> 
> 
> 
> 
> ___
> 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] [package] firewall: Redirect incoming WAN traffic only when destination IP address matches the IP address used for masquerading

2015-09-10 Thread Alin Nastac


(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 and it does that by setting destination 
IP address of the
delegate_prerouting rules for zone with masq enabled to whatever address(es) 
that particular network
interface has.

The typical scenario this patch fixes involves 2 LAN network prefixes:
  - the usual 192.168.1.0/24 which is masqueraded by the public IP address 
configured on the WAN interface
  - a public IP network prefix for those LAN devices that are supposed to be 
excluded from NAT
Without this patch, port forwarding rules introduced for 192.168.1.x LAN 
devices will also affect traffic
towards the 2nd prefix.

From 56820e2e3e09f68e4f9a74e6aff832fbcf2c5729 Mon Sep 17 00:00:00 2001
From: Alin Nastac
Date: Fri, 4 Sep 2015 13:54:10 +0200
Subject: [PATCH] Redirect incoming WAN traffic only when
 destination IP address matches the IP address configured on the incoming 
interface

---
 zones.c | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/zones.c b/zones.c
index 2ddd7b4..8bd6673 100644
--- a/zones.c
+++ b/zones.c
@@ -383,10 +383,38 @@ print_interface_rule(struct fw3_ipt_handle *handle, 
struct fw3_state *state,
{
if (has(zone->flags, handle->family, FW3_FLAG_DNAT))
{
-   r = fw3_ipt_rule_create(handle, NULL, dev, NULL, sub, 
NULL);
-   fw3_ipt_rule_target(r, "zone_%s_prerouting", 
zone->name);
-   fw3_ipt_rule_extra(r, zone->extra_src);
-   fw3_ipt_rule_replace(r, "delegate_prerouting");
+   struct list_head *addrs;
+   struct fw3_address *addr;
+
+   addrs = zone->masq ? calloc(1, sizeof(*addrs)) : NULL;
+   if (addrs)
+   {
+   /* redirect only the traffic towards a locally 
configured address */
+   INIT_LIST_HEAD(addrs);
+   fw3_ubus_address(addrs, dev->network);
+
+   list_for_each_entry(addr, addrs, list)
+   {
+   if (!fw3_is_family(addr, 
handle->family))
+   continue;
+   /* reset mask to its maximum value */
+   memset(&addr->mask.v6, 0xFF, 
sizeof(addr->mask.v6));
+
+   r = fw3_ipt_rule_create(handle, NULL, 
dev, NULL, sub, addr);
+   fw3_ipt_rule_target(r, 
"zone_%s_prerouting", zone->name);
+   fw3_ipt_rule_extra(r, zone->extra_src);
+   fw3_ipt_rule_replace(r, 
"delegate_prerouting");
+   }
+
+   fw3_free_list(addrs);
+   }
+   else
+   {
+   r = fw3_ipt_rule_create(handle, NULL, dev, 
NULL, sub, NULL);
+   fw3_ipt_rule_target(r, "zone_%s_prerouting", 
zone->name);
+   fw3_ipt_rule_extra(r, zone->extra_src);
+   fw3_ipt_rule_replace(r, "delegate_prerouting");
+   }
}

if (has(zone->flags, handle->family, FW3_FLAG_SNAT))
--
1.7.12.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Tuan Nguyen

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, &req);
req.fd_cb = test_client_fd_cb;
req.complete_cb = test_client_complete_cb;
ubus_complete_request_async(ctx, &req);

We need to create a ubus_request to register callbacks and maybe more data
for this callback.

My question is how to call ubus_invoke_async() many times with one callback
for this function.
When I tried this with the same struct ubus_request and I got lost
callback, then I tried to malloc this struct and It worked well, but I dont
know how to free this struct.

Digging in to source code:
I found this struct will be assign to the main context,
INIT_LIST_HEAD(&req->list);
INIT_LIST_HEAD(&req->pending);
req->ctx = ctx;
req->peer = peer;
req->seq = ++ctx->request_seq;

I tried to do req->ctx= NULL; and free it in callback function but i didn't
work.

How could I do that?

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

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

2015-09-10 Thread Dmitry Ivanov

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 insertions(+), 4 deletions(-)

diff --git a/system-linux.c b/system-linux.c
index 01500a5..6994ace 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -576,12 +576,11 @@ static char *system_get_bridge(const char *name, char 
*buf, int buflen)
 static void
 system_bridge_set_wireless(struct device *bridge, struct device *dev)
 {
-   bool mcast_to_ucast = true;
+   bool mcast_to_ucast = false;
bool hairpin = true;
 
-   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST &&
-   !bridge->settings.multicast_to_unicast)
-   mcast_to_ucast = false;
+   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST)
+   mcast_to_ucast = bridge->settings.multicast_to_unicast;
 
if (!mcast_to_ucast || dev->wireless_isolate)
hairpin = false;
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Jonas Gorski

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.
>
> Signed-off-by: Dmitry Ivanov 

Commit subject/message does not match what the patch does:

> ---
>  system-linux.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/system-linux.c b/system-linux.c
> index 01500a5..6994ace 100644
> --- a/system-linux.c
> +++ b/system-linux.c
> @@ -576,12 +576,11 @@ static char *system_get_bridge(const char *name, char 
> *buf, int buflen)
>  static void
>  system_bridge_set_wireless(struct device *bridge, struct device *dev)
>  {
> -   bool mcast_to_ucast = true;
> +   bool mcast_to_ucast = false;
> bool hairpin = true;
>
> -   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST &&
> -   !bridge->settings.multicast_to_unicast)
> -   mcast_to_ucast = false;
> +   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST)
> +   mcast_to_ucast = bridge->settings.multicast_to_unicast;
>
> if (!mcast_to_ucast || dev->wireless_isolate)
> hairpin = false;

hairpin mode will already be disabled if macst_to_ucast is disabled.

What this patch does is change the default of multicast to unicast to
off. Changing the default of hairpin mode to off is only a side effect
of that.


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

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

2015-09-10 Thread Felix Fietkau

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 
Please try this patch instead: 
---
diff --git a/device.h b/device.h
index b2c0ba9..37814c8 100644
--- a/device.h
+++ b/device.h
@@ -182,6 +182,7 @@ struct device {
bool iface_config;
bool default_config;
bool wireless;
+   bool wireless_ap;
bool wireless_isolate;
 
struct interface *config_iface;
diff --git a/system-linux.c b/system-linux.c
index 01500a5..f51c078 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -576,7 +576,7 @@ static char *system_get_bridge(const char *name, char *buf, 
int buflen)
 static void
 system_bridge_set_wireless(struct device *bridge, struct device *dev)
 {
-   bool mcast_to_ucast = true;
+   bool mcast_to_ucast = dev->wireless_ap;
bool hairpin = true;
 
if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST &&
diff --git a/wireless.c b/wireless.c
index d0d2942..7e8dc93 100644
--- a/wireless.c
+++ b/wireless.c
@@ -36,6 +36,7 @@ enum {
VIF_ATTR_DISABLED,
VIF_ATTR_NETWORK,
VIF_ATTR_ISOLATE,
+   VIF_ATTR_MODE,
__VIF_ATTR_MAX,
 };
 
@@ -43,6 +44,7 @@ static const struct blobmsg_policy vif_policy[__VIF_ATTR_MAX] 
= {
[VIF_ATTR_DISABLED] = { .name = "disabled", .type = BLOBMSG_TYPE_BOOL },
[VIF_ATTR_NETWORK] = { .name = "network", .type = BLOBMSG_TYPE_ARRAY },
[VIF_ATTR_ISOLATE] = { .name = "isolate", .type = BLOBMSG_TYPE_BOOL },
+   [VIF_ATTR_MODE] = { .name = "mode", .type = BLOBMSG_TYPE_STRING },
 };
 
 static const struct uci_blob_param_list vif_param = {
@@ -213,6 +215,7 @@ static void wireless_interface_handle_link(struct 
wireless_interface *vif, bool
if (dev) {
dev->wireless_isolate = vif->isolate;
dev->wireless = true;
+   dev->wireless_ap = vif->ap_mode;
}
}
 
@@ -714,6 +717,10 @@ void wireless_interface_create(struct wireless_device 
*wdev, struct blob_attr *d
if (cur && blobmsg_get_bool(cur))
vif->isolate = blobmsg_get_bool(cur);
 
+   cur = tb[VIF_ATTR_MODE];
+   if (cur && !strcmp(blobmsg_get_string(cur), "ap"))
+   vif->ap_mode = true;
+
vlist_add(&wdev->interfaces, &vif->node, vif->name);
 }
 
diff --git a/wireless.h b/wireless.h
index 476c63e..cb725b2 100644
--- a/wireless.h
+++ b/wireless.h
@@ -78,6 +78,7 @@ struct wireless_interface {
const char *ifname;
struct blob_attr *network;
bool isolate;
+   bool ap_mode;
 };
 
 struct wireless_process {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Linus Lüssing

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 fine together with the
ap-isolation. But I'm not that familiar with WDS, I have to admit.

Do you see duplicate broadcast packets or echoes on the
transmitter? Or what is the issue?

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

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

2015-09-10 Thread Dmitrijs Ivanovs

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,
>
> 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 fine together with the
> ap-isolation. But I'm not that familiar with WDS, I have to admit.
>
> Do you see duplicate broadcast packets or echoes on the
> transmitter? Or what is the issue?
>
> Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Dmitry Ivanov

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 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index 83a8223..774a503 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -256,7 +256,7 @@ _wireless_set_brsnoop_isolation() {
 
[ $isolate -gt 0 -o -z "$network_bridge" ] && return
 
-   [ -z "$multicast_to_unicast" ] && multicast_to_unicast=1
+   [ -z "$multicast_to_unicast" ] && multicast_to_unicast=0
[ $multicast_to_unicast -gt 0 ] && json_add_boolean isolate 1
 }
 
diff --git a/system-linux.c b/system-linux.c
index 01500a5..6994ace 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -576,12 +576,11 @@ static char *system_get_bridge(const char *name, char 
*buf, int buflen)
 static void
 system_bridge_set_wireless(struct device *bridge, struct device *dev)
 {
-   bool mcast_to_ucast = true;
+   bool mcast_to_ucast = false;
bool hairpin = true;
 
-   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST &&
-   !bridge->settings.multicast_to_unicast)
-   mcast_to_ucast = false;
+   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST)
+   mcast_to_ucast = bridge->settings.multicast_to_unicast;
 
if (!mcast_to_ucast || dev->wireless_isolate)
hairpin = false;
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Felix Fietkau

On 2015-09-10 16:16, Dmitry Ivanov wrote:
> 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 
The feature was intended to work automatically and transparently, and
your hack simply disables it instead of attempting to solve the real issue.
I've already posted a patch that should hopefully fix it properly, so
please test that instead of sending more hack patches.

- Felix
___
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 ar724x clock calculation

2015-09-10 Thread Karl Palsson

-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 procedure is as follows:
> CPU_PLL = (DIV * REF_CLK) / REF_DIV / 2.
> 
> This patch is compatible with the current calculation procedure with
> default
> DIV and REF_DIV values.
> 
> Test on both AR7240, AR7241 and AR7242.


So, what was the behaviour before?

Cheers,
Karl P

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJV8ZUHAAoJEBmotQ/U1cr2aAAP/iPniiHKY/hEKqriniqdWdvE
y9e9gs48KcYxBt5wHninUK1Jsz3Gc1qzpsuyfxxWS6yuZvqMeSnR1UBnH9ztbRQM
ZvXKS79GhCEQkdBlZL74RBqVaBGz0lQ59La7b4NRTmPfKV5HQdZpo51EaA/iNOwT
6iy1w2HUEhGIlxG+/2NSz2ppNPeg82iexaxus70NrGtmtmttaUxMJ4hSFZ74ToMF
zsPzn24GFGBrCSZpTQb5kHp+cz+ZO6SvANtCAsFjJBY4Wyo1To8K5/sOzOy/WY2m
tzvOwrFnGWlnmAPATopSN5eWYcPK60HFUkCrtj/bMLfI3b3ses787Z5YBegZRkGe
g15zWuSp/B7rRQFagyYw7UtuCaKZdHlvAvBfOA+nIZP9wMX16v1vy41MHhMoD39z
4ZLjvq3xavdVGMNlFKTn8C/qQEMNS1WDXjI3IhU98+CTlpTirauSE1xccTIEwUWs
okEvhSWGoc8HsgSMuNLI2OdlzQk3QkLGujd1QSB3KNA5Jwwjldnc/wB8gt3/T3W1
U4sGr4omig3hyv0+MHtnlmlzeQH+earq8aykTdqT1odLHLZwoBqFqhQFcuzG1puS
VsL0KhR2X4BeNFz8rDtfjJ6qS/SH8nrUmXil2/peqwXWWwTDAkwVCSu+9OZ8PfjN
ppcYaXyAm55OeDDx8GmC
=vE53
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] how to use ubus_invoke_async parallels with once callback

2015-09-10 Thread Tuan Nguyen

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, &req);
req.fd_cb = test_client_fd_cb;
req.complete_cb = test_client_complete_cb;
ubus_complete_request_async(ctx, &req);

We need to create a ubus_request to register callbacks and maybe more data
for this callback.

My question is how to call ubus_invoke_async() many times with one callback
for this function.
When I tried this with the same struct ubus_request and I got lost
callback, then I tried to malloc this struct and It worked well, but I dont
know how to free this struct.

Digging in to source code:
I found this struct will be assign to the main context,
INIT_LIST_HEAD(&req->list);
INIT_LIST_HEAD(&req->pending);
req->ctx = ctx;
req->peer = peer;
req->seq = ++ctx->request_seq;

I tried to do req->ctx= NULL; and free it in callback function but i didn't
work.

How could I do that?

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

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

2015-09-10 Thread Dmitry Ivanov

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 leads to broadcast frames such as ARP and DHCP
> > being retransmitted back to AP in WDS configurations.
> > 
> > Signed-off-by: Dmitry Ivanov 
> Please try this patch instead: 
> ---
> diff --git a/device.h b/device.h
> index b2c0ba9..37814c8 100644
> --- a/device.h
> +++ b/device.h
> @@ -182,6 +182,7 @@ struct device {
>   bool iface_config;
>   bool default_config;
>   bool wireless;
> + bool wireless_ap;
>   bool wireless_isolate;
>  
>   struct interface *config_iface;
> diff --git a/system-linux.c b/system-linux.c
> index 01500a5..f51c078 100644
> --- a/system-linux.c
> +++ b/system-linux.c
> @@ -576,7 +576,7 @@ static char *system_get_bridge(const char *name, char 
> *buf, int buflen)
>  static void
>  system_bridge_set_wireless(struct device *bridge, struct device *dev)
>  {
> - bool mcast_to_ucast = true;
> + bool mcast_to_ucast = dev->wireless_ap;
>   bool hairpin = true;
>  
>   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST &&
> diff --git a/wireless.c b/wireless.c
> index d0d2942..7e8dc93 100644
> --- a/wireless.c
> +++ b/wireless.c
> @@ -36,6 +36,7 @@ enum {
>   VIF_ATTR_DISABLED,
>   VIF_ATTR_NETWORK,
>   VIF_ATTR_ISOLATE,
> + VIF_ATTR_MODE,
>   __VIF_ATTR_MAX,
>  };
>  
> @@ -43,6 +44,7 @@ static const struct blobmsg_policy 
> vif_policy[__VIF_ATTR_MAX] = {
>   [VIF_ATTR_DISABLED] = { .name = "disabled", .type = BLOBMSG_TYPE_BOOL },
>   [VIF_ATTR_NETWORK] = { .name = "network", .type = BLOBMSG_TYPE_ARRAY },
>   [VIF_ATTR_ISOLATE] = { .name = "isolate", .type = BLOBMSG_TYPE_BOOL },
> + [VIF_ATTR_MODE] = { .name = "mode", .type = BLOBMSG_TYPE_STRING },
>  };
>  
>  static const struct uci_blob_param_list vif_param = {
> @@ -213,6 +215,7 @@ static void wireless_interface_handle_link(struct 
> wireless_interface *vif, bool
>   if (dev) {
>   dev->wireless_isolate = vif->isolate;
>   dev->wireless = true;
> + dev->wireless_ap = vif->ap_mode;
>   }
>   }
>  
> @@ -714,6 +717,10 @@ void wireless_interface_create(struct wireless_device 
> *wdev, struct blob_attr *d
>   if (cur && blobmsg_get_bool(cur))
>   vif->isolate = blobmsg_get_bool(cur);
>  
> + cur = tb[VIF_ATTR_MODE];
> + if (cur && !strcmp(blobmsg_get_string(cur), "ap"))
> + vif->ap_mode = true;
> +
>   vlist_add(&wdev->interfaces, &vif->node, vif->name);
>  }
>  
> diff --git a/wireless.h b/wireless.h
> index 476c63e..cb725b2 100644
> --- a/wireless.h
> +++ b/wireless.h
> @@ -78,6 +78,7 @@ struct wireless_interface {
>   const char *ifname;
>   struct blob_attr *network;
>   bool isolate;
> + bool ap_mode;
>  };
>  
>  struct wireless_process {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] uqmi: Add proper IPv6 support

2015-09-10 Thread Matti Laakso

Use the new --ip-family option to start both IPv4 and IPv6 sessions
by default. Autoconnect can't be used when starting two sessions,
so revert back to using the client IDs and packet data handles for
handling the network connection.

Some modem firmwares do not implement a RA server, therefore by
default use outband IP configuration and static addressing. Some
other firmwares report bogus IP configuration with the WDS get
current settings command. In this case inband configuration with
DHCP/RA can be optionally enabled by setting option dhcp to 1.

Per 3GPP standard a /64 prefix is served to all clients, which is
extended to LAN as specified in RFC 7278.

v2: Restrict the IPv6 gateway route source address
Signed-off-by: Matti Laakso 
---
 package/network/utils/uqmi/Makefile|   4 +-
 .../utils/uqmi/files/lib/netifd/proto/qmi.sh   | 199 +++--
 2 files changed, 145 insertions(+), 58 deletions(-)
 mode change 100755 => 100644 
package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh

diff --git a/package/network/utils/uqmi/Makefile 
b/package/network/utils/uqmi/Makefile
index 8ca7b85..16e7fea 100644
--- a/package/network/utils/uqmi/Makefile
+++ b/package/network/utils/uqmi/Makefile
@@ -1,13 +1,13 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=uqmi
-PKG_VERSION:=2014-12-03
+PKG_VERSION:=2015-08-13
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL:=git://nbd.name/uqmi.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=86bcdb8cca652676a78b2df8b5e3fb27a40c60a4
+PKG_SOURCE_VERSION:=8a97586e9445a60e355dea13aa87885ab3dcb277
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
 PKG_MAINTAINER:=Matti Laakso 
 # PKG_MIRROR_MD5SUM:=
diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
old mode 100755
new mode 100644
index b416da6..8ee7dbd
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -17,28 +17,25 @@ proto_qmi_init_config() {
proto_config_add_string pincode
proto_config_add_string delay
proto_config_add_string modes
+   proto_config_add_boolean ipv6
+   proto_config_add_boolean dhcp
 }
 
-qmi_disconnect() {
-   # disable previous autoconnect state using the global handle
-   # do not reuse previous wds client id to prevent hangs caused by stale 
data
-   uqmi -s -d "$device" \
-   --stop-network 0x \
-   --autoconnect > /dev/null
-}
-
-qmi_wds_release() {
-   [ -n "$cid" ] || return 0
+proto_qmi_setup() {
+   local interface="$1"
 
-   uqmi -s -d "$device" --set-client-id wds,"$cid" --release-client-id wds
-   uci_revert_state network $interface cid
-}
+   local device apn auth username password pincode delay modes ipv6 dhcp
+   local cid_4 pdh_4 cid_6 pdh_6 ipv4
+   local ip subnet gateway dns1 dns2 ip_6 ip_prefix_length gateway_6 
dns1_6 dns2_6
+   json_get_vars device apn auth username password pincode delay modes 
ipv6 dhcp
 
-_proto_qmi_setup() {
-   local interface="$1"
+   ipv4=1
 
-   local device apn auth username password pincode delay modes cid pdh
-   json_get_vars device apn auth username password pincode delay modes
+   if [ "$ipv6" = 0 ]; then
+   ipv6=""
+   else
+   ipv6=1
+   fi
 
[ -n "$ctl_device" ] && device=$ctl_device
 
@@ -86,8 +83,6 @@ _proto_qmi_setup() {
return 1
}
 
-   qmi_disconnect
-
uqmi -s -d "$device" --set-data-format 802.3
uqmi -s -d "$device" --wda-set-data-format 802.3
 
@@ -99,67 +94,159 @@ _proto_qmi_setup() {
[ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes "$modes"
 
echo "Starting network $apn"
-   cid=`uqmi -s -d "$device" --get-client-id wds`
+
+   cid_4=`uqmi -s -d "$device" --get-client-id wds`
[ $? -ne 0 ] && {
echo "Unable to obtain client ID"
proto_notify_error "$interface" NO_CID
return 1
}
 
-   uqmi -s -d "$device" --set-client-id wds,"$cid" \
+   pdh_4=`uqmi -s -d "$device" --set-client-id wds,"$cid_4" \
--start-network "$apn" \
${auth:+--auth-type $auth} \
${username:+--username $username} \
${password:+--password $password} \
-   --autoconnect > /dev/null
-
-   echo "Starting DHCP"
-   proto_init_update "$ifname" 1
-   proto_send_update "$interface"
-
-   json_init
-   json_add_string name "${interface}_4"
-   json_add_string ifname "@$interface"
-   json_add_string proto "dhcp"
-   json_close_object
-   ubus call network add_dynamic "$(json_dump)"
-
-   json_init
-   json_add_string name "${interface}_6"
-   json_add_string ifname "@$interface"
-   json_add_string proto "dhc

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

2015-09-10 Thread Tobias Welz


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 trunk 
and seperate names for the releases. (What about some Cocktail with a 
letter from the end of the alphabet like Z Z or X X in 
case there exists one)


On that idea, the possible permanent name for the trunk could be 
something Txx Trunk. There are over 20 releases until TT is reached, 
so not for soon. I didn't find any really suitable drink names, but 
below are some ideas:

Trekking Trunk
Tasty Trunk
Tricky Trunk
Tempting Trunk
Twisty Trunk
Trunk Thrill
Thrilling Trunk

But until that, renaming trunk to something Dxxx Dxxx would be enough 
to decrease confusion.

___
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] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

2015-09-10 Thread edgar . soldin

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 Nyman:
>> Tobias Welz wrote at Wed Sep 9 17:24:14 CEST 2015:
>> > So I absolutely vote for some clear consistent naming of the trunk and 
>> > seperate names for the releases. (What about some Cocktail with a letter 
>> > from the end of the alphabet like Z Z or X X in case there 
>> > exists one)
>>
>> On that idea, the possible permanent name for the trunk could be something 
>> Txx Trunk. There are over 20 releases until TT is reached, so not for soon. 
>> I didn't find any really suitable drink names, but below are some ideas:
>> Trekking Trunk
>> Tasty Trunk
>> Tricky Trunk
>> Tempting Trunk
>> Twisty Trunk
>> Trunk Thrill
>> Thrilling Trunk
>>
>> But until that, renaming trunk to something Dxxx Dxxx would be enough to 
>> decrease confusion.
>> ___
>> 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] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

2015-09-10 Thread Luiz Angelo Daros de Luca

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 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 Nyman:
> >> Tobias Welz wrote at Wed Sep 9 17:24:14 CEST 2015:
> >> > So I absolutely vote for some clear consistent naming of the trunk
> and seperate names for the releases. (What about some Cocktail with a
> letter from the end of the alphabet like Z Z or X X in case
> there exists one)
> >>
> >> On that idea, the possible permanent name for the trunk could be
> something Txx Trunk. There are over 20 releases until TT is reached, so not
> for soon. I didn't find any really suitable drink names, but below are some
> ideas:
> >> Trekking Trunk
> >> Tasty Trunk
> >> Tricky Trunk
> >> Tempting Trunk
> >> Twisty Trunk
> >> Trunk Thrill
> >> Thrilling Trunk
> >>
> >> But until that, renaming trunk to something Dxxx Dxxx would be enough
> to decrease confusion.
> >> ___
> >> 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
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Carlos Ferreira

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 pointing into an empty
/tmp directory.

Is there any reason that might prevent the /proc from being mounted?
After booting for the first time, /proc is not mounted and because of that,
I'm unable to use 'top' or 'ps' to list the active processes.

I have been banging my head into the wall for the last day, unable to
understand what is going on.

Has anyone had the same issue before?
-- 

Carlos Miguel Ferreira
Researcher at Telecommunications Institute
Aveiro - Portugal
Work E-mail - c...@av.it.pt
Skype & GTalk -> carlosmf...@gmail.com
LinkedIn -> http://www.linkedin.com/in/carlosmferreira
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Carlos Ferreira

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 pointing into an empty
> /tmp directory.
>
> Is there any reason that might prevent the /proc from being mounted?
> After booting for the first time, /proc is not mounted and because of
> that, I'm unable to use 'top' or 'ps' to list the active processes.
>
> I have been banging my head into the wall for the last day, unable to
> understand what is going on.
>
> Has anyone had the same issue before?
> --
>
> Carlos Miguel Ferreira
> Researcher at Telecommunications Institute
> Aveiro - Portugal
> Work E-mail - c...@av.it.pt
> Skype & GTalk -> carlosmf...@gmail.com
> LinkedIn -> http://www.linkedin.com/in/carlosmferreira
>



-- 

Carlos Miguel Ferreira
Researcher at Telecommunications Institute
Aveiro - Portugal
Work E-mail - c...@av.it.pt
Skype & GTalk -> carlosmf...@gmail.com
LinkedIn -> http://www.linkedin.com/in/carlosmferreira
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Rafał Miłecki

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
> like Debian Unstable (trunk) is always called "Sid".

We may wait with branching until some rcX (we did that in past), so we
need a release name in trunk.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Anselm Eberhardt

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 changed, 1 deletion(-)

diff --git a/package/network/config/firewall/files/firewall.config 
b/package/network/config/firewall/files/firewall.config
index 7be01d2..ba7e4ec 100644
--- a/package/network/config/firewall/files/firewall.config
+++ b/package/network/config/firewall/files/firewall.config
@@ -60,7 +60,6 @@ config rule
option src  wan
option protoudp
option src_ip   fe80::/10
-   option src_port 547
option dest_ip  fe80::/10
option dest_port546
option family   ipv6
-- 
2.3.2 (Apple Git-55)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread John Crispin

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 always clear, that you are on the trunk. Similar
>> like Debian Unstable (trunk) is always called "Sid".
> 
> We may wait with branching until some rcX (we did that in past), so we
> need a release name in trunk.

we just need to change the name inside trunk when we fork. this time we
did not do this as we did a public vote for the name and the result was
not known when we forked.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread John Crispin



On 11/09/2015 01: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 pointing into
> an empty /tmp directory.
> 
> Is there any reason that might prevent the /proc from being mounted?
> After booting for the first time, /proc is not mounted and because of
> that, I'm unable to use 'top' or 'ps' to list the active processes.
> 
> I have been banging my head into the wall for the last day, unable to
> understand what is going on.


procfs is enabled by default. i am not sure why you had to enable it by
hand. does the default configuration work for you ? what other changes
did you make to your tree ?

John


> 
> Has anyone had the same issue before?
> -- 
> 
> Carlos Miguel Ferreira
> Researcher at Telecommunications Institute
> Aveiro - Portugal
> Work E-mail - c...@av.it.pt 
> Skype & GTalk -> carlosmf.pt @gmail.com
> 
> LinkedIn -> http://www.linkedin.com/in/carlosmferreira
> 
> 
> ___
> 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] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

2015-09-10 Thread Rafał Miłecki

On 11 September 2015 at 07:51, John Crispin  wrote:
> 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 always clear, that you are on the trunk. Similar
>>> like Debian Unstable (trunk) is always called "Sid".
>>
>> We may wait with branching until some rcX (we did that in past), so we
>> need a release name in trunk.
>
> we just need to change the name inside trunk when we fork. this time we
> did not do this as we did a public vote for the name and the result was
> not known when we forked.

I know, my reply was to explain why we *want* names in trunk :)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread John Crispin



On 11/09/2015 08:39, Rafał Miłecki wrote:
> On 11 September 2015 at 07:51, John Crispin  wrote:
>> 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 always clear, that you are on the trunk. Similar
 like Debian Unstable (trunk) is always called "Sid".
>>>
>>> We may wait with branching until some rcX (we did that in past), so we
>>> need a release name in trunk.
>>
>> we just need to change the name inside trunk when we fork. this time we
>> did not do this as we did a public vote for the name and the result was
>> not known when we forked.
> 
> I know, my reply was to explain why we *want* names in trunk :)
> 

agreed! I tried to explain why what you and me think is best did not
work out this time :)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread Etienne Champetier

2015-09-11 8:46 GMT+02:00 John Crispin :

>
>
> On 11/09/2015 08:39, Rafał Miłecki wrote:
> > On 11 September 2015 at 07:51, John Crispin  wrote:
> >> 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 always clear, that you are on the trunk.
> Similar
>  like Debian Unstable (trunk) is always called "Sid".
> >>>
> >>> We may wait with branching until some rcX (we did that in past), so we
> >>> need a release name in trunk.
> >>
> >> we just need to change the name inside trunk when we fork. this time we
> >> did not do this as we did a public vote for the name and the result was
> >> not known when we forked.
> >
> > I know, my reply was to explain why we *want* names in trunk :)
> >
>
> agreed! I tried to explain why what you and me think is best did not
> work out this time :)
>
>
Now that everyone has explained why it's cool to have a name in trunk,
maybe we can have it :)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-10 Thread John Crispin



On 11/09/2015 08:53, Etienne Champetier wrote:
> 
> 
> 2015-09-11 8:46 GMT+02:00 John Crispin  >:
> 
> 
> 
> On 11/09/2015 08:39, Rafał Miłecki wrote:
> > On 11 September 2015 at 07:51, John Crispin  > wrote:
> >> 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 always clear, that you are on the trunk. 
> Similar
>  like Debian Unstable (trunk) is always called "Sid".
> >>>
> >>> We may wait with branching until some rcX (we did that in past), so we
> >>> need a release name in trunk.
> >>
> >> we just need to change the name inside trunk when we fork. this time we
> >> did not do this as we did a public vote for the name and the result was
> >> not known when we forked.
> >
> > I know, my reply was to explain why we *want* names in trunk :)
> >
> 
> agreed! I tried to explain why what you and me think is best did not
> work out this time :)
> 
> 
> Now that everyone has explained why it's cool to have a name in trunk,
> maybe we can have it :)
>  

yes, once all the stuff required for doing so is resolved :) as you may
have noticed CC-final is already uploaded to the dl server. we did basic
testing already and all seems well. only missing bit is that the folder
currently shows a 403 and we are waiting on someone that has access to
the machine to figure out why. once that is done we will announce CC and
change trunk to DD :)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

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

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

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

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

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

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

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

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

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

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

[OpenWrt-Devel] how to use ubus_invoke_async parallels with once callback

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

[OpenWrt-Devel] [PATCH v2] uqmi: Add proper IPv6 support

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

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

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

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

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

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

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

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

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

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

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

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

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

29 matches

Site Navigation

Mail list logo

Footer information