You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current shared/src/wg.rs code has ip link set mtu 1420 ... hardcoded, which is presumably derived from 1420 B payload + 54 B wg header + 20 B IPv4 header, and sums up to just under 1500 B, which is a typical MTU you'd see on eth0 interface.
Such calculation of course breaks down with IPv6, where header is 40B, causing fragmentation on 1500B ifaces.
This might be somewhat related to #15.
But more generally, if innernet is used over e.g. batman-adv mesh (which makes sense to use with such overlay network), MTU can be something like 1450 there anyway, so switching 1420 -> 1400 in the code won't cover this use-case like configurable MTU value might.
Given that "inn up" operation creates interface, sets mtu and immediately tries to contact innernet-server over it, I think such mtu adjustment might need to be done by innernet tool itself, as doing that after it runs or from some netlink event-monitor might be too late or at least racy, and tool will fail if mtu prevents it talking to server for long enough.
Thanks!
The text was updated successfully, but these errors were encountered:
Sorry for the late reply! Just pushed a change to make MTU configurable via the CLI, ex. inn --mtu 1350 up foo. Will also add some logic in to set the default MTU to 1400 if the network's CIDR range is IPv6.
Hi,
Current shared/src/wg.rs code has
ip link set mtu 1420 ...
hardcoded, which is presumably derived from 1420 B payload + 54 B wg header + 20 B IPv4 header, and sums up to just under 1500 B, which is a typical MTU you'd see on eth0 interface.Such calculation of course breaks down with IPv6, where header is 40B, causing fragmentation on 1500B ifaces.
This might be somewhat related to #15.
But more generally, if innernet is used over e.g. batman-adv mesh (which makes sense to use with such overlay network), MTU can be something like 1450 there anyway, so switching 1420 -> 1400 in the code won't cover this use-case like configurable MTU value might.
Given that "inn up" operation creates interface, sets mtu and immediately tries to contact innernet-server over it, I think such mtu adjustment might need to be done by innernet tool itself, as doing that after it runs or from some netlink event-monitor might be too late or at least racy, and tool will fail if mtu prevents it talking to server for long enough.
Thanks!
The text was updated successfully, but these errors were encountered: