Apple Airport users and DSL potential issue with ST and fix

If you happen to have a DSL connection or any other type of connection that has a smaller then the standard 1500 MTU size for IP packets and use an Apple Airport for a firewall, you might have packet fragmentation which can cause all kinds of random issues with ST and other programs.

Some of the potential issues with fragmented packets would be any device that uses a local hub action like cameras, hues or other local to hub to cloud back to hub type connection. If a packet is dropped due to fragmentation, the whole round trip process can drop.

Apples solution is to hard code the MTU to the provider setting on all end use devices, since Apple doesn’t allow it to be set on their device.

This is not an ideal solution.

It may be possible to put your DSL modem into bridge mode which will pass on the MTU size to the airport and thus solve the problem.

If you want to find your MTU size you can use the following link:

This issue may not just be limited to Apple Airports but could be any router that doesn’t auto set MTU size.

Hopefully this will help some people who might be having those random issues that seem to be ST hub issues but are really network configuration issues.


Nice write up man. Thanks for the info!

What made you look into this? Just curious.

I am using Cable, but I have a Airport. I also have a linksys I can wire up to see if I still have problems.

Someone else was having problems with my Generic Camera Device where it was working in one location and not another.

After a few hours of remote support, I was able to see that it was a packet fragmentation issue, where the MTU size was lower then what Apple Airport hard codes as 1500.

This causes all packets to be split up and was causing all kinds of issues.

Since the DSL modem was also a NAT, it was also creating a double NAT situation, which isn’t all that bad, but with the MTU size it is really bad.

So, the fix was to put the dsl modem into bridge mode and carry the public IP to the Airport and then it passes through the bridged MTU size of 1492 instead of expecting 1500.

Anyway, hope it helps some people figure out why their ST isn’t working when others are working just fine.

Sigh… I had hoped this was my problem but I switched over to my Linksys 1900AC and I still have intermittent problems. It does have MTU set to auto.

Just cause its Auto doesn’t mean it is working right. Open up a command prompt (on windows) and run

ping -f -l 1492

And see if it responds with a fragmentation response. If so, its a problem.

It’s official… @pstuart is awesome!

I am curious Tim, is this something that ST is finding a root cause to some issues? I really hope MTU size isn’t causing widespread issues. However, I have found almost every DSL connection I’ve seen have MTU set to 1492 instead of 1500 which would cause major random fragmentation issues with ST and cloud to device solutions.

Maybe this is beyond just Apple Airport devices and anyone with DSL or other connection with MTU sizes below 1500.

I wonder if it is at all possible in firmware to modify the hub ping to check for fragmentation and warn users of a network config issue?

I honestly don’t have any answer for that right now. Initially I think this is going to be a small subset of users, but I could be wrong and I will ask around to see what people think about this.

On my Mac, I ran:

ping -D -s 1492

Here is what I received:

ping: sendto: Message too long
ping: sendto: Message too long
Request timeout for icmp_seq 0
ping: sendto: Message too long
Request timeout for icmp_seq 1
ping: sendto: Message too long
Request timeout for icmp_seq 2
ping: sendto: Message too long
Request timeout for icmp_seq 3
ping: sendto: Message too long
Request timeout for icmp_seq 4
ping: sendto: Message too long
Request timeout for icmp_seq 5
ping: sendto: Message too long
Request timeout for icmp_seq 6
ping: sendto: Message too long
Request timeout for icmp_seq 7

This works:

ping -D -s 1472
PING ( 1472 data bytes
1480 bytes from icmp_seq=0 ttl=45 time=76.180 ms
1480 bytes from icmp_seq=1 ttl=45 time=79.273 ms

Even if this does turn out to be a small subset of users. Will support be able to help people fix this? Most people won’t know how to put their modem in “bridge mode”. I am sure with a little poking around I can figure it out, but I have no idea what the change is doing. I am a pretty technical person, and support linux systems, but networking isn’t something I know a ton about.

Yup you have fragmentation, if your MTU is hard coded or set to 1500

I set my router manually to 1472 and connected my hue bulbs back on to ST last night. I’ll monitor it for a bit and see if my problems are fixed. Everything was working fine on my system until about month or so ago and it gradually got worse. Does fragmentation just start out of the blue or does something need to change?

Remember to add 8 to your ping size that didn’t fragment to be your actual MTU size.

Hard to say what causes what but there will be issues with fragmentation for sure with critical timed events like hub to cloud ST type stuff.

Other things like web surfing, will just load a bit slower as all packets are split.

TCP/IP is resilient in the fact that these packets can be fragmented, ie larger transfers.

But since the hub can’t handle this fragmentation well, it times out waiting for the next packet or worse yet, only parses the first packet.

Ultimately, I think ST could test for MTU size on the hub and properly set it so this issue doesn’t occur.

What does adding 8 do? Why not 9 or 10? Just curious.

Thanks for this information. I am going to be cautiously optimistic. Last night all of my bulbs were pretty snappy to respond. I am not sure if it is coincidence or not. Time will tell.

8 bits of overhead to handle the transmission information of the data packet.

Thus if you try the ping test with a value of 1492 and it works then your default MTU size is 1500

I hope this isn’t a widespread issue but I am beginning to think almost all DSL folks are hit by this.

And, if you are behind a double nat then you might have multiple issues if the second nat isn’t configured exactly right.

Anyway, let me know if things improve. Already heard from a few people it solved some random flakeyness in St.

Well… It was short lived. My hue bulbs are back to only responding every 2 or 3 times.

When you set your router to 1472 did you do that on the wan or lan side?

Forgive my ignorance here. I assume since it was on my router it was on the LAN side. I don’t have access to my Modem to make those changes. TWC locks their crap down and I don’t have an admin ID or PW for it.