It seems not to be enabled by default.
(but even if enabled, I don't see options for providing ecdsa keyfile).

https://lists.openwrt.org/pipermail/openwrt-devel/2014-January/023593.html
http://git.openwrt.org/?p=openwrt.git;a … in;hb=HEAD
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=25a9554d5694b17493d1f16983a72ba60a857296
http://git.openwrt.org/?p=openwrt.git;a … it;hb=HEAD

(Last edited by hnyman on 19 Nov 2014, 13:37)

I've played a bit with it myself now, all you need really is make sure the key is generated. Look at the Makefile and the init file, only some small changes needed. The init script expects a file to exist in /etc/dropbear/dropbear_keytype_host_key and the Makefile touches it.

It's indeed faster

Hmm I'll have to look into that. I tried using dropbearkey earlier but it doesnt seem to support generating ECDSA keys.

(Last edited by ceri on 20 Nov 2014, 03:01)

It does when compiled with ECC.

Oh, I was looking at System>Software in LuCI and I see "Remove" buttons alongside packages like 6in4, odhcp6c, etc, so I thought they were optional if  not using IPv6 and thus removable. Or are they put their by the vanilla configuration and not by you?

they are now in vanilla default config, but weren't 4 years ago.

But my point was more that you will not get disk space. You actually lose it if you try removing original packages...
The packages that are in the compiled firmware, stay there on flash even if you try to delete them. The space is not freed, they are just logically marked deleted. But you can't reuse the read-only part of the firmware.

Ah, right. The original image is stored as is and the changes you make just become a "diff" added to that. I should have thought about that, thanks for pointing it out :-)

ar71xx architecture has been bumped to 3.14 kernel (from 3.10). The newest trunk build (r43368) is based on that 3.14.

Thanks for the update

On another note I think I've had intermittent wifi problems on my WND3800 (signal strength and ping times seem to fluctuate up and down). Is all ok for the rest of you here or are there any known wifi issues with WND3x00?

Hello hnyman,
I'm building Archer C7 trunk releases based on your build.
Unfortunately in laste releases I found that DHCP protocol on WAN is not working. router is obtaining an address from the router of the service provider.
My last working is 43292.
I then built 43347, 43350, 343368 not working.
I suppose can be the netifd version changed in 43346 or the change of kernel release fro 3.10 to 3.14 in 43344 - 43347
Did you experience any problem on wndr3700?
Can you please explain how I can build an old release so that I can catch the last working release?
Thanks and regards

Sergio

(Last edited by sergiosatellite on 24 Nov 2014, 21:32)

No, I have seen no problems.

Regarding old builds, it is rather easy with my time machine script. VersionT.sh takes "yyyy-mm-dd hh:mm" as argument, so that you can specify the exact moment to go back into. Before using it, you need "make dirclean" to clear all tools, toolchain etc.

I have had intermittent problems with WDS clients crashing.  I have two WNDR3800 WDS clients connected to a third WNDR3800 WDS server.  It used to be rock solid and fast as bloody hell.  For the last few weeks, a client WNDR3800 will sometimes crash when under load.

I have not had time to test or debug.  I have seen others post some similar problems (not WDS, but wifi crashing) on the other WND3x00 thread.  I tend to rebuild every week or two based on hnyman's great setup, but with some little tweaks.

WDS crashing is probably fixed already:

https://dev.openwrt.org/changeset/43367/trunk

Thanks for the heads up.  I'll let everyone know if I see crashes again, but assume no wifi problems here otherwise.

Thanks all!

I've been running on the r43393 build for a few days now and haven't seen the problems, so definitely looks better!
(My wifi is a plain vanilla AP so no WDS.)

I spoke too soon, wifi problems are back and I am seeing ping times to 192.168.1.1 varying around 50-500 msec and sometimes more.
Any hints on how I can debug this?

hnyman, have you seen anything related to this issue:
https://dev.openwrt.org/ticket/18497

I've based my builds loosely on your config, so perhaps you've seen this too? My WNDR3700 ran flawlessly for a month (in continuous service) with r43427 (based on the 3.10 kernel), and this issue must therefore have  been introduced some time between r43427 and now. Perhaps related to the kernel bump to 3.14, I don't know.

I'm on hnyman's r43393 (which has the 3.14 kernel) and I currently have one instance of the irq stack trace in my kernel log:

