do all 3 WG devices have the same LAN LED behavior? (as you said, GPIO controlled on one side, and hardwired to the switch on the other side)
because right now I have the other LED to use the netdev trigger for recieve for AP300, and that would be redundant (try deleting LED settings)
No the AP300 LAN LEDs behave as expected. They can be ON, OFF or Net triggered. The default values in the most recent image are OK.
Personally I have set it to use only the green LED and be Net triggered.
Steve
ok I decided to make LED function for all 3 the same since it seems to be the case
heres updated images with TFTP image for AP100
please check LED function, both with the defaults and if you delete the LED settings for all 3
I assumed that LED pins are the same for AP200 and AP100, but it might not be
and for AP100, check MAC addresses
which one is on the label and compare original MACs to openwrt
because I also copied that from AP200
https://www.dropbox.com/sh/st6jsy3q6f60098/AACzDq7SQYOK3CKJj4dYyGuwa?dl=0
I apologise for the delay. I finally had a chance to test these and they look good.
I tftp loaded the image in each case so I haven't (yet) tested the factory or sysupgrade images.
AP300:
MAC address is correct:
Same MAC used in uboot, for OpenWRT eth0, in WGOS and on the lable.
Default LED config:
system.led_lan_data=led
system.led_lan_data.name='LAN_DATA'
system.led_lan_data.sysfs='orange:lan_data'
system.led_lan_data.trigger='netdev'
system.led_lan_data.mode='rx'
system.led_lan_data.dev='eth0'
system.led_lan_link=led
system.led_lan_link.name='LAN_LINK'
system.led_lan_link.sysfs='green:lan_link'
system.led_lan_link.trigger='netdev'
system.led_lan_link.mode='link'
system.led_lan_link.dev='eth0'
LED behaviour:
Network as expected
Power LED green.
After removing the LED config:
Power LED green only.
Power LED can be disabled by setting it to none.
AP200:
No MAC address on the lable.
uboot MAC is: 00:90:7f:b2:c5:c0
OpenWRT MAC is: 00:90:7f:b2:c5:be
WGOS MAC is: 00:90:7f:b2:c5:be
Default LED config:
system.led_lan_data=led
system.led_lan_data.name='LAN_DATA'
system.led_lan_data.sysfs='orange:lan_data'
system.led_lan_data.trigger='netdev'
system.led_lan_data.mode='rx'
system.led_lan_data.dev='eth0'
system.led_lan_link=led
system.led_lan_link.name='LAN_LINK'
system.led_lan_link.sysfs='green:lan_link'
system.led_lan_link.trigger='netdev'
system.led_lan_link.mode='link'
system.led_lan_link.dev='eth0'
LED behabiour:
Network as expected, green also flashes since it's hard wired to.
Power LED is green.
After removing the LED config:
Power LED green only.
Green power LED can be disabled.
Orange power LED can be enabled.
AP100 (close to identical to the AP200):
No MAC address on the lable.
WGOS MAC: HWaddr 00:90:7F:B0:2D:E5
uboot MAC: eth0: 00:90:7f:b0:2d:e7
OpenWRT MAC: HWaddr 00:90:7F:B0:2D:E5
Default LED config:
system.led_lan_data=led
system.led_lan_data.name='LAN_DATA'
system.led_lan_data.sysfs='orange:lan_data'
system.led_lan_data.trigger='netdev'
system.led_lan_data.mode='rx'
system.led_lan_data.dev='eth0'
system.led_lan_link=led
system.led_lan_link.name='LAN_LINK'
system.led_lan_link.sysfs='green:lan_link'
system.led_lan_link.trigger='netdev'
system.led_lan_link.mode='link'
system.led_lan_link.dev='eth0'
LED behabiour:
Network as expected, green also flashes since it's hard wired to.
Power LED is green.
After removing the LED config:
Power LED green only.
Green power LED can be disabled.
Orange power LED can be enabled.
But the really good news is the AP100 WIFI behaviour. It now works fine at both 2GHz and 5GHz. I tested connecting to it in both bands.
AP100 WIFI:
root@OpenWrt:/# iw list
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
* outside context of a BSS
Band 1:
Capabilities: 0x11ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:
* 2412 MHz [1] (19.0 dBm)
* 2417 MHz [2] (19.0 dBm)
* 2422 MHz [3] (19.0 dBm)
* 2427 MHz [4] (19.0 dBm)
* 2432 MHz [5] (19.0 dBm)
* 2437 MHz [6] (19.0 dBm)
* 2442 MHz [7] (19.0 dBm)
* 2447 MHz [8] (19.0 dBm)
* 2452 MHz [9] (19.0 dBm)
* 2457 MHz [10] (19.0 dBm)
* 2462 MHz [11] (19.0 dBm)
* 2467 MHz [12] (19.0 dBm) (no IR)
* 2472 MHz [13] (19.0 dBm) (no IR)
* 2484 MHz [14] (19.0 dBm) (no IR)
Band 2:
Capabilities: 0x11ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
* 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
* 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
* 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
* 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
* 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
* 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
* 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
* 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
* 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
* 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
* 5745 MHz [149] (20.0 dBm) (no IR)
* 5765 MHz [153] (20.0 dBm) (no IR)
* 5785 MHz [157] (20.0 dBm) (no IR)
* 5805 MHz [161] (20.0 dBm) (no IR)
* 5825 MHz [165] (20.0 dBm) (no IR)
valid interface combinations:
* #{ managed } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1,
total <= 2048, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
* [ RRM ]: RRM
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
* [ CAN_REPLACE_PTK0 ]: can safely replace PTK 0 when rekeying
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ MULTICAST_REGISTRATIONS ]: mgmt frame registration for multicast
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
root@OpenWrt:/# iw dev wlan0 info
Interface wlan0
ifindex 7
wdev 0x3
addr 00:90:7f:b0:2d:e5
ssid ap100test
type AP
wiphy 0
channel 36 (5180 MHz), width: 20 MHz, center1: 5180 MHz
txpower 15.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 42 0 0 0 0 4194 42
root@OpenWrt:/# iw dev wlan0 info
Interface wlan0
ifindex 8
wdev 0x4
addr 00:90:7f:b0:2d:e5
ssid ap100test
type AP
wiphy 0
channel 8 (2447 MHz), width: 20 MHz, center1: 2447 MHz
txpower 17.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 27 0 0 0 0 2766 27
Personally I would choose to have the APs set with LAN as DHCP by default. Having to make that change at the command line each time is painful enough even with access to the console. I see no use case where you would want an AP to be 192.168.1.1 and handing out leases.
I would probably also choose to remove the artificial band disable from the AP200 image too. There is a use case for running an AP on a band and monitoring it at the same time on another radio.
Steve
Thanks for testing, I don't mind the wait, was just making sure you dont forget and months dont go by 
OK sounds good, I will be prepping to update my PR and mark it ready, and then post some images built from master instead of release branch.
the whole thing about DHCP as default...again this is just to remain consistent with all other common ath79 devices, you never know when someone wants their AP to actually function as a wireless-only router. Also, guides for failsafe mode would no longer apply, and there would need to be 2 sets of directions. There has been some talk here about having different network profiles in the form of a package but that is up in the air. In general, the definition of an AP is pretty ambiguous. there are single ethernet port devices that are not advertised as AP's and there are also devices advertised as APs that have more than one ethernet port. Marketing or naming of a devices is not really taken into consideration, we see each board as its SOC + peripherals. It's a pain for you because I have you test so many images, 
and perhaps you're not using LuCI (which by the way is part of the images I send if you didnt notice)
Ideally, one sets up a board with just a PC, before connecting it to another network
Also, it might help people to have a wiki page on how to change default for their own personal build, like for example to have wifi on by default and like you said, DHCP by default
Most likely AP200 does not support the other band on either of its radios at the hardware level (the components in the RF circuits of the board), so its negligible. If for some reason the caldata did allow the other band on the same radio you might find the performance to be so bad that its unusable
The DHCP setting is not really a huge deal for me because I do have the console connected most of the time. And, yes, I could use a separate connection directly to a laptop etc. I don't because I power those APs using PoE and the switch I use for it is on an existing subnet. And I already have a 192.168.1.0/24 subnet on my local network which makes things....awkward! I should probably just remove that.
The only real issues I've seen are that it starts handing out leases and I've forgotten to disable it more than once. 
It would be interesting to see if the AP200 SoC radio is limited. I guess I can just boot the AP100 to test that. Would they really have produced a second set of calibration data for it? It does have a different antenna so... maybe.
Anyway thanks for working on this. It will be great to get at least some of those back into service.
Steve
remember AP100 is one radio device only, and this is reflected in the DTS (pcie node set to disabled)
its not a second caldata block, more like the same block listing both bands as usable, we got AP100 to have both frequencies due to the DTS property being removed, because the same caldata actually did include both (and was meant to compared to other devices where they aren't meant to)
different looking antenna coming from the SOC is a good indicator that the one (AP100) is dual-band at the SOC's radio, and the other (AP200) is not.
set of images for Watchguard AP100, AP200, AP300 from master branch
keep in mind because it's from master branch it they are like "beta" and I don't guarentee they are perfectly fine
https://www.dropbox.com/sh/bejal7psaodmk54/AAAAPI_aEWud6PEGw6jRJfc7a?dl=1
I also updated my PR and opened it again
@mk24 @cybrnook @tolcheen @heatman5
If any of you have used my images for AP200 or AP100
could I have name and email so I can tag you in the commit message as Tested-By:
Hi There. Long gone since last contact.
I Took this weekend to update my AP300 to last build and I believe that I bricked one of them that was used as 1st try... I have no more ideas how to revert my shit. 
After flash this new version, I noticed that it was not booting normally so after some digging I discovered that was left behind on this device the setting to tftp boot. So... I simply removed bootcmd parameter and rebooted. After that I noticed that AP doesn't boot anymore. Doing some more research I noticed that bootcmd can't be deleted and originally it have bootcmd=bootm 0x9f0a0000... 
So i also was expecting it to boot failsafe image, but seems not the case... Any ideas to unbrick this guy once we can't access it serial console? Maybe some way to force it to failsafe... I tried some reset hold during boot but nothing... always just power led on. None of other led blink or anything else. I see that ipaddress set on env is up (arp -a show lan mac address while ping have no reply) but there's nothing listening for incoming connections like ssh web telnet or tftp.
how is power LED behaving?
If you think that is the board where we changed bootcmd to include trying tftp:
try power it without ethernet connected, and try with ethernet connected, and see if there is any difference in LED behavior (also difference in the amount of time it takes for blinking to start)
probably a timer would be useful
No matter with or without cable connected during power on just power led turn on. And it just turn solid on. No blinks in any color on power on another leds.
And on any of these tests local ip stated in env variable is being brought up. At least arp show it with correct mac address.
it sounds like you would be able to try TFTP?
you have to set your computer (server) to the ip 192.168.1.101 and offer file "test.bin"
thats assuming that the bootcmd is the way we left it when modified
Nope. I'm wiresharking computer for any connection and after i removed bootcmd requests are not being made to server on my recovery computer...
Where u boot and env settings are saved? In some eprom? I have an eprom programmer and might have any chance of copying from another working device?
uboot environment is in the flash, at 0x40000 (block 4, when blocksize is 64k)
I recommend instead of taking from another board, you read the entire flash from both boards, and do manual editing of just uboot environment, then flash back
I said "manual editing", but keep in mind the beginning of uboot environment is actually a small checksum of the contents, this is mentioned in here
There's a checksum in some place that might prevent manual edit of eprom. Or at least create complications for manual offline editing to inject back bootcmd with correct arguments.
you may try to recreate the checksum before doing anything. Supposedly it is simple crc32 of the beginning of variables to the end of the block
otherwise, have a copy of original, and copy uboot environment from another board, then change some of them back when openwrt boots again with fw_printenv and fw_setenv
We last spoke about adding support for the wifi 6 devices. I have not had any experience with the 100 or 200, but thanks for thinking of me.