Re: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if upstream network goes down

[Weedy]

On 3 February 2017 at 19:17, Nick Malyon  wrote:
> If anyone has a workaround that would be great — currently I managed to get 
> back in range of a network to make it accessible again, and now I run from 
> batteries and delete the wifi client configuration every night before the 
> jungle power goes out.


Do you have access to a PC? I would be interested in seeing the
wireless config file. specifically if the AP or STA section is listed
first.

I have a script I use to keep my repeated online in case of bullshit.
I can probably modify it to help you out if I get your config. Are you
using the template off the wiki with relayd and interface wwan etc?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] MT7620A WiFi issue - with a twist!

[Weedy]

On 1 February 2017 at 15:29, Jamie Stuart  wrote:
> Hello LEDE / OpenWRT devs,
>
> I am requesting your help. First a little background…
...
> This a known issue with the chipset and seems to have been round for years.
> We are currently building on LEDE trunk and still the issue persists.
>
> We are not driver developers, so my question is whether anyone with
> knowledge can help and provide a proper fix for this issue?


You will probably have the most luck posting a bounty on the linux
wifi mailing list.

Your root problem is picking a platform that basically uses a client
mode tested driver in AP mode and then hanging a million clients off
of it. I'm honestly surprised it didn't fall over sooner.

May I suggest when it comes time to refresh the hardware you guys pick
something with NGFF or mini-pcie slots for ALL radios.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if upstream network goes down

[Luiz Angelo Daros de Luca]

Nick, you can try lede-project bug tracker. I recently released rc1.

Em sex, 3 de fev de 2017 22:18, Nick Malyon  escreveu:

> Hi all,
>
> I tried to open the following bug report but Trac's spam filter wouldn't
> let me, so I thought I'd raise it on the mailing list to see what you
> think...
>
> I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it
> to provide a WiFi access point to my phone/tablet while I travel, and it's
> acting as a WiFi client for the various hostels I visit.
>
> If you configure it as a wifi client with a wwan interface using the LuCI
> scan/join wizard, and then you configure a wifi access point on the same
> radio, the router works as expected and when you connect to the router's
> AP, you get Internet via the client connection.
>
> However, if you move out of range of the network the router is a client
> of, or if it goes down, when you power off the OpenWrt router and power
> back on, the access point won't come up.
>
> The AP will only come up if the client network you configured is also
> working; so you have no way to connect to the router over wifi, and no way
> to reconfigure the router, if that client network is down or out of range.
>
> This is a particular problem for a travel router because it will often
> move it out of range of the original upstream network, and you may only
> have a wifi-capable device with which to reconfigure it.
>
> The Ethernet port on the router does remain active, so I can tell it does
> actually boot. It's just the radio that doesn't come up. I managed to get
> back in range of a network once, and the router worked as expected.
>
> It doesn't matter whether the AP or client connection are configured first
> or second on the radio interface, and, unticking "bring up on boot" for the
> wwan interface has no effect on the behaviour.
>
> Steps to reproduce: Connect the router to a wifi network as a client using
> the Join wizard. Add a wifi master-mode access point on the same radio
> interface. Verify you can access the Internet by joining the router's new
> master AP. Reboot the router with the original network it was a client of
> turned off. Notice the router's AP you configured never comes up.
>
> Expected behaviour: The master access point of the router should always
> come up, regardless of the availability of the client network.
>
> If anyone has a workaround that would be great — currently I managed to
> get back in range of a network to make it accessible again, and now I run
> from batteries and delete the wifi client configuration every night before
> the jungle power goes out.
>
> If this is indeed a bug, if you could please raise it in Trac for me —
> sorry, I get a "rejected due to possible spam" error, maybe because of my
> location.
>
> Many thanks!
> - Nick
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] WiFi client mode leaves router inaccessible if upstream network goes down

[Nick Malyon]

Hi all,

