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
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 on
Hi, do I understand it correctly. For CC is 3.14 planed?
Thanks,
Claudio
--
Reviewing OpenWrt BB for Xmodus Systems XM1710E GSM/UMTS Router
http://www.xmodus-systems.de/en/terminals/routers.html
On 05.12.2014 09:07, John Crispin wrote:
i intentionally don't set a date. i have done so in the
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
http://www.xmodus-systems.de/en/terminals/routers.html
On 05.12.2014
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
(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
John
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
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,
On Fri, Dec 5, 2014 at 9:57 AM, John Crispin blo...@openwrt.org 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
From: Kristian Evensen kristian.even...@gmail.com
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
From: Kristian Evensen kristian.even...@gmail.com
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:
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
On Fri, Dec 5, 2014 at 10:21 AM, Chris Green c...@isbd.net 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
On 17 November 2014 at 18:42, Sebastian Moeller moell...@gmx.de 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
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 not
On Fri, Dec 05, 2014 at 10:59:11AM +0100, Heiner Kallweit wrote:
On Fri, Dec 5, 2014 at 10:21 AM, Chris Green c...@isbd.net 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
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 these
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. is
it part
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.
Avoids flooding the network with multicast data.
Signed-off-by: Cristian Morales Vega crist...@samknows.com
---
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
From: Roger Pueyo Centelles roger.pu...@guifi.net
---
target/linux/ramips/dts/WT1520-4M.dts | 83 +++
target/linux/ramips/dts/WT1520-8M.dts | 83 +++
target/linux/ramips/dts/WT1520.dts| 83 ---
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.
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
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.
I was
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 must use
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
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,
On Dec 5, 2014 5:12 AM, Jaime T enopa...@gmail.com 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
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 cannot
On Fri, Dec 5, 2014 at 5:21 AM, Chris Green c...@isbd.net 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 (
30 matches
Mail list logo
