Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
2.4.0 Linux kernel released

By Justinfinity in News
Fri Jan 05, 2001 at 05:48:21 AM EST
Tags: Software (all tags)
Software

As many of you may have already heard, the 2.4.0 version of the Linux kernel has been deemed worthy for the public (or maybe he's just tired of the e-mail asking when it'll be done :-P ). Of course, you can download the official source at Kernel.org. Let's reveiw some of the more interesting additions.


First off is something that I really like, full USB support. Yes USB had been backported to 2.2.x, but it still requires patching the sources AFAIK. It's good to see this in the kernel tree. I hate having to switch my mouse back to PS/2 when I boot Slackware instead of Win98 or FreeBSD. [being a *BSD advocate, I will mention that FreeBSD, OpenBSD and NetBSD have had USB support for at least a year. :-) ]

Next comes the built-in firewalling. iptables works much like ipchains and ipmasq used with previous kernels. The bonus comes from having the packet filtering and masqerading done in kernel space, for a speed increase. People operating Linux based firewall have been looking forward to this.

Another speed increase (at least on multi-processor machines) comes from improved SMP (symetric multi-processing) Linux can take advantage of multiple processors better and faster than ever. On the same line is multi-threaded TCP/IP, allowing IP connections to be handled more effeciently and quickly.

DRI (Direct Rendering Interface) support is a huge thing for anyone running X or playing games on Linux. Previously, all graphics stuff was done in userland, which is also why many SVGAlib based games had to be run suid root. With graphics drivers now in kernel-space, we will see big speed increases and greater support for the advanced features in modern graphics cards.

As one K5er in #kuro5hin said, "tons of stuff" is new and improved. Speed increases, bug fixed, more hardware support, CPU optimizations, the list goes on.

The only question left for me is: "When will Patrick Volkerding deem 2.4.0 and it associated tools good enough for Slackware?" :-)

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
While waiting for 2.4.0 you...
o wrote stories for K5 1%
o trolled slashdot 10%
o ran the 2.4.0-testX versions 27%
o hacked on 2.2.x 6%
o new kernel, huh? 12%
o just used *BSD :-) 20%
o made fun of our local girl-drink drunk, Inoshiro 21%

Votes: 148
Results | Other Polls

Related Links
o Kuro5hin
o Kernel.org
o Also by Justinfinity


