The content of this topic has been archived between 1 Oct 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.
There are no required patches that I am aware of that need to be applied from the current SVN builds.
nice
I also ordered mine.
What about this issue :
https://dev.openwrt.org/ticket/6533
Right, Isn't there the antenna grouping as well as the LED configuration?
LED support has been checked into trunk for a few weeks now.
The antenna configuration isn't at 100% of the stock firmware strength, but it's pretty good. My OpenWrt results are on par (or even a few dB better) at 5 GHz, but they are about 10 dB below desired at 2.4 GHz.
The patch in that Trac ticket only enables the ability to fiddle around with the antenna groupings at runtime, so it's not needed for normal usage. It's possible that some improvement is possible using the patch, but I haven't yet had time to do a bunch of signal strength tests.
I'll post some updated builds in the next little while, including that patch, in case anyone wants to play with them.
Only issue that I've had with my builds have been with getting hostapd to work with WPA-Enterprise.
Has anyone else had any success with this under the WNDR3700 or OpenWrt in general? Still having trouble identifying the scope of the problem.
Details are posted in https://forum.openwrt.org/viewtopic.php?id=23911
Here are two torrents for a recent WNDR3700 build, based on trunk revision 20254 (current as of a day or so ago). Help with seeding the torrents is always appreciated.
Torrent: r20254 factory upgrade version (for routers that are still running stock NETGEAR firmware)
Torrent: r20254 "sysupgrade" version (for routers that are already running an older version of OpenWrt)
These images are primarily built using a static configuration, meaning that they should work with wireless and other major features enabled from the first boot. Don't forget to adjust the country option for both radios in /etc/config/wireless to set up your proper regulatory region.
Aside from all of the goodness that was added in the OpenWrt trunk, the following configuration items differ between this build and the torrent from last month:
- added support for external rootfs
- ath9k debugging mode turned off
- added UPnP/NAT-PMP
The only code differences between this build and trunk 20254 are:
- this build includes the antenna /proc filesystem patch from ticket 6533. See the Trac ticket for information on how to use it to adjust the antenna GPIOs.
- this build uses a modified /lib/wifi/mac80211.sh so that the wireless interfaces are brought up at first boot
If you want to use the .config for this build as your own base, you can also download it here:
LED support has been checked into trunk for a few weeks now.
The antenna configuration isn't at 100% of the stock firmware strength, but it's pretty good. My OpenWrt results are on par (or even a few dB better) at 5 GHz, but they are about 10 dB below desired at 2.4 GHz.
The patch in that Trac ticket only enables the ability to fiddle around with the antenna groupings at runtime, so it's not needed for normal usage. It's possible that some improvement is possible using the patch, but I haven't yet had time to do a bunch of signal strength tests.
I'll post some updated builds in the next little while, including that patch, in case anyone wants to play with them.
Thanks for the update.
Isn't it requiered to set CONFIG_ATH_USER_REGD=y (it is off by default but I see that it is on in your config) as reported in this topic or this issue is solved?
(Last edited by zorxd on 18 Mar 2010, 19:05)
It is still off by default. I just built off svn last night and it was off.
It is still off by default. I just built off svn last night and it was off.
yes but is it still requiered for ath9k to work properly?
WOOOOO.
I got my WNDR3700 today and installed it and everything is working out fine.
Evening spanning appears to work 216MBPs.
Not bad not bad.
The serial header is already soldered on! Haha.
Doe anyone know how to setup the buttons though? This little baby has two buttons on the front I'd like to fiddle with. I know I did this back in the day with a WRT54GS.
This is exciting, it's been a while since I had a cutting edge router that OpenWRT worked with, not the mention BEFORE dd-wrt.
Just FYI on the leds I have never seen my usb led light up even with a drive hooked up to it. You must specifically select the wndr3700 usb led config if I remember correctly which I have done during build. Not sure if there is something I need to setup to get it to actually work as the other leds work out of the box. I was to busy messing with nfs and samba to worry about it.
skarlson wrote:It is still off by default. I just built off svn last night and it was off.
yes but is it still requiered for ath9k to work properly?
Is it required? I can't say if it is required or not; I must have misread your question before. I always select it so I have not had the occassion to test a build without that installed.
It is required to be enabled to get 5GHz radio working and channels above 11 in 2.4Ghz.
Does anyone know how to lump the wan port into the lan?
Do I just have to make "0 1 2 3 5" into "0 1 2 3 4 5"?
I don't see the config for vlan1 anywhere.
(Last edited by napierzaza on 20 Mar 2010, 02:00)
napierzaza,
Buttons are controlled through the hotplug system.
Drop in a file called /etc/hotplug.d/button/01-button-press and place something like the following in it as a demo:
echo button: $BUTTON, action: $ACTION >>/tmp/buttons.logYou can then write your own scripts as appropriate. Incidentally, I believe that the reset button (inset) on the back of the router is also shunted through the hotplug system.
As far as napierzaza's LAN/WAN question:
I am not an expert on the switch stuff (check in with ase!)...but my potentially-incorrect understanding of the architecture based on past posts is that the WAN port is not part of the main switch at all, and that traffic between LAN and WAN has to first transit the processor.
With that in mind, perhaps you can consider bridging the interfaces together instead. (If you want to go that route, note that the default busybox version of brctl is functionality-crippled, but a fully-functional version of brctl is installable via opkg in package "bridge".)
To skarlson:
I also believe that the USB LED module simply installs kernel support for the LED. It's up to userland programs to tell it when you want it on or off.
For example:
# Turn on the USB LED solid
echo "255" >/sys/devices/platform/wndr3700-led-usb/leds/wndr3700:green:usb/brightness
# Wait 10 seconds
sleep 10
# Turn off the USB LED
echo "0" >/sys/devices/platform/wndr3700-led-usb/leds/wndr3700:green:usb/brightness
sleep 5
# Now make the LED blink continuously 250 ms on, 500 ms off, 250 ms on, 500 ms off, ...
echo "timer" >/sys/devices/platform/wndr3700-led-usb/leds/wndr3700:green:usb/trigger
echo "250" >/sys/devices/platform/wndr3700-led-usb/leds/wndr3700:green:usb/delay_on
echo "500" >/sys/devices/platform/wndr3700-led-usb/leds/wndr3700:green:usb/delay_onI should add that I haven't done any research to see whether or not the default OpenWrt install has any hooks in SAMBA or the USB-hotplug system to look for or use the LED. I guess that's someone's next project...
(Last edited by essdz on 20 Mar 2010, 02:25)
It is required to be enabled to get 5GHz radio working and channels above 11 in 2.4Ghz.
So is there any reason for not turning this on by default in backfire 10.03?
can you detail a little more how you can turn various LEDS on and off? I tried "swconfig dev eth1 port 0 set led 10" but it says that it "Failed to connect to the switch".
What I want to do is push a button, have a LED of my choosing blink in response and then for it to respond to the button press. I can't seem to figure out how to work the leds. I used to use /proc/diag/led in my wrt54g
Switch LED config is described in the wiki. ase's original post, from which you got the failing swconfig command, describes the old syntax: the newer syntax (which is correct in the wiki) uses the driver name rather than the interface name as an argument.
The non-switch LEDs are controlled separately. Here's an example to configure the WPS button to toggle the WPS light between off and blinking. Drop this into /etc/hotplug.d/buttons/02-toggle-wps. Please note that this doesn't do anything other than toggle the LED mode!
LED="/sys/devices/platform/leds-gpio/leds/wndr3700:green:wps"
[ "$ACTION" = "released" -a "$BUTTON" = "BTN_1" ] && {
HOTPLUG="$(cat /proc/sys/kernel/hotplug)"
(echo /bin/true > /proc/sys/kernel/hotplug)
[ -f $LED/delay_on ] && STATE="on" || STATE="off"
case "$STATE" in
"on")
echo "none" >$LED/trigger
echo "0" >$LED/brightness
;;
"off")
echo "timer" >$LED/trigger
echo "250" >$LED/delay_on
echo "100" >$LED/delay_off
;;
esac
}test report with revision 20299 :
ath9k works (with CONFIG_ATH_USER_REGD=y) on channel 48 in HT40- mode by setting the following option :
'
config 'wifi-device' 'radio1'
option 'type' 'mac80211'
option 'macaddr' 'XXXXXXXXXXXX'
option 'hwmode' '11na'
list 'ht_capab' 'SHORT-GI-40'
list 'ht_capab' 'DSSS_CCK-40'
option 'disabled' '0'
option 'channel' '48'
option 'htmode' 'HT40-'
option 'country' 'US'
I get a windows file copy speed (wifi to ethernet or ethernet to wifi) of up to 13-15 MiB/s, which I consider very good. However, ping times are strange. It is usually <2ms but it sometimes spikes to up to about 200 ms.
root@wndr3700:/etc/config# ping clo
PING clo (192.168.12.2): 56 data bytes
64 bytes from 192.168.12.2: seq=0 ttl=128 time=1.250 ms
64 bytes from 192.168.12.2: seq=1 ttl=128 time=1.151 ms
64 bytes from 192.168.12.2: seq=2 ttl=128 time=8.943 ms
64 bytes from 192.168.12.2: seq=3 ttl=128 time=1.236 ms
64 bytes from 192.168.12.2: seq=4 ttl=128 time=1.154 ms
64 bytes from 192.168.12.2: seq=5 ttl=128 time=1.126 ms
64 bytes from 192.168.12.2: seq=6 ttl=128 time=1.159 ms
64 bytes from 192.168.12.2: seq=7 ttl=128 time=74.964 ms
64 bytes from 192.168.12.2: seq=8 ttl=128 time=1.141 ms
64 bytes from 192.168.12.2: seq=9 ttl=128 time=1.151 ms
64 bytes from 192.168.12.2: seq=10 ttl=128 time=1.156 ms
64 bytes from 192.168.12.2: seq=11 ttl=128 time=1.172 ms
64 bytes from 192.168.12.2: seq=12 ttl=128 time=1.156 ms
64 bytes from 192.168.12.2: seq=13 ttl=128 time=1.145 ms
64 bytes from 192.168.12.2: seq=14 ttl=128 time=1.146 ms
64 bytes from 192.168.12.2: seq=15 ttl=128 time=1.163 ms
64 bytes from 192.168.12.2: seq=16 ttl=128 time=1.139 ms
64 bytes from 192.168.12.2: seq=17 ttl=128 time=195.904 ms
64 bytes from 192.168.12.2: seq=18 ttl=128 time=1.147 ms
64 bytes from 192.168.12.2: seq=19 ttl=128 time=1.128 ms
64 bytes from 192.168.12.2: seq=20 ttl=128 time=1.130 ms
64 bytes from 192.168.12.2: seq=21 ttl=128 time=1.148 ms
64 bytes from 192.168.12.2: seq=22 ttl=128 time=1.208 ms
64 bytes from 192.168.12.2: seq=23 ttl=128 time=221.903 ms
64 bytes from 192.168.12.2: seq=24 ttl=128 time=1.177 ms
64 bytes from 192.168.12.2: seq=25 ttl=128 time=1.146 ms
64 bytes from 192.168.12.2: seq=26 ttl=128 time=1.161 ms
64 bytes from 192.168.12.2: seq=27 ttl=128 time=1.147 ms
64 bytes from 192.168.12.2: seq=28 ttl=128 time=1.198 ms
64 bytes from 192.168.12.2: seq=29 ttl=128 time=1.179 ms
64 bytes from 192.168.12.2: seq=30 ttl=128 time=1.148 ms
64 bytes from 192.168.12.2: seq=31 ttl=128 time=1.167 ms
64 bytes from 192.168.12.2: seq=32 ttl=128 time=1.171 ms
64 bytes from 192.168.12.2: seq=33 ttl=128 time=1.197 ms
64 bytes from 192.168.12.2: seq=34 ttl=128 time=1.151 ms
64 bytes from 192.168.12.2: seq=35 ttl=128 time=1.161 ms
^C
--- clo ping statistics ---
36 packets transmitted, 36 packets received, 0% packet loss
round-trip min/avg/max = 1.126/14.970/221.903 ms(Last edited by zorxd on 22 Mar 2010, 18:10)
thanks to developers for great work on this firmware.
I'm watching this thread since day-0, but only couple of days ago gave it a shot and installed to my router.
I got everything working. my 4965AGN based card got succesfully associated 300mbit @5Ghz band.
everything looks good and pretty stable, but speed is significantly lower than with factory firmware which allowed me 15-22mbytes/s depending on conditions
here I'm getting 7-8 mbytes/s in peak. and as low as 3mbyte/s on average.
HT40 is enabled and active.
I have noticed that retries count is really high - almost 25% of success.
also I notice that for some reason connection speed varies from 108 to 300mbps over short period in time without any changes in laptop position or anything else.
is there something I can try to improve the speed?
here's relevant information
root@OpenWrt:~# cat /etc/config/wireless
config 'wifi-device' 'radio0'
option 'type' 'mac80211'
option 'channel' '5'
option 'macaddr' 'gone'
option 'hwmode' '11ng'
option 'country' 'US'
list 'ht_capab' 'SHORT-GI-40'
list 'ht_capab' 'DSSS_CCK-40'
list 'ht_capab' 'HT40+'
list 'ht_capab' 'HT40-'
option 'htmode' 'HT40-'
config 'wifi-iface'
option 'device' 'radio0'
option 'network' 'lan'
option 'mode' 'ap'
option 'ssid' 'home-net'
option 'encryption' 'psk2'
option 'key' 'gone'
option 'hidden' '1'
config 'wifi-device' 'radio1'
option 'type' 'mac80211'
option 'macaddr' 'gone'
option 'hwmode' '11na'
option 'country' 'US'
list 'ht_capab' 'SHORT-GI-40'
list 'ht_capab' 'DSSS_CCK-40'
list 'ht_capab' 'HT40+'
list 'ht_capab' 'HT40-'
option 'channel' '157'
option 'htmode' 'HT40+'
config 'wifi-iface'
option 'device' 'radio1'
option 'network' 'lan'
option 'mode' 'ap'
option 'ssid' 'home-net-5G'
option 'encryption' 'psk2'
option 'key' 'gone'
option 'hidden' '1'
root@OpenWrt:~# cat /sys/kernel/debug/ath9k/phy1/rcstat
HT MCS Rate Success Retries XRetries PER
6.0: 0 0 0 0
9.0: 0 0 0 0
12.0: 0 0 0 0
18.0: 0 0 0 0
24.0: 0 0 0 0
36.0: 0 0 0 0
48.0: 0 0 0 0
54.0: 0 0 0 0
HT20 0 6.5: 2 0 0 0
HT20 1 13.0: 0 0 0 0
HT20 2 19.5: 0 0 0 0
HT20 3 26.0: 0 0 0 0
HT20 4 39.0: 0 0 0 0
HT20 5 52.0: 0 0 0 0
HT20 6 58.5: 0 0 0 0
HT20 7 65.0: 0 0 0 0
HT20 8 13.0: 0 0 0 0
HT20 9 26.0: 0 0 0 0
HT20 10 39.0: 0 0 0 0
HT20 11 52.0: 0 0 0 0
HT20 12 78.0: 0 0 0 0
HT20 13 104.0: 0 0 0 0
HT20 14 117.0: 0 0 0 0
HT20 15 130.0: 0 0 0 0
HT40 0 13.5: 0 8 4 21
HT40 1 27.5: 0 8 4 21
HT40 2 40.5: 3 12 4 20
HT40 3 54.0: 25 51 9 34
HT40 4 81.5: 13922 1297 48 0
HT40 5 108.0: 0 0 0 0
HT40 6 121.5: 0 0 0 0
HT40 7 135.0: 0 0 0 0
HT40 7 150.0: 0 0 0 0
HT40 8 27.0: 0 0 0 0
HT40 9 54.0: 0 0 0 0
HT40 10 81.0: 0 0 0 0
HT40 11 108.0: 134473 32376 4931 0
HT40 12 162.0: 354982 141215 33544 7
HT40 13 216.0: 625335 236047 64714 15
HT40 14 243.0: 521867 238226 71905 0
HT40 15 270.0: 125767 162123 70834 2
HT40 15 300.0: 1146968 261617 48007 14
root@OpenWrt:~# iw wlan1 station dump
Station gone (on wlan1)
inactive time: 20 ms
rx bytes: 36273716
rx packets: 351272
tx bytes: 879409942
tx packets: 607049
signal: -65 dBm
tx bitrate: 300.0 MBit/s MCS 15 40Mhz short GIthanks
thanks to developers for great work on this firmware.
I'm watching this thread since day-0, but only couple of days ago gave it a shot and installed to my router.I got everything working. my 4965AGN based card got succesfully associated 300mbit @5Ghz band.
everything looks good and pretty stable, but speed is significantly lower than with factory firmware which allowed me 15-22mbytes/s depending on conditions
here I'm getting 7-8 mbytes/s in peak. and as low as 3mbyte/s on average.
HT40 is enabled and active.
I have noticed that retries count is really high - almost 25% of success.
also I notice that for some reason connection speed varies from 108 to 300mbps over short period in time without any changes in laptop position or anything else.
is there something I can try to improve the speed?
here's relevant informationroot@OpenWrt:~# cat /etc/config/wireless config 'wifi-device' 'radio0' option 'type' 'mac80211' option 'channel' '5' option 'macaddr' 'gone' option 'hwmode' '11ng' option 'country' 'US' list 'ht_capab' 'SHORT-GI-40' list 'ht_capab' 'DSSS_CCK-40' list 'ht_capab' 'HT40+' list 'ht_capab' 'HT40-' option 'htmode' 'HT40-' config 'wifi-iface' option 'device' 'radio0' option 'network' 'lan' option 'mode' 'ap' option 'ssid' 'home-net' option 'encryption' 'psk2' option 'key' 'gone' option 'hidden' '1' config 'wifi-device' 'radio1' option 'type' 'mac80211' option 'macaddr' 'gone' option 'hwmode' '11na' option 'country' 'US' list 'ht_capab' 'SHORT-GI-40' list 'ht_capab' 'DSSS_CCK-40' list 'ht_capab' 'HT40+' list 'ht_capab' 'HT40-' option 'channel' '157' option 'htmode' 'HT40+' config 'wifi-iface' option 'device' 'radio1' option 'network' 'lan' option 'mode' 'ap' option 'ssid' 'home-net-5G' option 'encryption' 'psk2' option 'key' 'gone' option 'hidden' '1' root@OpenWrt:~# cat /sys/kernel/debug/ath9k/phy1/rcstat HT MCS Rate Success Retries XRetries PER 6.0: 0 0 0 0 9.0: 0 0 0 0 12.0: 0 0 0 0 18.0: 0 0 0 0 24.0: 0 0 0 0 36.0: 0 0 0 0 48.0: 0 0 0 0 54.0: 0 0 0 0 HT20 0 6.5: 2 0 0 0 HT20 1 13.0: 0 0 0 0 HT20 2 19.5: 0 0 0 0 HT20 3 26.0: 0 0 0 0 HT20 4 39.0: 0 0 0 0 HT20 5 52.0: 0 0 0 0 HT20 6 58.5: 0 0 0 0 HT20 7 65.0: 0 0 0 0 HT20 8 13.0: 0 0 0 0 HT20 9 26.0: 0 0 0 0 HT20 10 39.0: 0 0 0 0 HT20 11 52.0: 0 0 0 0 HT20 12 78.0: 0 0 0 0 HT20 13 104.0: 0 0 0 0 HT20 14 117.0: 0 0 0 0 HT20 15 130.0: 0 0 0 0 HT40 0 13.5: 0 8 4 21 HT40 1 27.5: 0 8 4 21 HT40 2 40.5: 3 12 4 20 HT40 3 54.0: 25 51 9 34 HT40 4 81.5: 13922 1297 48 0 HT40 5 108.0: 0 0 0 0 HT40 6 121.5: 0 0 0 0 HT40 7 135.0: 0 0 0 0 HT40 7 150.0: 0 0 0 0 HT40 8 27.0: 0 0 0 0 HT40 9 54.0: 0 0 0 0 HT40 10 81.0: 0 0 0 0 HT40 11 108.0: 134473 32376 4931 0 HT40 12 162.0: 354982 141215 33544 7 HT40 13 216.0: 625335 236047 64714 15 HT40 14 243.0: 521867 238226 71905 0 HT40 15 270.0: 125767 162123 70834 2 HT40 15 300.0: 1146968 261617 48007 14 root@OpenWrt:~# iw wlan1 station dump Station gone (on wlan1) inactive time: 20 ms rx bytes: 36273716 rx packets: 351272 tx bytes: 879409942 tx packets: 607049 signal: -65 dBm tx bitrate: 300.0 MBit/s MCS 15 40Mhz short GIthanks
Have been watching this thread since I bought mine, and noticed that fiddling with the antenna grouping (as per patch from bug 6533) made a massive distance to the speed problem on my machines, I now see 10-15mbyte/sec on average.
My retries are still _very_ high though:
root@WLN:~# cat /sys/kernel/debug/ath9k/phy1/rcstat
HT MCS Rate Success Retries XRetries PER
6.0: 0 0 0 0
9.0: 0 0 0 0
12.0: 0 0 0 0
18.0: 0 0 0 0
24.0: 0 0 0 0
36.0: 0 0 0 0
48.0: 0 0 0 0
54.0: 0 0 0 0
HT20 0 6.5: 251 5214 1158 100
HT20 1 13.0: 0 0 0 0
HT20 2 19.5: 0 0 0 0
HT20 3 26.0: 0 0 0 0
HT20 4 39.0: 0 0 0 0
HT20 5 52.0: 0 0 0 0
HT20 6 58.5: 0 0 0 0
HT20 7 65.0: 0 0 0 0
HT20 8 13.0: 0 0 0 0
HT20 9 26.0: 0 0 0 0
HT20 10 39.0: 0 0 0 0
HT20 11 52.0: 0 0 0 0
HT20 12 78.0: 0 0 0 0
HT20 13 104.0: 0 0 0 0
HT20 14 117.0: 0 0 0 0
HT20 15 130.0: 0 0 0 0
HT40 0 13.5: 3 78 20 56
HT40 1 27.5: 10 138 20 56
HT40 2 40.5: 2 86 31 52
HT40 3 54.0: 1872 199 27 52
HT40 4 81.5: 10188 3334 1365 64
HT40 5 108.0: 0 0 0 0
HT40 6 121.5: 0 0 0 0
HT40 7 135.0: 0 0 0 0
HT40 7 150.0: 0 0 0 0
HT40 8 27.0: 0 0 0 0
HT40 9 54.0: 0 0 0 0
HT40 10 81.0: 0 0 0 0
HT40 11 108.0: 21625 13646 6938 64
HT40 12 162.0: 15428 29189 17695 60
HT40 13 216.0: 2038 12049 10912 63
HT40 14 243.0: 3412 2626 1624 42
HT40 15 270.0: 2422 2722 1466 27
HT40 15 300.0: 8513 2985 1484 24My retries on 2.4ghz for anything above 11mbit are downright awful but I have seen no performance issues.
Only other thing I think we need to sort out before 'going live' is probably USB LED function.
Hi all,
Would anyone on this thread be able to do me a favor and test the issue I recently reported here? It should be a pretty easy test to set up and it requires no special equipment...and it'd help me figure out if I am going crazy or if there really is a problem.
On a somewhat related note, I see that my wlan0 interface and my eth0 interface both have identical MACs. Is that the case for other people too? I didn't think this was supposed to happen, but I suppose it might make it easier to bridge traffic or something along those lines.
On a somewhat related note, I see that my wlan0 interface and my eth0 interface both have identical MACs. Is that the case for other people too?
yes
On a somewhat related note, I see that my wlan0 interface and my eth0 interface both have identical MACs. Is that the case for other people too? I didn't think this was supposed to happen, but I suppose it might make it easier to bridge traffic or something along those lines.
Yes, this is normal. This is the same with the stock firmware. Funny thing is, there is a 3rd MAC in the flash, right in the middle between the two used. Maybe MACs cost money and Netgear tried to save some? 
(Edited 25/03/09 to reflect that this issue is only apparent when wireless/wired bridging is used.)
Maybe MACs cost money and Netgear tried to save some?
Does anyone want to buy my unused MAC? For posters to this thread, I have a very special price. :-)
Anyway, I did some more digging and confirmed my issue. Full details are here, but I just wanted to warn everyone that if you use wireless encryption, multiple virtual interfaces on the same radio WILL NOT WORK PROPERLY if you also rely on bridging wireless traffic to the switch on the WNDR3700. This seems to be due to a lack of functionality in the ath9k driver (for all platforms it supports), so it's not a problem with the WNDR3700 or OpenWrt itself.
There is a easy hack you can use to make it work, but the trade-off is a ~90% loss in wireless performance...
(Last edited by essdz on 25 Mar 2010, 17:40)
Hi.
I have updated my router with this ver.: r20254 "sysupgrade" version (for routers that are already running an older version of OpenWrt)
Something is wrong with DHCP .
When I try to open DHCP, I receive this message:
/usr/lib/lua/luci/cbi.lua:338: Unable to read UCI data: luci_ethers
stack traceback:
[C]: in function 'error'
/usr/lib/lua/luci/cbi.lua:338: in function '__init__'
/usr/lib/lua/luci/util.lua:70: in function 'Map'
/usr/lib/lua/luci/model/cbi/mini/dhcp.lua:63: in function 'func'
/usr/lib/lua/luci/cbi.lua:91: in function 'load'
/usr/lib/lua/luci/dispatcher.lua:663: in function 'target'
/usr/lib/lua/luci/dispatcher.lua:363: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:129: in function </usr/lib/lua/luci/dispatcher.lua:128>
With old version DHCP works without any problem.
Regards ...