Re: [OpenWrt-Devel] CC release dates? (Was Re: [PATCH 1/2] oxnas: re-add support for kernel 3.14)

i intentionally don't set a date. i have done so in the past and got ranted at for not being on time. this happened with AA and BB so CC is illusive and will be ready when ready. all i will say is that i am already working on it, but you noticed that yourself :) On 05/12/2014 02:20, Karl P wrote:

Re: [OpenWrt-Devel] Need guidance to modify default vanilla OpenWRT settings

add a file in /etc/uci-defaults/ these get called on firstboot and are deleted after being run to add the file you need to make a package or you simply place the script in the files/ folder of your checkout John On 05/12/2014 08:16, Nguyen Nam wrote: > Hi list, > > I posted request o

Re: [OpenWrt-Devel] CC release dates? (Was Re: [PATCH 1/2] oxnas: re-add support for kernel 3.14)

Hi, do I understand it correctly. For CC is 3.14 planed? Thanks, Claudio -- Reviewing OpenWrt BB for Xmodus Systems XM1710E GSM/UMTS Router On 05.12.2014 09:07, John Crispin wrote: > i intentionally don't set a date. i have done so in the p

Re: [OpenWrt-Devel] CC release dates? (Was Re: [PATCH 1/2] oxnas: re-add support for kernel 3.14)

yes, 3.14 is baseline for CC On 05/12/2014 09:45, Claudio Thomas wrote: > Hi, do I understand it correctly. For CC is 3.14 planed? Thanks, > Claudio > > -- Reviewing OpenWrt BB for Xmodus Systems XM1710E GSM/UMTS Router > > > On 05.12.2

Re: [OpenWrt-Devel] [PATCH 1/3] ag71xx: replace fixed PHY reset wait time in ar7240sw_setup

Hi, just added this to my local tree, images are building, the ar71xx network stuff scares me and i want to test this for a few b On 05/12/2014 07:36, Heiner Kallweit wrote: > Replace the fixed wait time of 1s with polling for BMCR_RESET > to be cleared on all PHYs. > > Signed-off-by: Heiner Kal

Re: [OpenWrt-Devel] [PATCH 1/3] ag71xx: replace fixed PHY reset wait time in ar7240sw_setup

(i got attacked by the cat :) and she did manage to hit the "send" button before i finished typing) Hi, just added this to my local tree, images are building, the ar71xx network stuff scares me and i want to test this for a few boards before pushing. i might not manage to do so today Joh

Re: [OpenWrt-Devel] [PATCH 1/1] [kernel] ar71xx: reset problem fix

Hello guys, I got no response here in this mailing list to my last e-mail regarding to the reset patch. The problem is still active and it also concerns the trunk version. Please also see the corresponding ticket: https://dev.openwrt.org/ticket/17839 The patch which I used for BB is also availab

[OpenWrt-Devel] QA for upcoming(?) CC?

since i see muttering about an imminent CC, what is the plan for QA to make sure all packages download and build correctly, since some of them don't at the moment. my assumption when i want to build for a new board is that i can check out trunk, and i can use the appropriate default config fi

Re: [OpenWrt-Devel] ar934x+ar8327v4

This sounds very like the bug #18401 I have raised for my RB2011UiAS-2HnD-IN. I have exactly the same problem of everything appearing to be detected OK and interfaces OK but eth0 simply doesn't do anything. I can try patches etc. if/when necessary. On Thu, Dec 04, 2014 at 10:13:52PM -0700, David

Re: [OpenWrt-Devel] ar934x+ar8327v4

On Fri, Dec 05, 2014 at 07:57:35AM +0100, Heiner Kallweit wrote: > Am 05.12.2014 um 06:13 schrieb David Hutchison: > > Hi, > > > > I ran into an issue with the Mikrotik Routerboard 951G's switch chip. > > The new batch that we received use an updated ar8327 switch chip. The > > switch chip would n

