[LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients

[Timo Sigurdsson]

Hi everybody,

I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE (r1952, 
Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for the
fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel or
ath10k driver will crash after a while. 5Ghz wifi will be dead after that
until I reboot the system.

This issue has been reported before [1] and it also has been declared as
solved with newer firmwares [2] (but reopened by other users). However, even
with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository the
issue is far from resolved. I have tried many different firmware revisions
over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can could
only find that the issue sometimes takes longer to trigger with some firmwares
(which might just be random), but it would always occur at some point with API
level 5 firmwares. With API level 2 firmwares (which I testesd when I was
still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had
other connectivity issues with these older firmwares that made this
combination no fun to use either. But this shows that the firmware itself
makes the difference here.

I actually have two Nexus 5X on my network (my wife's and my own). I can
trigger the crash with either one of them. And if both Nexus 5X are connected
to the 5Ghz radio, then the issue triggers much faster (can be as low as 15
minutes). My workaround is to let the Nexus 5X devices only connect to the
2.4GHz radio. This way, the device can runs for weeks without any issue or
crash, but of course I would prefer the actual bug being fixed rather than to
circumvent it.

I'm appending a syslog from my access point with a crash happening while one
Nexus 5X was connected to the 5GHz radio starting from the time the system
booted. I randomized the MAC addresses. but left the first two characters
unique so different clients can be distinguished.

If there is more info I could collect to help identify the cause of this
issue, please let me know (and possibly how to do that as well).

Thank you and regards,

Timo

[1] http://lists.infradead.org/pipermail/ath10k/2015-November/006413.html
[2] https://dev.openwrt.org/ticket/20854

And here's the log:
Fri Oct 28 02:01:35 2016 kern.notice kernel: [0.00] Linux version 
4.4.26 (user@buildsystem) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1952) ) #0 Fri 
Oct 21 15:52:28 2016
[...]
Fri Oct 28 02:01:35 2016 kern.info kernel: [9.468751] Loading modules 
backported from Linux version wt-2016-10-03-1-g6fcb1a6
Fri Oct 28 02:01:35 2016 kern.info kernel: [9.476481] Backport generated by 
backports.git backports-20160324-9-g0e38f5c
Fri Oct 28 02:01:35 2016 kern.warn kernel: [9.576570] PCI: Enabling device 
:01:00.0 ( -> 0002)
Fri Oct 28 02:01:35 2016 kern.info kernel: [9.582475] ath10k_pci 
:01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.087609] ath10k_pci 
:01:00.0: Direct firmware load for ath10k/pre-cal-pci-:01:00.0.bin 
failed with error -2
Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.098492] ath10k_pci 
:01:00.0: Falling back to user helper
Fri Oct 28 02:01:35 2016 kern.err kernel: [   10.176500] firmware 
ath10k!pre-cal-pci-:01:00.0.bin: firmware_loading_store: map pages failed
Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.677026] ath10k_pci 
:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub :
Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.686424] ath10k_pci 
:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.699498] ath10k_pci 
:01:00.0: firmware ver 10.2.4.70.58 api 5 features no-p2p,raw-mode,mfp 
crc32 e1af076f
Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.709932] ath10k_pci 
:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed 
with error -2
Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.720531] ath10k_pci 
:01:00.0: Falling back to user helper
Fri Oct 28 02:01:35 2016 kern.err kernel: [   10.798719] firmware 
ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.823845] ath10k_pci 
:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
Fri Oct 28 02:01:35 2016 kern.info kernel: [   11.954723] ath10k_pci 
:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 
1
[...]
// Evertyhing runs fine for a bit more than a day, but then this happens ... //
// Note: The ath10k radio in question is wlan0 //
Sat Oct 29 10:38:21 2016 daemon.info hostapd: wlan1: STA 9c:12:34:56:78:9a IEEE 
802.11: disassociated
Sat Oct 29 10:38:22 2016 daemon.info hostapd: wlan1: STA 9c:12:34:56:78:9a IEEE 
802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sat Oct 29 10:42:57 2016 daemon.info hostapd: wlan1: STA 00:12:34:56:78:9a WPA: 
group key handshake 

