[00:00] being blind it also not nice ;> [00:02] x86, amd64, alpha, ppc, sparc - are all know to be not broken at least with vserver? [00:03] well, untested, because I have no hardware to test it on ... [00:04] but if there are issues, they should be minimal ... [00:07] Action: arekm is building 2.6.2bklatest with vserver [00:08] CC [M] fs/ext3/inode.o [00:08] fs/ext3/inode.c:2447: error: redefinition of `ext3_truncate' [00:08] fs/ext3/inode.c:2118: error: `ext3_truncate' previously defined here [00:08] fs/ext3/inode.c: In function `ext3_truncate': [00:08] fs/ext3/inode.c:2450: warning: implicit declaration of function `ext3_truncate_nocheck' [00:11] hmm, which bk version is that? [00:11] do you have an url for the patch at hand? [00:11] latest, but not really bk - http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/ patch is here [00:12] is this a modified 2.6.2-rc1 ? [00:13] that's 2.6.2-rc1 + latest patch from bk (url above) [00:14] anyway your 2.6.2-rc1 doesn't have ext3_truncate() in inode.c? mine has quite huge function [00:16] hm, darned, I really got to learn how to use vim again [00:16] whats the command to erase lines from line 100 to 1000? [00:17] it might be that ext3 doesn't have the required stuff yet ... [00:17] could you provide your .config? [00:19] Bertl: I don't get it. There is ext3_truncate() already in fs/ext3/inode.c in vanilla 2.6.2rc1 (just checked to be sure). vserver patch adds second (much shorter) ext3_truncate() [00:19] yes, I can [00:19] click: 100G900dd [00:20] arekm: yes, but it renames the ext3_truncate, to ext3_truncate_nocheck() [00:20] (or at least it should ;) [00:21] uhm [00:21] it does [00:22] bert, it's done [00:23] Bertl: it does that but only for ext2, seems that this part for ext3 is missing [00:24] grep truncate patch-2.6.2-rc1-vs0.05.diff shows that [00:24] maybe I missed it ... it's only a few hours old ;= [00:25] post new one, please :-) [00:26] where did you say was your .config again? [00:27] http://www.t17.ds.pwr.wroc.pl/~misiek/rozne/config-up [00:37] <_shuri> humm [00:37] <_shuri> fs/fs.o: In function `proc_virtual_readdir': [00:37] <_shuri> fs/fs.o(.text+0x27b14): undefined reference to `__cmpdi2' [00:37] <_shuri> fs/fs.o(.text+0x27b2b): undefined reference to `__cmpdi2' [00:37] <_shuri> fs/fs.o(.text+0x27b3e): undefined reference to `__cmpdi2' [00:37] <_shuri> fs/fs.o(.text+0x27b57): undefined reference to `__cmpdi2' [00:37] <_shuri> fs/fs.o(.text+0x27b6e): undefined reference to `__cmpdi2' [00:37] <_shuri> make: *** [vmlinux] Error 1 [00:38] <_shuri> patch-2.4.25-pre7 [00:38] <_shuri> patch-2.4.25-pre7-vs1.3.6.diff [00:39] looks good ... almost like some math in the kernel ;) [00:39] arekm: okay, is fixed, just checking for other issues with your config ... [00:40] Doener_zZz (~doener@p5082DE34.dip.t-dialin.net) joined #vserver. [00:48] Doener`` (~doener@pD9E121A4.dip.t-dialin.net) left irc: Ping timeout: 480 seconds [00:49] _shuri (~shushushu@vserver.electronicbox.net) left irc: Quit: changing servers [00:50] _shuri (~shushushu@3ffe:bc0:8000::5bb) joined #vserver. [00:59] arekm: still compiling, but looks good ... [01:03] my config has almost everything possible in modules so it will compile long time [01:03] I can upload the patch so far, if you want to? [01:04] sure I want [01:04] incremental or new patch? [01:05] new [01:09] http://vserver.13thfloor.at/Experimental/patch-2.6.2-rc1-vs0.05.1.diff [01:18] building [01:19] still building here ... [01:25] Action: arekm needs some tool to diff diffs :) [01:26] let me know if you find a good one ... [01:33] noel- (~noel@pD9FFA8C3.dip.t-dialin.net) joined #vserver. [01:35] arekm: okay, compile finished here ... [01:38] no unresolved symbols in depmod? [01:38] well, I didn't install it ... [01:38] make finished without any complaints ... [01:40] noel (~noel@pD9E09913.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [01:44] miller7 (none@213.239.180.106) left irc: Ping timeout: 480 seconds [01:51] make modules_install INSTALL_MOD_PATH=/tmp/somewhere [01:52] depmod --basedir /tmp/somewhere -ae .... [01:56] do I have to? ;) [02:31] ugh, no free space, build failed, starting again :/ [02:31] hehe .. [03:24] Nick change: Bertl -> Bertl_oO [03:41] finally, finished building [03:46] monako (~monako@ts1-a9.Perm.dial.rol.ru) joined #vserver. [03:56] monako (~monako@ts1-a9.Perm.dial.rol.ru) left #vserver (всем пока ... good bye all ...). [04:01] anyone having problems with ftp? [04:02] i can't connect to a remote ftp server from inside my vservers [04:02] that is, i get the main connection, but the data connection fails: [04:02] Could not bind the data socket: Cannot assign requested address [04:03] Bertl: which vserver utils are ok for 2.6? [04:09] that's no firewall issue, the vserver host can connect and get data, but the vserver fails on active and passive mode [04:11] ip a shows correct ip address? [04:12] (just guessing, not used vserver yet) [04:12] ip what? [04:12] but yes, everything else works fine [04:12] ,,ip a'' [04:13] oh. this shows an IPv6 address which should not be there [04:13] or... [04:14] no, i just misread the output [04:14] 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 [04:14] link/ether 00:0e:a6:1e:8a:b4 brd ff:ff:ff:ff:ff:ff [04:14] inet 10.0.0.203/24 brd 10.255.255.255 scope global secondary eth0:kyra [04:14] looks fine to me [04:15] strace -o file -f -F ftpcommand [04:15] then grep bind file [04:15] hhhhm [04:15] bind(5, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.2")}}, 16) = -1 EADDRNOTAVAIL (Cannot assign requested address) [04:16] so it tries to bind to wrong address, no idea why [04:16] it should not bind to .2, that is the vserver host, not the vserver [04:18] i think this is the source part: [04:18] addrp->sin_port = 0; /* Let system pick one. */ [04:18] result = bind(sockfd, (struct sockaddr *) addrp, sizeof(struct sockaddr_in)); [04:19] how addrp is filled/initialized [04:19] htons 0 causes random port to be choosen afaik [04:19] well, not really random [04:19] yes, it should bind to an ephemeral port. [04:20] addrp initialization is interesting [04:20] i'm searching the call to that function, addrp is given as an argument to it... [04:36] i'm not totally sure i read this in the right direction, but i think the kernel returns the wrong address here: [04:36] getsockname(4, {sin_family=AF_INET, sin_port=htons(36714), sin_addr=inet_addr("10.0.0.2")}}, [16]) = 0 [04:38] Nick change: Bertl_oO -> Bertl [04:38] this is the main connection, which should start at .203, not .2: [04:38] tcp 0 0 10.0.0.2:36745 212.227.127.72:21 ESTABLISHED [04:38] hmm, seems like I missed quite some stuff ;) [04:39] btw, my ssh connections start at .2, too. [04:39] could somebody bring me up to date? [04:39] Bertl: wrt my problem? *-) [04:39] well, sounds interesting, whatever it is?! [04:40] ah. [04:40] is it vserver related? at least somehow? [04:40] ok: i can't get a ftp data connection to a remote ftp server from inside my vserver [04:40] connecting from the vserver host works fine [04:40] bertl, do you know the correct procedure for the grsec patches and vs? [04:41] youam: hmm, lets start with the basics, kernel version, patches, and tools? [04:41] click: well grepmaster provided patches for grsec patches .. IIRC [04:42] well, tried that, but it didn't patch nicely into the kernel it seems [04:42] mioght be that I mocked up somewhere [04:42] might be that the kernel version isn't the one the patches where done for ? [04:43] Bertl: debian kernel source 2.4.24, patch is vs1.22, vserver is 0.29 [04:43] okay, is there a chance for you that you use util-vserver instead of vserver? [04:43] s/0.29/0.27/ [04:43] bertl: 2.4.24 from kernel.org [04:43] Bertl: yes, i do [04:44] ah okay ... good ... [04:44] http://vserver.13thfloor.at/Stuff/testme.sh [04:44] this on the host works? except for one? [04:45] 201 failed, rest ok [04:45] okay [04:45] your vserver setup/config is? [04:45] (for that vserver) [04:46] i hope so. something special which has to work? [04:46] grsecurity-1.9.13-2.4.24-vs1.24.patch [04:46] grepmaster [04:46] ojn (~olof@cs6625217-161.austin.rr.com) left #vserver (Leaving). [04:46] this is the full edition I hope... *testing* [04:46] erm. misparsed your question [04:46] youam: okay, any chance I could have a look at it? [04:46] Bertl: sure. [04:46] one sec [04:48] https://hydra.youam.de/vservser.conf / https://hydra.youam.de/vserver/ [04:48] anything else? [04:48] let me have a look at it ... sec [04:49] oh. https://hydra.youam.de/vservers/ https://hydra.youam.de/vservers.conf are the real links [04:51] which one is the one you are trying to ftp from ... [04:51] kyra [04:51] ooh... could it bethat i have to replace "eth0" into "eth0:kyra"? [04:52] do you setup the ip yourself for that vserver? [04:53] nope, they apear automagically: [04:53] eth0:kyra Link encap:Ethernet HWaddr 00:0E:A6:1E:8A:B4 [04:53] inet addr:10.0.0.203 Bcast:10.255.255.255 Mask:255.255.255.0 [04:54] the file which controls network setup on debian contains only the .2 for the host and nothing at all for the vserver [04:54] sec [04:56] okay, inside the vserver, which address are your trying to reach? [04:57] nope, changing to eth0:kyra doesn't help [04:59] i'm trying to connect to ftp.debian.org from kyra (10.0.0.203) but it tries to bind() to 10.0.0.2 for the data connection as getsockname returns 10.0.0.2 as the local IP for the main connection [04:59] who is doing the masquerading/nat stuff? [05:00] 10.0.0.1, which should be transparent to this as it's another box [05:00] okay, so you have a default route to 10.0.0.1 and a separate box there ... [05:00] yep [05:01] okay, could you do a tcpdump on that router? [05:01] sure, one sec [05:04] https://hydra.youam.de/vserver.dump is the connection reply, i'm installing ethereal.. [05:04] bertl: btw, any way to hide the 'up'ed interfaces on the root-server? [05:04] s/reply/try/ [05:05] bertl: would stop identd running on the root-server binding to the ip's that the vservers allocate [05:05] youam: umum, maybe a readable ascii version ;) [05:05] Bertl: tcpdump -r vserver.dump :) [05:06] or https://hydra.youam.de/vserver.asc [05:09] hm. a bit complicated to read because all packets are shown for both incoming and outgoing interface on the router [05:09] but the connection is coming from the vserver /host/, not the vserver itself [05:12] 03:01:08.132208 10.0.0.2.36767 > 128.101.80.131.21: . ack 1 win 5840 (DF) [05:12] that looks goot to me? [05:12] s/goot/good/ [05:12] nope. it should be 10.0.0.203, not 10.0.0.2 [05:12] okay, got it ... [05:13] what does ifconfig show inside the vserver? [05:13] outch?! [05:13] bertl: only the ip it has [05:14] eth0 Link encap:Ethernet HWaddr 00:0E:A6:1E:8A:B4 [05:14] UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 [05:14] .. [05:14] bertl: i was more thinking of the root-servers ip's [05:14] eth0:kyra Link encap:Ethernet HWaddr 00:0E:A6:1E:8A:B4 [05:14] inet addr:10.0.0.203 Bcast:10.255.255.255 Mask:255.255.255.0 [05:14] it should not show eth0 there?! [05:14] hmm, interesting, let me see if I can reproduce this ... [05:14] hmm, you didn't enable ipv6, did you? [05:15] i did try, and it was enabled when i setup the box, but as it did not work i disabled it. the ipv6 module is not loaded [05:16] but it is enabled in the config, right? [05:16] okay, I'll check, brb [05:16] wouldn't know where [05:16] oh, you mean the kernel config? yes, i /could/ modprobe it [05:22] hm.... /all/ connections to remote (as in "not to $(hostname)", which connect to 10.0.0.203) origin at 10.0.0.2 [05:26] 03:27:39.268043 52:54:0:12:34:56 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 10.0.0.1 tell 10.0.0.100 [05:26] 03:27:39.268133 0:ff:ed:8a:9c:b6 52:54:0:12:34:56 0806 42: arp reply 10.0.0.1 is-at 0:ff:ed:8a:9c:b6 [05:26] 03:27:39.272183 52:54:0:12:34:56 0:ff:ed:8a:9c:b6 0800 74: 10.0.0.100.1024 > 192.35.244.50.21: S [tcp sum ok] 1708609764:1708609764(0) win 5840 (DF) (ttl 64, id 16562, len 60) [05:26] 03:27:42.260829 52:54:0:12:34:56 0:ff:ed:8a:9c:b6 0800 74: 10.0.0.100.1024 > 192.35.244.50.21: S [tcp sum ok] 1708609764:1708609764(0) win 5840 (DF) (ttl 64, id 16563, len 60) [05:26] this is how it looks here, with the following sequence ... [05:27] ifconfig eth0 10.0.0.2 netmask 255.255.255.0 [05:27] ifconfig eth0:XXXX 10.0.0.100 netmask 255.255.255.0 [05:27] route add default gw 10.0.0.1 [05:27] chbind --ip 10.0.0.100 /tmp/lftp [05:27] youam: could you try similar on your host with 203 instead of 100 ? [05:28] wooha [05:28] bertl, any fixes on 1.24 that I should be aware of? [05:28] from the release ver? [05:29] grsec+vs 2.4.24 compiled nicely [05:29] Bertl: (where) should i run the ifconfigs? [05:30] on the host ... [05:31] just configure an unused ip, so you only need [05:31] ifconfig eth0:XXXX 10.0.0.100 netmask 255.255.255.0 [05:31] doing that [05:31] for example ... [05:31] the default route and other ip should be the same ... [05:31] and again, check with tcpdump on the router ... [05:33] default route was set, local ip was set, so i didn't change anything there. this are the commands i ran, error stays the same: [05:33] ifconfig eth0:XXXX 10.0.0.100 netmask 255.255.255.0 [05:33] chbind --ip 10.0.0.100 ncftp ftp.debian.org [05:34] log is in https://hydra.youam.de/vserver2.asc and .dump, [05:35] hm. looks like a broken chbind() [05:35] bertl: where's the max-ip limit located on the vs-kernel? [05:35] max ip's for vservers that is [05:41] youam: okay, that differs from my results, question now is why ... [05:41] click: search in the vserver patch for a #define and 16 [05:42] youam: you mentioned debian kernel? [05:43] yes, i'm running a kernel based on kernel-source-2.4.24-1 plus vs1.22 [05:43] could you try with a vanilla 2.4.24 kernel? [05:43] the diff's between the debani kernel and a vanilla are about 2mb, i'm looking for something which could make problems there [05:44] DMA is broken with a vanilla kernel for me, but for testing: sure [05:45] is chbind a kernel syscall? [05:47] for the sake of equal versions, i'm using vs1.22, not vs1.24 [05:52] hmm, okay ... [06:05] bertl: +#define NB_S_CONTEXT 16 [06:05] +#define NB_IPV4ROOT 16 [06:05] which one :D ? [06:05] ipv4root? [06:06] (stupid question tho'... as its that define that controls max ip's bound to a context :/) [06:06] sorry, nevermind, just me being a bit fed up with some stupid kiddie oper on another net [06:13] sorry, just being a little busy right now ... [06:17] click: okay, you want to raise it to what value? [06:17] moving the shellusers to a single vserver. most probably I'll need at least 200 ip's allocated in a single vs [06:18] hmm, IIRC, I suggested last time to modify the matching algo for that purpose ... [06:18] hm, yeah, binding it into an array or smth [06:19] yeah, basically a mask would be sufficient for your purpose ... [06:19] or maybe even better, a range .-.. [06:19] yup [06:19] thats the best one actually [06:19] you could do that with a simple trick ... [06:19] all ears! [06:19] :) [06:20] without changing the interface and userspace tools ;) [06:20] but you would have to either setup _all_ your interface by hand ... [06:21] or write some addon tool, which does it for you ... [06:21] well, the interfaces is just a short 'for i in $(seq.... [06:22] yes, but also for 'other' servers you have to do the setup ;) [06:22] basically the idea is to check for ranges per se ... [06:22] so 192.0.0.1 is an ip [06:23] 192.0.0.1, 192.0.0.5 is a range . [06:23] 192.0.0.1, 192.0.0.5, 192.0.0.8 is a range + one ip [06:23] 192.0.0.1, 192.0.0.5, 192.0.0.8, 192.0.0.16 are two ranges ;) [06:24] so if you want 3 ip's you would have to assing 2 ranges and a separate ip ... [06:24] do you understand? [06:24] mhm, no probs, the thing is that we'll allocate .11 to .200 anyway into a single vs [06:25] so that part is not a problem, as we're not splitting up any blocks [06:25] that is no problem, would be 192.0.0.11, 192.0.0.200 [06:25] yup [06:25] but if you want 3 ip's on another server, you have to provide at least 5 addresses ;) [06:26] hm, in the respective servers config, and without making an overlapping ip? [06:26] 192.168.0.11, 192.168.1.200 in vs1 [06:26] yup [06:27] hm, thats a trickier one [06:27] no problem there ... [06:27] it's always a range [06:27] all ips are mapped to a uint32 ... [06:27] 192.168.0.201, 192.168.1.203 in vs2 wouldn't work then... [06:28] if i read you correctly [06:28] as I would need a delimiting ip inbetween [06:28] would work, both would be allowed to use 192.168.0.201 - 192.168.1.200 [06:28] hm... [06:28] (if you example was intentional ;) [06:29] mm, not quite. [06:29] vs1 uses 11-200 [06:29] okay look at it like this: [06:29] vs2 201-203 for instance [06:29] ip = a.b.c.d okay? [06:29] vs3 204-210 [06:29] yup [06:30] now F(ip) = ((a * 256) + b) * 256 + c) * 256 + d [06:30] or F(ip) = (a << 24) | (b << 16) | (c << 8) | d [06:30] mhm [06:30] whatever you prefer ;) [06:30] now we got ip1, and ip2 [06:30] a b or c nets [06:30] yup [06:31] back [06:31] click: and the check would simply do for a give ipX [06:31] looks like everything still is the same [06:31] if F(ip1) <= F(ipX) <= F(ip2) , then allow access ... [06:32] youam: so 2.4.24 (vanilla) + 1.22 gives the same results? [06:32] hm. [06:32] no. [06:32] ifconfig in the vserver still shows eth0 without ip, [06:32] that's okay ... [06:33] eth0 shouldn't show ip [06:33] eth0: shows its ip [06:33] ? [06:33] but i just tried the chbind --ip 10.0.0.100 ncftp thingie and now the connect succeds [06:33] click: exactly [06:33] well, it works here [06:33] both with ftp and everything else [06:34] okay, so now we know that the debian kernel is broken, right? [06:34] looks like [06:34] (I mean the debian, vserver kernel, of course) [06:34] <-- not running debians kernel [06:34] :) [06:35] okay, youam, could you upload all patches required to create such a debian kernel from a vanilla source, somewhere? [06:35] where did the debian vserver patch come from, or did you 'just' apply the vs1.22 patch on the debian kernel? [06:35] debian vserver is the ctx patch I believe, from solu [06:36] not vs [06:36] nope click, he was referring to vs1.22 ... [06:36] aah, mf. [06:36] Bertl: i applied your patch from 13thfloor, plus resolving one or two rejects [06:36] ah okay, you broke it yourself ;) [06:36] (which had nothing to do with networking, iirc) [06:36] well you have to keep _all_ pieces then ;) [06:37] okay, we could have saved us all some time, if you would have said this earlier ... [06:37] I _know_ that debian uses a modified (2.6 like) network stack, which doesn't work with default vserver patches ... [06:38] it's not too hard to adapt it, I've done that several times before .. so we can do it again ... [06:39] AAAAh [06:39] DAMN [06:39] did i just say "nothing with network"? [06:39] 1 out of 1 hunk FAILED -- saving rejects to file include/net/ip.h.rej [06:39] 1 out of 2 hunks FAILED -- saving rejects to file include/net/route.h.rej [06:39] 1 out of 7 hunks FAILED -- saving rejects to file net/ipv4/udp.c.rej [06:40] shame on me [06:40] okay, you have the 2.4.24 patches somewhere? [06:40] I mean the debian patches ontop of 2.4.24? [06:40] one sec [06:42] https://hydra.youam.de/stuff/diff_linux-2.4.24_kernel-source-2.4.24.bz2 [06:44] i solved the conflicts by looking at the latest debian ctx patches available, which were ctx1.21 for debians 2.4.22 [06:51] hmm, funny I have a 2.4.22-3-vs1.22 debian kernel here ... [06:52] the debian 2.4.24 version is 2.4.24-? [06:52] mine is a 2.4.22-5 [06:53] okay now I'm confused?! [06:53] but i used it only to have something to apply the patch against [06:53] what is the url you provided above? [06:53] the version numbers differ between woody-proposed-upgrades and sid [06:54] oh. sorry [06:54] i gave you the version of the 2.4.22 i applied the ctx1.21 against [06:54] 2.4.24-1 is the 2.4.24 version [06:55] okay, so this patch above is linux-2.4.24-2.4.24-1.diff , right? [06:55] or linux-2.4.24-to-2.4.24-1.diff [06:55] yep. the diff between a vanilla 2.4.24 and debians 2.4.24-1, both without vserver [06:59] well, but now that i know exactly what is broken, and where to find a working version, i think i can figure out the rest by myself [06:59] you can have a 'reference' patch in a few minutes ;) [07:00] i won't say "no" :) [07:00] i think my main problem was not knowing that the -ctx patch and the -vs patch are really two different things [07:00] and I would be glad, if you could test, and fix it, if it is wrong somewhere ;) [07:01] sure [07:01] because I don't test the debian kernels, so I don't know if something is broken ... [07:06] http://vserver.13thfloor.at/Experimental/patch-2.4.24-1-vs1.24.diff [07:29] Bertl: in a twisted way i'm relieved: it doesn't work [07:31] okay, so something is wrong in that version too, which means, it's probably wrong in 2.4.23-3-vs1.22 too ... [07:31] which should have been tested, long before ;) [07:31] same effect as before? [07:32] yep. all in all it's running, but the chbind-error is still there [07:32] so i'm happy i didn't make some stupid error and stole your time with this [07:33] okay, we had the ftp issue before? [07:33] that is working now? [07:34] or what is the chbind-error you refer to? [07:34] the ftp test? [07:34] i think the ftp issue /is/ the chbind error [07:34] can't follow, please elaborate ... [07:35] i meant, ftp is still not working in the vserver, but everything which worked before, with my version, still works [07:35] that is /the chbind error/? [07:36] and i think that my ftp connections are not running because of the chbind error: [07:36] okay, what is /the/ chbind error? [07:36] the ftp client opens a connection, which gets bound to .2 by mistake instead of to .203 [07:36] okay, so the 'bind()' actually goes wrong? [07:36] i think so [07:37] how'd you verify that? [07:37] the ftp client opens a connection without specifing an interface [07:37] and it gets bound to 10.0.0.2 (s/interface/ip-address/) [07:37] how do you see that? [07:38] this is shown in strace by getsockaddr [07:38] okay, [07:38] is that strace somewhere? [07:38] and the following bind tries to bind itself to /this/ address for the data connection, which fails [07:39] one sec, i'm making a new one [07:43] https://hydra.youam.de/stuff/strace.log [07:44] i read the getsockname() in line 347 in the way that the main connection originates from this address [07:44] the tcpdump looks that way, too [07:48] take a look at this patch : @@ -599,6 +616,18 @@ int udp_sendmsg(struct sock *sk, struct [07:49] IMHO it's the only difference, which could cause this ... [07:50] but that's udp?! [07:52] not really knowing anything of this code, i'd suspect this one: @@ -156,6 +157,45 @@ static inline int ip_route_connect(struc [07:54] in net/ipv4/udp.c change the line 626 ... [07:54] daddr = ipv4root; [07:55] yes, found it [07:55] to [07:55] fl.nl_u.ip4_u.daddr = ipv4root; [07:55] done. [07:55] next recompile/reboot? [07:56] compile with make bzImage modules ... [07:56] no make clean or dep required ... [07:57] hm. looks like make-kpkg (the debian kernel-packager-thingie) did a make clean anyway [07:59] argh, takes ages ... [07:59]