I tried to open the following bug report but Trac's spam filter wouldn't let 
me, so I thought I'd raise it on the mailing list to see what you think...

I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it to 
provide a WiFi access point to my phone/tablet while I travel, and it's acting 
as a WiFi client for the various hostels I visit.

If you configure it as a wifi client with a wwan interface using the LuCI 
scan/join wizard, and then you configure a wifi access point on the same radio, 
the router works as expected and when you connect to the router's AP, you get 
Internet via the client connection.

However, if you move out of range of the network the router is a client of, or 
if it goes down, when you power off the OpenWrt router and power back on, the 
access point won't come up.

The AP will only come up if the client network you configured is also working; 
so you have no way to connect to the router over wifi, and no way to 
reconfigure the router, if that client network is down or out of range.

This is a particular problem for a travel router because it will often move it 
out of range of the original upstream network, and you may only have a 
wifi-capable device with which to reconfigure it.

The Ethernet port on the router does remain active, so I can tell it does 
actually boot. It's just the radio that doesn't come up. I managed to get back 
in range of a network once, and the router worked as expected.

It doesn't matter whether the AP or client connection are configured first or 
second on the radio interface, and, unticking "bring up on boot" for the wwan 
interface has no effect on the behaviour.

Steps to reproduce: Connect the router to a wifi network as a client using the 
Join wizard. Add a wifi master-mode access point on the same radio interface. 
Verify you can access the Internet by joining the router's new master AP. 
Reboot the router with the original network it was a client of turned off. 
Notice the router's AP you configured never comes up.

Expected behaviour: The master access point of the router should always come 
up, regardless of the availability of the client network.

If anyone has a workaround that would be great — currently I managed to get 
back in range of a network to make it accessible again, and now I run from 
batteries and delete the wifi client configuration every night before the 
jungle power goes out.

If this is indeed a bug, if you could please raise it in Trac for me — sorry, I 
get a "rejected due to possible spam" error, maybe because of my location.

Many thanks!
- Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3 v3] watchdog: add DT bindings for Cortina Gemini

[Linus Walleij]

This adds DT bindings for the Cortina systems Gemini SoC
watchdog timer.

Cc: devicet...@vger.kernel.org
Reviewed-by: Guenter Roeck 
Acked-by: Rob Herring 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Fixed spelling error in filename "gemin" to "gemini"
- Collected ACKs
ChangeLog v1->v2:
- Make the timeout an optional property
- Do not mention any Linux defaults if the property is not there
---
 .../bindings/watchdog/cortina,gemini-watchdog.txt   | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt

diff --git 
a/Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt 
b/Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt
new file mode 100644
index ..bc4b865d178b
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt
@@ -0,0 +1,17 @@
+Cortina Systems Gemini SoC Watchdog
+
+Required properties:
+- compatible : must be "cortina,gemini-watchdog"
+- reg : shall contain base register location and length
+- interrupts : shall contain the interrupt for the watchdog
+
+Optional properties:
+- timeout-sec : the default watchdog timeout in seconds.
+
+Example:
+
+watchdog@4100 {
+   compatible = "cortina,gemini-watchdog";
+   reg = <0x4100 0x1000>;
+   interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+};
-- 
2.9.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

[Felix Fietkau]

