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

[Juergen Kimmel]

Hello everyone,
I'm in the same boat struggeling with  mt7620a WiFi performance,
namely with the device called   ZBT APE522ii.
Stock firmware based on Openwrt (has no version number) has no issues
concerning wifi performance.

Because I`m focussing on a mesh solution,  I tested Openwrt/Lede based
qMp (qmp.cat) but having the same issues described here.
IMHO there must be different drivers to be used. My skills are not at
all  sufficient to clear where the difference could be.
So help is very much appreciated.

2017-02-04 2:27 GMT+01:00 Juergen Kimmel :
> Hello everyone,
> I'm in the same boat struggeling with  mt7620a WiFi performance, namely with
> the device called
>  ZBT APE522ii.
> Stock firmware based on Openwrt (no version number) has no issues concerning
> wifi performance.
>
> Because I`m focussing on a mesh solution,  I tested Openwrt/Lede based qMp
> (qmp.cat) but having the same issues described here.
> IMHO there must be different drivers used. My skills are not at all
> sufficient to clear where the difference could be.
> So help is very much appreciated.
>
>
> Weedy  schrieb am Sa., 4. Feb. 2017 01:51:
>>
>> 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.
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Mit freundlichen Grüssen

Jürgen Kimmel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] dnsmasq make DHCPv6 viable for standalone dnsmasq install

[Eric Luehrsen]

I just rebuilt LEDE trunk on TL-WDR3600 with dnsmasq-full and odhcpd 
excluded. I also rebuilt LEDE trunk on TL-Archer-C7 which runs 
odhcpd+Unbound instead. The Archer is the internet gateway. The WDR is 
subnet from the Archer. The laptop sending this email is a client of the 
WDR. We have DHCP-PD to the laptop (until odhcpd flakes out and kills 
that route). The static ULA-domains and routes work [fd00::] around this 
and I can connect IP6 to any device in the network upstream or 
downstream. dnsmasq is handing out RA and DHCPv6 to the laptop.

Cabel -> Modem -> Archer (AP) -> WiFi -> (Client) WDR -> Wire -> Laptop

If you build LEDE nearly default and later disable odhcpd, then don't 
forget to stop odhcpd or reboot the router. odhcpd will hold the port 
(547/548) and dnsmasq will not be able to obtain it.


On 02/03/2017 04:46 PM, Eric Luehrsen wrote:
> I will look at it this weekend.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] 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.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] dnsmasq make DHCPv6 viable for standalone dnsmasq install

[Eric Luehrsen]

I will look at it this weekend. It seems that maybe some intermediate 
rebase-to-trunk event chewed up a line of code. The commit was lingering 
for quite a while. There is a report for another issue also. Its 
probably an esay fix, just need to stare at it for a while.

- Eric


 Original message 
From: Daniel Petre 
Date: 2/3/17 05:26 (GMT-05:00)
To: Eric Luehrsen , Jo-Philipp Wich 
Subject: Re: dnsmasq: make DHCPv6 viable for standalone dnsmasq install

On 02/02/2017 07:52 PM, Eric Luehrsen wrote:
> What I submitted I had tested on TL WDR3600 and TL Archer C7 ... working
> together. The archer DHCP-PD with odhcpd to the Wdr with dnsmasq full.

I only tried the dnsmasq-dhcpv6 and dnsmasq-full with only IPv6
selected. Should i compile in all dnsmasq options?

> Also pulled from. JOW staging at some point to see ... but I may not
> have tested any last minute fixup work.
>
>
>
> - Eric
>
>
>  Original message 
> From: Daniel Petre 
> Date: 2/2/17 10:55 (GMT-05:00)
> To: Eric Luehrsen , Jo-Philipp Wich 
> Subject: dnsmasq: make DHCPv6 viable for standalone dnsmasq install
>
> Hi,
> are you sure your commit works..? Did you tested it?
>
>https://github.com/lede-project/source/commit/9525743c076393336cd2129539c974f8a01c7894
>
> I have just removed odhcpd and tried both dnsmasq-dhcpv6 and the full
> dnsmasq with ipv6 enabled without luck. No IPv6 is getting to my wifi
> laptop from a nexx wt3020 router while the setup with odhcpd works just
> fine.
>
> I have a /64 via PD on pppoe.
>
> Thanks!

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 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.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] initialisation/startup of dnsmasq for multiple instances is broken