Re: [LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube

[Christian Lamparter]

On Saturday, October 29, 2016 8:44:27 PM CEST Christian Lamparter wrote:
> [...] 
> [7.849577] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in 
> Host mode
> [7.855582] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in 
> Host mode
> [7.862820] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in 
> Host mode
> [8.051083] usb 1-1: new high-speed USB device number 2 using dwc2
> [8.055952] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in 
> Host mode
> [8.063064] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in 
> Host mode
>
> Now, there has been recent changes to dwc2 which might fix these pesky
> errors. The discussion can be found on the LKML [3] and three patches
> were committed to 4.9-rc.
> 
> usb: dwc2: Properly account for the force mode delays [4]
> usb: dwc2: Add delay to core soft reset [5]
> usb: dwc2: gadget: Only initialize device if in device mode [6]
> 
> I'll give then a try and see test if they help. Otherwise:

Not much. There are now just four "Mode Mismatch Interrupt" instead of five.

I did a short 400MiB read speed test from a fast usb stick.
The dwc2 driver (with the param_ltq values) is faster than 
ifxhcd.

ifxhcd:
real 0m 23.26s
user 0m 0.01s
sys 0m 15.18s

dwc2:
real 0m 16.31s
user 0m 0.00s
sys 0m 8.38s

Regards,
Christian
 
> [4] 
> 
> [5] 
> 
> [6] 
> 

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

Re: [LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube

[Christian Lamparter]

On Friday, October 28, 2016 11:22:12 PM CEST Ben Mulvihill wrote:
> On Fri, 2016-10-28 at 18:28 +0200, Christian Lamparter wrote:
> > Hello,
> > 
> > On Friday, October 28, 2016 4:30:56 PM CEST Ben Mulvihill wrote:
> > > Add device tree binding for dwc2 usb driver on lantiq danube
> > > 
> > > Signed-off-by: Ben Mulvihill 
> > > ---
> > > diff -uprN a/target/linux/lantiq/dts/danube.dtsi 
> > > b/target/linux/lantiq/dts/danube.dtsi
> > > --- a/target/linux/lantiq/dts/danube.dtsi 2016-10-27 19:56:07.090392399 
> > > +0200
> > > +++ b/target/linux/lantiq/dts/danube.dtsi 2016-10-27 20:47:34.387511522 
> > > +0200
> > > @@ -140,7 +140,7 @@
> > >   };
> > >  
> > >   ifxhcd@E101000 {
> > > - compatible = "lantiq,ifxhcd-danube";
> > > + compatible = "lantiq,ifxhcd-danube", 
> > > "lantiq,ifxhcd-danube-dwc2";
> > Usually for device tree, the first compatible string is reserved for the
> > "exact device" that the node represents [0]. So wouldn't switching around
> > the strings (i.e.: "lantiq,ifxhcd-danube-dwc2", "lantiq,ifxhcd-danube")
> > make more sense? After all, the dwc2 is the "more exact device" in this 
> > case?
> > 
> 
> Thanks for reviewing.
> 
> Are they not equally "exact"? They are two alternative, and completely
> separate, drivers. (The names chosen for the bindings are perhaps a
> little misleading in that regard.) I Left "lantiq,ifxhcd-danube" in 
> first position simply because it has been the default driver until 
> now, and I didn't want to change the default at this stage. Not that
> it will make any difference to which driver is actually used unless
> for some strange reason someone decides to include both drivers in
> the same build.
> 
> Once we're sure that dwc2 works properly on danube, the old 
> ifxhcd-danube driver can be ditched from the source tree completely.
> But I thought it was better to get an ack from John on
> these first.

Ok, Thanks, I guess this should work fine if you follow through with 
phasing out the old driver too (Yay for that!). The 
"lantiq,ifxhcd-danube" will take preference as it is the first entry,
but that's fine.

I tested the patch on my EasyBox 802 (Arcadyan ARV752DPW).

[6.291426] dwc2 1e101000.ifxhcd: requested GPIO 464
[6.294998] dwc2 1e101000.ifxhcd: Configuration mismatch. Forcing host mode
^^

This can be fixed by setting dr_mode to host in the DTS.

---
diff --git a/target/linux/lantiq/dts/danube.dtsi 
b/target/linux/lantiq/dts/danube.dtsi
index 009696a..538ec19 100644
--- a/target/linux/lantiq/dts/danube.dtsi
+++ b/target/linux/lantiq/dts/danube.dtsi
@@ -146,6 +146,7 @@
interrupt-parent = <>;
interrupts = <62>;
status = "disabled";
+   dr_mode = "host";
};
 
deu@E103100 {
---

The generic dwc2 defaults to OTG mode (as per generic.txt) [0].
(Well, technically, it's UNKNOWN at first but here's the logic [1]).

[7.159262] dwc2 1e101000.ifxhcd: DWC OTG Controller
[7.162832] dwc2 1e101000.ifxhcd: new USB bus registered, assigned bus 
number 1
[7.169959] dwc2 1e101000.ifxhcd: irq 62, io mem 0x
[7.177488] hub 1-0:1.0: USB hub found
[7.180650] hub 1-0:1.0: 1 port detected
[7.196214] init: - preinit -

[7.849577] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in Host 
mode
[7.855582] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in Host 
mode
[7.862820] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in Host 
mode
[8.051083] usb 1-1: new high-speed USB device number 2 using dwc2
[8.055952] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in Host 
mode
[8.063064] dwc2 1e101000.ifxhcd: Mode Mismatch Interrupt: currently in Host 
mode

I don't think these are much of an issue. At least for this device the ifxhcd 
driver
also produces the same messages. For example, this is an extract bootlog from 
the
opernwrt wiki [2].

| [6.98] IFXUSB: ifxusb_hcd: version 3.2 B110801
| [7.484000] IFXUSB: USB core #0 soft-reset
| [7.688000] IFXUSB: USB core #0 soft-reset
| [7.692000] ifxusb_hcd ifxusb_hcd: IFX USB Controller
| [7.696000] ifxusb_hcd ifxusb_hcd: new USB bus registered, assigned bus 
number 1
| [7.704000] ifxusb_hcd ifxusb_hcd: irq 62, io mem 0xbe101000
| [7.712000] IFXUSB: Mode Mismatch Interrupt: currently in Host mode
| [7.716000] IFXUSB: Mode Mismatch Interrupt: currently in Host mode
 
Now, there has been recent changes to dwc2 which might fix these pesky
errors. The discussion can be found on the LKML [3] and three patches
were committed to 4.9-rc.

usb: dwc2: Properly account for the force mode delays [4]
usb: dwc2: Add delay to core soft reset [5]
usb: dwc2: gadget: Only initialize device if in device mode [6]

I'll give then a try and see test if they help. Otherwise:

Tested-by: Christian Lamparter 

[LEDE-DEV] lots of broken packages

[Torbjorn Jansson]

Hello

looks like there are lots of broken packages currently.
was going to install i2c-tools but it looks like it failed with lots of 
messages like:


include/linux/i2c-dev.h:156:21: warning: inlining failed in call to 
'i2c_smbus_access': call is unlikely and code size would grow [-Winline]
 static inline __s32 i2c_smbus_access(int file, char read_write, __u8 
command,


is this a case of problem already known and i just have to wait a bit 
and it will get fixed by itself?


i'm currently testing something and i need i2c tools.
then later i probably need to read up how the building of primarily the 
kernel is done so i can add a few missing kernel modules.


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

Re: [LEDE-DEV] buildroot broken on debian jessie

[Dirk]

Hi Alex,

you're right, but I'm using testing of course and the right codename is
"stretch"

root@blackserve:~# uname -a
Linux blackserve 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19)
x86_64 GNU/Linux

root@blackserve:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (stretch)
Release:testing
Codename:   stretch

root@blackserve:~# gcc --version
gcc (Debian 6.2.0-9) 6.2.0 20161019

br
dirk

Am Samstag, den 29.10.2016, 16:43 +0200 schrieb Alexander Dahl:
> Hei hei,
> 
> On 29.10.2016 11:00, Dirk wrote:
> > I'm using debian testing/jessie as host - see output below.
> 
> How? Jessie is stable since 2015, current testing is stretch. o.O
> 
> Greets
> Alex
> 
> 
> ___
> 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 3/3] lantiq: add device tree binding for dwc2 on danube

[Ben Mulvihill]

On Sat, 2016-10-29 at 13:28 +0200, Ben Mulvihill wrote:
> On Fri, 2016-10-28 at 23:35 +0200, Ben Mulvihill wrote:
> > On Fri, 2016-10-28 at 19:14 +0300, Antti Seppälä wrote:
> > > On 28 October 2016 at 17:30, Ben Mulvihill  
> > > wrote:
> > > > Add device tree binding for dwc2 usb driver on lantiq danube
> > > >
> > > > Signed-off-by: Ben Mulvihill 
> > > > ---
> > > > diff -uprN a/target/linux/lantiq/dts/danube.dtsi 
> > > > b/target/linux/lantiq/dts/danube.dtsi
> > > > --- a/target/linux/lantiq/dts/danube.dtsi   2016-10-27 
> > > > 19:56:07.090392399 +0200
> > > > +++ b/target/linux/lantiq/dts/danube.dtsi   2016-10-27 
> > > > 20:47:34.387511522 +0200
> > > > @@ -140,7 +140,7 @@
> > > > };
> > > >
> > > > ifxhcd@E101000 {
> > > > -   compatible = "lantiq,ifxhcd-danube";
> > > > +   compatible = "lantiq,ifxhcd-danube", 
> > > > "lantiq,ifxhcd-danube-dwc2";
> > > > reg = <0xE101000 0x1000
> > > > 0xE12 0x3f000>;
> > > > interrupt-parent = <>;
> > > >
> > > >
> > > 
> > > Hi.
> > > 
> > > Have you tried if danube can simply be compatible with vanilla 
> > > "snps,dwc2"?
> > > 
> > > The main reason we created our own definition for lantiq is that arx
> > > and xrx have fifo sizes smaller than what the dwc2 autodetection
> > > mechanism expects.
> > > I remember finding some references in ifxhcd code which would suggest
> > > that danube had bigger fifo and thus would maybe work without any
> > > special treatment.
> > > 
> > > Br,
> > 
> > I'm pretty sure I tried it, but must have been a couple of years
> > ago and I can't remember why it didn't work. I'll have another go.
> > 
> > Thanks for the suggestion,
> > 
> > Ben 
> 
> You are right. It works fine with "snps,dwc2". (Apart from the same
> mode mismatch warnings) When I tried that before I didn't have the
> benefit of your hardware initialisation code and my own version
> must have been wrong.
> 
> I'll submit a version 2 patch set.
> 
> Ben

No, sorry. I was testing the wrong build. I'm afraid "snps,dwc2" doesn't
work after all. It tries to autodetect the parameters, doesn't log any
errors, but then doesn't recognise devices which are plugged in, 
so presumably the parameter values it thinks it has detected are
not correct.

What do you think would be the best thing to do, stick with my original
patch set using the same parameters as for arx and vrx, which appear
to work fine, or investigate the ifxhcd code and add a separate 
dwc2_core_params structure called params_danube with (possibly) bigger
fifos? I'd prefer the former for simplicity's sake.

Thanks again,

Ben





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

Re: [LEDE-DEV] buildroot broken on debian jessie

[Alexander Dahl]

Hei hei,

On 29.10.2016 11:00, Dirk wrote:
> I'm using debian testing/jessie as host - see output below.

How? Jessie is stable since 2015, current testing is stretch. o.O

Greets
Alex




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

Re: [LEDE-DEV] Stability & release plans

[Jo-Philipp Wich]

Hi

> 2. When looking at lede I'm somewhat missing the release engineering 
> part. This has nothing to do with infrastructure or build setups or
> even coding. When looking at Debian they have a release team taking
> care of freezing, planning and releases. - or take Theo de Raadt's
> job in OpenBSD for instance.

We have to start somewhere, and having the technical base available to
actually build releases is a good first step.

I agree that eventually there needs to be a release engineering team but
it makes no sense to have that in place when nobody is actually able to
build releases. Also code freezes or branches make less sense when no
one is able to produce suitable, updated binary artifacts - that is the
main reason why we try to solve the technical hurdles first.

> IMHO From a release engineering point of view it's good to do release
> if a software is reasonable better then the one released before. From
> a developer's point of view, it's good to release, if he or she feels
> confident with his or her work and all annoying bugs are fixed.

Yes.

> IMHO planning a lede release is worth the effort if it's reasonable 
> better then the last OpenWRT-Release, no matter what bugs,
> refactorings or infrastructure issue are outstanding, still. Having a
> fixed schedule (every 6/8/12 months) or so will ease discussion on
> when to release and what features to include, since freeze-dates,
> commit-handling etc. are more or less fixed.

Yes.

> IMHO it is an interesting idea to announce a release in six months or
> so (one year after its founding :-) ), make a plan on freezing /
> branching / etc. and stick to fixed schedule (every n months)