[74948.350000] irq 40: nobody cared (try booting with the "irqpoll" option)
[74948.350000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.18 #1
[74948.350000] Stack : 00000000 00000000 00000000 00000000 803bc8ae 00000032 80343348 00000000
[74948.350000]       802fa294 8034376f 00000000 803b3b5c 80343348 00000000 80340000 802fd610
[74948.350000]       802fd624 8029cfe0 00000000 801fedf4 00000006 801a383c 802fd458 80333b5c
[74948.350000]       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[74948.350000]       00000000 00000000 00000000 00000000 00000000 00000000 00000000 80333ae8
[74948.350000]       ...
[74948.350000] Call Trace:
[74948.350000] [<802411ac>] show_stack+0x48/0x70
[74948.350000] [<800a65d8>] __report_bad_irq.isra.7+0x44/0xf8
[74948.350000] [<801d4328>] note_interrupt+0x224/0x2d8
[74948.350000] [<8015be78>] handle_irq_event_percpu+0x1b8/0x1ec
[74948.350000] [<8015bc9c>] handle_irq_event+0x3c/0x60
[74948.350000] [<8015bf8c>] handle_level_irq+0xe0/0xf8
[74948.350000] [<8014f7e8>] generic_handle_irq+0x28/0x44
[74948.350000] [<8014f7e8>] generic_handle_irq+0x28/0x44
[74948.350000] [<80118c60>] do_IRQ+0x1c/0x2c
[74948.350000] [<80060830>] ret_from_irq+0x0/0x4
[74948.350000] [<868e1274>] ath_start_rfkill_poll+0x10c/0x37c [ath9k]
[74948.350000] [<868e3d68>] ath9k_tasklet+0x214/0x230 [ath9k]
[74948.350000] [<80264114>] tasklet_action+0x84/0xcc
[74948.350000] [<8008f534>] __do_softirq+0xf8/0x228
[74948.350000] [<80186600>] irq_exit+0x54/0x70
[74948.350000] [<80060830>] ret_from_irq+0x0/0x4
[74948.350000] [<80060a80>] __r4k_wait+0x20/0x40
[74948.350000] [<8010054c>] cpu_startup_entry+0xa4/0x104
[74948.350000] [<8035094c>] start_kernel+0x3c8/0x3e0
[74948.350000] 
[74948.350000] handlers:
[74948.350000] [<868e3864>] ath_isr [ath9k]
[74948.350000] Disabling IRQ #40

It'd be great to hear from someone here with a 100% working wifi connection on a WNDR3x00:
- OpenWRT release
- ping times between router and client
- wifi config (Legacy/N, channel etc)

I'm on r43393, have tried both Legacy and N, channel 11 and am using standard AP mode with WPA2 PSK (CCMP). With a device just a few meters away I get ping times up to 3000ms and sometimes packet loss.

Might be the same problem as https://dev.openwrt.org/ticket/18455 , which is supposed to be fixed today with https://dev.openwrt.org/changeset/43560. Other most likely related bugs with "Disabling IRQ #40": https://dev.openwrt.org/ticket/18483 and https://dev.openwrt.org/ticket/18497

The bug has been introduced by the bump to 3.14 two weeks ago.
https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029744.html

You might try the r43569 build, which supposedly has the invalid pointer access fixed.

(Last edited by hnyman on 9 Dec 2014, 10:29)

Thanks, I'll try the new build.
What are typical router ping times on your wireless network?

Unfortunately, https://dev.openwrt.org/changeset/43560 doesn't fix the IRQ issue. I flashed my router with a fresh build just now, and the issue appeared shortly after.

Hi,

I'm used this build for a while, and it's worked well. All clients get an ipv6 connection. However, I'm a bit confused as to how everything works.

Windows clients get an ipv6 lease and can register hostname (so reverse dns works)
Mac clients also get an ipv6 lease but do not register a hostname. Mac clients also seem to configure ipv6 with SLAAC as well, so I have multiple ipv6 addresses on mac.
Linux clients (with isc-dhcp 4.2) do not get a ipv6 lease but still configure a ip, I assume with SLAAC.

Now I want reverse dns to work for all clients (so kerberos and stuff can work for ipv6). How come all dhcp clients behave so differently? Is this something I can configure on openwrt, or is it only the client responsibility?

Devs have again tried to fix it, this time by r43586 ...  (I have not yet built it)

https://dev.openwrt.org/ticket/18455#comment:14
https://dev.openwrt.org/changeset/43586

(Last edited by hnyman on 9 Dec 2014, 11:46)

Not sure if it is actually the same issue, it seems ticket 18455 might be something else. However, rebuilding is painless, so I'll try it anyway.