[Lxc-users] tun use from within lxc

[Nigel Magnay]

Interestingly, doing

openvpn --mktun --dev tun0

in the lxc spits out a kernel bug into dmesg:

[ 1632.334040] tun0: Disabled Privacy Extensions
[ 1632.334251] ------------[ cut here ]------------
[ 1632.334263] kernel BUG at /build/buildd/linux-2.6.32/fs/sysfs/file.c:539!
[ 1632.334269] invalid opcode: 0000 [#1] SMP
[ 1632.334272] last sysfs file: /sys/devices/virtual/net/vethKV9R8v/flags
[ 1632.334275] Modules linked in: veth binfmt_misc bridge stp ppdev
parport_pc fbcon tileblit font bitblit softcursor psmouse intel_agp
serio_raw i2c_piix4 agpgart vga16fb vgastate lp vmxnet3 shpchp parport
vmw_pvscsi floppy
[ 1632.334288]
[ 1632.334297] Pid: 5075, comm: openvpn Not tainted (2.6.32-16-generic
#25-Ubuntu) VMware Virtual Platform
[ 1632.334300] EIP: 0062:[<c025b9a3>] EFLAGS: 00210246 CPU: 0
[ 1632.334320] EIP is at sysfs_create_file+0x23/0x30
[ 1632.334323] EAX: 00000000 EBX: e9db5ba0 ECX: e9db5a58 EDX: c07b0974
[ 1632.334326] ESI: e9339f20 EDI: e9238c00 EBP: e9339ed8 ESP: e9339ed8
[ 1632.334329]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 006a
[ 1632.334334] Process openvpn (pid: 5075, ti=e9338000 task=e93059b0
task.ti=e9338000)
[ 1632.334337] Stack:
[ 1632.334339]  e9339ee0 c03df988 e9339f08 c044b169 c07b08c0 00000002
00000001 e9db5800
[ 1632.334346] <0> e99f2700 e9339f20 e9fe1090 00000000 e9339f50
c044b5ac bfd60e8c e99f2700
[ 1632.334351] <0> ffffffb3 e9339f4c 306e7574 00000000 00000000
00000000 00003001 00000000
[ 1632.334356] Call Trace:
[ 1632.334366]  [<c03df988>] ? device_create_file+0x18/0x20
[ 1632.334375]  [<c044b169>] ? tun_set_iff+0x319/0x400
[ 1632.334379]  [<c044b5ac>] ? tun_chr_ioctl+0x1ac/0x4a0
[ 1632.334383]  [<c044b400>] ? tun_chr_ioctl+0x0/0x4a0
[ 1632.334392]  [<c0213a11>] ? vfs_ioctl+0x21/0x90
[ 1632.334396]  [<c020e8eb>] ? putname+0x2b/0x40
[ 1632.334400]  [<c0213cf9>] ? do_vfs_ioctl+0x79/0x310
[ 1632.334403]  [<c0213ff7>] ? sys_ioctl+0x67/0x80
[ 1632.334409]  [<c020356e>] ? sys_open+0x2e/0x40
[ 1632.334417]  [<c01033ec>] ? syscall_call+0x7/0xb
[ 1632.334420] Code: 83 c4 04 5b 5d c3 66 90 55 89 e5 0f 1f 44 00 00
85 c0 74 17 85 d2 8b 40 18 74 10 85 c0 74 0c b9 02 00 00 00 e8 bf ff
ff ff 5d c3 <0f> 0b eb fe 89 f6 8d bc 27 00 00 00 00 55 89 e5 83 ec 0c
89 5d
[ 1632.334437] EIP: [<c025b9a3>] sysfs_create_file+0x23/0x30 SS:ESP
006a:e9339ed8
[ 1632.334445] ---[ end trace e5a32668add24ded ]---




On Mon, Apr 5, 2010 at 8:20 PM, Nigel Magnay <nigel.magnay at gmail.com> wrote:
> Hi!
>
> Having had my earlier problems magically disappear (I suspect user
> error), I'm experimenting a bit further.
>
> I'd like to connect an 'inner' lxc machine using openvpn to another
> network. What I've done so far is
>
> - make sure tun exists in the outer machine (in fact, verified the
> whole openvpn config can operate in the outer machine)
> - added lxc.cgroup.devices.allow to the relevant node
> - created /dev/net/tun item in the lxc fs
>
> When I start up openvpn however, I get a segmentation fault and
> shortly afterwards the entire outer machine ceases to function. I
> don't know if that's yet because I've missed something vital, or
> there's a better way to expose the tun device to the 'inner' machine?
>
> I'll keep experimenting, but was wondering if there was any obvious
> problems with what I'm trying..
>