[e9hack]

Am 03.02.2017 um 04:45 schrieb Eric Luehrsen:
> Precisely, 
> what are you expecting and what isnt happening? Could you cut n paste 
> snippets from uci and conf as examples?

my dhcp config file looks like this:

config dnsmasq 'main'
option nonwildcard '1'
option ...

config dnsmasq 'guest'
option nonwildcard '1'
option ...

config dhcp
option interface 'wan'
option ignore '1'

config dhcp
option instance 'main'
option interface 'lan'
option ...

config dhcp
option instance 'guest'
option interface 'guest'
option ...

config host
option instance 'main'
option name 'darkstar'
option ...

I have configured two dnsmasq sections for two instances, which provide DHCP 
and DNS for two different interfaces. Dhcp
and host sections are containing the option instance. dhcp-host=... entries are 
generated in the configuration files
depend on the instance option. Both dhcp-range=... entries for my different 
networks are generated in both configuration
files. The option instance is completely ignored for dhcp sections since the 
last commit related to dhcp6. It does work
with the previous revisions. The dnsmasq.conf.main file contains only 
dhcp-range=lan,... and dnsmasq.conf.guest only
dhcp-range=guest,...

Regards,
Hartmut

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Kristian Evensen]

On Fri, Feb 3, 2017 at 12:52 PM, Piotr Dymacz  wrote:
> As this is a general problem and I'm sure it's going to grow in time,
> maybe we should start thinking about different approach for naming
> boards in system, dts files and image filenames? Including there also
> the manufacturer name would be one of possible options, but... I'm
> pretty sure this problem is also kernel related (upstream dts
> filenames convention).

I will submit a v3 with the renaming + licensing later this evening.
Everything is ready, but need to test changes on an actual device.

-Kristian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ltq-ptm: Support 1508-byte MTU for RFC4638

[David Woodhouse]

On Fri, 2016-10-07 at 15:02 +0100, David Woodhouse wrote:
> Tested with VDSL on TP-Link WD8970, I see full 1500-byte PPP data
> frames, which end up being 1526 byte Ethernet frames (including
> Ethernet+VLAN headers) on the wire.
> 
> Fixes: FS#210

So this got merged, and now it *can* work properly. But it doesn't. I
updated to 17.01 and I'm back to 1492-byte PPP.

I think I had also hacked my local build of the module so that not only
would it *permit* a 1508-byte MTU to be set, but it also *defaulted* to
that.

Now, it defaults to 1500 and needs userspace to *set* an MTU of 1508 on
the ptm0 and ptm0.101 VLAN interfaces... and I can't persuade netifd to
do that. I only get full frames if I set the MTU manually.

What am I missing?

config interface 'vdsl'
option proto 'pppoe'
option username 'xx'
option password 'xx'
option pppd_options 'debug'
option ifname 'ptm0.101'
option mtu '1500'
option ipv6 'auto'

config route6
option interface 'vdsl'
option target '::/0'
option metric '1'

config switch_vlan 'ptm0_101'
option device 'ptm0'
option vlan '101'
option vid '101'

config interface 'aa101'
option ifname 'ptm0.101'
option proto 'none'
option mtu '1508'
option delegate '0'

config interface 'ptm0'
option ifname 'ptm0'
option proto 'none'
option mtu '1508'
option delegate '0'

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 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: [LEDE-DEV] NETSHe mac80211 GPL sources

[Stanislav V. Korsakov]

Hi Daniel,

Why do you think that all our TDMA-related modifications must be under
GPL license?

We use cfg80211, mac80211, ath5k and ath9k with very small modifications
to support new type of interface and to handle some new netlink commands.
We call own dual licensed module from mac80211 to handle new type of
interface. Some code to provide new functionality is placed in our
proprietary licensed driver. This driver does not use any GPL exported
calls/symbols from the kernel and other drivers. Code from this module
is used from our dual licensed module only. This module taints kernel.

