I’m trying to do development work on the AR150, so I need to build OpenWRT from source. Support for the AR150 appears to have been integrated into the CC branch in git. However, it seems incomplete: when I boot the OpenWRT image that I built, it finds the WAN and LAN ethernet interfaces, but does not find the wireless interface.
Is this a known issue? Do I still need part of the patch from the GL.iNet github repo?
I’ve attached the boot log.
It turns out what I built from source was the head of the tree, not Chaos Calmer. I haven’t been able to get Chaos Calmer to build an AR150 image with the github patches.
The default OpenWrt firmware don’t have wireless enabled. But seems you don’t have wireless driver loaded???
AR150 patches is in Trunk, but there may be bugs.
AR150 patches is not in CC. We submitted patches but the developers didn’t merge it. You’d better use our git source directly because the CC patches may not apply due to that OpenWrt continuously update the CC repo.
Yes, the wireless driver isn’t loading; question is why. Can you give me a hint where to look? Could this be an issue with the boot ramdisk? You are right that the CC patches don’t work on the head of the CC branch. Probably not worth debugging, but I do want to be able to run the head of some branch, whether it’s CC or the trunk.
Thanks for the response!
when you do “make menuconfig”, be sure to select the right profile and you can check if the “ath9k” driver is select or not.
In your current firmware, do “lsmod” to display the kernel modules and check if there are ath9k module
<span style=“color: #222222; font-family: arial, sans-serif; font-size: 12.8px; line-height: normal;”>The ath9k module is being built, but not ath9k-usb, which I think isn’t needed (right?). I went in and added a bunch of stuff (including ath9k-usb), and am rebuilding, so I’ll try again and do the lsmod to see what’s going on. Thanks!</span>
This is interesting:
root@OpenWrt:~# lsmod
nls_base 5008 1 usbcore
usb_common 1192 1 usbcore
usbcore 118012 0
root@OpenWrt:~# modprobe
Usage:
modprobe module
root@OpenWrt:~# ls /lib/
ar71xx.sh functions/ libfstools.so libsw.so libvalidate.so preinit/ wifi/
config/ ld-musl-mips-sf.so.1 libgcc_s.so.1 libubox.so modules/ uboot-envtools.sh
firmware/ libblobmsg_json.so libjson_script.so libubus.so netifd/ uci/
functions.sh libc.so libsetlbf.so libuci.so network/ upgrade/
root@OpenWrt:~# ls /lib/modules/
3.18.17/ 4.1.16/
root@OpenWrt:~# ls /lib/modules/4.1.16/
ath10k_core.ko ath9k_htc.ko lib80211_crypt_ccmp.ko lib80211_crypt_wep.ko usb-common.ko
ath10k_pci.ko lib80211.ko lib80211_crypt_tkip.ko nls_base.ko usbcore.ko
root@OpenWrt:~# modprobe /lib/modules/4.1.16/ath9k_htc.ko
failed to find dependency mac80211
failed to find dependency ath9k_hw
failed to find dependency ath9k_common
failed to find dependency compat
failed to find dependency ath
failed to find dependency cfg80211
1 module could not be probed
- ath9k_htc
root@OpenWrt:~#
It is “ath9k”, not ath9k-usb or ath9k-htc
From your info, the whole wireless driver is not built at all, including ath9k (ath9k_hw, ath, ath9k_common), mac80211 etc.
Check your menuconfig
I was able to build a version of the trunk that worked, but it was buggy. I realized the reason chaos calmer wasn’t building was that I’d forgotten to remove the tmp directory after patching the tree. Once I did that, I was able to get an AR150 build. Unfortunately, flashing that to the router bricked it. I don’t know if this is the result of failing to wipe the configuration, or if the chaos calmer build is simply broken.
So now I’m trying to access the u-boot web UI, but it’s not working. I hold down the button, wait for the five flashes and then let go, and I get the little burst of flashes on the red LED. At this point ARP for 192.168.1.1 works, but when I try to connect to port 80 with my browser, the connection times out–there’s no response to the TCP SYN packet. If I try to connect to any other port (I tried them all!) I get an RST, so the TCP stack is sort of working.
Here’s the TCPDUMP output:
12:37:23.809166 IP 192.168.1.2.47201 > 192.168.1.1.20: Flags [S], seq 727319644, win 29200, options [mss 1460,sackOK,TS val 19684815 ecr 0,nop,wscale 7], length 0
12:37:23.809287 IP 192.168.1.1.20 > 192.168.1.2.47201: Flags [R.], seq 0, ack 727319645, win 29200, length 0
12:37:28.821121 ARP, Request who-has 192.168.1.1 tell 192.168.1.2, length 28
12:37:28.821220 ARP, Reply 192.168.1.1 is-at e4:95:6e:40:60:81, length 46
Is it possible that some of the TCP options linux is sending are causing the stack to reject the packet? Unfortunately I don’t have a Windows machine, so I can’t try that.
OK, I’ve unbricked the firmware. It looks like the TCP stack is broken in the following way: if a TCP SYN is received on port 80, but the SYN+ACK is lost, then no further SYNs will be responded to. There may be more to it than this, but the bottom line is that I was able to upload the stock firmware through u-boot using this information–the reason it wasn’t working before was a NAT problem, and when I bypassed the NAT the connection succeeded.
I suspect that this SYN problem is why you sometimes hear from people that they weren’t able to access the u-boot web page.
Hi, I can send you working firmware and/or config and diff for ar150 or a tar of my fresh clean buildroot. I found git repo and based my buildroot on it. Actually I can choose AR300M target also. My firmware has all features of stock plus all mesh stuff from qmp big-node without excess, all important wifi drivers, ad-block, usb encryption, extroot, dns-sec, pineapple, d00mb0x, borgbox, comprehensive strict firewall.user script I made and converted from a good web-based firewall generator, essential scripts, all cronjobs in seperate directory, my extensive configs with sensitive info removed, improvements to certain key files in /etc and it’s bmx6 mesh-ready with upto 7 radios using a 7-port plugables hub. And much more!