Just a day ago I installed LEDE 17.01 RC1 on an Archer C5 v1.0. Everything seems to run flawless from start. Thumbs up for the LEDE-project team!
However, today I noticed that the DNS request from a Galaxy Mini S4 did not resolve. When IO used IP adresses in stead of DNS names, the sites could be reached. After one hour of searching (and complaining) I just turned off the LEDE 17.01 Archer C5 Router, the phone connected to another access point and the problem disappeared. I did not experience this problem before on a LEDE trunk version (I don't remember the trunk release correctly) I installed a week ago. My other Android Phone do not seem to have this problem.
This isn't an Android 5.1 phone by any chance? If so, disabling IPv6 might be a workaround.
Do you have any other LEDE/OpenWrt devices active in the same network? If so, make sure they run as an AP/switch only and have their DHCP server(s) disabled (dnsmasq, odhcpd).
Thank you for your comments. The problem seems to bigger indeed. Updating the LEDE packages is not possible due to the DNS addresses cannot be resolved... I have shut down all my other LEDE devices and started from scrath with this one (Reset to defaults) but it doesn't work...
Seems to be some issues with the ath9k driver. I experienced also some issues that a android phone and a laptop didn't want to connect at all with the wifi, only after power off and power on the router. I didn't have time yet to further investigate.
Quick question, did you test it only with the initial release of LEDE 17.01 RC1 or also with the latest source?
They updated recently Musl from 1.1.15 to 1.1.16 which fixes a regression on MIPS routers as the Archer C5. You might want to try build it from the latest source and test it.
You can also wait for RC2 which will be released next week which will include this update.
[quote="bladeoner, post:6, topic:1359"]
They updated recently Musl from 1.1.15 to 1.1.16 which fixes a regression on MIPS routers as the Archer C5.
[/quote]I think that the fix for that "mips regression" was included in the original 1.1.15 version as a patch in LEDE. So no change in the formal upstep to 1.1.16.
Similarly, about 30 additional fixes were included since Dec 2016, so the formal upstep to 1.1.16 was like from 1.1.15.9999.
I tested with the initial release of LEDE 17.01 RC1. This week I 'upgraded' to the 17.01 RC1, before that I used the trunk of 2 weeks ago and did not experience any problem.
I will try the latest trunk and see if it works. The DNS itself is working properly (all other devices that do not use the Archer C5 are able to resolve DNS queries), so that is not causing the problem.
I just installed the trunk version, and started from the factory defaults. I connected the LAN port direct to my computer and the WAN port to my LAN network. I was able to log in and to update the packages (DNS was resolved). After that I changed the setup to an access point setup by disabling the DHCP server on the LAN port, changing protocol on the LAN port to DHCP client, removing the connection to my pc and moving the connection on the WAN port to my home network to one of the LAN ports (number 1). As I result I can access the Router (which has become an access point) from my computer (which is also on the LAN Network), but DNSqueries do not resolve (I cannot download new packages or ping). What am I missing....
You are thinking it a bit strangely when you set router2 to be DHCP client. It is more predetermined, if you assign a fixed IP to the second router. (The advice below is copied from my original message in the Openwrt forum.)
I have a rather similar config:
router1 acts as the master and serves DHCP & DNS etc.
router2 acts as a LAN switch & Wifi access point.
I have pretty much dumbed down the second router. I have turned off all DHCP & DNS services (plus disabled miniupnpd and ipv6 tunnels etc.).
The needed config is pretty simple if you simply connect a LAN port of router2 to a LAN port of router1. Then all the LAN clients are in the same switched network and see each other, and the whole LAN is also inside the firewall's LAN zone. (you can leave firewall running on router2). And you can forget about NAT settings in router2. Router2's WAN remains unused, so there is no NAT settings need. All traffic gets routed via the main router1, which also acts as the DNS and DHCP server, so all LAN clients get the correct info from it.
Basically you need to adjust these in router2:
set the hostname to be different than the main router has
set router2's LAN interface to match the subnet of router1, but to have a different fixed IP address. I use 192.168.1.2
set that router's DNS and gateway info to point into router1 (192.168.1.1 in my case)
config the DHCP server in router2 to ignore requests from local LAN interface. I do that config to prevent mishaps with the service starting accidentally, although I also disable the service itself (dnsmasq).
disable the DHCP/DNS service (dnsmasq) in router2
config the Wifi normally. At least change the wifi channel to prevent signal overlap.
(additionally, I adjust the IPv6 address settings, disable ipv6 tunnels, disable miniupnpd)
Adding a guest WLAN network would complicate things somewhat, as the router2 would need more logic. So my advice does not got there. This is just about a dumb LAN-connected wifi AP.
All those settings changes can be done via LuCI GUI, but I use a script to do that (modify settings for a "LAN repeater"). My full script:
root@OpenWrt2:~# cat /etc/lan-repeater.sh
#!/bin/sh
uci set system.@system[0].hostname=OpenWrt2
uci set network.lan.ipaddr=192.168.1.2
uci set network.lan.ip6ifaceid='::2'
uci set network.lan.gateway=192.168.1.1
uci set network.lan.dns=192.168.1.1
uci set network.sixxs.auto=0
uci set network.henet.auto=0
uci set network.lan6=interface
uci set network.lan6.ifname=@lan
uci set network.lan6.proto=dhcpv6
uci set network.lan6.reqprefix=no
uci set wireless.@wifi-device[0].channel=9
uci set wireless.@wifi-device[1].channel=48
uci set dhcp.lan.ignore=1
uci set dhcp.lan.force=0
uci delete dhcp.lan.dhcpv6
uci delete dhcp.lan.ra
uci delete dhcp.lan.ndp
uci set upnpd.config.enable_natpmp=0
uci set upnpd.config.enable_upnp=0
uci commit dhcp
uci commit network
uci commit wireless
uci commit system
uci commit upnpd
/etc/init.d/dnsmasq disable
/etc/init.d/miniupnpd disable
Cutting away commands for second radio, ipv6, ipv6 tunnels, dhcp tuning and miniupnpd leaves:
#!/bin/sh
uci set system.@system[0].hostname=OpenWrt2
uci set network.lan.ipaddr=192.168.1.2
uci set network.lan.gateway=192.168.1.1
uci set network.lan.dns=192.168.1.1
uci set wireless.@wifi-device[0].channel=9
uci set dhcp.lan.ignore=1
uci commit dhcp
uci commit network
uci commit wireless
uci commit system
/etc/init.d/dnsmasq disable
I agree, but I always have used this config. Besides, I want to use the router as an access point (for known clients) and a router (for guest clients, setting up a guest network).
However, I tried the fixed IP setup and that seems to work. So I think problem solved.
Why not have your main router act as a DHCP server for both your LAN and your guest network? Unless it doesn't run OpenWrt or LEDE, that is the most elegant setup.
Also, I see you talking about connecting your TP-Link to your LAN through it's WAN port - you should only use the LAN ports when operating inside a LAN. By connecting your TP-Link to your router through the WAN port, you are effectively double NAT'ing. That's far from ideal.
Thank you for all your help. I'm now using only the LAN ports, using Fixed IP adresses for the LAN interfaces, and guest network( blocks all internal end points) so I am satisfied.
Tonight some problems reoccured. When using chrome, the Samsung S4 mini (running android 4.4.2) shows the message dns_probe_finished_bad_config when I try to reach a webpage. Disabling both dnsmasq and odhcp did the trick. Can I still set up a guest network? And what happened with dnsmasq and odhcp that I had to disable it (never done this before...)?