Not that I'm arguing in favor of layer 2 vs layer 3 forwarding (although we're already pretty deep in certain parts of layer 2 implementations), but why can't we just match the MTU of the open0 interface to the bat0 interface? On 10/17/14, 11:51 AM, Alexander Papazoglou wrote: Hello mesh-dev. I think we may finally have an explanation of the vexing issue of "I can't connect to the internet over peoplesopen.net." Marc and I spent some time staring at wireshark dumps and thinking about why some clients are unable to consistently connect via the tunnel last night. I think Marc came up with a disappointing but correct answer: it is basically an mtu issue (mtu is not being discovered correctly), BUT there is no good fix because we are tunneling at layer 2. When a packet arrives at a node from a client with too large an mtu, what SHOULD happen in a normal forwarding situation (per RFC 1191) is that the node issue a ICMP "Destination Unreachable" packet with a "Fragmentation required" code. The client then uses this information to reset its mtu. This doesn't happen because we aren't really forwarding (forwarding happens at layer 3). Instead, our interfaces (open0 and bat0) are bridged. So if a frame coming from open0 doesn't fit into bat0 it most likely gets silently dropped. So bridging open0 with bat0 is a disaster. A quick fix might be to replace bridging with forwarding (at the IP level). I suspect this is not the right thing to do. It might be better to abandon the idea of meshing at layer 2; there are numerous advantages to this. In any case; we should discuss options this Tuesday. Alex _______________________________________________ mesh-dev mailing listmesh-dev@lists.sudoroom.orghttps://lists.sudoroom.org/listinfo/mesh-dev _______________________________________________ mesh-dev mailing list mesh-dev(a)lists.sudoroom.org https://lists.sudoroom.org/listinfo/mesh-dev

Can we get a more clear understanding of how exactly we might reproduce these issues? All of my desktop clients (mac osx, linux, windows 7) seem to be able to connect. They're all able to view youtube videos and seem to browse the web fairly regularly. My android phone is working for 90% of applications, although it looks like maybe some of the apps aren't connecting reliably. That being said, some of these apps seem to always have some sort of connectivity issues and I'm having a hard time isolating them. Furthermore, isn't this MTU problem an issue that would occur on every batman-adv network that is connected to the internet? I'm not able to articulate this as well as I'd like, but I'm not seeing how this is specific to our particular network structure... Also - tried this on my picostation: root@my:~# iptables -t mangle -A POSTROUTING -s 10.0.0.0/8 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 root@my:~# iptables -t mangle -A POSTROUTING -d 10.0.0.0/8 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 I'm wondering, though, that if this is also layer 3 routing, it probably won't flag the sort of issue that you're describing... I'm curious though, if the scenario you've described is accurate, why wouldn't the bridge (which is layer 3, and which has an ip address and a set mtu) respond with the ICMP response? In terms of layer 3 traffic, we have a client with a layer 3 ip addr and then we also have a mesh node with a layer 3 ip addr (which is the bridged interface). Also - are these only hosts which have dhcp clients that don't respect the MTU option? Hopefully catch you all on Tuesday, but things have been a little crazy on my end, so we'll see.... On Fri, Oct 17, 2014 at 12:38 PM, Alexander Papazoglou <papazoga(a)gmail.com