On 2017-02-03 16:41, Alin Năstac wrote:
> On Fri, Feb 3, 2017 at 4:19 PM, Felix Fietkau  wrote:
>> On 2017-02-03 15:57, Alin Năstac wrote:
>>> Hi Felix,
>>>
>>> The SIGTERM ignore issue I was experiencing before is no longer
>>> reproducible after I apply your patch.
>>>
>>> However, I'm concerned about a possible ignore of SIGTERM signal
>>> received during a ubus_complete_request() call. If ctx->stack_depth is
>>> 0, any such signal received between prev_uloop_initialization and the
>>> reset of ulopp_cancelling to false will be ignored. Is this
>>> "uloop_cancelling = false" really necessary?
>>>
>>> BTW, I think the reset of uloop_status and uloop_cancelled should be
>>> executed before uloop_setup_signals() like so:
>>> if (!recursive_calls++) {
>>>uloop_status = 0;
>>>uloop_cancelled = false;
>>>uloop_setup_signals(true);
>>> }
>> I was worried about the corner case of performing a ubus request after
>> uloop_run has already completed.
>> I guess one way this could be addressed is by setting uloop_cancelled =
>> false at the end of uloop_run().
> 
> How about adding this uloop function:
> static int recursive_calls = 0; /* moved from uloop_run() context */
> int uloop_cancelling()
> {
> return recursive_calls > 0 && uloop_cancelled;
> }
> 
> This function will return true only when uloop_run() is still running,
> so you will no longer need to touch uloop_cancelled state at all. This
> way you could reduce the scope of uloop_cancelled to uloop.c too.
Implemented that in libubox.git and ubus.git. Will push to LEDE master soon.

Thanks,

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

Re: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

[Alin Năstac]

On Fri, Feb 3, 2017 at 4:19 PM, Felix Fietkau  wrote:
> On 2017-02-03 15:57, Alin Năstac wrote:
>> Hi Felix,
>>
>> The SIGTERM ignore issue I was experiencing before is no longer
>> reproducible after I apply your patch.
>>
>> However, I'm concerned about a possible ignore of SIGTERM signal
>> received during a ubus_complete_request() call. If ctx->stack_depth is
>> 0, any such signal received between prev_uloop_initialization and the
>> reset of ulopp_cancelling to false will be ignored. Is this
>> "uloop_cancelling = false" really necessary?
>>
>> BTW, I think the reset of uloop_status and uloop_cancelled should be
>> executed before uloop_setup_signals() like so:
>> if (!recursive_calls++) {
>>uloop_status = 0;
>>uloop_cancelled = false;
>>uloop_setup_signals(true);
>> }
> I was worried about the corner case of performing a ubus request after
> uloop_run has already completed.
> I guess one way this could be addressed is by setting uloop_cancelled =
> false at the end of uloop_run().

How about adding this uloop function:
static int recursive_calls = 0; /* moved from uloop_run() context */
int uloop_cancelling()
{
return recursive_calls > 0 && uloop_cancelled;
}

This function will return true only when uloop_run() is still running,
so you will no longer need to touch uloop_cancelled state at all. This
way you could reduce the scope of uloop_cancelled to uloop.c too.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

[Felix Fietkau]

On 2017-02-03 15:57, Alin Năstac wrote:
> Hi Felix,
> 
> The SIGTERM ignore issue I was experiencing before is no longer
> reproducible after I apply your patch.
> 
> However, I'm concerned about a possible ignore of SIGTERM signal
> received during a ubus_complete_request() call. If ctx->stack_depth is
> 0, any such signal received between prev_uloop_initialization and the
> reset of ulopp_cancelling to false will be ignored. Is this
> "uloop_cancelling = false" really necessary?
> 
> BTW, I think the reset of uloop_status and uloop_cancelled should be
> executed before uloop_setup_signals() like so:
> if (!recursive_calls++) {
>uloop_status = 0;
>uloop_cancelled = false;
>uloop_setup_signals(true);
> }
I was worried about the corner case of performing a ubus request after
uloop_run has already completed.
I guess one way this could be addressed is by setting uloop_cancelled =
false at the end of uloop_run().

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

Re: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

[Alin Năstac]

Hi Felix,

The SIGTERM ignore issue I was experiencing before is no longer
reproducible after I apply your patch.

However, I'm concerned about a possible ignore of SIGTERM signal
received during a ubus_complete_request() call. If ctx->stack_depth is
0, any such signal received between prev_uloop_initialization and the
reset of ulopp_cancelling to false will be ignored. Is this
"uloop_cancelling = false" really necessary?