Re: [OpenWrt-Devel] [PATCH 1/3] ag71xx: replace fixed PHY reset wait time in ar7240sw_setup

On Fri, Dec 5, 2014 at 9:57 AM, John Crispin wrote: > Hi, > > just added this to my local tree, images are building, the ar71xx > network stuff scares me and i want to test this for a few boards > before pushing. i might not manage to do so today Sure, take your time. A similar phy poll change was

[OpenWrt-Devel] [PATCH] netifd: Pass source address to proto_add_ipv4_route

From: Kristian Evensen Enable callers to pass the source IP of an IPv4 route when using proto_add_ipv4_route(). This is useful with for example DHCP in a multihomed scenario, as it provides an easy way to match default routes with the correct IP address. One use case for this are applications tha

[OpenWrt-Devel] [PATCH] netifd: Set source IP for DHCP default route

From: Kristian Evensen This patch depends on "Pass source address to proto_add_ipv4_route". I have not found a scenario that would break by setting the source address on default, but please let me know if any special considerations should be taken. Signed-off-by: Kristian Evensen --- package/

Re: [OpenWrt-Devel] ar934x+ar8327v4

its your lucky day, according to the DHL website my RB2011UiAS-2HnD-IN will arrive in the next 2-3 hours :) On 05/12/2014 10:21, Chris Green wrote: > This sounds very like the bug #18401 I have raised for my > RB2011UiAS-2HnD-IN. > > I have exactly the same problem of everything appearing to be

Re: [OpenWrt-Devel] ar934x+ar8327v4

On Fri, Dec 5, 2014 at 10:21 AM, Chris Green wrote: > This sounds very like the bug #18401 I have raised for my > RB2011UiAS-2HnD-IN. > > I have exactly the same problem of everything appearing to be detected > OK and interfaces OK but eth0 simply doesn't do anything. Ticket 18401 relates to BB 14

Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)

On 17 November 2014 at 18:42, Sebastian Moeller wrote: > Hi Richard, hi Jaime > After changing the pop values have a look at the output of “ps w” on > the router, when I tried to p;ay with these from the luci GUI I noticed that > pppd was called with lcp-echo-failure 5 while the GUI repo

Re: [OpenWrt-Devel] QA for upcoming(?) CC?

Hi. > in any event, if the idea of an official release is that it should > build out of the box, there are clearly a number of (albeit easily > fixable) download and build issues to clean up. is it part of > pre-release QA to make sure all of these issues are resolved? Such issues are usually n

Re: [OpenWrt-Devel] ar934x+ar8327v4

On Fri, Dec 05, 2014 at 10:59:11AM +0100, Heiner Kallweit wrote: > On Fri, Dec 5, 2014 at 10:21 AM, Chris Green wrote: > > This sounds very like the bug #18401 I have raised for my > > RB2011UiAS-2HnD-IN. > > > > I have exactly the same problem of everything appearing to be detected > > OK and int

Re: [OpenWrt-Devel] QA for upcoming(?) CC?

On 05/12/2014 11:19, Jo-Philipp Wich wrote: > Hi. > >> in any event, if the idea of an official release is that it >> should build out of the box, there are clearly a number of >> (albeit easily fixable) download and build issues to clean up. is >> it part of pre-release QA to make sure all of t

Re: [OpenWrt-Devel] QA for upcoming(?) CC?

On Fri, 5 Dec 2014, John Crispin wrote: > > > On 05/12/2014 11:19, Jo-Philipp Wich wrote: > > Hi. > > > >> in any event, if the idea of an official release is that it > >> should build out of the box, there are clearly a number of > >> (albeit easily fixable) download and build issues to clean up.

[OpenWrt-Devel] OpenWRT and grsecurity experiments and ponderings

Hi all noticing that CC may be coming at some point, and whilst recently taking the latest turunk for a spin, I noticed that the kernel 3.14.25 matched the current grsecurity patch (which is in long term support against 3.14) so I thought I'd see what it would take to apply it to OpenWRT. It