Display: Sort:
2.4.0 Linux kernel released | 75 comments (69 topical, 6 editorial, 1 hidden)
Packet filtering already in kernel space (4.42 / 7) (#3)
by maynard on Fri Jan 05, 2001 at 01:10:26 AM EST

I'm under the impression that packet filtering from 2.0 outward was always managed in kernel space. certainly ipchains in 2.2 only sets policy, but does not implement the chain rules directly in userspace. I seem to remember a discussion of this during the 1999 USENIX Technical conference hosted by Stephen Tweedie on 2.2 and 2.3 kernel design where he presented several slides showing the networking stack -- and nowhere to be found was there a hook in the netstack from kernel to userspace in order to filter and toss packets by rule. I don't remember 1.0 or 1.2 having any packet filtering to speak of -- and MASQ was definately a feature addon in 1.3... though it's been a while.

Now, maybe I'm on crack and simply misremember what Tweedie said -- but I doubt it.

Cheers,
--Maynard

Read The Proxies, a short crime thriller.

Also: 2.2.18 shipped with backported USB (3.66 / 3) (#4)
by maynard on Fri Jan 05, 2001 at 01:13:58 AM EST

2.2.18 ships with the backported USB patches integrated into the kernel proper. It's now a supported feature of 2.2 and will be maintained from here on outward.

Read The Proxies, a short crime thriller.
[ Parent ]
that's good to hear (3.00 / 1) (#7)
by Justinfinity on Fri Jan 05, 2001 at 01:31:50 AM EST

i didn't know that USB had been offically backported. guess it's time to upgrade the kernel in slackware again :-)

-justin
[ Parent ]
Networking stack multithreaded in 2.2 (4.60 / 5) (#5)
by maynard on Fri Jan 05, 2001 at 01:21:30 AM EST

It was the Networking DRIVERS which weren't thread safe with their own spinlock per driver. This is why Netcraft and Microsoft chose a four CPU system with four NICs of the same manufacturer. When the driver set a spinlock it blocked all the other cards, which in turn blocked the entire networking stack. This is an entirely separate problem from the "Thundering Hurd" issue resolved for Apache in 2.4 in order to force waking only one thread on a socket request instead of waking all threads owned by a process -- which is the case for 2.2. These were two separate bottlenecks which let to two separate solutions, primarily in response to the Netcraft benchmarks.

Read The Proxies, a short crime thriller.
[ Parent ]
Slight Clarification Needed... (4.00 / 1) (#68)
by sracer9 on Sat Jan 06, 2001 at 03:01:35 PM EST

This is why Netcraft and Microsoft chose a four CPU system with four NICs of the same manufacturer.

I believe it was Mindcraft and Microsoft which got together originally for the "comparison". Netcraft only surveys the web for web browser / platform information.

[ Parent ]
then what's the big deal about iptables? (3.00 / 2) (#9)
by Justinfinity on Fri Jan 05, 2001 at 01:39:16 AM EST

it seems to be a much-awaited feature, but what you've said makes it sound a bit less.

-justin
[ Parent ]
Haven't read up recently (3.00 / 2) (#12)
by maynard on Fri Jan 05, 2001 at 01:49:18 AM EST

Last I looked into it iptables simply added more flexibility to the rulesets and reduced unneccessary redundancy in the chains. I think they also tied in the netshaper stuff to allow for fine-grained network load balancing -- but I could be wrong about that. I haven't looked into this stuff since the 2.3 series so I'm horribly out of date here, but I seem to remember that was in the plans. Here's Joe Pranevich's Wonderful World of Linux 2.4 - 11/23/00, which I think was the last of his releases. That should give you a better idea than what I've written. --M

Read The Proxies, a short crime thriller.
[ Parent ]
thanks (3.00 / 1) (#18)
by Justinfinity on Fri Jan 05, 2001 at 02:10:25 AM EST

checking out that link right now :-) i'm always interested in learning new stuff. especially this because i'm in the midst of setting up a [freebsd,openbsd,slackware] firewall at home :-)

-justin
[ Parent ]
Stateful (none / 0) (#67)
by The Madpostal Worker on Sat Jan 06, 2001 at 12:48:15 PM EST

The iptables includes support for stateful packet filtering, which makes some protocols a _lot_ easier to deal with.
<-- #include "~/.sig" -->
[ Parent ]
Asking K5: DRI in kernel space? (3.87 / 16) (#6)
by vastor on Fri Jan 05, 2001 at 01:28:33 AM EST

DRI in kernel space...

I seem to recall there was a great hammering of NT 4 when it came out because it moved video into kernel space (and was blamed for its lesser reliability compared to OS/2 at the time... yeah, we're going back a while, could even be 3.51 or something like that, an NT zealot would probably know).

Is this a non-issue now or will we find not so good video drivers crashing linux machines now (rather than just X crashing lots I guess). Or are linux blue screens of death something to look forward to?

Disclaimer: I've no idea about this kind of stuff, but it does seem that the more drivers etc moved into kernelspace the more chances there will be for nasty problems.


More than just a video drver (3.66 / 6) (#8)
by maynard on Fri Jan 05, 2001 at 01:37:12 AM EST

It's my understanding that Microsoft moved not only video card drivers (which is reasonable as it's a hardware device), but also GDI drawing primitives into kernel space as well. However, the problems with NT-4.0 were mostly the result badly written video card driver by the manufacturers of the video cards and not from moving GDI into the kernel as a NT microkernel process, like so many claimed.

It's ironic that for so long Linus has rebuked the GGI project from inclusion of their original KGI kernel space video drivers, yet has managed to introduce much the same idea on his own. DRI will benefit Linux users tremendously as one of the main problems with having multiple userspace processes manage video hardware is getting all the various projects to treat the hardware properly. This is why we have so many video lockups while switching between X and svgalib programs. It's simply appropriate for the kernel to manage security and properly resetting hardware when sharing between multiple processes.

JMO

--Maynard

Read The Proxies, a short crime thriller.
[ Parent ]

who's to say Linux DRI drivers will be better? (2.33 / 3) (#10)
by Justinfinity on Fri Jan 05, 2001 at 01:45:18 AM EST

yeah, open-source, blah blah blah. microsoft's WHQL (windows hardware quality lab) does seom pretty stringent testing before certifying drivers. also, not all DRI drivers will be released with source. just look at nvidia.

i was also wondering about why GGI and Berlin have been overlooked as far as the kernel is concerned. DRI seems to be fairly new compared to GGI. maybe it's just a Linus thing, like not using CVS. anyone in know about kernel development have any idea?



-justin
[ Parent ]
Better than what? (3.25 / 4) (#15)
by maynard on Fri Jan 05, 2001 at 01:57:17 AM EST

I was simply replying to the question. Anyone who has had to suffer through NT-4.0 in production knows that it's prone to random lockups. Usually this can be traces to a poorly written vendor supplied video driver. Many folks have been claiming that these lockups were the result of moving GDI into kernelspace between NT-3.51 and NT-4.0, but this really hasn't been borne out. Not surprising really, since MS has complete control over their GDI code tree, while during the early part of NT-4.0's release they didn't enact very strict controls over vendors who wrote drivers. They've wised up to this mess in NT-5 with the somewhat predictable result that it's pretty stable. I've seen Win2k run for several months straight without going tits up, so it looks like they've resolved this problem. Still, my whole point had nothing to do with a "open-source vs. Microsoft" qualitative judgment regarding the inclusion of kernel space video drivers in Linux. --M

Read The Proxies, a short crime thriller.
[ Parent ]
heh - COMPLETELY off topic tangential question (4.00 / 2) (#27)
by el_guapo on Fri Jan 05, 2001 at 10:17:44 AM EST

"tits up" - i haven't heard this term for over _10 years_, and then it was only while i was in the navy that i ever used it. i'm just curious if you're ex-military...
mas cerveza, por favor mirrors, manifestos, etc.
[ Parent ]
Really? (none / 0) (#30)
by spiralx on Fri Jan 05, 2001 at 10:46:00 AM EST

I hear it quite a lot here in London. Dunno, maybe it's not so much an American thing nowadays, but it's been used around here for longer than I can remember...

You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
[ Parent ]

Ski Lifts? (none / 0) (#57)
by edibiase on Fri Jan 05, 2001 at 05:58:03 PM EST

My dad always says, "Tits up!" when we're nearing the end of ski lifts and he sees the "KEEP TIPS UP" sign.

[ Parent ]

Kernelspace video and stability (3.25 / 4) (#13)
by gblues on Fri Jan 05, 2001 at 01:51:36 AM EST

It's good to finally see video drivers in the kernel, where they belong. I used to follow the GGI project, back when it was actually going somewhere. The topic of stability/crashes came up quite frequently on the mailing list.

What it comes down to is that many PC video adapters are very poorly designed, and put a large burden on the driver writer to avoid locking up the video card processor.

For example, with the main CPU, even if your program does something clearly illegal, the worst that will happen is that you'll get a segmentation fault and the process dies. There are exceptions (F0 0F bug), but in general it's always able to recover from bogus programs.

Not so with many video adapters. Feed it the wrong instructions and your computer's locked up solid. So the driver author has to make sure this doesn't happen, which usually means that acceleration features aren't used very extensively (at least not in the early revisions of the driver).

Nathan
... although in retrospect, having sex to the news was probably doomed to fail from the get-go. --squinky
[ Parent ]
it comes down to code quality (2.33 / 3) (#14)
by Justinfinity on Fri Jan 05, 2001 at 01:54:07 AM EST

if the drivers are of high enough quality, a graphics related crash should be as likely as a network related crash. OTOH, the graphics pipeline has a lot of dis-jointed parts: X clients, [GLX], X server, driver, hardware. we all know that a single mishaving app can crash X (netscape 4.x anyone).

even with high quality code. stability is still a question. is navigator crashing and taking X with it going to cause a kernel panic with DRI drivers? or am i going to be able to just kill anything leftover from the dead X session and startx again? i'm still using 2.2.17 currently, and not using any of the few [experimental]kernel graphics drivers there so i don't know exactly what will happen.

of course, on a server, you usually won't find a GUI, so that's moot. but for a workstation that doesn't _need_ ultrafast GUI performance, the old userland stuff might be better from a stability standpoint.



-justin
[ Parent ]
I have never once seen Navigator crash my X server (3.00 / 1) (#17)
by maynard on Fri Jan 05, 2001 at 02:07:46 AM EST

I've seen it consume all availabe virtual memory from it's many insufferable memory leaks. I've seen it segfault randomly crash the application, taking my work down with it. I've repeatedly seen various Motif bugs such as the text input bug which has a horrible memory leak during each text wrapping instance in the text input box. But I have NEVER seen Navigator take down my X server. The only times I've seen my X server crash were from DRI changes in recent games, or from switching between svgalib X applications back and forth. This is due to various applications not treating the video card hardware properly, such as improperly resetting the card registers and restoring previous state during the transition between one video mode to the next. This has nothing to do with Navigator and everything to do with lame-ass PC video cards and a broken video driver model in Linux. DRI should fix this once and for all. --M

Read The Proxies, a short crime thriller.
[ Parent ]
i have had navigator crash X (3.00 / 1) (#19)
by Justinfinity on Fri Jan 05, 2001 at 02:27:32 AM EST

full lockup, no keyboard response, no mouse. only things running were navigator and xchat, and it's never happened with xchat and mozilla. may be something else, but it's happened more than once and always with navigator

anyways, you make a damn good point about fixing the broken graphics driver model. i've done some games programming, and one of the issues when programming a game running on top of a GUI is mode switching, restoring state and such. i remember the allegro library dealt with this with a few creative hacks, but i did manage to jam up the video card more than a few times. :-P

"lame-ass PC video cards", hehe. x86 is one giant kluge. anything that smooths it out is great IMO



-justin
[ Parent ]
Navigator freezing X (3.00 / 1) (#26)
by gds on Fri Jan 05, 2001 at 08:48:30 AM EST

full lockup, no keyboard response, no mouse. only things running were navigator and xchat

I have seen navigator grab the X server and never let go (I suspect incautious use of XGrabServer() in the motif menu code), which produces the same kind of symptoms you are describing -- If the mouse is still moving but the pointer shape doesn't change and clicks seem to be ignored then that's probably what it is (especially if navigator has a menu visible). logging in remotely and killing navigator usually recovers the session, though. If remotely logging in isn't an option you could look at the Joystick Reboot Daemon which did the trick for me when I was trying to program with a rather buggy X library.

Anyway, it looks like DRI is just the low level drivers. This should mean the X server can run with fewer privileges which will hopefully mean any potential lockups will cause less hassle (the kernel should be able to reset the console video mode cleanly, for instance). Hopefully this would mean that you could just kill off the (userland) X server and recover cleanly (you can do something similar right now with SysRq but it's not always neat). How did you deal with it when you were using Allegro?



[ Parent ]
i didn't actually do the hacks to allegro (none / 0) (#44)
by Justinfinity on Fri Jan 05, 2001 at 02:18:26 PM EST

i was programming for allegro in windows, and you had to be careful with state changes with respect to switching from full-screen to windowed mode. the allegro crew eventually got some flags setup to tell the driver exactly what you wanted to do when you switched modes

-justin
[ Parent ]
Aha! (none / 0) (#74)
by 11223 on Tue Jan 09, 2001 at 03:24:18 PM EST

I *hate* that netscape does that. It's caused me no end of pain on this Sun machine. Grrr....

A real OS never grabs the pointer for anything. There should never be modality in an operating system.

--
The dead hand of Asimov's mass psychology wins every time.
[ Parent ]

Not quite (4.66 / 9) (#20)
by fluffy grue on Fri Jan 05, 2001 at 02:44:19 AM EST

All that's in kernel space is the stuff for acquiring and executing command buffers on the 3D card, which is rather minimal. Everything else (i.e. setting up the commandbuffers, etc.) is in userspace; the kernelspace driver is just a resource manager, which is much better than the alternative (having the X server and/or 3D program run as root). I did a presentation on Linux OpenGL drivers for CS574 last semester which goes somewhat into the various data paths taken by the various Linux hardware OpenGL implementations (fxMesa, Utah-GLX, and DRI), though it's rather cursory, but it does link to the various pertinent DRI documents and stuff if you want to wade through Precision Insight's marketing-hype-ish "technical" documents.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

BZZT (3.40 / 5) (#21)
by ksandstr on Fri Jan 05, 2001 at 04:00:22 AM EST

Wroong. The part of the direct rendering infrastructure (aka DRI) that is in the kernel is the direct rendering manager (also known as DRM). NT had/has so much of the GDI in kernel space that moving Xfree86 into the kernel (ultrix, anyone? :-) would be a comparable move for Linux.



Fin.
[ Parent ]
video and the nt executive (2.50 / 2) (#28)
by Inferno on Fri Jan 05, 2001 at 10:33:43 AM EST

NT still crashes when the video is done is user space because the nt executive can't function without it. if video subsystem crashes, the system goes down whether it's running in kernel or user space.

[ Parent ]
Well, here are some of my experiences... (4.00 / 2) (#29)
by WWWWolf on Fri Jan 05, 2001 at 10:45:29 AM EST

I have ATI Rage128 card, known not to work that well but at least it works in X nicely.

Currently, I run 2.4.0, and DRI for kernel and X are compiled as modules that are NOT loaded by default for me. Reason? Wrong program combination with X == BOOOM.

I had a Serious Crash with xawtv and DRI in 2.4.0-test11 or so, and I survived the reboot. Luckily. Not used it since, but at least I know some 3D games and apps work if I need them - I just need to be careful. =)

But when I'm not using the 3D stuff, I can keep the hardware graphics modules unloaded. If I wouldn't need video card support, I might as well remove it from kernel completely. And uninstall X while I was at it.

The keyword here is that stuff like this here is optional. If you require absolute stability, you can remove all potential trouble-inducing elements from Linux. That, in NT, may be pretty hard.

-- Weyfour WWWWolf, a lupine technomancer from the cold north...


[ Parent ]
Kernel 2.4.0 Released - heres a fast mirror (1.50 / 2) (#32)
by CiXeL on Fri Jan 05, 2001 at 11:38:32 AM EST

heres a mirror

DOWNLOAD NOW - Linux Kernel 2.4.0

enjoy... i'm really suprised the headline was scrolled off /. so fast.
Question Tradition...
[ Parent ]

Slackware.. (3.00 / 5) (#22)
by enterfornone on Fri Jan 05, 2001 at 04:28:35 AM EST

"When will Patrick Volkerding deem 2.4.0 and it associated tools good enough for Slackware?"

Well if the time it took him to move to glibc is any indication probably not any time soon...

--
efn 26/m/syd
Will sponsor new accounts for porn.

glibc was nasty full of bugs (2.50 / 2) (#23)
by Justinfinity on Fri Jan 05, 2001 at 05:00:29 AM EST

Patrick didn't incorporate glibc immediately because it was buggy to start off with. once it was up to the slackware standards, it went right in.

-justin
[ Parent ]
Heh, but what about conribs? (none / 0) (#41)
by simmons75 on Fri Jan 05, 2001 at 01:58:21 PM EST

glibc was available in the contribs section for quite a while before it was ever part of the main distro. Not that there was any reason to run it (unless you tried to install converted RH RPMs...)
poot!
So there.

[ Parent ]
Bring it yourself (none / 0) (#45)
by shrub34 on Fri Jan 05, 2001 at 02:26:27 PM EST

Rememeber, Linux is only the kernel, therefore download 2.4.0 and go.

I've done this myself with Slackware and had no problems at all.


=====
It's good to see the BSD community forking and execing so many child processes.

  • Comment about editor of Daemon News not attending BSDcon 2000

  • [ Parent ]
    really? (none / 0) (#54)
    by Justinfinity on Fri Jan 05, 2001 at 04:16:27 PM EST

    i tried 2.4.0-test9 or so in slack 7.1 and had problems with modules because insmod, modprobe and such didn't play nice with the new kernel. what version of slackware are you running? and did you get a new copy of modutils from somewhere?

    -justin
    [ Parent ]
    Read Documentation/Changes (none / 0) (#59)
    by Zane_NBK on Fri Jan 05, 2001 at 07:13:06 PM EST

    Under your linux dir read Documentation/Changes (as you should with every new kernel version). Go down a page and it'll tell you what utilties should be upgraded since 2.2.x, modutils is one of them. You'll have to download the source to several of those and recompile before those packages will work properly.

    -Zane


    [ Parent ]
    doh! (NT) (none / 0) (#63)
    by Justinfinity on Sat Jan 06, 2001 at 01:29:56 AM EST



    -justin
    [ Parent ]
    Question: UDF (2.60 / 5) (#25)
    by Niggle on Fri Jan 05, 2001 at 08:02:28 AM EST

    Does anybody know if the UDF support is read-write? Last time I looked (about a year ago, I'll admit) it was read-only. I'd like to be able to use my CD-RW like a giant floppy under Linux.

    UDF R/W (3.50 / 4) (#33)
    by AngelKnight on Fri Jan 05, 2001 at 11:39:52 AM EST

    As I understand it, UDF is R/W-ready now for DVD-RAM drives. The reason it may never be R/W for CD-RW drives is that there is no standard command set for block writing CD-ROM/CD-RW data.

    This is why CDParanoia and the like require access to the SCSI generic device hooks; they have to build the SCSI-II commands by hand in userspace then issue them to the CD-RW device. Kind-of analagous to having to open a raw socket to write ICMP; only in this case you have to since not every burner speaks the exact same language.

    [ Parent ]
    Experimental (2.00 / 2) (#50)
    by Sherman Peabody on Fri Jan 05, 2001 at 03:16:41 PM EST

    It is in there, but you take your chances. Why not go in there and pund on it? Someone has to find the bugs ;)

    [ Parent ]
    IPTables (3.33 / 3) (#31)
    by reshippie on Fri Jan 05, 2001 at 11:23:21 AM EST

    You say that it works like ipchains and ipmasq, does that mean that I'd have to play with it to get NAT working? I was planning on upgrading to 2.4 so I could get my Visor synched up nicely, but I also want to be able to use my computer as a server in my apt, to connect all of the other computer to the internet.

    Maybe i'll just go with 2.2.18. hmm. Any thoughts or comments are greatly appreciated.

    Those who don't know me, probably shouldn't trust me. Those who do DEFINITELY shouldn't trust me. :-)

    ipchains.o (3.00 / 1) (#36)
    by Aztech on Fri Jan 05, 2001 at 12:49:48 PM EST

    There's a module you can load that allows you to use ipchains with the iptables backend, so you don't have to go converting your firewall over to iptables at the moment.

    [ Parent ]
    Or ... (2.00 / 1) (#37)
    by stepson3 on Fri Jan 05, 2001 at 12:59:39 PM EST

    Or just Run OpenBSD :) I was amazed at how easily I could set up firewall rules and NAT with OpenBSD (using IPFilter) and what a PITA it was with Linux.

    For real fun, try to get True 1:1 NAT working under Linux 2.2 kernel ... on IRC they told me to use MASQ, I told them, No I want 1:1 Nat Mapping ... they told me ...use MASQ ...:)

    [ Parent ]
    RE: Or ... (4.50 / 2) (#51)
    by kimo_sabe on Fri Jan 05, 2001 at 03:18:09 PM EST

    hmm:
    echo 1 > /proc/sys/net/ipv4/ip_forward
    ipchains -F
    ipchains -P FORWARD -j DENY
    ipchains -A FORWARD -s 192.168.0.0/255.255.0.0 -j MASQ

    Is there some incredible challenge I'm missing?

    With iptables it's a little different, not much, only the last line changes.

    iptables -A FORWARD -s 192.168.0.0/16 -j ACCEPT
    iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE

    As for 1:1 NAT, why? I don't think ipchains can handle it. iptables shouldn't have any trouble with it though.


    Among other iptables trick not mentioned yet:
    - taking TCP flags into account(All SYN's are denied, but existing connects are left intact)
    - Multiple(up to 15) tcp/udp ports per-rule
    - using local packet owner in rules. (luser@localhost can't connect to /., but everybody else can)
    - "mirror" target. Bounced matched packets back to their owner.
    - better/real source NAT, including range support.
    - destination NAT support: Change where a packet well end up.
    - ooh, and I almost forgot the packet mangling table. I don't know of any constructive use for it, maybe setting TOS field in packets. But it lets you arbitrarilly change the contents of a packet.

    That was all pulled from the iptables manpage.

    Lots of neat new toys, and that's just the firewall changes.

    - kimo_sabe

    "Software is like sex: It's better when it's free." -- Linus Torvalds
    [ Parent ]
    Get a cheap comp for your firewall (3.00 / 1) (#38)
    by ltfiend on Fri Jan 05, 2001 at 01:25:12 PM EST

    I run linux on a 133mhz machine with 2 nics. Very cut down linux to enhance security IP masq for all the other computers and snort to boot as intrusion detection (ntop does a good job of monitoring the whole thing)

    [ Parent ]
    routers are cheap (3.00 / 2) (#48)
    by SEAL on Fri Jan 05, 2001 at 03:11:19 PM EST

    You can pick up a Linksys (don't know model # offhand), or a Netgear RT-314 for about 150 bucks. They are cheaper, quieter, and much easier to set up than a Linux router. Also, they are arguably more secure.

    Of course if you already have the machine lying around, or you want to run services like oh... a quake dedicated server, then the Linux box might make more sense.

    Just my $.02

    - SEAL

    It's only after we've lost everything that we're free to do anything.
    [ Parent ]
    Cheaper (2.50 / 2) (#55)
    by reshippie on Fri Jan 05, 2001 at 04:31:21 PM EST

    But not as cheap, or as fun, as just playing with my own system. :)

    Those who don't know me, probably shouldn't trust me. Those who do DEFINITELY shouldn't trust me. :-)
    [ Parent ]
    NAT (3.50 / 2) (#49)
    by bretjb on Fri Jan 05, 2001 at 03:13:35 PM EST

    Kernel 2.4 NAT Howto. -- enjoy :)

    http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO.html

    [ Parent ]
    Linux 2.4.0 is Slashdotted (sorry)... (2.50 / 4) (#34)
    by alexburke on Fri Jan 05, 2001 at 11:41:49 AM EST

    ...so here's a mirror I just put up for the K5 crowd. Enjoy, and go easy on me! :)

    - Alexander Burke
      Hardware hacker and all-around technogeek
    Vaguely OT: You know you've spent time on /. (3.50 / 2) (#35)
    by Captain_Tenille on Fri Jan 05, 2001 at 12:45:04 PM EST

    When somebody claims to put up a "mirror" of something that has been /.'ed, and you always check first. Not that I would accuse anyone here of doing that. :-)
    ----
    /* You are not expected to understand this. */

    Man Vs. Nature: The Road to Victory!
    [ Parent ]

    Fast UK/Europe Mirror (2.50 / 2) (#43)
    by vrai on Fri Jan 05, 2001 at 02:12:11 PM EST

    Kernel.org is still slower than a very slow thing - So I've been allowed to stick a copy on our company server (my employers understand a techy's needs :). Its at http://www.hoojit.com.mirror/.



    [ Parent ]
    don't forget (2.40 / 5) (#39)
    by yavor on Fri Jan 05, 2001 at 01:27:06 PM EST

    now you can filter packets based on their MAC address
    beautiful ;)

    Determining the MAC address. (none / 0) (#46)
    by substrate on Fri Jan 05, 2001 at 02:52:22 PM EST

    How do you determine the MAC of a remote computer? Sorry, this is really off topic, but a google search only turned up pages on finding the MAC on your windows box to make ISP's happy.

    [ Parent ]
    MAC addresses (3.00 / 1) (#58)
    by whatnotever on Fri Jan 05, 2001 at 06:21:40 PM EST

    Depends what you mean by remote. MAC addresses are used in ethernet to deliver frames to a particular adapter, so you can find out the MAC of a particular ip /on your lan/ by pinging it and running arp (with options or not, depending on your os) to check the arp cache. The MAC address of any machine past a router is unknown, as it is not used for any routed protocols.

    I'm not sure what the point of filtering by MAC address is, though. The machine will have to be on your lan, so I would assume you will know the ip of each machine and probably control it. MAC addresses can be changed and faked as easily as ip's, so it wouldn't offer any more security... I dunno.

    [ Parent ]
    Perhaps... (none / 0) (#69)
    by Ranger Rick on Sat Jan 06, 2001 at 04:11:33 PM EST

    Perhaps it would allow filtering and forwarding of non-IP-based packets...

    :wq!


    [ Parent ]
    What I want to know (2.00 / 3) (#47)
    by Demona on Fri Jan 05, 2001 at 03:02:00 PM EST

    I do not want to know who will be the first distribution to use the 2.4.x-stable [whatever :] kernel.

    h I will be extremely interested to see who the first distribution is, to use it well.

    Debian! (2.00 / 2) (#62)
    by Ig0r on Sat Jan 06, 2001 at 12:04:53 AM EST

    Debian could use a 2.4 kernel NOW if they wanted, as could Slackware and Redhat. I don't know about other distros, but the supporting programs are already there, and all that's needed is to drop in a 2.4 kernel.
    I've been using a 2.4.0-test kernel in debian unstable for a while now.

    [ Parent ]
    Does IPtables do Remasqing? (4.00 / 5) (#52)
    by Srin Tuar on Fri Jan 05, 2001 at 03:48:16 PM EST

    The was/is an issue with the 2.2 Ipchains Masqing code: A packet that has been masq'd for transmission out to the internet will not be remasq'd if its destination is back inside the LAN.

    For example, I am running a webserver inside my lan, and I have an ipchains box port-forwarding port 80 to it. Its works fine, requests for the firewalls's internet address are sent to it properly, except that other hosts inside my lan who are sharing the connection cannot acces the site from its canonical internet address.

    This is also an issue with games such as starcraft: two people playing from the same LAN cannot join each other's battle.net games because ipchains will not do remasqing.

    Now this is one of my main problems with ipchains, Does anyone know if this is fixed? If not, does anyone know an operating system that does support remasqing?

    BTW: i know there is a 2.2 kernel patch to allow remasqing but it screws up other aspects of ipchains such as security.

    games, servers, and ipchains. (4.00 / 3) (#65)
    by erotus on Sat Jan 06, 2001 at 04:40:40 AM EST

    "2.2 Ipchains Masqing code: A packet that has been masq'd for transmission out to the internet will not be remasq'd if its destination is back inside the LAN. "

    I'm not sure what you mean by this. You mean you make a connection to a point outside your LAN and the return packets die at the firewall? Maybe you are refering to stateless vs. stateful packet filtering. IPTables will be stateful and may solve some of your problems.

    I can't speak for starcraft. I have had seven people behind a an IPChains box connected to an @home cable modem - we logged on to unreal tournament and counterstrike servers with absolutely no problems. Maybe starcraft is an entirely different beast.

    "I am running a webserver inside my lan, and I have an ipchains box port-forwarding port 80 to it. Its works fine, requests for the firewalls's internet address are sent to it properly, except that other hosts inside my lan who are sharing the connection cannot acces the site from its canonical internet address."

    But I'm sure you can get to it by typing in it's IP address. A quick fix for this would be to add the canonical name for your webserver and it's (internal)IP address to your /etc/hosts file if you're using linux on the desktop. If you're using windows 9x then make the changes in c:\windows\hosts.sam. I think I may have a hunch as to what is going on and why you may not be able to access your webserver using it's name. You may want to check your firewall logs to get a better clue.

    There was a clever ipchains firewall script floating around the net a while back that many people copied. There is also a web-based ipchains script generator which made that script. (maybe you did the same) Anyway, attempted accesses on the externel interface claiming to be from an internal address were automatically denied to prevent spoofing. I think this is your problem. You type in www.somename.org and it queries the DNS server. The DNS server returns the IP address of the externel interface of your firewall. Your browser then tries to access this IP address. The firewall sees an internal address trying to access it's external interface and checks its ruleset only to DENY the packets.

    Even if it didn't deny the packets, the whole process of name lookup and packet redirection is a waste of energy. You'd basically send requests to your external interface which would then be sent back in to your internal server. The server would see the external interface as the originating IP and send packets back to that address which would then be forward back to your box. Wow, this is starting to sound like a VLAN. Anyhow, make those changes in the hosts files and you won't have to worry about any of this.



    [ Parent ]
    IP doesn't work (none / 0) (#70)
    by Jeremy Mooney on Sat Jan 06, 2001 at 04:32:57 PM EST

    I've had the same problem, and using the IP doesn't work. The firewall shows no attempts, and it doesn't work with no rules in place either... I remember reading when I tried to solve this that it is a known bug in the masq code somewhere.

    yafiygi.com - Randomization in web design
    [ Parent ]
    Re: IP doesn't work (4.00 / 1) (#72)
    by erotus on Sat Jan 06, 2001 at 06:41:22 PM EST

    ok. Are you talking about the IP the outside world sees or the internal IP in the LAN. If it is the latter and not the former then I don't see why it would not work. Well, let me give you my setup.

    .........destop pc
    ``````````````\
    desktop pc ----hub----firewall-----cable modem
    ``````````````/
    .............server

    The rightmost side of the word firewall would have the external IP(x.x.x.x). The leftmost side would have the internal IP(192.168.0.1). The server would be 192.168.0.200 and the pc are assigned addresses from the server in the same subnet range of course.

    If I do a http://192.168.0.200 then I can reach the server with no problem. If I try to go thru the forwarded port 80 on the external side with an ip of 24.x.x.x then that's when the problem occurs. Unless I completely misunderstood the original posters message, then I'm assuming he has 2 nics - one external and one internal. He said he was forwarding packets destined for port 80 to a computer inside of his LAN. If the computer you are trying to access is inside of your LAN then firewall rules need not apply. If you have to hit your firewall to get back to a computer inside your LAN then you either have a VLAN(router on a stick) or you have a problem. In his case, he has a configuration problem.

    I would like to try IPTables out, but I don't think it will happen soon. I've had no problems with IPChains and being the lazy guy that I am, I can't see my self changing it anytime soon. I will eventually give in to curiosity and change my firewall for fun! Did I just say fun out loud? I do this kind of stuff for fun? No, but really, it would be educational to try and change it - that's what I meant.



    [ Parent ]
    Re: IP doesn't work (none / 0) (#75)
    by Jeremy Mooney on Thu Jan 11, 2001 at 07:43:08 PM EST

    The problem is usually when using DNS names... They give the external IP, which doesn't get forwarded back in (the inside machines go to the router unless you manually specify a route because it's not an IP on the local subnet.

    yafiygi.com - Randomization in web design
    [ Parent ]
    distributions (3.66 / 3) (#53)
    by brad3378 on Fri Jan 05, 2001 at 03:57:02 PM EST

    Could somebody please comment on when we should expect to see the next Redhat & SuSE distributions in stores?

    I've been waiting to buy a new set of disks, but I'm not sure how much longer I'll have to wait.

    Thanks In advance.

    Serious performance problems? (4.00 / 1) (#56)
    by kovacsp on Fri Jan 05, 2001 at 04:47:15 PM EST

    I just tried it after compiling a set of new utilities (e2fsprogs, etc) and I ran into a lot of performance problems while running X. I didn't have time to investigate before switching back to 2.2.18. I think it might have had to do with having VESA framebuffer support in the kernel while running X, but I don't know. Every now and then CPU usage goes to 100% and stays there for 10 seconds, for no good reason.

    Anybody else have these problems?

    New record in inaccurate reporting ? (3.50 / 4) (#60)
    by Eivind on Fri Jan 05, 2001 at 08:14:43 PM EST

    * USB in 2.2 is fully integrated. It does /not/ require patching the source in any way. (yes, it's bacported)

    * Packet filtering has been in the kernel all along. Atleast since 2.0. (actually, I doubt it's /ever/ been done in userland on Linux) They have however changed implemntation with each revision. 2.0 had ipfwadm as a frontend to handle the internal kernel-firewall rules. 2.2 changed to the ipchains-implemntation since that was deemed more flexible. (again the ipchains command is just a frontend for manipulating the internal kernel-rules) 2.4 uses yet another implementation, iptables, presumably even better than ipchains, but I've not tested it yet so I can't really comment on that.

    * "many" SVGAlib programs didn't need to be suid-root -- they /all/ needed to (and still do, though now ther'es better ways)



    Re: New record in inaccurate reporting (3.00 / 1) (#64)
    by erotus on Sat Jan 06, 2001 at 03:54:41 AM EST

    "2.4 uses yet another implementation, iptables, presumably even better than ipchains"

    Yes... the rulesets are simpler and we now have stateful packet filtering.

    [ Parent ]
    Not all 2.2.x kernels have USB (3.00 / 1) (#66)
    by ScottW on Sat Jan 06, 2001 at 12:37:54 PM EST

    * USB in 2.2 is fully integrated. It does /not/ require patching the source in any way. (yes, it's bacported)
    Since USB support was backported only recently, only the most recent 2.2.x kernels have it.

    [ Parent ]
    slackware (3.50 / 2) (#61)
    by andyschm on Fri Jan 05, 2001 at 08:42:38 PM EST

    I dropped linux-2.4.0-test12 into my Slackware 7 distro about a week ago and have been running strong on 2.4 since. I did have trouble compiling a couple things... php 4.0.4 'configure' would hang and I tried to compile some MPI test programs and it threw me into a hard-freeze (ugh!)... I am sure that 2.4 will be stable within 6 months or so.. ;-)



    mirror (none / 0) (#71)
    by anticlus on Sat Jan 06, 2001 at 05:02:16 PM EST

    ok, well, kenel.org is back up, but the bandwidth meter is still high. anyway, i put up a mirror for k5 people on my school's new t1, considering that there won't be a rush to get the kernel anymore, i think that our little server should be able to handle it. enough blabbering... this will take you to my personal site, just click on the very obvious 2.4 image ;-> And have fun!

    gfx in kernel space!?!? (none / 0) (#73)
    by nickwkg on Mon Jan 08, 2001 at 07:06:44 AM EST

    "graphics drivers now in kernel-space" - that can't be right can it?

    Not that I'm an expert but I had always thought that that was bad kernel design. Can anyone explain why (apart from for speed reasons) this is a good thing?

    2.4.0 Linux kernel released | 75 comments (69 topical, 6 editorial, 1 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!