In our mind, we do not breach GPL v2 with this architecture.
Thus, we have two parts of source code:
1. GPLed and dual-licensed. We provide this source code to our
customers. Any customer can open GPLed part if he wish to do it. Why
should we provide it for everyone (not customers)? Please point me to
GPL v2 license term which has this requirements. Not your interpretation.
2. Closed source for our proprietary module.

We do not share our binaries for everyone since v3.2. All GPLed code
(including patches) is available in a free access for v3.2.

At least, we try to keep copyrights and software licenses and I do not
see license breaches now. You can find what we build our firmware, what
we used and how. E.g. how we use OpenWRT and what is the difference. We
do not hide it.
If you found breaches - inform me to cancel.

About idealistic...
I did not see long time and effective working just for fun only...
Programmers want to eat...
Open source is very good and helpful thing. Let discuss how we can help
but keep in mind that we need to earn money too.

Excuse me my bad English. Hope, I explained our point of view...

Now about implementation details if it still interesting...

Our implementation is completely different from Ubiquiti or FreeBSD's.
In my mind, first uses PCF mode variation. Second is original but i do
not impress how it works in noisy environment.
For our implementation, closest mode is AdHoc with own scheduler.
Scheduler is implemented in software completely.
Our implementation is well for narrow channels and not big mesh networks
(and we do own mesh implementation above TDMA) but lost efficiency with
wide channels. We can not utilize HT/VHT  and have bigger delay by design.

Regards, Stas


On 03.02.2017 13:40, Daniel Golle wrote:
> 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 

Re: [LEDE-DEV] License for DTS files

[Linus Lüssing]

On Fri, Feb 03, 2017 at 12:29:35PM +0100, Rafał Miłecki wrote:
> Upstream Linux maintainers prefer/require clear BSD-compatible
> license, see e.g.:
> https://lkml.org/lkml/2016/5/4/707

I would be a little more careful with such statements, that seems
like a wrong generalization to me concerning license preferences
of Linux maintainers.


The link says "ARM SoC maintainers", not "Linux maintainers" in
general. And I wouldn't be surprised if the request came from
developers getting their paycheck from Google or Google affiliates.
It's no secret that Google (management?) does not like the GPL.

They already wrote a BSD licensed replacement for the GPL licensed
bluetooth stack "BlueZ" called "BlueDroid". And they even started
developing a whole new kernel from the scratch called "Fuchsia".


(Why might Google management steer towards BSD licenses? To lock
things down as soon as it gets en par with its GPL counterparts,
to be able to sell exclusive features again, if you ask me.
Interesting read here:

https://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/
)


PS: Don't get me wrong, this is no opinion concerning the license
of DTS files or a religious statement concerning "the right
license" (there are plenty of cases where BSD-like licenses are
an excellent choice - and maybe DTS files is one of them ;) ).

My nitpicking is just about this one sentence :-).

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[Alberto Bursi]

On 02/03/2017 11:40 AM, Daniel Golle wrote:
> Hi Stas,
>
> 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.

Not gonna fly, they are making it for money, they don't want a "shared 
codebase", they want to sell their NETSHe.

What might be interesting for a commercial entity like them is that if 
they do like Qt does (dual-license, either proprietary for paying 
customers or GPL for everyone else, contributors sign a license 
agreement that allows Qt to do this dual licensing), the NETSHe's 
position will be strenghtened.
They will receive a boost for public awareness and contributions, as 
open firmwares and Linux OS will likely use their implementation by 
default so that's what people will be more likely to 
know/learn/test/contribute to.
While since many companies don't like GPL they will still make money 
selling proprietary-licensed code to them.

Assuming it isn't just a massive GPL violation where they just do ugly 
hacks to the GPLed drivers and make these new version closed source, anyway.
I'm probably very biased but tricks like the above are very very common.

-Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Piotr Dymacz]

Hi Mathias,

