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
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
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.
Wi
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:
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
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-d
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
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 violatio
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 th
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/
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 @@
>
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 h
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
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?)]
>
> Wh
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 (Sanlin
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
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 l
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 handl
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.
>
> T
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 properl
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
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_i
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_dep
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 ...
conf
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
>> rece
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
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
It seems like the easiest thing would be to make a /contrib directory
and start putting things in it as a staging directory.
If something ends up being amazing it will get packaged, and maybe
shipped by default.
___
Lede-dev mailing list
Lede-dev@lists.
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 a
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-P
UCI for stateful+stateless mode. This makes hosts easy targets for ping
and other testing (dns-dhcp). This allows Android devices to connect
because they won't do DHCPv6 (argh! Google!)
config dhcp 'lan'
option dhcpv4 'server'
option dhcpv6 'server'
option interface 'lan'
On 02/04/2017 05:42 AM, Eric Luehrsen wrote:
UCI for stateful+stateless mode. This makes hosts easy targets for ping
and other testing (dns-dhcp). This allows Android devices to connect
because they won't do DHCPv6 (argh! Google!)
config dhcp 'lan'
option dhcpv4 'server'
option d
Small mistake that is easily fixed. See pull request:
https://github.com/lede-project/source/pull/780
On 02/03/2017 10:21 AM, e9hack wrote:
> my dhcp config file looks like this:
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infrade
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
q
34 matches
Mail list logo