BTW, I think the reset of uloop_status and uloop_cancelled should be
executed before uloop_setup_signals() like so:
if (!recursive_calls++) {
   uloop_status = 0;
   uloop_cancelled = false;
   uloop_setup_signals(true);
}

Cheers,
Alin

On Fri, Feb 3, 2017 at 2:47 PM, Felix Fietkau  wrote:
> Hi Alin,
>
> On 2017-02-03 09:29, Alin Năstac wrote:
>> Hi Felix,
>>
>> SIGTERM & SIGINT signals received during ubus_complete_request()
>> waiting for ubus_poll_data() to return are ignored due to
>> uloop_cancelled being restored to its previous value it had before
>> uloop_poll_data() was called.
>>
>> The reproduction scenario is this:
>>   1) cancelled local variable is set to false, current value of 
>> uloop_cancelled
>>   2) while ubus_poll_data() is waiting for a read event, a SIGTERM is
>> received, so uloop_cancelled is set to true
>>   3) after ubus_poll_data() returns, uloop_cancelled value gets
>> overwritten with false and SIGTERM signal ends up being ignored in the
>> uloop_run()
>>
>> The whole uloop_cancelled related logic in the ubus_complete_request()
>> seems to be focused on getting out from the current recursion of
>> uloop_run(), but from what I see uloop_run() capability to be called
>> recursively is no longer used in ubus, so I wonder if it is still
>> necessary.
> I left in uloop_cancelled primarily to deal with cleaning up recursive
> requests after Ctrl+c or SIGTERM when uloop is in use.
>
>> If the answer is no, the entire logic referring to uloop_cancelled and
>> uloop_end() should be removed from libubus-req.c. Otherwise an
>> additional uloop_cancelled_recursions bit mask would be needed that
>> will allow to control uloop_run() exit condition for each individual
>> recursion.
> I think the main problem was the fact that uloop_cancelled was used
> both for internal request termination and also for external use.
> Here's a patch that should resolve this issue, please test:
>
> ---
> diff --git a/libubus-io.c b/libubus-io.c
> index 1075c65..1343bb2 100644
> --- a/libubus-io.c
> +++ b/libubus-io.c
> @@ -154,9 +154,10 @@ int __hidden ubus_send_msg(struct ubus_context *ctx, 
> uint32_t seq,
> return ret;
>  }
>
> -static int recv_retry(int fd, struct iovec *iov, bool wait, int *recv_fd)
> +static int recv_retry(struct ubus_context *ctx, struct iovec *iov, bool 
> wait, int *recv_fd)
>  {
> int bytes, total = 0;
> +   int fd = ctx->sock.fd;
> static struct {
> struct cmsghdr h;
> int fd;
> @@ -191,7 +192,7 @@ static int recv_retry(int fd, struct iovec *iov, bool 
> wait, int *recv_fd)
>
> if (bytes < 0) {
> bytes = 0;
> -   if (uloop_cancelled)
> +   if (uloop_cancelled || ctx->cancel_poll)
> return 0;
> if (errno == EINTR)
> continue;
> @@ -274,7 +275,7 @@ static bool get_next_msg(struct ubus_context *ctx, int 
> *recv_fd)
> int r;
>
> /* receive header + start attribute */
> -   r = recv_retry(ctx->sock.fd, , false, recv_fd);
> +   r = recv_retry(ctx, , false, recv_fd);
> if (r <= 0) {
> if (r < 0)
> ctx->sock.eof = true;
> @@ -298,7 +299,7 @@ static bool get_next_msg(struct ubus_context *ctx, int 
> *recv_fd)
> iov.iov_base = (char *)ctx->msgbuf.data + sizeof(hdrbuf.data);
> iov.iov_len = blob_len(ctx->msgbuf.data);
> if (iov.iov_len > 0 &&
> -   recv_retry(ctx->sock.fd, , true, NULL) <= 0)
> +   recv_retry(ctx, , true, NULL) <= 0)
> return false;
>
> return true;
> @@ -311,7 +312,7 @@ void __hidden ubus_handle_data(struct uloop_fd *u, 
> unsigned int events)
>
> while (get_next_msg(ctx, _fd)) {
> ubus_process_msg(ctx, >msgbuf, recv_fd);
> -   if (uloop_cancelled)
> +   if (uloop_cancelled || ctx->cancel_poll)
> break;
> }
>
> @@ -326,6 +327,7 @@ void __hidden ubus_poll_data(struct ubus_context *ctx, 
> int timeout)
> .events = POLLIN | POLLERR,
> };
>
> +   ctx->cancel_poll = false;
> poll(, 1, timeout ? timeout : -1);
> ubus_handle_data(>sock, ULOOP_READ);
>  }
> diff --git a/libubus-req.c b/libubus-req.c
> index db5061c..305e813 100644
> --- a/libubus-req.c
> +++ b/libubus-req.c
> @@ -122,7 +122,7 @@ static void 

Re: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

[Felix Fietkau]

Hi Alin,

On 2017-02-03 09:29, Alin Năstac wrote:
> Hi Felix,
> 
> SIGTERM & SIGINT signals received during ubus_complete_request()
> waiting for ubus_poll_data() to return are ignored due to
> uloop_cancelled being restored to its previous value it had before
> uloop_poll_data() was called.
> 
> The reproduction scenario is this:
>   1) cancelled local variable is set to false, current value of 
> uloop_cancelled
>   2) while ubus_poll_data() is waiting for a read event, a SIGTERM is
> received, so uloop_cancelled is set to true
>   3) after ubus_poll_data() returns, uloop_cancelled value gets
> overwritten with false and SIGTERM signal ends up being ignored in the
> uloop_run()
> 
> The whole uloop_cancelled related logic in the ubus_complete_request()
> seems to be focused on getting out from the current recursion of
> uloop_run(), but from what I see uloop_run() capability to be called
> recursively is no longer used in ubus, so I wonder if it is still
> necessary.
I left in uloop_cancelled primarily to deal with cleaning up recursive
requests after Ctrl+c or SIGTERM when uloop is in use.

