Messages

I Agree with above comment. I use AWS R53 and Tunnel Broker(HE.net) which are built in options in the old dyndns client. They don't exist in the ddclient settings. It doesn't  have to be an all in one in my opinion. I've seen projects for aws53 updates that could maybe be worked into a new module. For example: https://github.com/crazy-max/ddns-route53

The FCC6 fixes seem to have done the trick. Wifi is up and working and dmesg is much better

Code Select Expand


ath0: <Atheros AR938x> mem 0xf0600000-0xf061ffff irq 16 at device 0.0 on pci2
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] LDPC transmit/receive enabled
ath0: [HT] 3 RX streams; 3 TX streams
ath0: AR9380 mac 448.3 RF5110 phy 3172.10
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000


Thanks thats all i ask. All my research points to the missing FCC6 reg domain being the culprit, but well aware it may not fix the issue.

Will the fixes for reg_domain be present in 19.7? I have an AR9380 card that's currently not usable.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194336
https://svnweb.freebsd.org/base?view=revision&revision=343493

Card:
https://wikidevi.com/wiki/Rosewill_N900PCE

Dmesg:

ath0: <Atheros AR938x> mem 0xf0600000-0xf061ffff irq 16 at device 0.0 on pci2
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: ath_getchannels: unable to collect channel list from hal, status 12
device_attach: ath0 attach returned 22

Then put in a NO-RDR rule with a SOURCE alias for the IP of your WSUS server. I do that as well for the devices that do not function properly behind the transparent proxy(smart tv + netflix for example).

That image is the proxy whitelist, NOT the Redirect rules.
You need "NO RDR" rules under Firewall->NAT->Port Forward
You basically clone the proxy redirect rule, change it to NO-RDR near the top and set destinations to an alias of type host(s) containing the windows update servers.

I wish i could find some good documentation on it, but have yet to find it. The whitelist doesn't change how the traffic is treated, it just changes whether or not it's allowed thru. Setting the NO RDR rules makes the windows update bypass the proxy altogether.

I attached an example of one of my ipv6 no redirect rules for https.

Like i mentioned in another similar thread, create "NO RDR" rules with the windows update servers in an alias as destination and see if that helps. I don't do wsus rules personally but it fixed some sites that just don't work via transparent https proxy for me

For any sites that I have that don't behave properly with the transparent SSL proxy i create an ALIAS containing the destination netblock or hosts with the issue and then create "No RDR (NOT)" rules under Firewall -> NAT -> Port forward and put the alias in the destination. It may take a while to get the alias right given this is windows update. I'd start with the names failing in the logs. I have one rule now for crashplan backups so they don't go thru the proxy, and i have another for iboss on my sons school supplied ipad and it works well.

You'll loose the ability to cache the updates but at least they will work.  Otherwise you are looking at forcing proxy settings using manual proxy config, or a wpad server, or sending the proxy as a dhcp option(not sure you can do this with opnsense)