I will feel much more confident about this once we actually did a
release test (means a test on how to build a binary release, not a
release for testing binaries) - then we can start planning schedules.

In the past, building OpenWrt binary releases was a painful, manual and
time consuming task which took between 4 to 8 weeks to pull of.

> I offered help on this to nbd on 2012's (2013 .. maybe) Wireless 
> Community Week and my offer is still stands. Not being a OpenWRT /
> lede veteran  I'm not interesting in taking the lead here. I'm not
> interested in bossing somebody around of becoming a ego-manic project
> lead ..,. Back in 2012, there was hardly any interest in this kind of
> help, but I'm not sure, if the lede split has changed anything here.

Help is pretty much appreciated in, any direction :)

> 3. I think, gluon is doing an good job here. They're taking the
> OpenWRT / lede codebase and release it in a concise way.
> Unfortunately - due to releasing no binary artifacts - they address
> power-users instead of novices. And gluon - in its current form - can
> hardly be used to just flash and use a SOHO router for whatever is
> interesting.

I cannot tell much about Gluon, I never used it myself but I did notice
that it has a rather continuous and solid development model. Also with
Matthias on board I am confident that some experience can be shared here
in the long run.

> I don't know much about tcatm's plans for gluon. I don't know, if
> binary releases are on its map or if synchronizing gluon and lede
> releases is a good idea. But ... IMHO it's worth thinking about
> this.