2017-02-03 12:13 GMT+01:00 Mathias Kresin :
> 2017-02-03 11:49 GMT+01:00 Kristian Evensen :
>> Hi
>>
>> On Fri, Feb 3, 2017 at 11:02 AM, Piotr Dymacz  wrote:
>>> Hi Kristian,
>>>
>>> My two cents: the general convention for board name is to not include
>>> the manufacturer name (Sanlinking here).
>>> As you can see, (almost) all other boards follow this rule, so please
>>> use "d240" instead of "sanlinking-d240" (also for dts filename).
>>>
>>
>> I have no strong feelings for the manufacturer name, so I will remove
>> it if that is what it takes to get the patch accepted. However, I can
>> easily imagine a second manufacturer naming their device something
>> something D240, so perhaps shortening the name to for example SL- is a
>> good compromise between the two?
>
> I'm for using SL-D240. I share Kristians concerns about possible name
> collisions in targets supporting a lot of boards like ar71xx and
> ramips. Piotr, are fine with SL-D240?

I don't think we should modify model names given by manufacturers
unless it's really needed.
Of course, in case of name conflict, we should take care of it, but
only when it happens, not in advance and/or "just in case".

And, as Larry already pointed out, SL-* prefix is used by Skyline
products (I suppose SL-something is a real model name, and prefix
wasn't added by us) which might be misleading for users when they look
for ready image.

We already have at least one name conflict under ar71xx target (ap96)
and IMHO it wasn't solved properly. We have there board names "ap96"
and "alfa-ap96" and ready images also use these names (actually, image
for "Atheros AP96 Reference Board" is not generated as the kernel grew
too much...). Question here is why only ALFA board got the prefix and
Atheros one didn't?

As this is a general problem and I'm sure it's going to grow in time,
maybe we should start thinking about different approach for naming
boards in system, dts files and image filenames? Including there also
the manufacturer name would be one of possible options, but... I'm
pretty sure this problem is also kernel related (upstream dts
filenames convention).

Cheers,
Piotr

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Baptiste Jonglez]

On Tue, Jan 31, 2017 at 10:14:04AM +, David Woodhouse wrote:
> On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
> > 
> > - IPv6 support: since that was the focus of CC, at least mention that
> >   nothing was intentionally broken (and maybe there were some
> >   improvement?)]
> 
> What was the IPv6 problem?

Nothing, hopefully :) What I meant is that LEDE should work as well as
OpenWRT CC with respect to IPv6 support.  This is currently implicit,
because the release notes do not mention IPv6 at all.  I was wondering if
it would make sense to mention that IPv6 support remains very good.

Baptiste


signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] License for DTS files

[Rafał Miłecki]

In LEDE we have quite a lot of DTS files that hasn't been upstreamed.
They often contain no licensing info.

Upstream Linux maintainers prefer/require clear BSD-compatible
license, see e.g.:
https://lkml.org/lkml/2016/5/4/707

Some people may not agree such files are copyrightable at all, but
most of us are not layers (including upstream maintainers) so it's
probably just easier to specify some license and be done with it.

Could we require/ask new DTS files added to LEDE project to use
BSD-compatible license? This would help upstreaming code if someone
decides to do that.

-- 
Rafał

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[David Lang]

On Fri, 3 Feb 2017, Daniel Golle wrote:


Hi Alberto,

On Fri, Feb 03, 2017 at 10:59:38AM +, Alberto Bursi wrote:



On 02/03/2017 07:35 AM, Stanislav V. Korsakov wrote:

Hi Daniel,

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/



What you wrote here sounds like a license violation.
Source code of GPLed software you use *must* be provided to everyone
that asks it, not just to customers.
That's what the GPL license requires.


Strictly speaking, it must be provided to anyone who also got access
to the binary. So, if you offer a free download of the binary, you must
provide the sources under the same terms. Ie. by downloading the
binaries from the website, that makes me a customer entitled to ask for
the sources.
However, if you provide the binaries only to customers or keep them
"in-house" (that's what most telcos do), only the parties which were
handed the binaries can ask for the sources, that's at least how I
understood the GPLv2.


If you never distribute the binaries, then you don't have to provide source to 
anyone (but if you sell devices with the binaries, you are distributing them)


If you "enclose a written offer for the source" when you ship the binaries, that 
offer is good to anyone, not just those who receive the binaries (and must be in 
place for at least three years). Most companies do this and put tarballs of the 
source on a server and forget about it.


If you ship the source with the binaries on the same media, then you are not 
required to setup any additional methods/processes for people to ask for the 
source. Your obligations under the GPL are satisfied by shipping the source with 
the binaries, so this is the easiest thing to do in the long run.


There have been a number of companies who have tried to set things up so that 
they only give the source to their customers, and only when they ask, with 
restrictions preventing the customers from giving the source to anyone else. 
These have always been a violation of the GPL and while none have gone to court 
in the US, that's because the violators have always settled before getting into 
court (with vmware being the only exception, and I haven't heard that that case 
has gone to trial yet)


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Rafał Miłecki]

