SateLites

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
TableOfContents
=== MTU issues ===
=== 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 ===
=== daisy chain ===
Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
>I believe there is some guidance on the wiki in setting up Aramiska 
>connections. Also, I think you have to use the "daisy chain" feature 
>that was built in especially for Aramiska connections and requires 
>dev84 or higher.
You don't have to use the daisy chain feature, but it gives improved 
performance on satellite connections. The reason for this is that if 
the meshbox does DNS queries, each query for a new address will take 
3 or 4 jumps across the satellite link - take the example of 
www.bbc.co.uk
1) Query the root servers for .uk
2) Query the .uk servers for .co.uk
3) Query the .co.uk servers for bbc.co.uk
4) Query the .bbc.co.uk server for www.bbc.co.uk
Each one of these queries will add latency. What quite often happens 
is that a client's first DNS request will time out, but the second 
request will give the answer.
Running with daisy chaining, each meshbox will pass the request to 
the satellite provider's DNS server, which should be optimised to 
send the request to a server at the downlink site. This will do the 
recursive lookup with no latency, and then send the answer back - 
thus only one satellite hop.
=== Redirecting mail traffic out not by the default gateway ===
We have done exactly this at Rural-WEB, and though a bit of a phaff to 
set up, works well.
Three basic steps:
1) Direct port25 on the gateway attached to the ADSL gateway to point 
tothe
node attached to the Aramiska end-station
2) direct port 25 on the Aramiska connected node to point to 
192.168.1.1
(This allows you to redirect any mail coming in across the Mesh to be
redirectable at this point too)
3) open up your firewall on the Aramiska attached node for port 25
This is what we had to do and it works brilliantly. I beleive the WiKi 
to
be accurate (as we wrote half of it). If you want to get in touch 
directly
we'll try and help you pronto.
Cheers, Bertil.
(At work for now, but on behalf of Rural-WEB.org)
> I hope someone can help resolve an issue we have encountered today.
>
> Today we have installed a new ADSL (Zen) gateway on one of our mesh
> nodes to be used as the primary internet gateway. Previous to this we
> only had one connection via an Aramiska satellite connection (on a
> different node). However, we need to send mail out via the Aramiska
> connection as this is where the mail server is.
>
> We have followed the directions in the Wiki (Redirecting traffic out 
not
> by the default route), without success. Neither POP3 nor SMTP work.
>
> We have managed a work around using the Aramiska server external 
address
> and the Zen SMTP server. But we need our local mail working.
>
> Can anyone suggest what is wrong? Our mail server is on internal 
address
> 192.168.1.1.
Category:Mesh