Sure, it might make sense to leverage synergies here (sorry for the BS
phrase) but for example I think that Gluon has a good testing exposure
and valuable community feedback which are things LEDE can certainly
benefit from.

> That's it. I'll be at the 33c3 by the end of the year, so if you're
> interested discussing this in person, I'm available ;-).

I'm sure some people will attend the 33c3 - for the rest we can maybe
stage a video conference or something to exchange ideas. Personally I'll
likely not able to be there but I would appreciate some discussions
nonetheless.


Regards,
Jo

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

Re: [LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube

[Ben Mulvihill]

On Fri, 2016-10-28 at 23:35 +0200, Ben Mulvihill wrote:
> On Fri, 2016-10-28 at 19:14 +0300, Antti Seppälä wrote:
> > On 28 October 2016 at 17:30, Ben Mulvihill  wrote:
> > > Add device tree binding for dwc2 usb driver on lantiq danube
> > >
> > > Signed-off-by: Ben Mulvihill 
> > > ---
> > > diff -uprN a/target/linux/lantiq/dts/danube.dtsi 
> > > b/target/linux/lantiq/dts/danube.dtsi
> > > --- a/target/linux/lantiq/dts/danube.dtsi   2016-10-27 
> > > 19:56:07.090392399 +0200
> > > +++ b/target/linux/lantiq/dts/danube.dtsi   2016-10-27 
> > > 20:47:34.387511522 +0200
> > > @@ -140,7 +140,7 @@
> > > };
> > >
> > > ifxhcd@E101000 {
> > > -   compatible = "lantiq,ifxhcd-danube";
> > > +   compatible = "lantiq,ifxhcd-danube", 
> > > "lantiq,ifxhcd-danube-dwc2";
> > > reg = <0xE101000 0x1000
> > > 0xE12 0x3f000>;
> > > interrupt-parent = <>;
> > >
> > >
> > 
> > Hi.
> > 
> > Have you tried if danube can simply be compatible with vanilla "snps,dwc2"?
> > 
> > The main reason we created our own definition for lantiq is that arx
> > and xrx have fifo sizes smaller than what the dwc2 autodetection
> > mechanism expects.
> > I remember finding some references in ifxhcd code which would suggest
> > that danube had bigger fifo and thus would maybe work without any
> > special treatment.
> > 
> > Br,
> 
> I'm pretty sure I tried it, but must have been a couple of years
> ago and I can't remember why it didn't work. I'll have another go.
> 
> Thanks for the suggestion,
> 
> Ben 

You are right. It works fine with "snps,dwc2". (Apart from the same
mode mismatch warnings) When I tried that before I didn't have the
benefit of your hardware initialisation code and my own version
must have been wrong.

I'll submit a version 2 patch set.

Ben





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

Re: [LEDE-DEV] o2 box 6431 / VGV7510KW22 - SIP with FXS/TAE Ports | owsip or alternative ?

[Eddi De Pieri]

As already said... in lede is missing the patch I've added to bb to support vmmc

On Fri, Oct 28, 2016 at 11:24 PM, Eddi De Pieri  wrote:
> Give a look at
> https://github.com/pgid69/bcm63xx-phone/tree/master/bcm63xx-ast-chan
>
> they have the same source for both 1.8 1.11 and 1.13, it seems that it
> does change just the makefile... maybe it can be applied to lantiq
> asterisk-tapi
>
> Regards
>
> On Mon, Oct 3, 2016 at 1:56 AM, Hauke Mehrtens  wrote:
>> On 09/23/2016 09:02 PM, Daniel Golle wrote:
>>> On Fri, Sep 23, 2016 at 08:14:24PM +0200, Dennis Schneck wrote:



 Hello,
 i use the o2 box 6431 / VGV7510KW22 with LEDE r1640.
 Like to use my SIP Accout with the 3x FXS Ports (Analog Phone / TAE Ports)

 I read about owsip but can not find a package.
 Is there a simular package for lede ?
>>>
>>> No. owsip disappeared a while ago, asterisk-chan-lantiq was dropped
>>> with asterisk-1.8.x being moved to packages-abandoned, but it may
>>> possible to still build it. If you want to give asterisk-1.8.x with
>>> chan-lantiq a shot, I'd be happy to assist and maybe even forward-
>>> port things to asterisk-13.x -- on this box having plenty of RAM
>>> and flash, this might actually be a quite nice option.
>>
>> Hi Daniel,
>>
>> I looked into it and was unable to find any documentation on how to
>> write a asterisk channel driver. Do you know some documentation or
>> should I look into the code of the other channel drivers? My plan was to
>> port the lantiq channel driver to asterisk 1.13.x.
>>
>> Hauke
>>
>>
>> ___
>> 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] Stability & release plans -- CVE-2016-5195

[Alberto Bursi]

On 10/29/2016 03:18 AM, J Mo wrote:
>
> On 10/28/2016 11:39 AM, yanosz wrote:
>> 1. I'm unhappy with the state of OpenWRT at the moment. I see some
>> trouble in building and releasing. The current code base has some bugs.
>> I'ven't seen a fix for "mad cow" yet. For me it is hard to estimate
>> whether OpenWRT is able to include, build and release critical patches
>> over the next months in a timely fashion.
>
> My impression is that CVE-2016-5195 (also known by it's marketing name
> for low-intellect individuals as "dirty COW") is mostly a non-issue on
> OpenWRT/LEDE. This is why you have not heard much about a response for it.
>
> The exploit is a privilege escalation. However, almost everything on a
> standard LEDE/OpenWRT system already runs as root anyway, since these
> kinds of systems are not designed for multi-user scenarios.
>

Uhm, I think you are wrong.
In OpenWRT/LEDE applications that don't need root access are run as 
unprivileged users for security reasons, so yes, a privilege escalation 
is BAD also for OpenWRT/LEDE.

root@lede:/# cat /etc/passwd
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false

And for LEDE the answer to the vulnerability was "finish the porting to 
latest kernel 4.4 for all devices ASAP as that kernel is a LTS kernel so 
it received the fix upstream, and apply patches to other kernels", see 
these mailing list posts:
http://lists.infradead.org/pipermail/lede-dev/2016-October/003579.html
http://lists.infradead.org/pipermail/lede-dev/2016-October/003580.html

So current LEDE is already protected, I don't know if this stuff also 
ends in OpenWRT.

-Alberto

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

Re: [LEDE-DEV] Stability & release plans -- CVE-2016-5195

[yanosz]

Hello,

Am 10/29/2016 um 03:18 AM schrieb J Mo:
> 
> On 10/28/2016 11:39 AM, yanosz wrote:
>> 1. I'm unhappy with the state of OpenWRT at the moment. I see some
>> trouble in building and releasing. The current code base has some bugs.
>> I'ven't seen a fix for "mad cow" yet. For me it is hard to estimate
>> whether OpenWRT is able to include, build and release critical patches
>> over the next months in a timely fashion.
> 
> My impression is that CVE-2016-5195 (also known by it's marketing name
> for low-intellect individuals as "dirty COW") is mostly a non-issue on
> OpenWRT/LEDE. This is why you have not heard much about a response for it.
> 
> The exploit is a privilege escalation. However, almost everything on a
> standard LEDE/OpenWRT system already runs as root anyway, since these
> kinds of systems are not designed for multi-user scenarios.

Depends :-).
OpenWRT has a big package repository, offering dozens applications. I
guess, that you're right for about > 80% of all OpenWRT users, but there
are others. As far as I'm aware of, discussions on CVE-2016-5195 are
taking place  https://forum.openwrt.org/viewtopic.php?id=68181 so some
people do care - some discussions are happening on openwrt-dev, too.

However, I'm neither interested in discussing the impact of a local root
exploit, nor the urgency for this kind of fix.

I'm trying to estimate the liveliness and its future impact for OpenWRT.
Take
https://lists.openwrt.org/pipermail/openwrt-devel/2016-July/041987.html
for instance.
Please don't get me wrong: I'm not saying that OpenWRT is unable to do
releases, but "KanjiMonster" statements, make me worry about the shape
of OpenWRT-Setup when something bigger happens.

Greetz, yanosz

-- 
For those of you without hope, we have rooms with color TV,
cable and air conditioning

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

