Beta Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models

[Anubis]

5G client /TV keeps losing connection, about eery half an hour. 6E client stays connected.

Apr 6 19:50:59 cfg_server: cm_updateChanspec call wl_chanspec_changed_action Apr 6 19:50:59 cfg_server: event: wl_chanspec_changed_action_a101 of eid(2) of cfgs(2951) Apr 6 19:50:59 cfg_server: current chansp(unit0) is 1009 Apr 6 19:50:59 cfg_server: current chansp(unit1) is ec32 Apr 6 19:50:59 cfg_server: dump exclchans: Apr 6 19:50:59 cfg_server: old wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c Apr 6 19:50:59 cfg_server: new wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c Apr 6 19:50:59 cfg_server: old wl1_acs_excl_chans:0xd074,0xd078,0xd07c,0xd080,0xd0a5,0xd876,0xd976,0xd87e,0xd97e,0xe07a,0xe17a,0xe27a,0xe37a,0xec72,0xed72,0xee72,0xef72 Apr 6 19:50:59 cfg_server: new wl1_acs_excl_chans:0xd0a5 Apr 6 19:50:59 cfg_server: wl_chanspec_changed_action: Need to restart acsd for AVBL update Apr 6 19:50:59 rc_service: cfg_server 2951:notify_rc restart_acsd Apr 6 19:50:59 acsd: eth6: Selecting 2g band ACS policy Apr 6 19:51:02 acsd: eth6: selected channel spec: 0x1808 (6l) Apr 6 19:51:02 acsd: eth6: Adjusted channel spec: 0x1808 (6l) Apr 6 19:51:02 acsd: eth6: selected channel spec: 0x1808 (6l) Apr 6 19:51:02 acsd: eth7: Selecting 5g band ACS policy Apr 6 19:51:03 kernel: In wl_dfs_cac_notify_status chanspec 0xd028 DFS state 0 Apr 6 19:51:06 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind 0C:96:E6:14:0F:1E, status: 0, reason: Unspecified reason (1), rssi:-37 Apr 6 19:51:06 wlceventd: wlceventd_proc_event(530): eth6: Auth 0C:96:E6:14:0F:1E, status: Successful (0), rssi:-37 Apr 6 19:51:06 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc 0C:96:E6:14:0F:1E, status: Successful (0), rssi:-37 Apr 6 19:51:11 acsd: eth7: selected channel spec: 0xe872 (100/160) Apr 6 19:51:11 acsd: eth7: Adjusted channel spec: 0xe872 (100/160) Apr 6 19:51:11 acsd: eth7: selected channel spec: 0xe872 (100/160) Apr 6 19:51:12 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind 38:B8:00:40:87:5C, status: 0, reason: Disassociated due to inactivity (4), rssi:-40 Apr 6 19:51:12 kernel: In wl_dfs_cac_notify_status chanspec 0xe872 DFS state 1 Apr 6 19:51:14 wlceventd: wlceventd_proc_event(530): eth6: Auth 38:B8:00:40:87:5C, status: Successful (0), rssi:-43 Apr 6 19:51:14 wlceventd: wlceventd_proc_event(559): eth6: Assoc 38:B8:00:40:87:5C, status: Successful (0), rssi:-43 Apr 6 19:51:30 wlceventd: wlceventd_proc_event(511): eth7: Disassoc A8:93:4A:65:F1:EF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0 Apr 6 19:51:35 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 60:8B:0E:06:13:C1, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0 Apr 6 19:51:42 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 6E:C7:72:9F:18:D6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0 Apr 6 19:52:12 kernel: In wl_dfs_cac_notify_status chanspec 0xe872 DFS state 2 Apr 6 19:52:13 wlceventd: wlceventd_proc_event(530): eth7: Auth A8:93:4A:65:F1:EF, status: Successful (0), rssi:-56 Apr 6 19:52:13 wlceventd: wlceventd_proc_event(559): eth7: Assoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-55 Apr 6 19:52:34 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind 16:09:35:44:D6:EA, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:-43 Apr 6 19:52:34 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 16:09:35:44:D6:EA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:-43 Apr 6 19:52:35 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind 16:09:35:44:D6:EA, status: 0, reason: Unspecified reason (1), rssi:0 Apr 6 19:52:35 wlceventd: wlceventd_proc_event(559): eth7: Assoc 16:09:35:44:D6:EA, status: Successful (0), rssi:-45 Apr 6 19:52:39 wlceventd: wlceventd_proc_event(530): eth7: Auth 6E:C7:72:9F:18:D6, status: Successful (0), rssi:-49 Apr 6 19:52:39 wlceventd: wlceventd_proc_event(559): eth7: Assoc 6E:C7:72:9F:18:D6, status: Successful (0), rssi:-49 Apr 6 19:53:30 wlceventd: wlceventd_proc_event(540): eth7: ReAssoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-54 Apr 6 19:53:48 wlceventd: wlceventd_proc_event(559): eth7: Assoc 60:8B:0E:06:13:C1, status: Successful (0), rssi:-50

 

[Tech9]

6E client stays connected.

6E client stays connected to what?

Switch to 80MHz wide non-DFS fixed channels for better Wi-Fi stability.

 

[bluepoint]

Moving on, when using this current firmware release; Merlin 388.2_beta2, the DDNS functionality for both IPv4 and IPv6, works well for me / my router / my setup etc and any type of associated IPv6 query that I run, on either of my own DDNS IPv6 Names (one of which is ****.asuscomm.com) always returns the correct, expected values (See Post #452). It's perhaps worth looking at Posts #466 and #479 too, maybe?

Looks like we are not looking eye to eye. My original post was about DDNS service and not DNS lookup. With my settings below with IPv6 update ticked using blank@asuscomm.com host , are you able to update your IP when it change? Mine can not when IPv6 upodate is toggled 'YES". Inadyn keeps on trying to udate the IP but it can not.

 

[learning_curve]

Looks like we are not looking eye to eye. My original post was about DDNS service and not DNS lookup. With my settings below with IPv6 update ticked using blank@asuscomm.com host , are you able to update your IP when it change? Mine can not when IPv6 upodate is toggled 'YES". Inadyn keeps on trying to udate the IP but it can not.

Maybe not eye to eye but I think we're close enough
I posted about the DNS data, primarily to respond to Post #466, but also, because IPv6 DNS configs have been involved in previous IPv6 DDNS issues too.

My answer to the question you've posted above, when using this current firmware release; Merlin 388.2_beta2 is: Yes, by default, every time.
My version of your previous screen grab I shown below.

Going back to your original Post #447, forgive me for repeating and/or stating the obvious, but the assumptions that I've made are:
a) Your ISP's IPv6 service is fully functional and verifiable via tests made from within your router, from devices on your LAN and external test sites
b) The issue you currently have is not present - IF - the IPv6 Update option shown on the screen-grabs, is toggled to "No"
c) The supposition therefore, is that the Javascript error - identified in Merlin's Post #449 - is what's causing the issue (for you) at present.

That would make sense, yet only a) applies to me! (although we're on the same firmware release; Merlin 388.2_beta2, but with different routers and ISP's)

 

[Dedel66]

Any idea why I am getting this after a dirty update from _388.2_beta1?

Please click on the exclamation mark and you will get further information.
But you are right there is a background picture missing.
In 388.1 it´s ok.

 

[northumberland]

Beta 1 I had issues that caused loss of connectivity to devices that appeared random, changing DNS seemed to cause something to update and got connectivity back for a time.

I also noticed some wireless clients when I chose the wireless network, they'd connect, disconnect and immediatley reconnect.. weirdness!

Upgraded to beta 2 and the problems continued.

* Factory reset seems to have fixed things though I've further testing to do before I enable some options I used previously (encrypted DNS etc). Hopefully I'll either have no problems, it be too able to establish where the problem comes in to play.

Using diversion/skynet and some minor add-ons stored on usb sdd. Lots of clients though.

Not using mesh.

AX88U

Is there an up to date script that cleans/reports outdated variables etc - there was many years ago.

S

 

[Deleted member 77025]

Dirty Update, Uptime 1 Day 20 hours:

No Errors so far, just MIC messages maybe because of AES/WPA3 ?

Apr  6 05:30:09 hostapd: eth6: STA xx:xx:xx:xx:xx WPA: received EAPOL-Key with invalid MIC

 

[ollimoe]

Just ugraded from an RT-AX88u running Beta 2 to an RT-AX88u Pro with Beta 2 and what should I say - runing like a charm - I am tempted to say: FLAWLESS!! Will do further testing over the coming weekend with the new HW ...

 

[bluepoint]

My answer to the question you've posted above, when using this current firmware release; Merlin 388.2_beta2 is: Yes, by default, every time.
My version of your previous screen grab I shown below.

Going back to your original Post #447, forgive me for repeating and/or stating the obvious, but the assumptions that I've made are:
a) Your ISP's IPv6 service is fully functional and verifiable via tests made from within your router, from devices on your LAN and external test sites
b) The issue you currently have is not present - IF - the IPv6 Update option shown on the screen-grabs, is toggled to "No"
c) The supposition therefore, is that the Javascript error - identified in Merlin's Post #449 - is what's causing the issue (for you) at present.

That would make sense, yet only a) applies to me! (although we're on the same firmware release; Merlin 388.2_beta2, but with different routers and ISP's)

Yes to both a and b. C is yes and no, yes because the javascript error is not allowing me to make changes(toggle yes, enable DDNS client after a reset) when I click apply. No because the option to enable ipv6 update is causing inadyn's ability to update both my IPv4/IPv6 IP's to the DDNS server before, that's why I want to try it with this beta2, unfortunately, the javascript error is not letting me test. In the earlier post by @RMerlin, he confirmed that it's still not working but you said it is working for you now with this beta? Can you show the log of inadyn's completion?

 

[learning_curve]

Yes to both a and b. C is yes and no, yes because the javascript error is not allowing me to make changes(toggle yes, enable DDNS client after a reset) when I click apply. No because the option to enable ipv6 update is causing inadyn's ability to update both my IPv4/IPv6 IP's to the DDNS server before, that's why I want to try it with this beta2, unfortunately, the javascript error is not letting me test. In the earlier post by @RMerlin, he confirmed that it's still not working but you said it is working for you now with this beta? Can you show the log of inadyn's completion?

Ahhhh I see

that's why I want to try it with this beta2

Does that ^ mean you're not, yet, using Merlin 388.2_beta2, OR, you are and it still doesn't work?

Can you show the log of inadyn's completion?

Kind of a Yes and No answer, just as you have for C above!

As previously posted, I have a FTTH, Dual Stack, Modem in bridge mode, setup from my ISP.
I have a static, IPv4 address via PPPoE, so this never changes.
I also have a "static" IPv6 address via PPP, but obviously, it's not actually "static" in terms of the router's specific IPv6 address, because the router's IPv6 address is taken from within the "static" 2001: *.*.*.* ::/64 (WAN) allocation, which in turn, provides all device IPv6 addresses, within the "static" 2001: *.*.*.* ::/56 (LAN) allocation.

As a result of both that ^ and my own intentional system choice, my log levels, are currently both set at 'Info' only. I'll need to check those and in reality, re-boot my router, for you to see what you want to check. I'll do that this weekend and post just the ASUS parts (as that's all you're looking at) not the No-IP parts, of the log entries.

 

[bluepoint]

Ahhhh I see

Does that ^ mean you're not, yet, using Merlin 388.2_beta2, OR, you are and it still doesn't work?

I'm at beta2 and had a chance to reset to factory default which i planned awhile ago but I can't test it due to javasript error in the DDNS client page. Thanks in advance to do the test and looking forward for the inadyn log. I wonder why you use the DDNS client if you have static IP's.

You know what it's really not a big deal for me if DDNS ipv6 is not working, I use openvpn if I need to access my network, I'm just curious if that bug was fixed. So, don't even bother to change your settings if it's too much to do Ill just wait for the next release. The problem might just be the DDNS server(www.asus.com) is not IPv6 aware as it's only an IPv4 server.

[C:\~]$ nslookup www.asus.com
Non-authoritative answer:
Server: GT-AX6000
Address: 2600:40xxxxxxxxxxxx::1

Name: cs95619.adn.psicdn.net
Address: 72.21.92.171
Aliases: www.asus.com

 

[Ripshod]

Well I never. Huston we have a problem. Just coming up to 24hrs uptime and my radios both turn themselves off. It's bedtime so any autopsy will have to wait til tomorrow. Only noticed because I couldn't browse the net on my phone and VoLTE was active even though wifi showed connected. Wifi LEDs on the router were out.
Last few lines of the log before reboot.
System Messages:

Apr  4 22:37:43 ripshod rc_service: watchdog 1292:notify_rc stop_obd
Apr  4 22:37:43 ripshod custom_script: Running /jffs/scripts/service-event (args: stop obd)
Apr  4 22:37:43 ripshod kernel: device eth6 left promiscuous mode
Apr  4 22:37:43 ripshod kernel: br0: port 4(eth6) entered STP off state
Apr  4 22:37:43 ripshod kernel: device eth7 left promiscuous mode
Apr  4 22:37:43 ripshod kernel: br0: port 5(eth7) entered STP off state
Apr  4 22:37:43 ripshod kernel: device wl0.1 left promiscuous mode
Apr  4 22:37:43 ripshod kernel: br0: port 6(wl0.1) entered STP off state
Apr  4 22:37:43 ripshod avahi-daemon[5932]: Interface wl0.1.IPv4 no longer relevant for mDNS.
Apr  4 22:37:43 ripshod avahi-daemon[5932]: Leaving mDNS multicast group on interface wl0.1.IPv4 with address 10.0.2.1.
Apr  4 22:37:43 ripshod avahi-daemon[5932]: Withdrawing address record for 10.0.2.1 on wl0.1.
Apr  4 22:37:43 ripshod kernel: device wl0.4 left promiscuous mode
Apr  4 22:37:43 ripshod kernel: br0: port 7(wl0.4) entered STP off state
Apr  4 22:37:43 ripshod services: apply rules error(19227)

wlceventd.log:

Apr  4 22:37:43 ripshod wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind 00:00:00:00:00:00, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0

It happened again after another 24hrs. Factory reset and a rebuild later, I'm on 25hrs and no problem.
I haven't a clue what it was but it's fixed now

 

[oldgringo]

Do you mean disabling IPv6 support on the OpenVPN Server settings, or disabling IPv6 globally on your WAN interface?

Globally on WAN.

 

[roundaway]

RT-AX86U Pro, H/W 1.0. Flashed the latest Asus firmware and then restored to factory defaults. Tried twice to flash, wired connection, beta2 with a failure. The text said firmware upgrade was unsuccessful while the progress bar kept counting to 100%. Anyone else with an RT-AX86U Pro having an issue? Thank you.

 

[aex.perez]

Had to disable IPv6 entirely. DDNS (ASUS) refreshed WAN IP address but never showed on WAN interface. Trying to match settings IPV6 and IPV6 Advanced would turn on IPv6 on LAN side but going into IPv6 log would say disabled on WAN. Trying to get it to work right, router rebooted after cutting my usual SpeedTest results in 1/2 for a few cycles (and I thought it was the scripts that were the issue). Only partially worked when IPv6/IPv6 advanced had different settings (Passthrough/Native). Once IPv6 disabled, been stable. Took to comparing nvram (I save a nvram dump from a working release for this purpose) from prior versions and while some variables were different, once matched the router started going bonkers. DHCP was giving each MAC about 8 temporary IPv6 address at one point. Just couldn't stabilize it, like it used to be. IPv6 testing sites all told me I did not have IPv6 but ASUS IP lookup page would show both my IPv4 and IPv6 addresses.

Just leaving it off for now.

 

[learning_curve]

I'm at beta2 and had a chance to reset to factory default which i planned awhile ago but I can't test it due to javasript error in the DDNS client page.

Got it.

I wonder why you use the DDNS client if you have static IP's.

Good point, well made. Yes the router's specific IPv4 address doesn't (shouldn't!) change, but it's specific IPv6 address does change (albeit only within the vast space of the "static" 2001: *.*.*.* ::/64 (WAN) allocation & only following on from a re-boot / firmware upgrade etc, so it is of limited use with my setup, yes.

By default, I have 'Enable Web Access from WAN' disabled, as most people do & my SSH access is only via Authorised Keys & LAN Only, but - IF - I am going to be away for a while and for some reason, I might need access to something that's only held on any device back there, then in advance, I could temporarily revert the 'Enable Web Access from WAN' setting before leaving, so as to access via DDNS. The No-IP DDNS is just built in redundancy, in case ASUS have DDNS access issues (which they have, in the past). It's a little over the top maybe, but remote access via DDNS is there, if needed & in both cases it's FOC too (only the config is required).

You know what it's really not a big deal for me if DDNS ipv6 is not working, I use openvpn if I need to access my network, I'm just curious if that bug was fixed. So, don't even bother to change your settings if it's too much to do Ill just wait for the next release. The problem might just be the DDNS server(www.asus.com) is not IPv6 aware as it's only an IPv4 server.

I did it anyway. No problem. Here's the extracted, inadyn (sanitised ASUS parts only) taken from the main log:

~
Apr  8 06:42:44 inadyn[3173]: In-a-dyn version 2.10.0 -- Dynamic DNS update client.
Apr  8 06:42:44 inadyn[3173]: Update forced for alias  *.* .asuscomm.com, new IP#  *.*
Apr  8 06:42:45 inadyn[3173]: ppp0 ipv6 address=< *.* >
Apr  8 06:42:45 inadyn[3173]: alias address=< *.* >
Apr  8 06:42:45 inadyn[3173]: request<GET /ddns/update.jsp?hostname= *.* .asuscomm.com&myip= *.* &myipv6= *.* &model=RT-AX86U&fw_ver=3.0.0.4.388.2_beta2 HTTP/1.0^M Authorization: Basic  *.* ^M Host: ns1.asuscomm.com^M User-Agent: inadyn/2.10.0 https://github.com/troglobit/inadyn/issues^M ^M >
Apr  8 06:42:45 inadyn[3173]: [response_update]HTTP/1.1 200 OK^M Date: Fri, 07 Apr 2023 23:42:45 GMT^M Server: Apache^M Content-Length: 0^M Connection: close^M Content-Type: text/html; charset=UTF-8^M ^M
Apr  8 06:42:45 inadyn[3173]: Updating cache for  *.* .asuscomm.com
~

 

[learning_curve]

I'm at beta2 and had a chance to reset to factory default which i planned awhile ago but I can't test it due to javasript error in the DDNS client page.

~ I'm just curious if that bug was fixed ~ The problem might just be the DDNS server(www.asus.com) is not IPv6 aware as it's only an IPv4 server.

Final reference to that ^^ The odd thing, still, is that we're using exactly the same firmware release; Merlin 388.2_beta2, but we're using different Asus routers and ISP's. So, is the issue that you're having (but I'm not) located somewhere within your router itself and/or it's setup and/or your ISP setup and not, within the firmware** release? ** With a caveat for the javascript error that's been mentioned / posted about already in this thread (yet doesn't seem to matter, in my case)

 

[bluepoint]

Got it.

Good point, well made. Yes the router's specific IPv4 address doesn't (shouldn't!) change, but it's specific IPv6 address does change (albeit only within the vast space of the "static" 2001: *.*.*.* ::/64 (WAN) allocation & only following on from a re-boot / firmware upgrade etc, so it is of limited use with my setup, yes.

By default, I have 'Enable Web Access from WAN' disabled, as most people do & my SSH access is only via Authorised Keys & LAN Only, but - IF - I am going to be away for a while and for some reason, I might need access to something that's only held on any device back there, then in advance, I could temporarily revert the 'Enable Web Access from WAN' setting before leaving, so as to access via DDNS. The No-IP DDNS is just built in redundancy, in case ASUS have DDNS access issues (which they have, in the past). It's a little over the top maybe, but remote access via DDNS is there, if needed & in both cases it's FOC too (only the config is required).

I did it anyway. No problem. Here's the extracted, inadyn (sanitised ASUS parts only) taken from the main log:

~
Apr  8 06:42:44 inadyn[3173]: In-a-dyn version 2.10.0 -- Dynamic DNS update client.
Apr  8 06:42:44 inadyn[3173]: Update forced for alias  *.* .asuscomm.com, new IP#  *.*
Apr  8 06:42:45 inadyn[3173]: ppp0 ipv6 address=< *.* >
Apr  8 06:42:45 inadyn[3173]: alias address=< *.* >
Apr  8 06:42:45 inadyn[3173]: request<GET /ddns/update.jsp?hostname= *.* .asuscomm.com&myip= *.* &myipv6= *.* &model=RT-AX86U&fw_ver=3.0.0.4.388.2_beta2 HTTP/1.0^M Authorization: Basic  *.* ^M Host: ns1.asuscomm.com^M User-Agent: inadyn/2.10.0 https://github.com/troglobit/inadyn/issues^M ^M >
Apr  8 06:42:45 inadyn[3173]: [response_update]HTTP/1.1 200 OK^M Date: Fri, 07 Apr 2023 23:42:45 GMT^M Server: Apache^M Content-Length: 0^M Connection: close^M Content-Type: text/html; charset=UTF-8^M ^M
Apr  8 06:42:45 inadyn[3173]: Updating cache for  *.* .asuscomm.com
~

Can you show more logs in the bottom of the last line? Wow you're approximately 12 hours ahead of me.

 

[bluepoint]

Final reference to that ^^ The odd thing, still, is that we're using exactly the same firmware release; Merlin 388.2_beta2, but we're using different Asus routers and ISP's. So, is the issue that you're having (but I'm not) located somewhere within your router itself and/or it's setup and/or your ISP setup and not, within the firmware** release? ** With a caveat for the javascript error that's been mentioned / posted about already in this thread (yet doesn't seem to matter, in my case)

To answer your questions
a. ISP service - FTTH Dynamic DHCP WAN conneection
b. GT-AX6000 reset to factory default after B2 update.
-DDNS service page defaults to off-- I can't make the change cause there is a javascript error.
c. I've seen the inability of inadyn to update the DDNS server with my IPv6 IP from an RT-AX88U 388.2 alpha1 before it was replaced with the RT-AX6000

And finally, you probably have not seen error in that page if you updated on top. Try to change ipv6 update to no then apply, see if it takes.

 

[ColinTaylor]

@RMerlin Did you see the IPv6 DoS Protection bug reported in this thread.

firewall-start generates this line when DoS protection is enabled and Logged packets type = None:

-A ICMP_V6 -p ipv6-icmp --icmpv6-type 128 -m limit --limit 1/s -j RETURN

I think it should really be this:

-A ICMP_V6 -p ipv6-icmp --icmpv6-type 128 -m limit --limit 1/s -j ACCEPT

@RMerlin Sorry to bring this up again but I stumbled upon an old post that mentioned this change:

386.2_2 (13-Apr-2021)
  - FIXED: IPv6 pings were blocked if sent below the rate limit
           instead of above (issue introduced in 42095)

This references this:

rc: fix incorrect ICMPv6 rate control rule · RMerl/asuswrt-merlin.ng@6ee9136

Third party firmware for Asus routers (newer codebase) - rc: fix incorrect ICMPv6 rate control rule · RMerl/asuswrt-merlin.ng@6ee9136

github.com

This fix was in effect reverted with this change:

https://github.com/RMerl/asuswrt-merlin.ng/commit/c990d2c05b118ac415601fb9a4eb8c2fb429b7c7

Merge with 388_20566 (from RT-AX88U) + 5.02axhnd SDK update …
Notes:
  - rc/firewall.c was repatched from the ground up, dropping some
    of our previous changes for the time being, as the 388 changes to
    the firewall will need to be reviewed first