> If the answer is no, the entire logic referring to uloop_cancelled and
> uloop_end() should be removed from libubus-req.c. Otherwise an
> additional uloop_cancelled_recursions bit mask would be needed that
> will allow to control uloop_run() exit condition for each individual
> recursion.
I think the main problem was the fact that uloop_cancelled was used
both for internal request termination and also for external use.
Here's a patch that should resolve this issue, please test:

---
diff --git a/libubus-io.c b/libubus-io.c
index 1075c65..1343bb2 100644
--- a/libubus-io.c
+++ b/libubus-io.c
@@ -154,9 +154,10 @@ int __hidden ubus_send_msg(struct ubus_context *ctx, 
uint32_t seq,
return ret;
 }
 
-static int recv_retry(int fd, struct iovec *iov, bool wait, int *recv_fd)
+static int recv_retry(struct ubus_context *ctx, struct iovec *iov, bool wait, 
int *recv_fd)
 {
int bytes, total = 0;
+   int fd = ctx->sock.fd;
static struct {
struct cmsghdr h;
int fd;
@@ -191,7 +192,7 @@ static int recv_retry(int fd, struct iovec *iov, bool wait, 
int *recv_fd)
 
if (bytes < 0) {
bytes = 0;
-   if (uloop_cancelled)
+   if (uloop_cancelled || ctx->cancel_poll)
return 0;
if (errno == EINTR)
continue;
@@ -274,7 +275,7 @@ static bool get_next_msg(struct ubus_context *ctx, int 
*recv_fd)
int r;
 
/* receive header + start attribute */
-   r = recv_retry(ctx->sock.fd, , false, recv_fd);
+   r = recv_retry(ctx, , false, recv_fd);
if (r <= 0) {
if (r < 0)
ctx->sock.eof = true;
@@ -298,7 +299,7 @@ static bool get_next_msg(struct ubus_context *ctx, int 
*recv_fd)
iov.iov_base = (char *)ctx->msgbuf.data + sizeof(hdrbuf.data);
iov.iov_len = blob_len(ctx->msgbuf.data);
if (iov.iov_len > 0 &&
-   recv_retry(ctx->sock.fd, , true, NULL) <= 0)
+   recv_retry(ctx, , true, NULL) <= 0)
return false;
 
return true;
@@ -311,7 +312,7 @@ void __hidden ubus_handle_data(struct uloop_fd *u, unsigned 
int events)
 
while (get_next_msg(ctx, _fd)) {
ubus_process_msg(ctx, >msgbuf, recv_fd);
-   if (uloop_cancelled)
+   if (uloop_cancelled || ctx->cancel_poll)
break;
}
 
@@ -326,6 +327,7 @@ void __hidden ubus_poll_data(struct ubus_context *ctx, int 
timeout)
.events = POLLIN | POLLERR,
};
 
+   ctx->cancel_poll = false;
poll(, 1, timeout ? timeout : -1);
ubus_handle_data(>sock, ULOOP_READ);
 }
diff --git a/libubus-req.c b/libubus-req.c
index db5061c..305e813 100644
--- a/libubus-req.c
+++ b/libubus-req.c
@@ -122,7 +122,7 @@ static void ubus_sync_req_cb(struct ubus_request *req, int 
ret)
 {
req->status_msg = true;
req->status_code = ret;
-   uloop_end();
+   req->ctx->cancel_poll = true;
 }
 
 static int64_t get_time_msec(void)
@@ -142,6 +142,7 @@ int ubus_complete_request(struct ubus_context *ctx, struct 
ubus_request *req,
ubus_complete_handler_t complete_cb = req->complete_cb;
int status = UBUS_STATUS_NO_DATA;
int64_t timeout = 0, time_end = 0;
+   bool prev_uloop_cancelled = uloop_cancelled;
 
if (req_timeout)
time_end = get_time_msec() + req_timeout;
@@ -149,29 +150,32 @@ int ubus_complete_request(struct ubus_context *ctx, 
struct ubus_request *req,
ubus_complete_request_async(ctx, req);
req->complete_cb = ubus_sync_req_cb;
 
+   if (!ctx->stack_depth)
+   uloop_cancelled = false;
+
ctx->stack_depth++;
while (!req->status_msg) {
-   bool 

Re: [OpenWrt-Devel] [LEDE-DEV] NETSHe mac80211 GPL sources

[Daniel Golle]

Hi Stas,

thanks for the quick reply!

I'm looking for a good way to replace ubiquiti's proprietary TDMA
implementation with something which could be vendor-independent and
interoperable -- and ideally Free Open Source Software.
As TDMA has been implemented for ath9k in FreeBSD, I was wondering if
a similar extension to mac80211 has been made -- and found NETSHe's
wireless stack. As ath9k, mac80211 and the Linux kernel are under the
GPL license, I was assuming that NETSHe's modifications to support
TDMA thus must be available under the GPL licensed as well.

So from what I understand you are using your own proprietary driver
instead of ath9k? Yet, cfg80211 and mac80211 seem to be involved
according to what I found in TDMA_brief_en.pdf, as TDMA interfaces
are added obviously added through nl80211. Earlier today I also
realised that this has previously been discussed on this mailing
list, see
https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034374.html

As you are offering a binary version of the firmware for download,
according to the GPL you are oblidged to also share the portion of
the source code which is under GPL (ie. at least the Linux kernel,
GPL'ed wireless drivers like ath9k, libnl, the 'iw' userspace, ...)
as well as all modifications you've made to that GPL licensed code.

Obviously you could easily avoid that legal requirement by just not
offering a free download of the binaries, so don't get me wrong, I
do appreciate your openness! Yet, it'd be great if we had a shared
codebase for TDMA instead of a growing number of competing
implementations (ubnt, mikrotik, Deliberant's iPoll, NETSHe, ...) each
being developed behind closed doors. As your implementation is built
upon GPL'ed code and you offer binaries for download, please also
share the patches for iw, libnl, cfg80211, mac80211 and ath*k.
By the end of the day, you are using 99% code which other people have
written and published under the assumption that everyone is granted
the freedom to run, study, share and modify the software.
"The GPL is a copyleft license, which means that derivative work can
only be distributed under the same license terms." [1]
However, I'm not a lawyer and I have simply no idea if the GPL can
actually be enforced in the judicative domain NETSHe is located in or
whether we are talking about a purely idealistic/moralic issue here.

Anywa, my interest is to use and improve that code! Friends of mine
have started a non-profit collaborative ISP project [2] and we are
having a heated debate whether to use OpenWrt/LEDE from source or
ubnt's proprietary firmware on ubnt and other ath9k-based hardware.
Even though Wifi performance on ath9k recently improved a lot, a TDMA
implementation under a free license (ie. GPL) would be great thing to
have, also for use in Wireless Community Mesh Networks.

A good compromise could be to publish the code without the userspace
tools allowing AES crypto -- in that way, free community networks
can use that implementation and commercial entities would need to
license the crypto bits if they want link-level crypto.



Cheers


Daniel

[1]: https://en.wikipedia.org/wiki/GNU_General_Public_License
[2]: https://www.reudnetz.org/


On Fri, Feb 03, 2017 at 09:35:30AM +0300, Stanislav V. Korsakov wrote:
> Hi Daniel,
> 
> Please check this article http://netshe.ru/wirelessstack to understand
> layering of our modifications in Linux wireless stack. You can see that
> we add proprietary licensed and dual licensed drivers in wireless stack.
> We provide our GPLed and dual licensed source codes to our customer only.
> Not our source code is available at http://gw.stasoft.net/dl/
> 
> Can you tell me what is your real interest?
> 
> Regards, Stas
> 
> 
> On 03.02.2017 03:43, Daniel Golle wrote:
> > Hi!
> >
> > NETSHe offers a modified version of ath9k, mac80211 and cfg80211 which
> > offers support for TDMA, see:
> > http://netshe.ru/files/doc/en/TDMA_brief_en.pdf
> >
> > Where to download the sourcecode of mac80211 and the modified drivers?
> >
> >
> > Cheers
> >
> >
> > Daniel
> 
> 
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

[Alin Năstac]

Hi Felix,

SIGTERM & SIGINT signals received during ubus_complete_request()
waiting for ubus_poll_data() to return are ignored due to
uloop_cancelled being restored to its previous value it had before
uloop_poll_data() was called.

The reproduction scenario is this:
  1) cancelled local variable is set to false, current value of uloop_cancelled
  2) while ubus_poll_data() is waiting for a read event, a SIGTERM is
received, so uloop_cancelled is set to true
  3) after ubus_poll_data() returns, uloop_cancelled value gets
overwritten with false and SIGTERM signal ends up being ignored in the
uloop_run()

The whole uloop_cancelled related logic in the ubus_complete_request()
seems to be focused on getting out from the current recursion of
uloop_run(), but from what I see uloop_run() capability to be called
recursively is no longer used in ubus, so I wonder if it is still
necessary.

If the answer is no, the entire logic referring to uloop_cancelled and
uloop_end() should be removed from libubus-req.c. Otherwise an
additional uloop_cancelled_recursions bit mask would be needed that
will allow to control uloop_run() exit condition for each individual
recursion.

Please share your pov so I could prepare the necessary patches.

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