17 Oct
2014
17 Oct
'14
12:38 p.m.
Max,
We can't do what you're suggesting because the open0 interface is not
operating as a layer 3 interface. It is
bridged to br-openmesh along with bat0. This means that an over-sized
packet (e.g. one that doesn't fit in the
L2TP envelope of size ~1400bytes) arriving at open0 and headed toward bat0,
wouldn't trigger an ICMP
response, and would be unceremoniously dropped.
The ICMP response is triggered by the IP protocol layer (layer 3). That
response is also the only way
a Windows (and I think OS X) client would know that the mtu is smaller than
it thinks.
Assuming this is correct, which is still up for debate, we have two options:
(1) find a way to make the Win/OSX (Android/iOS?) client understand that it
must use a lower mtu
(DHCP is not an option).
(2) remove the bridge and forward at layer 3 (so that ICMP responses would
be triggered, and the
client can discover its mtu).
Alex
2014-10-17 12:06 GMT-07:00 Max B <maxb.personal(a)gmail.com>om>:
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