[OpenWrt-Devel] [PATCH] ar8216: Use IGMP Join and Fast Leave functions

Avoids flooding the network with multicast data. Signed-off-by: Cristian Morales Vega --- Since I guess not all the switches support this... Good idea? Is some OpenWRT package expecting to receive the multicast packages? At the very least you lose the capacity of using iptables to play with the

[OpenWrt-Devel] [PATCH] ramips: generate factory images for Nexx devices

From: Roger Pueyo Centelles --- target/linux/ramips/dts/WT1520-4M.dts | 83 +++ target/linux/ramips/dts/WT1520-8M.dts | 83 +++ target/linux/ramips/dts/WT1520.dts| 83 --- target/linux/ramips/imag

Re: [OpenWrt-Devel] ar934x+ar8327v4

Hello, Yes the problem remains when enable_vlan is set to 0 I don't think it's related to your changes either. I synced with trunk in hope that your changes made a difference with my problem. However that does not seem to be the case. I was hoping someone could point me in the right direction. D

Re: [OpenWrt-Devel] ar934x+ar8327v4

I meant to say Could it be as simple as the switch just isn't fully initialized? instead of *recognized*... the ar8216 driver definitely recognizes it properly, and exposes the switch0 interface. I was thinking perhaps something else had to happen during init for the "eth0" interface. -- Davey On

Re: [OpenWrt-Devel] ar934x+ar8327v4

On 2014-12-05 17:15, David Hutchison wrote: > Hello, > > Yes the problem remains when enable_vlan is set to 0 > > I don't think it's related to your changes either. I synced with trunk > in hope that your changes made a difference with my problem. However > that does not seem to be the case. > >

Re: [OpenWrt-Devel] ar934x+ar8327v4

On Fri, Dec 05, 2014 at 05:37:31PM +0100, Felix Fietkau wrote: > On 2014-12-05 17:15, David Hutchison wrote: > > > > The other thing to note ( and i'm not sure if this is by design ).. I > > used to be able to do "swconfig dev eth0 show" and show the switch the > > eth0 was connected to. Now I mus

[OpenWrt-Devel] [PATCH] e2fsprogs: add InstallDev section to Makefile

btrfs-progs is using libext2fs, so headers and libs need to be staged Signed-off-by: Daniel Golle --- package/utils/e2fsprogs/Makefile | 15 +++ 1 file changed, 15 insertions(+) diff --git a/package/utils/e2fsprogs/Makefile b/package/utils/e2fsprogs/Makefile index d4fd8d7..b91c957 1

Re: [OpenWrt-Devel] ar934x+ar8327v4

I am using a very simple test setup with no vlans for now: root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula

Re: [OpenWrt-Devel] ar934x+ar8327v4

Here is a test I did by setting up swconfig manually. As you can see I put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping 10.128.41.1 which is a device on port 1. However eth0.1 which as address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. Attached is the swconfig setup, an

Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)

On Dec 5, 2014 5:12 AM, "Jaime T" wrote: > Problem fixed! After hours of trying to diagnose what was going wrong, > I took a long shot and tried overwriting the openwrt-distributed adsl > firmware blob (/lib/firmware/ltq-dsl-fw-a-danube.bin) with the > firmware blob that was originally distributed

Re: [OpenWrt-Devel] ar934x+ar8327v4

On Fri, Dec 05, 2014 at 12:39:16PM -0700, David Hutchison wrote: > Here is a test I did by setting up swconfig manually. As you can see I > put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping > 10.128.41.1 which is a device on port 1. However eth0.1 which as > address 10.128.41.249 can

Re: [OpenWrt-Devel] ar934x+ar8327v4

On Fri, Dec 5, 2014 at 5:21 AM, Chris Green wrote: > Some people with the RB2011 (other incarnations but presumably > basically the same) have it working OK. I'm one of those that has a working RB2011; it's currently running r41293 with my RB2011UiAS patch ( http://patchwork.openwrt.org/patch/584