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.
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.
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.
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
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.
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?
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.
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.