On 3 February 2017 at 09:54, Kristian Evensen
 wrote:
> diff --git a/target/linux/ramips/dts/SANLINKING-D240.dts 
> b/target/linux/ramips/dts/SANLINKING-D240.dts
> new file mode 100644
> index 000..888f5aa
> --- /dev/null
> +++ b/target/linux/ramips/dts/SANLINKING-D240.dts
> @@ -0,0 +1,120 @@
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include 
> +#include 

Could you put a header with licensing info in this file? For /some/
reason upstream Linux maintainers want to have license specified.
Anything BSD-compatible would be great.

I'll send a global e-mail with such a request to make it clear for the future.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[Daniel Golle]

Hi Alberto,

On Fri, Feb 03, 2017 at 10:59:38AM +, Alberto Bursi wrote:
> 
> 
> On 02/03/2017 07:35 AM, Stanislav V. Korsakov wrote:
> > Hi Daniel,
> >
> > 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/
> >
> 
> What you wrote here sounds like a license violation.
> Source code of GPLed software you use *must* be provided to everyone 
> that asks it, not just to customers.
> That's what the GPL license requires.

Strictly speaking, it must be provided to anyone who also got access
to the binary. So, if you offer a free download of the binary, you must
provide the sources under the same terms. Ie. by downloading the
binaries from the website, that makes me a customer entitled to ask for
the sources.
However, if you provide the binaries only to customers or keep them
"in-house" (that's what most telcos do), only the parties which were
handed the binaries can ask for the sources, that's at least how I
understood the GPLv2.


Cheers


Daniel

> 
> -Alberto
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Mathias Kresin]

2017-02-03 11:49 GMT+01:00 Kristian Evensen :
> Hi
>
> On Fri, Feb 3, 2017 at 11:02 AM, Piotr Dymacz  wrote:
>> Hi Kristian,
>>
>> My two cents: the general convention for board name is to not include
>> the manufacturer name (Sanlinking here).
>> As you can see, (almost) all other boards follow this rule, so please
>> use "d240" instead of "sanlinking-d240" (also for dts filename).
>>
>
> I have no strong feelings for the manufacturer name, so I will remove
> it if that is what it takes to get the patch accepted. However, I can
> easily imagine a second manufacturer naming their device something
> something D240, so perhaps shortening the name to for example SL- is a
> good compromise between the two?

I'm for using SL-D240. I share Kristians concerns about possible name
collisions in targets supporting a lot of boards like ar71xx and
ramips. Piotr, are fine with SL-D240?

Kristian, if you send a v3, please add some information on how to
install LEDE to the Sanlinking D240 to the commit message. Have a look
at https://git.lede-project.org/fd62fa752bbff9ae5277098152e7960a14d241e1
for a good example how it could look like.

Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[David Lang]

On Fri, 3 Feb 2017, Alberto Bursi wrote:


On 02/03/2017 07:35 AM, Stanislav V. Korsakov wrote:

Hi Daniel,

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/



What you wrote here sounds like a license violation.
Source code of GPLed software you use *must* be provided to everyone
that asks it, not just to customers.
That's what the GPL license requires.


If it's shipped with the binary (as opposed to a separte download), they don't 
have to offer it to anyone else. But any of the customers are free to pass the 
source along, as it is GPL.


But if it's a separate download, it does have to be made available to anyone.

David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[Alberto Bursi]

On 02/03/2017 07:35 AM, Stanislav V. Korsakov wrote:
> Hi Daniel,
>
> 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/
>

