After hearing this we upgraded again to version 6.38 but results were the same. So to be safe we downgraded all AP’s back to version 6.30 and everything started working again.
All AP’s have a public IP Address and use PPPOE for authentication. Clients receive private ip address from allocated subnet of AP. srcnat - masquerade with service address of subnet customers are receiving ip from.
This is just a few of the different AP’s that were effected. We have yet to determine if any of the others are having issues yet or not.
RB433AH - Atheros AR5413 Radios
RB433GL - Atheros AR5413 Radios
SXT HG5
SXT G-5HPnD r2
Would like to know if anyone else has seen this issue and if there is any resolution? We want to get back to the latest version of software.
Maybe a problem with MTU ?
Try adding this to the config:
/ip firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
When your infrastructure permits it you can also try to have 1500-byte MTU on your PPPoE interfaces.
This requires an oversized MTU on the transport network between the PPPoE peers. So you have to
validate that this is possible. You need at least 8 bytes more MTU than is default.
(normally the network MTU is 1500 so the PPPoE MTU is 1492 or less and the users who expect 1500
byte MTU and have misconfigured firewall will get trouble, so when you can raise the transport network
MTU to 1508 or 1512 and the PPPoE MTU/MRU to 1500 you can avoid some of this trouble)