Re: [LEDE-DEV] buildroot broken on debian jessie

[Jo-Philipp Wich]

Hi Dirk,

please try the following patch:
http://git.lede-project.org/3bc496c

~ Jo

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

Re: [LEDE-DEV] [RFC v2 3/3] config: ext4: increase x86 rootfs size to 2GB to support online resize2fs

[Felix Fietkau]

On 2016-10-25 13:02, Jo-Philipp Wich wrote:
> The current default rootfs size of 256MB in conjunction with 4K blocks
> produces an ext4 filesystem which lacks the appropriate amount of backup GDT
> entries to support online-resizing.
> 
> For x86 targets, increase the default rootfs size to 2048MB which allows
> online resizing the filesystem to up to 2TB which is the current theoretical
> maximum for LEDE, due to missing GPT support on the root block device.
> 
> Note that the filesystem artefact will not occupy 2GB on the build system as
> the make_ext4fs utility uses sparse files to generate the filesystem images,
> so the actual disk usage is much lower. Furthermore the filesystem images
> are gzip compressed, shrinking them to only a few megabytes on the download
> server.
> 
> Signed-off-by: Jo-Philipp Wich 
I think 2 GB is excessive. Due to the way that sysupgrade works, having
such a large rootfs partition is often not very useful anyway, since
everything except for config files gets lost.
It significantly increases build time and the amount of time it takes to
transfer an image to a flash medium.

In my opinion it's much more useful to keep the rootfs small and add a
data partition covering the rest of the medium, which then gets
preserved across upgrades.

- Felix

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

[LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.28

[p . wassi]

From: Paul Wassi 

Refresh patches for all targets that support kernel 4.4.
compile/run-tested on ar71xx, brcm47xx, kirkwood.

Signed-off-by: Paul Wassi 
---
 include/kernel-version.mk  
  |4 +-
 
target/linux/brcm2708/patches-4.4/0348-mmc-Add-MMC_QUIRK_ERASE_BROKEN-for-some-cards.patch
   |2 -
 
target/linux/brcm2708/patches-4.4/0350-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch
|2 -
 
target/linux/brcm2708/patches-4.4/0352-mmc-Add-card_quirks-module-parameter-log-quirks.patch
 |6 +--
 
target/linux/brcm2708/patches-4.4/0413-mmc-Apply-ERASE_BROKEN-quirks-correctly.patch
 |2 -
 
target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
 |   18 +-
 target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch 
  |2 -
 target/linux/generic/patches-4.4/902-debloat_proc.patch
  |2 -
 8 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -4,11 +4,11 @@ LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .43
 LINUX_VERSION-4.1 = .34
-LINUX_VERSION-4.4 = .27
+LINUX_VERSION-4.4 = .28
 
 LINUX_KERNEL_MD5SUM-3.18.43 = b1faeb4a2e1e70ffe061bdbb3452840a
 LINUX_KERNEL_MD5SUM-4.1.34 = fba99f0f4765ebf01033e69518740a3c
-LINUX_KERNEL_MD5SUM-4.4.27 = 
6c437dd8f9e964c843211cf99a876b42724fe9f2013241c13e14b6ce17846afd
+LINUX_KERNEL_MD5SUM-4.4.28 = 
841acb9109a893ab2f60b02355e1527e80fa09251e46339317f6984d69b1f4fc
 
 ifdef KERNEL_PATCHVER
   LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git 
a/target/linux/brcm2708/patches-4.4/0348-mmc-Add-MMC_QUIRK_ERASE_BROKEN-for-some-cards.patch
 
b/target/linux/brcm2708/patches-4.4/0348-mmc-Add-MMC_QUIRK_ERASE_BROKEN-for-some-cards.patch
--- 
a/target/linux/brcm2708/patches-4.4/0348-mmc-Add-MMC_QUIRK_ERASE_BROKEN-for-some-cards.patch
+++ 
b/target/linux/brcm2708/patches-4.4/0348-mmc-Add-MMC_QUIRK_ERASE_BROKEN-for-some-cards.patch
@@ -16,7 +16,7 @@ Signed-off-by: Phil Elwell 
 
 --- a/drivers/mmc/card/block.c
 +++ b/drivers/mmc/card/block.c
-@@ -2552,6 +2552,13 @@ static const struct mmc_fixup blk_fixups
+@@ -2553,6 +2553,13 @@ static const struct mmc_fixup blk_fixups
MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
  MMC_QUIRK_TRIM_BROKEN),
  
