I tried to set this up in bridging mode, no success, so best to use router mode, I used advanced mode also. Log into your Nanostation and select the tab with the Ubiquiti logo, switch airMAX priority to “None” The access point we’re trying to reach from the 13th floor is the little square boxįirst to note that airMAX is a proprietary protocol used in Ubiquiti products, so best to turn it off if you aren’t sure if it’s a Ubiquiti device you’re talking to. This is a great piece of equipment highly recommended. Ubiquiti make stuff that works for outdoor wifi, expect to pay around 70-100£ for a Nanostation M2. (I hope my notes are still comprehensible.Getting a reliable wifi connection can be a paid in the backside.Ī solution is a Ubiquiti Nanostation M2, for the unenlightened that’s one of these – Signal wouldn’t connect.Īs soon as I set the MTU to 1452 on the client, Signal does connect. I tried setting the MTU to as low as 1200 on the NanoStation for all interfaces but this made no difference to the Linux client, e.g. It returns an error if DF is set: ip li set mtu 1500 dev ping -c1 -s 1472 -M dont I am also pretty sure the NanoStation does properly fragment. I can prove the Kabelbox at least sometimes does that properly (commands run at NanoStation): XW.v6.3.2-cs.33267.200715.1627# ip link set mtu 1500 dev ath0 To my knowledge both the NanoStation and the Kabelbox routers should transparently fragment packets larger than the the next hop’s MTU. traceroute -mtu showed 1452 between Kabelbox and Vodafone (this seems default for DS-Lite over PPPoE).ip link on the NanoStation showed 1500 for LAN and 2268 for WiFi (that is okay for 802.11).ip link on the Linux client showed 1500 (pretty standard to my experience).Setting the MTU to 1200 by chance removed the symptoms. My researchĪfter some poking around in the dark I found this is probably MTU related. The programs would try but never receive a response, because either request or response packets/frames were dropped.
Nanostation loco m2 transmit failure android#
Signal desktop and Android app wouldn’t connect/update (actually the most reliable test I found)Īll issues above are timeout issues.web pages sometimes didn’t load (even the same URLs sometimes did, then didn’t).Raspberry Pi couldn’t send system management emails for many days.Raspberry Pi couldn’t establish SSH connection for many days.I have not yet found a minimal test to demonstrate the issue. This was pretty hard to debug because the problem is not deterministic and at least seems not to be permanent. Linux client (routinely a switch + Raspberry Pi, for debugging direct connection to laptop with Debian Stretch).Ubiquity NanoStation loco m5 (WiFi client, IPv4 router, OS based on Linux 2.6.32.71).WiFi 5GHz link (Kabelbox provides a seperate “Backbone” SSID)."Kabelbox" (German marketing name for cable box, combined cable modem + router + WiFi AP).Here is kind of a network graph: Vodafone - Kabelbox ) ) ) ( ( ( NanoStation loco m5 - Linux clientĭS-Lite over PPPoE 192.168.0.0/24 192.168.157.0/24
Nanostation loco m2 transmit failure how to#
Overall question is: Why does setting MTU to 1452 solve any Internet connection problems and how to fix the root cause? I would prefer not to decrease the MTU for the whole network and I’d very much like to understand what’s actually going on. I don’t understand the root cause yet but the workaround is: set the MTU to 1452 on the client. 2 weeks my Raspberry Pi on site couldn’t establish an SSH link to the Internet. At first everything seemed (at least) fine but since some weeks general “Internet stability problems” increased and since approx. In our church we get Internet uplink from a friendly neighbor’s WiFi.
0 kommentar(er)