What you wrote here sounds like a license violation.
Source code of GPLed software you use *must* be provided to everyone 
that asks it, not just to customers.
That's what the GPL license requires.

-Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Kristian Evensen]

Hi

On Fri, Feb 3, 2017 at 11:02 AM, Piotr Dymacz  wrote:
> Hi Kristian,
>
> My two cents: the general convention for board name is to not include
> the manufacturer name (Sanlinking here).
> As you can see, (almost) all other boards follow this rule, so please
> use "d240" instead of "sanlinking-d240" (also for dts filename).
>

I have no strong feelings for the manufacturer name, so I will remove
it if that is what it takes to get the patch accepted. However, I can
easily imagine a second manufacturer naming their device something
something D240, so perhaps shortening the name to for example SL- is a
good compromise between the two?

-Kristian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [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-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Piotr Dymacz]

Hi Kristian,

My two cents: the general convention for board name is to not include
the manufacturer name (Sanlinking here).
As you can see, (almost) all other boards follow this rule, so please
use "d240" instead of "sanlinking-d240" (also for dts filename).

Cheers,
Piotr

2017-02-03 9:54 GMT+01:00 Kristian Evensen :
> The Sanlinking Technologies D240
> (http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the 
> same
> device as the ZBT WE826, so adding support for it in LEDE is straight forward.
> The differences is that the D240 has two mini-PCIe slots (instead of one), 
> blue
> LEDs and supports PoE.
>
> Wifi, USB, switch and both mini-PCIe slots are working. I have not been able 
> to
> test the SD card reader on the device.
>
> v1->v2:
>
> * Misc. code cleanup (thanks Mathias Kresin)
>
> Signed-off-by: Kristian Evensen 
>
> Cleanup
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
>  .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>  target/linux/ramips/base-files/etc/diag.sh |   1 +
>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ramips/dts/SANLINKING-D240.dts| 120 
> +
>  target/linux/ramips/image/mt7620.mk|   8 ++
>  7 files changed, 138 insertions(+)
>  create mode 100644 target/linux/ramips/dts/SANLINKING-D240.dts
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 545d6a4..409854f 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -300,6 +300,10 @@ rt-n14u)
> set_wifi_led "$board:blue:air"
> set_usb_led "$board:blue:usb"
> ;;
> +sanlinking-d240)
> +   set_wifi_led "$board:blue:wifi"
> +   set_usb_led "$board:blue:usb"
> +   ;;
>  tew-714tru)
> set_usb_led "$board:red:usb"
> set_wifi_led "$board:green:wifi"
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index c001dfe..bf2edf0 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -92,6 +92,7 @@ ramips_setup_interfaces()
> pbr-m1|\
> psg1208|\
> psg1218|\
> +   sanlinking-d240|\
> sap-g3200u3|\
> sk-wb8|\
> vr500|\
> diff --git a/target/linux/ramips/base-files/etc/diag.sh 
> b/target/linux/ramips/base-files/etc/diag.sh
> index 5fb2213..b92d871 100644
> --- a/target/linux/ramips/base-files/etc/diag.sh
> +++ b/target/linux/ramips/base-files/etc/diag.sh
> @@ -115,6 +115,7 @@ get_status_led() {
> rt-n14u|\
> rt-n15|\
> rt-n56u|\
> +   sanlinking-d240|\
> wl-330n|\
> wl-330n3g|\
> wli-tx4-ag300n|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
> b/target/linux/ramips/base-files/lib/ramips.sh
> index d9918cc..dc86a82 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -442,6 +442,9 @@ ramips_board_detect() {
> *"SamKnows Whitebox 8")
> name="sk-wb8"
> ;;
> +   *"SANLINKING-D240")
> +   name="sanlinking-d240"
> +   ;;
> *"SAP-G3200U3")
> name="sap-g3200u3"
> ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index d83e5c1..afc6014 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -123,6 +123,7 @@ platform_check_image() {
> rt-n15|\
> rt-n56u|\
> rut5xx|\
> +   sanlinking-d240|\
> sap-g3200u3|\
> sk-wb8|\
> sl-r7205|\
> diff --git a/target/linux/ramips/dts/SANLINKING-D240.dts 
> b/target/linux/ramips/dts/SANLINKING-D240.dts
> new file mode 100644
> index 000..888f5aa
> --- /dev/null
> +++ b/target/linux/ramips/dts/SANLINKING-D240.dts
> @@ -0,0 +1,120 @@
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> +   compatible = "sanlinking,sanlinking-d240", "ralink,mt7620a-soc";
> +   model = "SANLINKING-D240";
> +
> +   chosen {
> +   bootargs = "console=ttyS0,115200";
> +   };
> +
> +   gpio-leds {
> +   compatible = "gpio-leds";
> +   power {
> +   label = "sanlinking-d240:blue:power";
> +   gpios = < 14 GPIO_ACTIVE_HIGH>;
> +   };
> +   usb {
> +   label = "sanlinking-d240:blue:usb";
> +   gpios = < 15 GPIO_ACTIVE_HIGH>;
> +   };

[LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Kristian Evensen]

The Sanlinking Technologies D240
(http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same
device as the ZBT WE826, so adding support for it in LEDE is straight forward.
The differences is that the D240 has two mini-PCIe slots (instead of one), blue
LEDs and supports PoE.

Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader on the device.

v1->v2:

* Misc. code cleanup (thanks Mathias Kresin)

Signed-off-by: Kristian Evensen 

Cleanup
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/SANLINKING-D240.dts| 120 +
 target/linux/ramips/image/mt7620.mk|   8 ++
 7 files changed, 138 insertions(+)
 create mode 100644 target/linux/ramips/dts/SANLINKING-D240.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 545d6a4..409854f 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -300,6 +300,10 @@ rt-n14u)
set_wifi_led "$board:blue:air"
set_usb_led "$board:blue:usb"
;;
+sanlinking-d240)
+   set_wifi_led "$board:blue:wifi"
+   set_usb_led "$board:blue:usb"
+   ;;
 tew-714tru)
