MtuIssues

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
TableOfContents
from /SateLites/MtuIssues --- on moinmoin convert for zope
=== IPcop ===
=== document lates ===
If what Brendan is suggesting is true then you could use a Mikrotik 
router (demo mode should do it) to Mangle the packets to the required MTU
see www.mikrotik.com
> this is almost certainly an MTU issue.
> For clients not connected directly to the gateway node you may see
> problems (I did anyway ) with certain sat systems (Direcway 4020 in 
my
> case which has an underlying MTU of 580)
>
> LW Knows about it for at least 6 months but has yet to resolve the
> issue, don't hold your breath !
>
> try setting the MTU on the gateway eth0 port to 580 and see if the
> problem goes away (NOTE MTU of 580 may not be correct for your
> particular setup)
>
> if that fixes it add the following line to the end of
>
 * /etc/init.d/rc.local
 ifconfig eth0 mtu 580
> you only need to do this on the gateway
> > We have a customer who is trying to access one of his 
suppliers
web
> > sites in order to order stock. Half way through the order 
he
> > goes to a specific page and the page fails to successfully
> > load. We have successfully accessed the page from a PC 
between
> > our gateway node and the satellite link, and we can
> > successfully access the site from an PC sat on the ethernet
> > port of a meshbox (non gateway), however we can not
> > successfully access the site if we connect to the same mesh
> > box via a wireless ethernet bridge.
> >
> > My past experience , not with wireless, would suggest an 
MTU
> > problem.
> We have a customer who is trying to access one of his 
suppliers web
> sites in order to order stock. Half way through the order he
> goes to a specific page and the page fails to successfully
> load. We have successfully accessed the page from a PC 
between
> our gateway node and the satellite link, and we can
> successfully access the site from an PC sat on the ethernet
> port of a meshbox (non gateway), however we can not
> successfully access the site if we connect to the same mesh
> box via a wireless ethernet bridge.
> 
> My past experience , not with wireless, would suggest an MTU
> problem.
> 
> 
> Comments and suggestions please.
we have several issues of those kind in our deployments....
we investigate a lot and are now ready to shhare this exoperioence
surely as we succeeded in reprioduce the issues and fix them.
Observation:
1 - A gateway node directly connected in back2back eth with a sat modem
and 3 repeaters linked wirelessly to the gateway. MTU hasn't been
changed from the default
The client A connected wirelessly to a repeater coulnd't surf very well
. Tcp connection seems to be reseted and dropped or disconnected
Client B is directly connected to the gateway in wireless. He has no
issue to surf. all transfers are ok.
leechtest from repeater nodes are failing in 90% of the time after
transfering several kb. leechtest on gateway node are okay.
Investigations:
A datagrams analysis on the gateway , repeater and clients are showing 
a
fragmentation problem whit client A. However no fragmentation problem
with client B... In looking deeper, we saw the gateway was loosing
ipfrag_time bits in datagrams when natting from wireless tunnels to the
eth.
Deeper again we understood the problem was in ipfrag bits stacks and 
NAT
+ TUNNELS. When Client A (connected in wireless repeater) is surfing on
the net, his datagrams are encapsulated in TUN0 interface with a MTU
change from 1500 (Wlan0 interface) to 1450 (TUN0), then going through
the Tunnel toward the gateway. At this time datagrams is supposed to be
translated in the eth0 address (NAT rules) of the gateway and then
changing the MTU from 1450 to 1500...
We noticed then when we add a passive or active network equipment
between the gateway and the modem (eg: hub, switch, router or a Linux
IPCop distro) it fixes the problem.
Which means there is definitivly a problem with NAT/fragmentation 
causing some MTU problems on a gateway node directly connected in a Sat
modem or in back to back eth connection eg:
(MESHNODES <-- wireless links --> MESH GATEWAY <--eth cross-cable
back2back--> MODEM) ......
=== Jérémy Lacroix -- Linux-Services ===
Déploiement réseaux sans fils / logiciels libres / création web
tel: 0870 21 4312 -- 
http://www.linux-services.fr/ 
> "Wireless" > 
> What I fail to see with Bredons suggestion, but I've not tried it 
yet,
> is why the mtu on the gateway node would effect what is happening
> on a remote node, and why on the remote node its works on the 
ethernet
> but for wireless clients, unless there is some pmtu discovery stuff 
at
> work. But as I said this does look like an mtu problem, although I
> would have thought that if a wireless mtu problem existed we would 
see
> it on intermesh boxes links because of the overhead of the tunnels 
and
> encryption.
Whilst I agree that it does not seem entirely logical that this should
fix the issue, in my setup it did, I think that information concerning
fragmentation isn't always getting passed back down the mesh and there
may indeed be some PMTU issues.
Since details of what happens in the mesh and how the various
locustworld scripts configure everything is not well documented it's
hard to make a complete diagnosis. 
I don't see why one would need to add a router (or why this would
automatically help ) since the MTU can be set at the gateway, manually
for testing then automatically on boot by adding the line 
 * ifconfig eth0 mtu 580
 * to the end of 
 * /etc/init.d/rc.local
this 'fix' will be broken any time you update the version using
getandverify Why, if it's not a LWmesh issue do I not have any problems with my
Staros links off this system or over my wired ethernet one other issue for us poor satellite victims is the need for the
DNSchains to be set up so that we are using the Sat provider's proxyed DNS server instead of the locustworld one 
=== iwcconfig frag ===