WARNING: POSIX threads library NPTL requires kernel version [14:30] 2.6.1 or later. If you use a kernel 2.4, please upgrade it before installing glibc. great so now debian stable requires actually 2.6 fscking great No Oh, erm. Dunno. [14:31] shouldn't do, if you remove libc6-i686, no? gregj: I think you can get away without it. But 2.4 is not supported. etch has no 2.4 kernels afaik? 2.4 == loss, anyway kyllikki: right 2.4 really is dead...stick a stake in it and get a nice shiny 2.6.21 [14:32] Damn this reliance on code from over three years ago That's like, pre-history, man. mjg59: 2.4 is a lot older than that? kyllikki: 2.6.1 gregj: Erm, 2.6.1 has been around since 2004-01-09 gregj: that you're complaining about upgrading speaks volumes about you [14:33] mjg59: oic you mean 2.6 is three yes, 2.4 is way older tho ;-) -rw-r--r-- 30M 2007-04-22 15:58 linux-2.4.34.4.tar.bz2 that's scary that someone released a 2.4 kernel less than a month ago [14:34] It's so small! that's really really scary Any architectures that require 2.4 are clearly losses Kinnison: it was a pure "chuck the diffs in and see if they stick" thing tho * Kinnison shrugs 2.0.40 is newer than 2.6.1... [14:35] I was asked if I would take it on at one point and legge dit ;-0 Kinnison: ip addr question? as is 2.2.26 (surprisingly small patchlevel) I need 2.4 on me router [14:36] 2.6 is useless with networking stuff, on routers so... are we expecting 2.8 anytime? well don't use etch then dkscully: no actually that was a message from sid gregj: ? 3.0? no Yes, lenny won't support 2.4 under any circumstances end of the world? [14:37] I've not had problems w 2.6 on routers/firewalls. 2.6.666 * dkscully giggles. But by the time it's released 2.6.1 will have been around for over 4 years So fledermaus: you have small networks possibly, but you still haven't explained. memory leaks, memory leaks, poor performance on routers - that what 2.6 really is gregj: have you reported this to davem? [14:38] no one of dev folks on lkml seems to care about my problems anyway I seriously doubt he would let such stand well That is not the impression I have got from reading the netdev list. [14:39] And the kernel list. I don't remember the whol list of my problems really, I just decided to stick to 2.4, because it works. And on contrary, 2.6 always caused number of issues The claim of bad performance of 2.6 has been repeated again and again but usually without a test case. ask a middle sized ISP to let you put 2.6 on routers, and you'll see Ralf: and dave is rather shit hot on it when there is ;-) wtf is a netdev team for, if they can't understand "bad performance in routing" [14:40] The networking stack is davem's favority dild^Wtoy, so if you can demonstrate something I'm sure he'll care. "mem leaks in fucking iptables" that's not a bug report. it's just a complaint. test cases or at least some steps to reproduce are important. okay, here's one for you than Is BCN a mid-sized ISP? Do they use 2.6 on routers? * dkscully is sure you shouldn't let iptables fuck. gregj: Try reporting the bugs to the developers instead of bitching on IRC? try actually providing details, too [14:41] try recreating iptables rules, lets say every 5 minutes, and keep reloading * Kinnison has 2.6 systems routing many gigabytes of traffic per day without iptables exploding is it vanillia 2.6 ? Ubuntu 2.6 kernels and before that, Debian 2.6 kernels I bet there is slight difference ;) which is vanilla as far as the networking is concerned, iirc. And yes, it recreates iptables rules regularly for our SSH honeypot gregj: The Debian kernels are very vanilla. [14:42] debian yes * kyllikki knows of at least three routers in a large organisation which run at 3Gbit bonded flat out most of teh time? I doubt ubuntu ones are The networking code in Ubuntu kernels is vanilla We don't fuck with that I wish, when gcc said things like: warning: `iblk' might be used uninitialized in this function [14:43] i run quite a bit through some debian routers runing 2.6 gregj: *seriousl*, create a proper bug report with serious data and test case and I doubt any issue would be there for long. it would point at the first unintialised use but due to replace them soon rather than the declaration as quagga, erm, isn't "very good" it's fine if you don't have ip_conntrack loaded, i've had issues with it even without iptables rules (bug?) gregj: Even just post to netdev and you'll probably get asked for information to help diagnose. anyways, atm I am not in .pl, so not able to switch to 2.6 on routers Kinnison: 62.197.40.9 <- should be available? [14:44] Hang on. You want to run sid on routers? broonie: did that on many ocasions, and so did my friends broonie: always _no_ answer whatsoever they are sticking a tag 'whiner' if you have a problem, and that's it not always one is able to recreate a problem, or give good feedback about it, sometimes you just have to give some hints - and that is what guys on the list are quite incapable of doing it seems [14:45] fledermaus: nothing arping on that IP, but no reverse DNS either hm. gregj: is probably how you ask...personally whenever I have a real reproducable netwrking issue dave replied with the fix by return of mail...or bitches my patch sucked and provides a proper one * will-h suspects he may run your upstream ;) kyllikki: what's the email you send your bugs to ? [14:46] maybe I got a wrong one :> or something gregj: I sub patches et al to netdev or I talk to dave I don't have it here, cos I'm not on the list no medium or large-sized networks run linux on routers, and certainly not in the forwarding plane gregj: netdev is the place to ask. netdev at ? will-h: thanks. I was more sort of asking whether kinnison thought it should be up. [14:47] vger.kernel.org will-h: do you have asymetric paths? if so you really really don't want to run conntrack! shrug...well your in a # with three arch maintainers and numerous otehrs have subbed code to the kernel...so all we can say is it works for us :-/ or atleast you want to run notrack for traffic you might not see replies for. murb: conntrack just loaded itself at one point for some reason on a box i ran kyllikki: no [14:48] i think i rmmoded and blacklistsed it will-h: probably you randomly typed iptables -L kyllikki: sorry fledermaus: no fledermaus: That's, erm, OOOOOLD IP murb: you're almost certainly right Kinnison: aww I wanna ;-) fledermaus: Why are you even thinking about it? host zeus.pepperfish.org murb: but even without referencing it in an iptables rule it was tracking connections... v.bad fledermaus: pepperfish.org is obsolete and shouldn't be used fledermaus: but I'll fix it anyway gregj: google doesn't obviously seem to agree with you fledermaus: use zeus.pepperfish.net Kinnison: I will if I track down michael. [14:49] mjg59: hmm ? but I don't control the DNS. fledermaus: updated, give it a bit ta. gregj: About you having complained to netdev on several occasions * Kinnison workraves google fixes their own bugs internaly, and also add stuff internaly, not much of that code ends up in linux repo oh well, it is not just me, but some of my co workers too [14:50] 14:44 < gregj> broonie: did that on many ocasions, and so did my friends don't get so hung up on it, google are just an advertising company ;) [14:51] http://www.uwsg.indiana.edu/hypermail/linux/kernel/0412.0/1139.html and tihs was never fixed, and still isnt That's not strctly netdev this is not following basic standards [14:52] it makes kernel hang after a while on router with some traffic even 2.4 I ahve to fscking correct it me self over and over again routers don't need conntrack, remove it gregj: For that I would suggest submitting a patch. (it was the only seemingly relevant post I was able to find too) broonie: well you can fix that with some notrack rules. If my ISP dropped all my idle connections after 100 seconds, I'd be somewhat unhappy [14:53] patch is basicaly a change of one line, and everything including an explanation is in that very emali if netdev ppl are sane, they should have fixed it ages ago Where "somewhat unhappy" is equivalent to "changing ISP" it is not about dropping connection * broonie agrees with mjg59. mjg59: no ISP should be doing connection tracking, it's flow-based and very much unsuitable for ISP networks it is about memory usage on routers s/are sane/agree with me/ Kinnison: still borken - redirecting rtfm to www.rtfm something which does stateful tracking isn't a router, it's a firewall :-) will-h++ [14:54] gregj: No, it's about two conflicting desires - keeping connections alive and capping memory usage hehe, it seems you have absolutly no idea what it is all about, so please, refrain from making comments Oh fuck off you tedious shit yeah clearly mjg59 knows nothing about kernels and i know nothing about networks and i know nothing about drinking tea! I know little about kernels eitehr you said that and I said you know nothing about my issue, and why am I changing it [14:55] (caution: some of the above comments may contain inaccuracies) well, we have something in common, because it looks like you know nothing about your issue too! not to mention the parameter you are bitching about is settable by you catting a value into a proc file isnt it? [14:56] the way it works - you tedious shit - is, that if connection is _inactive_ for fucking 2 days, information about it is still wasting my fucking memory kyllikki: yes, as was pointed out in the first reply to the thread if you have 100k fucking clients, that's fscking loads of memory waste d . fledermaus: my fault, I braino'd fledermaus: done gregj: but i don't want all my connections to die after a a few minutes ta *** ChanServ (services@services.oftc.net) has changed mode for #debian-uk to +o thom if you have 100k clients rmmod conntrack and given it is a usesapce tunable value how is this a problem? gregj: The default behaviour is sensible behaviour for most users. There's an option in /proc to change it. will-h: or use NOTRACK mjg59: it isn't on routers gregj: In any case, it's realyl not a very reformed bug report. It'd help to be less confrontational. thom: ah right...I didnt read beyond "err no thats about right and its tunable" ;-) mjg59: and it isn't sane, it is really easy to DoS it [14:57] thom: yeah, I am scared gregj: so fix your config, as was replied to you gregj: i don't give a shit, you're just boring me config ? it's changable as a fricking sysctl there are some really nice polite replies on list too! s/reformed/well formed/ gah gregj: If most routers dropped idle connections after 100 seconds, people would become very upset my clients are very happy [14:58] would you like me to explain sysctls? or would that take away your ability to whine gratuitously so... Note here how I'm telling you that you're factually incorrect, rather than telling you that you don't understand this problem occurs with EVERY firewall in the world [14:59] Now, clearly, in your case you're happy killing those connections in order to save memory. That's fine, because there's a sysctl to let you do that. anyways, I would love to see that comments as a reply to my email. But no one did even give a sh** gregj: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0412.0/1244.html gregj: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0412.0/1150.html Is precisely that why would I need sysctl, I need a kenel that doesn't hang,or stop routing (cos that's what it does if memory ends! - clearly a bug) ddos is a bug? [15:00] so you have a router that after 2 days is just a airgap PEBKAC you can't even ssh to it, because its network is dead PEBKAC gregj: If the complaint is that the kernel will allocate enough memory that it can't actually work any more, then that sounds like a bug, yes. But that's not what you reported. [15:01] http://www.uwsg.indiana.edu/hypermail/linux/kernel/0412.0/1369.html What stops me from filling up your memory by opening an insane number of connections over a period of 100 seconds? You've reduced the chances of the system getting into a bad state, but you've done nothing to prevent it And, in the process, you've decided to kill idle connections after 100 seconds [15:02] yeah, you guys are right. no point talking to you about it. you don't see a problem here. but it doesn't mean it doesn't exists * iDunno wonders how gregj managed to stay in channel i see the problem very frequently Not only is there a problem, there is also a solution! mjg59: kernel does it, and is useless after a whlie i used to see it on flow-based routing for Extreme Summit i-series switches iDunno: not kicking him is funnier i still see it today on Netscreen and every other firewall manufacturer gregj: Sorry, perhaps I should try this with shorter words it is a problem it is known workaround is correct design gregj: Machine has limited amount of RAM [15:03] not breaking TCP end-to-end model gregj: Tracking connections takes RAM *** gregj (~gj@81-186-226-63.citynet.pl) has left channel #debian-uk: ta, talk to you when you are able to talk. Oh, good. heh Can we make him not come back? will-h: you mean, that if you "do it properly" Bad Shit (tm) doesn't happen? what a fuckwit! *** thom (~thom@amnesiac.heapspace.net) has changed mode for #debian-uk to +b gregj!gj@*.citynet.pl