set_usb_led "$board:red:usb"
set_wifi_led "$board:green:wifi"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index c001dfe..bf2edf0 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -92,6 +92,7 @@ ramips_setup_interfaces()
pbr-m1|\
psg1208|\
psg1218|\
+   sanlinking-d240|\
sap-g3200u3|\
sk-wb8|\
vr500|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5fb2213..b92d871 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -115,6 +115,7 @@ get_status_led() {
rt-n14u|\
rt-n15|\
rt-n56u|\
+   sanlinking-d240|\
wl-330n|\
wl-330n3g|\
wli-tx4-ag300n|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d9918cc..dc86a82 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -442,6 +442,9 @@ ramips_board_detect() {
*"SamKnows Whitebox 8")
name="sk-wb8"
;;
+   *"SANLINKING-D240")
+   name="sanlinking-d240"
+   ;;
*"SAP-G3200U3")
name="sap-g3200u3"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index d83e5c1..afc6014 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -123,6 +123,7 @@ platform_check_image() {
rt-n15|\
rt-n56u|\
rut5xx|\
+   sanlinking-d240|\
sap-g3200u3|\
sk-wb8|\
sl-r7205|\
diff --git a/target/linux/ramips/dts/SANLINKING-D240.dts 
b/target/linux/ramips/dts/SANLINKING-D240.dts
new file mode 100644
index 000..888f5aa
--- /dev/null
+++ b/target/linux/ramips/dts/SANLINKING-D240.dts
@@ -0,0 +1,120 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "sanlinking,sanlinking-d240", "ralink,mt7620a-soc";
+   model = "SANLINKING-D240";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+   power {
+   label = "sanlinking-d240:blue:power";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+   usb {
+   label = "sanlinking-d240:blue:usb";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+   air {
+   label = "sanlinking-d240:blue:wifi";
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+   reset {
+   label = "reset";
+   gpios = < 1 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";

Re: [LEDE-DEV] [PATCH] ramips: Add support for Sanlinking D240

[Kristian Evensen]

On Thu, Feb 2, 2017 at 8:13 PM, Mathias Kresin  wrote:
> Hey Kristian,
>
> thanks a lot for the patch. Find my comments inline.

Thanks a lot! Will submit a v2 soon.

-Kristian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] 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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev