What's your PPPoE server? Yesterday afternoon I got a call from a tech at a
customer location. Yahoo main page loaded. The yahoo mail login page did not.
The customer's linksys router had lost the internet port a few years ago, so
every device was using the ubnt radio in router mode with pppoe, 1492 MTU.
I lowered the MTU on the tech's laptop and everything worked. A bit later I
noticed that the dynamic PPP MTU fixup rules on the MikroTik PPPoE server were
at the bottom of the list and not being reached. Moving those rules to
position 0 solved the customer's issues.
I suspect most consumer routers are better at dealing with PathMTU discovery
blackholes than Windows TCP/IP stack. That *may* be why we only had one
customer complaint. I'm not sure why AirOS didn't handle it, if that's the
case.
I'm not sure how the rules ended up out of order after months of correct
operation. I suspect it happened when I updated the mangle packet marking
rules via a script. But it could be a RouterOS 6.26 bug. I've not dived into
deeply enough to prove any theory. I probably won't bother if it doesn't
happen again. I have scheduled it to upgrade to 6.34.6 tonight.
On August 19, 2016 6:38:46 AM CDT, Sam Morris <[email protected]> wrote:
>On 8/18/2016 2:41 PM, Scott Lambert wrote:
>> On Thu, Aug 18, 2016 at 08:55:29AM -0500, Sam Morris wrote:
>>> There is nothing in the event section of the AC2 server, nor is
>there
>>> any indication of the MTU size getting changed in the radio's logs.
>>> (There is an entry in the event log from when I changed it from 1492
>->
>>> 1500 bytes, but that's the only thing related to this.) (I checked
>>> Saturday and Sunday's logs - nothing to indicate the MTU size was
>>> changed.) I'm continuing to investigate - if anyone has another
>thought
>>> I'd welcome it :)
>>
>> Maybe the AP has been set that way for a long time.
>>
>> Did you recently change any firewall rules to block ICMP?
>>
>> If ICMP is working, PathMTU discovery can work and connections can
>deal
>> with arbitrary MTU limits along the path. The TCP/IP stacks just
>lower
>> the MSS until they no longer receive ICMP packet too big responses.
>
>Hi Scott,
>
>Nope, I'm positive nothing changed on the firewall. (No one other than
>me has the credentials to login to either the AP or the firewall.) I
>did
>consider it, but really don't think the AP MTU size could've been set
>like that all along as it was completely preventing customers
>(especially those with a Mac) from working; as soon as I changed it to
>1500 they immediately started working again. My thinking is if it had
>been set that way all along they wouldn't have ever worked (they've
>been
>working for months).
>
>At this point, after going through all the AP logs and AC2 logs, I have
>
>to think that there was something in that wonky switch port that
>must've
>somehow caused the setting to change. I can't prove that, but can rule
>out anything else (assuming the logs can be trusted). I did see entries
>
>from other APs where I was experimenting with increasing the MTU size -
>
>each time I made a change there was a corresponding log entry in both
>the AP log as well as the AC2 log. The only recent entry is from when I
>
>increased it from 1492 to 1500. There were 15,000+ errors on that port
>on the Netonix, and while I find it difficult to believe the switch
>caused that setting to change like it did, I can find nothing else
>remotely close to offering reasonable suspicion, short of a hacker
>getting into the Rocket and changing it - but were I to hack an AP,
>changing the MTU size wouldn't be high on my list of things to do once
>I
>gained access.... :)
>
>Sam
>
>_______________________________________________
>Ubnt_users mailing list
>[email protected]
>http://lists.wispa.org/mailman/listinfo/ubnt_users
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Ubnt_users mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/ubnt_users
