Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Alistair John Strachan <s0348365@sms.ed.ac.uk>]

[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]

On Monday 11 Jul 2005 15:43, Ingo Molnar wrote:
> * Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > It's annoying that this is so readily reproducible here, yet almost
> > impossible to debug, and clearly a sideaffect of 4KSTACKS.. without it
> > actually being a stack overflow.
> >
> > I realise 4KSTACKS is a considerable rework of the IRQ handler, etc.
> > and probably even more heavily modified by rt-preempt, but is there
> > nothing else that can be tested before a serial console run?
>
> 4K stacks never really caused any trouble under PREEMPT_RT (or any other
> kernel i tried). It's not that complex either.
>
> one useful thing could be to give me exact instructions on how to set up
> an openvpn network similar to yours, and what kind of workload to
> generate. Maybe i can reproduce it here.

OpenVPN isn't terribly difficult to set up, but it's more than a 5 minute job. 
You'll need universal tun/tap in your kernel before you start, and openvpn 
itself installed (I've compiled from source and used Debian's 2.0.0 package, 
I'm sure Red Hat has an equivalent), then it's just a case of setting up a 
client and a server.

If you like, I can generate the "keys" used for server/client and I've 
attached the configs for the server and the client they we use here. 
Obviously for security reasons I can't attach OUR keys verbatim, but I'll 
instruct you on how to generate them.

So, on the server:

a) Install OpenVPN
b) mkdir -p /etc/openvpn/keys
c) Copy attached server.conf to /etc/openvpn
d) Modify server.conf if necessary (shouldn't be required)
e) Generate your server and client keys (see below)

This mostly repeats the moderately good documentation on 
http://openvpn.net/howto.html, but I can't expect you to read it all so I'll 
give you a bite-sized version. It saves you figuring out the same rubbish I 
had to about 6 months ago. OpenVPN will create (with my configs) a verbose 
log in /etc/openvpn/log on both machines.

1) cd /usr/share/doc/openvpn/easy-rsa

2) Edit "vars". Change line export KEY_DIR=... to:

	export KEY_DIR=/etc/openvpn/keys

3) Save and exit

4) On Bash (at least) type

	. ./vars

	Which imports "vars" into your environment.

5) ./clean-all

6) ./build-ca (enter any old crap)

7) ./build-key-server server

	Enter the common-name as "server" again. No password.

8) Finally, generate the client key (used by the client for crypto)

	./build-key client1

	Where "client1" is an arbitrary name. When prompted for "common-name", enter
	the same string; this is important and I was head-scratching for some time
	as to why it wouldn't work without this... Again no password.

8) ./build-dh (this takes a while)

With that done, /etc/openvpn/keys should contain at least..

01.pem
ca.{crt,key}
dh1024.pem
server.{crt,csr,key}
client1.{crt,csr,key}

Plus some other cruft that's probably not required. Now you should be able to 
start the openvpn server with something like..

openvpn --cd /etc/openvpn --config server.conf

Add some other flags like verbose if you want to see what's happening. 
Remember it's logging everything to /etc/openvpn/log which you can supress by 
commenting out the logfile line in the config.

It'll bring up a tun device on the server side, and wait patiently for VPN 
connections.

The client side is a piece of cake.

1) mkdir /etc/openvpn

2) Copy client1.crt, client1.key, and ca.crt from the server's /etc/openvpn 
directory to the client's /etc/openvpn directory.

3) Copy the attached client.conf to the same directory.

4) Edit the config as necessary and save (should work with only the server IP 
changes).

Again, the client machine will need to have the universal tun/tap driver 
loaded. Bring up the openvpn with:

openvpn --cd /etc/openvpn --config client.conf

A connection should be established and, hopefully, you'll get a pingable route 
to 10.0.0.1. I then made this my default gateway with:

route del default wlan
route add default tun0

Then I was able to ping machines on the server side without having a local 
gateway to them. One working VPN.

I suggest you try all this on a "stable" kernel, and once you've established 
it works, just transfer a file at a reasonable data rate through the tunnel.

Ours links to a company server with a consumer grade 1Mbit ADSL connection, 
and transferring just about anything at 110K/s causes the kernel to crash 
within about 10 seconds.

I wish you the best of luck with getting this going, and I apologise in 
advance for the poor instructions.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:    CS/CSim Undergraduate
contact:    1F2 55 South Clerk Street,
            Edinburgh. EH8 9PP.

[-- Attachment #2: client.conf --]
[-- Type: text/plain, Size: 200 bytes --]

client
remote 192.168.99.1 443

ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server

dev tun
proto udp
nobind
user nobody
group nobody

persist-key
persist-tun

log /etc/openvpn/log
verb 3

[-- Attachment #3: server.conf --]
[-- Type: text/plain, Size: 358 bytes --]

server 10.0.0.0 255.255.255.0
port 443

ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem

dev tun
proto udp
user nobody
group nogroup

persist-key
persist-tun
ifconfig-pool-persist ipp

log /etc/openvpn/log
verb 3

client-to-client
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option WINS 192.168.1.2"