Does that mean that you kept the settings over flashing or flashed without keeping settings (but then restored a backup from an older version) ?
Keeping settings from older major releases has some unpredictable results, hence it is advised to flash without keeping settings and then restoring manually the configs.
Sorry, to be clear that's without keeping the settings (well, initially I'd been more ambitious, but my final test before posting was to reflash entirely with the defaults, wiping my configs). This is why I didn't post my configs - they are all unchanged.
Btw for those unfamiliar w/ the AR150, it's a made for OpenWrt device and very simple/basic hardware: one WAN and one LAN Ethernet and 2.4GHz WiFi.
Also I should have mentioned that the only obvious difference with 19.07.1 vs 18.06.4 is that eth0 and eth1 are swapped (in 18. eth0 is WAN but in 19. eth1 is WAN). However, the physical ports are correct and everything else seems copacetic.
1 Like
Could you verify that settings are correct on the lan hosts?
An arp request has local validity only, that means that a host can send an arp request for devices within the same subnet. When a host needs to contact a device outside of its subnet, it needs to know the mac address of the default gateway, hence it will send an arp request for the 192.168.1.1.
However sending arp requests for 8.8.4.4 (if I am not mistaken this is dns.google in your dump) it seems to me that subnet mask is not correct on the host.
1 Like
Post the files:
/etc/config/network
and
/etc/config/wireless
sigh Good point @trendy. I was testing using "ping -I" on the LAN host to force it out the correct interface, but that wasn't a valid test. So I think I fubarred something between my first test (a modified config with the AR150 functioning as my actual router) and the later test (the reset config but the AR150 running locally because I can't use it as my actual router w/o a modified config), so whatever problem I initially experienced that led me down this path was with my modified config. I'll do more debugging later and report back, but whatever the problem is, it's probably more mundane.
So I did a little more testing this morning. I hesitate to jump to conclusions, but I've tried this twice now and it appears if I enable WiFi and then reboot, the wired Ethernet LAN will not work after the reboot, and if I disable WiFi, the wired Ethernet LAN comes back (w/o rebooting).
@bluewavenet here you go, but as I said before, the config is largely unmodified (except for a password I added to the WiFi):
root@OpenWrt:/etc/config# cat wireless
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/ahb/18100000.wmac'
option htmode 'HT20'
option legacy_rates '0'
option disabled '1'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option key 'password'
option ssid 'OpenWrt'
option encryption 'psk2'
option disabled '1'
root@OpenWrt:/etc/config# cat 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_prefix 'fd79:4a86:cd2a::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option ifname 'eth1'
option proto 'dhcp'
config interface 'wan6'
option ifname 'eth1'
option proto 'dhcpv6'
So I haven't heard anything. This problem seems reproducible. Any suggestions for work-arounds to try (e.g., if I had to hazard a guess, I'd say it was related to bridging) or data to gather to file a proper bug report? Thanks.
You never did a nslookup on dns.google ...I honestly can't imagine that you didn't add a hostname or configure a DNS server?
@lleachii that is just tcpdump trying to be helpful by doing a reverse lookup on 8.8.8.8, which is what 192.168.1.206 was pinging. 192.168.1.206 was likely ARPing for it on that interface because I'd done a "ping -I" to try and debug, which was a bad test (I should have just used the AR150 "normally", except I didn't want to rely on it as my default router while debugging it). So please ignore the first part of the problem statement and focus on the one from Feb 24, where simply enabling the WiFi causes the problem, as this is reproducible and still consistent with my initial observations.
1 Like
Is there anything in the logs (logread or dmesg) that gives any hint for this issue?
Can you try to break the bridge and operate the wifi as a separate interface?
Is the power supply adequate?
I just dug out an old ar150 from my junk box and reflashed it with 19.07.1 and could not reproduce this initially.
I changed the power supply to an old Blackberry charger that outputs only 4.2 volts and do indeed get this issue. So @trendy yes - power supply.
1 Like
Thanks @bluewavenet and @trendy. I discovered 19.07.2 had been released, reflashed to that, "broke the bridge," and the problem still recurred. Then COVID-19 disrupted my schedule so I never got around to posting the logs. Fwiw my power supply is 1.2A vs minimum requirement is <500mA w/o any USB devices attached (my case - per https://forum.gl-inet.com/t/gl-ar150-power-requirements/1171), but sure, it could still be a bad supply. I hypothesize if the power supply is an issue, the WiFi increases power draw enough to cause this problem, but still it's very strange. I'll try switching supplies when I get a chance.
@mfullerca
It could be the actual usb power supply, the cable, cable connector, socket in the ar150 or even the onboard regulator coincidentally developed a fault.
Maybe time to upgrade to an ar300m or mt300n at half the price.
@bluewavenet and @trendy so I found a known good power supply, and sure enough, the problem doesn't recur. Weird, I've never seen anything like this as usually if the power supply is marginal, other obviously bad things happen vs subtle issues like this.
Btw I do have an AR300M -- the AR150 is my backup and my preferred method of handling major firmware upgrades and other risky config changes is to do them on the AR150 first, get a stable config, and then do the same on the AR300M so I always have a known, good router to switch back to.
BTW @bluewavenet according to https://openwrt.org/toh/start (entry # 491) 19.07.x isn't supported on the AR300M. I flashed a current, non-release build and messed around with it for a few hours and fell into NAND-flash hell. I eventually gave up on that and got it running on NOR-flash but discovered the WAN interface would die under heavy load. I found a page somewhere that says the AR300M won't be supported under 19.07.x and I assume no one wants to help debug this, so I'm back to the AR150.
That is not completely true. It had not been migrated from ar71xx to ath79 when 19.07 was forked, so is not supported in ath79, but is still to be found in ar71xx. ath71xx only supports NOR.
The 19.07- ar71xx version is NOR only and covers all versions of the ar300m (but you have to use image builder to enable wifi on an ar300m-lite, but that is a different story)
NAND hell is easily averted if you have the older uboot on your device, by first flashing NOR then flashing NAND with the NOR firmware. This breaks the NAND firmware making it fail over to a NOR boot.
If you have the latest uboot version it is a bit more complex. Let me know if you would like instructions.
I have run the snapshot ath79 NAND and the NAND-NOR versions with no problems at all.
I hate to say this but the only times I have seen issues under load have been when the power supply has been failing or inadequate 
You could of course have a fault in the device....
EDIT I have updated the toh entry.
@bluewavenet thanks, I flashed the ar71xx version and it works (though the eth0/1 swap is annoying if you are restoring a backup).
Re: the power supply, the AR300M was using a 2A power supply, and I don't have anything larger for < USB-C. It is the same brand and style as the one I was using for the AR150, so I swapped it with another 2A supply I was using on a Raspberry Pi that I believe is good.
Re: NAND, I've probably had enough adventure for this week but is the procedure you're envisioning different that what's at GL-AR300M and GL-AR750S NAND Support (ath79) ? Because I think I did it correctly: flash NOR, boot that, use that to flash NAND, reboot, and bricked. I did it twice, using uboot to recover both times.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.