2.x upgrade has been a nightmare. Several problems but this is a show stopper.

  • 4
  • Question
  • Updated 3 years ago
  • Answered
I am getting the square of death in the water fall when I access smartSDR or the ios app via the 2.x smart link.  The IOS app via smartlink is useless unless I enable a seperate vpn to that network that the radio resides on.

Everything works fine if I use the VPN.

According to the Facebook experts the radio is having fragmentation and that is why things are broke only on the smartlink mode. Ok I was remote last week and decided to wait until I was physically at the radio to test. 

I did a wireshark/tcpdump and see the fragmentation.

Here is the problem. I have jumbo frames and the MTU set to 9000 the entire path to the cable modem ( I have a 1gig symetric connection.)

According to my switch, the radio is connection at 1000 full duplex. It is impossible to hard set the network settings on the radio, thus it is impossible to troubleshoot.

The support I have seen on this is that people have changed a setting and things start working?

I do not run consumer gear. Thus ideas where to go?

1. I have jumbo frames enabled the entire path.
2. MTU is set to 9000 the entire path except the radio which I can not verifiy.
3. The radio ethernet is connecting at 1000 full duplex.
4. I ran a sniffer via a spanned port on the local switch and and see fragmentation on the local port. This means the radio is probally using a low mtu for some odd reason.
5. I have 1gig symetric with static ip space.
6. I am running a complete ubiquiti stack, all of the firmwares are current version.
7. Other udp fragmentation sensative protocols like voip, and L2TP work fine.
8. Everything works fine when accessing the radio via L2tp, openvpn, and Softether vpns. 
9. The radio is installed on a secure iot lan segment due to the fact that the OS is not accesible thus its security level can not be verified.


This particular 2.x problem is a showstopper since I can have the same working functionality with a 1.x firmware.  I am also having the audio drop problem when running digital modes, but that has a work around. 
Photo of David H Hickman

David H Hickman

  • 48 Posts
  • 4 Reply Likes
  • annoyed

Posted 3 years ago

  • 4
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1057 Posts
  • 1101 Reply Likes
Official Response
Tim's comment provides our most current information on this problem.  The incidence is low -- we didn't see this at all during testing of v2.0 which lasted several months with something like 50 people testing in a large number of environments, ISPs, etc.  My personal guess (which is probably wrong) is that it is an issue in a core open source router protocol implementation that rejects fragmented UDP packets.  This source then got passed around like a virus.  I have virtually no data to support this -- it's just a guess.

The unfortunate thing is that the fix we've seen solve the problem has typically been to switch a setting or for the customer to replace their router.  I don't want anyone to have to do either of these things if it's something we can fix.  Our alternative to using the fragmented protocol is write our own fragmenter/assembler on either end and not rely on this part of the UDP/IP protocol.  We have an issue for our engineering team to go investigate this and see if we can fix it (I suspect we can).  My preference would be a fix in our software that doesn't rely on this part of the protocol or checks to see if we can and, if not, ratchets down to our own fragmenter/assembler.  We'll get to this as soon as we can.  If you are having the problem, please enter a help desk ticket and let Tim know and when we believe we have a solution I'd like to send it to you to verify (because we have not see this problem except in one case where we couldn't get a Maestro to play remotely).