[lkml]   [2005]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Realtime Preemption, 2.6.12, Beginners Guide?
    On Monday 11 Jul 2005 15:43, Ingo Molnar wrote:
    > * Alistair John Strachan <> 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, 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..


    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

    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

    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 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.


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

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

    dev tun
    proto udp
    user nobody
    group nobody


    log /etc/openvpn/log
    verb 3
    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

    ifconfig-pool-persist ipp

    log /etc/openvpn/log
    verb 3

    push "redirect-gateway def1"
    push "dhcp-option DNS"
    push "dhcp-option WINS"
     \ /
      Last update: 2005-07-11 17:58    [W:0.028 / U:13.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site