{"@attributes":{"version":"2.0"},"channel":{"title":"goos.blog","link":"http:\/\/goos.blog\/","description":"goos.blog","generator":"Hugo -- gohugo.io","language":"en-us","lastBuildDate":"Sun, 31 Aug 2025 00:00:00 +0000","item":[{"title":"Cisco 1572 series wifi APs","link":"http:\/\/goos.blog\/2025\/08\/outdoor-aps\/","pubDate":"Sun, 31 Aug 2025 00:00:00 +0000","guid":"http:\/\/goos.blog\/2025\/08\/outdoor-aps\/","description":"

protip to oems: make your ca last for 40 years<\/em>\n\n\n<\/svg>\n<\/a>\n<\/span>\n<\/h4>

I recently acquired four cisco 1572EAC wifi APs for uh…. like 40$ a radio.<\/p>\n

I run a cisco 9800-CL vWLC at home for my wifi. The existing APs in my infra are a mix of 2802i and 3802i’s, and on WLC version 17.16.01 they work just fine.\nAdding new APs has literally been as simple as adding the s\/n to the allow list and plugging the AP into a switchport.<\/p>\n

Until I got these 1572’s.<\/p>\n

They refused to join with the message “AP Auth Failed”.<\/p>\n

Given that these were “new open box” i figured they had ancient firmware on them, and I was right.<\/p>\n

tl;dr they were failing to join because of this issue:<\/p>\n

Field Notice: FN63942 Cisco Wireless Lightweight Access Points and WLAN Controllers Fail to Create CAPWAP Connections Due to Certificate Expiration<\/a><\/p>\n

The link title really says it all. Certs were baked into the firmware at manufacturing time, and they’ve since expired.\nIf a radio was kept up to date over the years, it wouldn’t be an issue. BUT. Mine weren’t.<\/p>\n

The official solution to this is to just ratchet back the clock on the WLC to sometime before December 2022.<\/p>\n

Naturally, this doesn’t work.<\/p>\n

My next option is to tftp in newer firmware<\/a> that has newer certs. Having done many a switch in my day, I feel confident.<\/p>\n

Out comes the serial cable and I reach for my knockoff Knipex to crack open the console port cover plug.<\/p>\n

I plug ’er in and uh…… how do you update a cisco lwap from tftp again?? There’s no copy command, no archive command, nothing???<\/p>\n

A google turned up this: debug capwap console cli<\/code> which enabled a lot of the cli commands I’m used to.<\/p>\n

HOWEVER. Even though I could ping my tftp server (which was on the same L2 domain as the radio), I couldn’t actually tftp files from it. Even after setting ip tftp source-interface<\/code> and stuff. Weirdness.<\/p>\n

I remembered that modern Cisco bootloaders have tftp support too. I decided to try that.<\/p>\n

A few googles and some frustration later and I had this working set of commands:<\/p>\n

# Interrupt boot at bootloader with BREAK signal (delete on macos using screen)<\/span>\n<\/span><\/span>\n<\/span><\/span>set IP_ADDR 192.168.20.250\n<\/span><\/span>set NETMASK 255.255.255.0\n<\/span><\/span>set DEFAULT_ROUTER 192.168.20.1\n<\/span><\/span>\n<\/span><\/span>tftp_init\n<\/span><\/span>ether_init\n<\/span><\/span>flash_init\n<\/span><\/span>\n<\/span><\/span>format flash:\n<\/span><\/span>\n<\/span><\/span>tar -xtract tftp:\/\/192.168.20.254\/c1570-k9w8-tar.153-3.JPT3.tar flash:\n<\/span><\/span>\n<\/span><\/span>set BOOT flash:\/c1570-k9w8-tar.153-3.JPT3\/c1570-k9w8-tar.153-3.JPT3\n<\/span><\/span>\n<\/span><\/span>unset IP_ADDR\n<\/span><\/span>unset NETMASK\n<\/span><\/span>unset DEFAULT_ROUTER\n<\/span><\/span>\n<\/span><\/span>boot\n<\/span><\/span><\/code><\/pre><\/div>
This worked, and worked well. The APs came up and joined the controller.<\/p>\n
I’d hate to think about what I’d do if I had hundreds of these things though…….<\/p>"},{"title":"Changing the ipv6 pools on a rke2 k8s cluster","link":"http:\/\/goos.blog\/2025\/08\/a-new-address\/","pubDate":"Sat, 23 Aug 2025 00:00:00 -0400","guid":"http:\/\/goos.blog\/2025\/08\/a-new-address\/","description":"
there’s no place like ::1<\/em>\n\n\n<\/svg>\n<\/a>\n<\/span>\n<\/h4>
A short one today to get me back into it:<\/p>\n
As part of my rework of my home network and various services, I’ve been moving more and more things into various k8s clusters. 
\nI started this process by re-using fd16:feed:f00d::\/64<\/code> as the pod network in a few different clusters. 
\nNow that I’ve decided to use fd00::\/8<\/code> for LAN as well, I decided to give these clusters different subnets - I might want to do weird mesh networking in the future<\/p>\n
I started with the cluster that backs auth.thegoos.cloud<\/code>, my Authentik instance. A quick few googles showed that the general process for this was to:<\/p>\n