diff --git 
a/target/linux/brcm2708/patches-4.4/0350-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch
 
b/target/linux/brcm2708/patches-4.4/0350-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch
--- 
a/target/linux/brcm2708/patches-4.4/0350-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch
+++ 
b/target/linux/brcm2708/patches-4.4/0350-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch
@@ -10,7 +10,7 @@ Signed-off-by: Phil Elwell 
 
 --- a/drivers/mmc/card/block.c
 +++ b/drivers/mmc/card/block.c
-@@ -2558,6 +2558,10 @@ static const struct mmc_fixup blk_fixups
+@@ -2559,6 +2559,10 @@ static const struct mmc_fixup blk_fixups
 */
MMC_FIXUP("SD16G", 0x41, 0x3432, add_quirk_mmc,
  MMC_QUIRK_ERASE_BROKEN),
diff --git 
a/target/linux/brcm2708/patches-4.4/0352-mmc-Add-card_quirks-module-parameter-log-quirks.patch
 
b/target/linux/brcm2708/patches-4.4/0352-mmc-Add-card_quirks-module-parameter-log-quirks.patch
--- 
a/target/linux/brcm2708/patches-4.4/0352-mmc-Add-card_quirks-module-parameter-log-quirks.patch
+++ 
b/target/linux/brcm2708/patches-4.4/0352-mmc-Add-card_quirks-module-parameter-log-quirks.patch
@@ -31,7 +31,7 @@ Signed-off-by: Phil Elwell 
  static inline int mmc_blk_part_switch(struct mmc_card *card,
  struct mmc_blk_data *md);
  static int get_card_status(struct mmc_card *card, u32 *status, int retries);
-@@ -2570,6 +2577,7 @@ static int mmc_blk_probe(struct mmc_card
+@@ -2571,6 +2578,7 @@ static int mmc_blk_probe(struct mmc_card
  {
struct mmc_blk_data *md, *part_md;
char cap_str[10];
@@ -39,7 +39,7 @@ Signed-off-by: Phil Elwell 
  
/*
 * Check that the card supports the command class(es) we need.
-@@ -2577,7 +2585,16 @@ static int mmc_blk_probe(struct mmc_card
+@@ -2578,7 +2586,16 @@ static int mmc_blk_probe(struct mmc_card
if (!(card->csd.cmdclass & CCC_BLOCK_READ))
return -ENODEV;
  
@@ -57,7 +57,7 @@ Signed-off-by: Phil Elwell 
  
md = mmc_blk_alloc(card);
if (IS_ERR(md))
-@@ -2585,9 +2602,14 @@ static int mmc_blk_probe(struct mmc_card
+@@ -2586,9 +2603,14 @@ static int mmc_blk_probe(struct mmc_card
  
string_get_size((u64)get_capacity(md->disk), 512, 

Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network

[p . wassi]

> Have you tested your patch on these mvebu devices? or just in theory?

I've successfully tested on WRT1200AC, which is affected by this patch.
(I.e. eth0 and eth1 are swapped then)
That's the only mvebu device I have here right now.

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

Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network

[Syrone Wong]

Have you tested your patch on these mvebu devices? or just in theory?


Best Regards,
Syrone Wong


On Sat, Oct 29, 2016 at 2:50 PM,   wrote:
>> According to https://wiki.openwrt.org/toh/linksys/wrt_ac_series, they
>> have different switch layouts, especially mamba(WRT1900ac v1).
>
> No, they do not - all three switches (=all five devices) have this layout:
>
> Switch Port | Function / External Port
>   0 | LAN 4
>   1 | LAN 3
>   2 | LAN 2
>   3 | LAN 1
>   4 | WAN
>   5 | eth0
>   6 | eth1
>
> The assignment of the ports to a specific VLAN is done arbitraryly.
> And what you found on the wiki is this artificial complication of things,
> which I want to address with my patch. Do you agree?
>
> Best regards,
> P. Wassi

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

Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network

[p . wassi]

> According to https://wiki.openwrt.org/toh/linksys/wrt_ac_series, they
> have different switch layouts, especially mamba(WRT1900ac v1).

No, they do not - all three switches (=all five devices) have this layout:

Switch Port | Function / External Port
  0 | LAN 4
  1 | LAN 3
  2 | LAN 2
  3 | LAN 1
  4 | WAN
  5 | eth0
  6 | eth1

The assignment of the ports to a specific VLAN is done arbitraryly.
And what you found on the wiki is this artificial complication of things,
which I want to address with my patch. Do you agree?

Best regards,
P. Wassi

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