Re: [Leaf-devel] IP-Masq'ing question
The only way I can see this working is if you: a) know and define the subnet the fixed addresses will be in b) don't ever need to get to that subnet on the Internet (or at least not at the same time as you're using a wireless device). Better ways: DHCP. It's pretty easy to write a .bat or .sh which releases and renews -- with a little more work and snort you could probably autosense when that sort of activity was required? I'll assume you know about the big ugly holes recently discovered in WEP and have heard the stories about driving around with a laptop and an antenna... The risks aren't new (WEP == wired equivalent protocol and imagine a hub with a patch cable reaching out to the street for anyone to use), but they are recently publicized which means lots more script kiddies know about it. -- Jack Coates Monkeynoodle: It's what's for dinner! On Fri, 20 Apr 2001, Scott C. Best wrote: Heyaz. Curious for any leads, pointers, suggestions, patient explanations here. Here's the situation: given a Linux based NAT'ing firewall/router in between a modem and a 802.11 access point, I'd like to support an 802.11 network device that arrives on the network which is preconfigured "incorrectly". That is, suppose my LAN is 192.168.x.y, but a new device is configured with a static IP# (and static DNS, and even a static proxy) in some *other* range (say, in 206.184.139.137/24 somewhere). Presuming the firewall ruleset is flexible enough, how much of this would common IP-masquerading be able to handle already? Certainly the DNS and and proxy stuff would require some careful forwarding...but what about the NAT'ing and the routing? I've been noodling on this most of the day, and have fairly well convinced myself that it should be fairly straightforward with the NAT'ing, but a bit trickier with the ad-hoc ip-aliasing of the internal interface (so it would appear as the default gateway, DNS, and proxy for multiple devices differently). Anyhow...thanks in advance for any thoughts on this. cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] IP-Masq'ing question
Jack: Hurm. I know that I can't assure you of "a". In fact, quite the opposite: I have no idea what people will be bringing into the wireless LAN. On the other hand, I can safely assure you of "b". Can see your point: if I alias the internal interface to some other subnet's gateway or DNS IP address, it'd be tricky to ever trying to send packets thru the router to the "real" one. Regarding DHCP, I agree completely. That'd be best, and it's certainly going to be the default. But, I'm not sure I can force a user's laptop (say) to use DHCP if it started life in my LAN as a statically configured device. I think I just gotta deal with it, somehow detecting "lost" packets and adapting the interfaces, on the fly, accordingly. Or, as you suggest, run an active LAN scanner (perhaps an ARP watcher?) to see what just joined and make some guesses as to how to handle it. Risk wise, 802.11 certainly has that limitation with the independent-BSS mode. My understanding is in that "software access point" mode, everything on the LAN is essentially a peer, and so an illicit user can see and affect legitimate users directly. In "real" access points, there's a normal BSS mode, in which the AP mediates all of the traffic, and so peers are safer from each other. My understanding, though, is that none of the open-source projects support this second mode -- not until an Orinoco access point gets reverse engineered. -Scott On Fri, 20 Apr 2001, Jack Coates wrote: The only way I can see this working is if you: a) know and define the subnet the fixed addresses will be in b) don't ever need to get to that subnet on the Internet (or at least not at the same time as you're using a wireless device). Better ways: DHCP. It's pretty easy to write a .bat or .sh which releases and renews -- with a little more work and snort you could probably autosense when that sort of activity was required? I'll assume you know about the big ugly holes recently discovered in WEP and have heard the stories about driving around with a laptop and an antenna... The risks aren't new (WEP == wired equivalent protocol and imagine a hub with a patch cable reaching out to the street for anyone to use), but they are recently publicized which means lots more script kiddies know about it. -- Jack Coates Monkeynoodle: It's what's for dinner! On Fri, 20 Apr 2001, Scott C. Best wrote: Heyaz. Curious for any leads, pointers, suggestions, patient explanations here. Here's the situation: given a Linux based NAT'ing firewall/router in between a modem and a 802.11 access point, I'd like to support an 802.11 network device that arrives on the network which is preconfigured "incorrectly". That is, suppose my LAN is 192.168.x.y, but a new device is configured with a static IP# (and static DNS, and even a static proxy) in some *other* range (say, in 206.184.139.137/24 somewhere). Presuming the firewall ruleset is flexible enough, how much of this would common IP-masquerading be able to handle already? Certainly the DNS and and proxy stuff would require some careful forwarding...but what about the NAT'ing and the routing? I've been noodling on this most of the day, and have fairly well convinced myself that it should be fairly straightforward with the NAT'ing, but a bit trickier with the ad-hoc ip-aliasing of the internal interface (so it would appear as the default gateway, DNS, and proxy for multiple devices differently). Anyhow...thanks in advance for any thoughts on this. cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Off-list Re: [Leaf-devel] Updating Eigerstein
Eric Wolzak wrote: Hello Ewald, Charles Is anyone working on this already? If not I will have a start this weekend, or perhaps when I return from work tonight. If you prefer someone else's work please tell me so; it will save me some superfluous work. yep, sort of. Argh, I have hardly touched a computer the last few days. I would have replied sooner if I had. I am implementing the eigerstein on the 2.4.3 kernel from george. It just seems to change quite a lot. I am using Busybox 0.50 for now. as I had problems compiling the 0.51 with insmod. (see previous posts) Updated the ash. ( oxygen) Am working on the weblet. But changing to 2.4 and updating to iptables means also changes in portforwarding and masquerading. I now have working ( not properly tested image with shorewall) Personally I think shorewall is great, but I would like to hear other's opinions. I am working on a basic ip-addres setup kind of the way lrp does it. The rest of the system will be setup with a webinterface (sort of prealpha stage ;) at the moment. Allthough this kind of changes would mean a rather radical change away from eigerstein. :( So perhaps it would be the best to stay with ipchains. and only update a few programms (busybox etc). I think that should be the first goal. It would of course be very interesting to create a truly linux 2.4 based distribution, but it will hardly be eigerstein I think (though rather cool) As said , i am still in a very pre-alpha stage, and don't know if I come further. Well I'm in the same stage, but intend to finish it rather soon. I think I'll post a log of the changes I have made so far on tuesday. best I can tell you for sure is that I'm not working on this (just too busy). Feel free to do whatever work you have time for, and just ask if you have any questions or need anything from me. Allright! I'll see what I can do this weekend. As I have a part-time job, no wife and no children I'm not as busy as both of you. Of course I will keep a full log of the changes that I make for you to comment on. One of the bigger changes I propose is replacing ae with e3 or the busybox vi applet. That will make it a lot easier to throw out ncurses The busybox vi applet functions very well :) tried this. Good. But e3 is even smaller and quite functional. Greetings to all of you. Ook ewald de groeten :) Greetings to all, and to Eric: Gruesse aus Holland (hmm, where did you read that before :-) Ewald P.S. Eric; I live only 5 KM from the Dutch-German border. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Off-list Re: [Leaf-devel] Updating Eigerstein
I think that should be the first goal. It would of course be very interesting to create a truly linux 2.4 based distribution, but it will hardly be eigerstein I think (though rather cool) The special part of eigerstein is in effect the script to setup the firewall. This is based on ipchains. Using iptables Portforwarding, proxyarp are imho much easier than with the ipchains. I used shorewall My weblet uses the same syntax as the rules. But if i get more comfortable it can be changed to something like: I want a server with the ip addr.. to be presented as ... allowed to use are :... As said , i am still in a very pre-alpha stage, and don't know if I come further. Well I'm in the same stage, but intend to finish it rather soon. I think I'll post a log of the changes I have made so far on tuesday. okay time for CVS :) best I can tell you for sure is that I'm not working on this (just too busy). Feel free to do whatever work you have time for, and just ask if you have any questions or need anything from me. Allright! I'll see what I can do this weekend. As I have a part-time job, no wife and no children I'm not as busy as both of you. Of course I will keep a full log of the changes that I make for you to comment on. One of the bigger changes I propose is replacing ae with e3 or the busybox vi applet. That will make it a lot easier to throw out ncurses The busybox vi applet functions very well :) tried this. Good. But e3 is even smaller and quite functional. Greetings to all of you. Ook ewald de groeten :) Greetings to all, and to Eric: Gruesse aus Holland (hmm, where did you read that before :-) in my schoolbooks ;) ,I am dutch but live in Germany since 1984. Ewald P.S. Eric; I live only 5 KM from the Dutch-German border. Greetings Eric http://home.t-online.de/home/h.wolzak http://leaf.sourceforge.net/devel/ericw ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Off-list Re: [Leaf-devel] Updating Eigerstein
Eric Wolzak wrote: Greetings to all of you. Ook ewald de groeten :) Greetings to all, and to Eric: Gruesse aus Holland (hmm, where did you read that before :-) in my schoolbooks ;) ,I am dutch but live in Germany since 1984. Ewald P.S. Eric; I live only 5 KM from the Dutch-German border. Greetings Eric Is it time for a German LEAF Conference? :-) When are we going to see leaf.sourceforge.net.de ? :-) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS Distribution Administration Models.........
George Metz, 2001-04-20 21:23 -0400 On Fri, 20 Apr 2001, Mike Noyes wrote: In case of emergency, Eric and I already worked out a way to backup individual CVS trees. Excellent idea all around. We should probably have the CVS tree backed up on a semi-regular basis; if it's necessary, I have enough free diskspace kicking around on my machines that I can accomodate if you guys are tight on room. George, SourceForge tarballs our repository nightly. I added a "Tarball" link to our phpWS "Development" lblock. Anyone can download it now. http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.gz The single tree CVS backup we developed is a shell script in my home directory on shell1. It will require modification to be useful for backup purposes. All of the shell scripts I use for our project are readable by our group. The only one that is set to run as a cron job is the DocManager backup. Suggestions for improvements on any of them are always welcome. /home/users/m/mh/mhnoyes -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Off-list Re: [Leaf-devel] Updating Eigerstein
Eric Wolzak wrote: okay time for CVS :) Hmm, and hwo are we going te set this up? Currently there are lots of binaries in my eigerstein2beta tree for which I don't have (yet) the source code. Should there be seperate source and binaries trees? It would be really nice to do a "cvs co" and then a "make world". Greetings to all of you. Ook ewald de groeten :) Greetings to all, and to Eric: Gruesse aus Holland (hmm, where did you read that before :-) in my schoolbooks ;) ,I am dutch but live in Germany since 1984. I see. I thought you would have read it on a postcard from the Dutch coast! Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] IP-Masq'ing question
I don't think it's going to work, then. "On the fly" reconfiguration would mean downing the interface everytime a new machine joined the wireless LAN, which would get really annoying to the users. But if you treat the LAN like the Internet (0.0.0.0/0) then you can't route to it. Actually, that could work, I think, with proxy arp. wireless int - 192.168.254.254, bridging enabled def route forwards all traffic to eth1 masquerade as 192.168.1.1 eth1 - 192.168.1.254 another LRP is the Internet gateway. Double-NATing is goofy as hell and will probably break something. -- Jack Coates Monkeynoodle: It's what's for dinner! On Sat, 21 Apr 2001, Scott C. Best wrote: Jack: Hurm. I know that I can't assure you of "a". In fact, quite the opposite: I have no idea what people will be bringing into the wireless LAN. On the other hand, I can safely assure you of "b". Can see your point: if I alias the internal interface to some other subnet's gateway or DNS IP address, it'd be tricky to ever trying to send packets thru the router to the "real" one. Regarding DHCP, I agree completely. That'd be best, and it's certainly going to be the default. But, I'm not sure I can force a user's laptop (say) to use DHCP if it started life in my LAN as a statically configured device. I think I just gotta deal with it, somehow detecting "lost" packets and adapting the interfaces, on the fly, accordingly. Or, as you suggest, run an active LAN scanner (perhaps an ARP watcher?) to see what just joined and make some guesses as to how to handle it. Risk wise, 802.11 certainly has that limitation with the independent-BSS mode. My understanding is in that "software access point" mode, everything on the LAN is essentially a peer, and so an illicit user can see and affect legitimate users directly. In "real" access points, there's a normal BSS mode, in which the AP mediates all of the traffic, and so peers are safer from each other. My understanding, though, is that none of the open-source projects support this second mode -- not until an Orinoco access point gets reverse engineered. -Scott On Fri, 20 Apr 2001, Jack Coates wrote: The only way I can see this working is if you: a) know and define the subnet the fixed addresses will be in b) don't ever need to get to that subnet on the Internet (or at least not at the same time as you're using a wireless device). Better ways: DHCP. It's pretty easy to write a .bat or .sh which releases and renews -- with a little more work and snort you could probably autosense when that sort of activity was required? I'll assume you know about the big ugly holes recently discovered in WEP and have heard the stories about driving around with a laptop and an antenna... The risks aren't new (WEP == wired equivalent protocol and imagine a hub with a patch cable reaching out to the street for anyone to use), but they are recently publicized which means lots more script kiddies know about it. -- Jack Coates Monkeynoodle: It's what's for dinner! On Fri, 20 Apr 2001, Scott C. Best wrote: Heyaz. Curious for any leads, pointers, suggestions, patient explanations here. Here's the situation: given a Linux based NAT'ing firewall/router in between a modem and a 802.11 access point, I'd like to support an 802.11 network device that arrives on the network which is preconfigured "incorrectly". That is, suppose my LAN is 192.168.x.y, but a new device is configured with a static IP# (and static DNS, and even a static proxy) in some *other* range (say, in 206.184.139.137/24 somewhere). Presuming the firewall ruleset is flexible enough, how much of this would common IP-masquerading be able to handle already? Certainly the DNS and and proxy stuff would require some careful forwarding...but what about the NAT'ing and the routing? I've been noodling on this most of the day, and have fairly well convinced myself that it should be fairly straightforward with the NAT'ing, but a bit trickier with the ad-hoc ip-aliasing of the internal interface (so it would appear as the default gateway, DNS, and proxy for multiple devices differently). Anyhow...thanks in advance for any thoughts on this. cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED]
Re: [Leaf-devel] File Systems (was: CVS structure)
[EMAIL PROTECTED], 2001-04-20 18:03 -0700 On Fri, 20 Apr 2001, Mike Noyes wrote: This still doesn't explain why Debian is trying to do the following for their boot floppies. http://lists.debian.org/debian-boot-0102/msg00435.html ~ Build in crams and ramfs. We're going to boot off of a cramfs initrd ~ and then set up and pivot_root into a ramfs filesystem. I;m not really familiar with the details, but I think the cramfs initrd is both disk- and ram-efficient, and pivoting the root means switching the root over to a writeable filesystem while maintaining access to the old filesystem. For a boot floppy there is no customization, but it is convenient to have a writeable root. Jeff, You have a better grasp of the details than I do. :) If I have this right, cramfs isn't flexible enough for our needs. That means that Midori isn't useful for a base, and we're back to vfat or minix for long file name support. The MontaVista rep. seemed to think ext2 wasn't out of the question for our needs. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] IP-Masq'ing question
actually, better depiction and idea improvements: wireless area Internet | | LRP LRP | | ---LAN- Both LRP's masq, both LRP's treat the top interface as default network. Wireless LRP forwards everything into the LAN, masqing it as a single IP. The hard part now is Internet access from the wireless LAN, because you can't give the LRP two default routes pointing in two different directions :-) Nor can you use the massively annoying "static routes supernetting the whole Internet" trick because you're likely to get registered addresses on the wireless net from time to time. Routing into the LAN is easy, but routing from the wireless area to the Internet is going to be challenging. I think you're better off changing people's IP addresses. -- Jack Coates Monkeynoodle: It's what's for dinner! On Sat, 21 Apr 2001, Jack Coates wrote: I don't think it's going to work, then. "On the fly" reconfiguration would mean downing the interface everytime a new machine joined the wireless LAN, which would get really annoying to the users. But if you treat the LAN like the Internet (0.0.0.0/0) then you can't route to it. Actually, that could work, I think, with proxy arp. wireless int - 192.168.254.254, bridging enabled def route forwards all traffic to eth1 masquerade as 192.168.1.1 eth1 - 192.168.1.254 another LRP is the Internet gateway. Double-NATing is goofy as hell and will probably break something. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
ext2fs would be handy, but it makes things harder on the Windows users. I think vfat is the best thing to do. I use vfat in my kernel -- it's 15K in 2.2, 16K in 2.4. UPX would turn that into .003 bytes, right :-) -- Jack Coates Monkeynoodle: It's what's for dinner! On Sat, 21 Apr 2001, Mike Noyes wrote: [EMAIL PROTECTED], 2001-04-20 18:03 -0700 On Fri, 20 Apr 2001, Mike Noyes wrote: This still doesn't explain why Debian is trying to do the following for their boot floppies. http://lists.debian.org/debian-boot-0102/msg00435.html ~ Build in crams and ramfs. We're going to boot off of a cramfs initrd ~ and then set up and pivot_root into a ramfs filesystem. I;m not really familiar with the details, but I think the cramfs initrd is both disk- and ram-efficient, and pivoting the root means switching the root over to a writeable filesystem while maintaining access to the old filesystem. For a boot floppy there is no customization, but it is convenient to have a writeable root. Jeff, You have a better grasp of the details than I do. :) If I have this right, cramfs isn't flexible enough for our needs. That means that Midori isn't useful for a base, and we're back to vfat or minix for long file name support. The MontaVista rep. seemed to think ext2 wasn't out of the question for our needs. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
It'd be interesting to see how much each option affected size, but overall a 411K 2.4 kernel is VERY COOL, and should be quite usable for floppy firewalls. While I'd like to see a 'one size fits all' kernel, perhaps there could be a floppy only, minimal kernel, and a larger kernel with all the 'goodies' like RAID, loopback, etc (compiled as modules, where possible) for folks running from CD, HDD, Flash, or what have you. Right. There's none of the MTD stuff compiled into this kernel, and I even went modular on the IDE support. The bitch of it all is that, for some of the ideas I've had, IDE support is Sorta-Kinda-Necessary. I think I'll play around a bit over the next few days and see what I come up with. Well, I generall think almost EVERYTHING should be modules. You can regain IDE support for booting by adding the modules to the initial ramdisk (the linuxrc mods I posted a while ago for my SCSI-RAID support do this). I'm envisioning a single kernel (or perhaps 2, if we don't want the module hooks for RAID, IPSec, and various other higher-end functions taking up space on a single floppy firewall), along with a small number of pre-rolled initial ram-disks (floppy-only, IDE HDD, IDE HDD+CD-ROM, Flash/DOC support, etc). Anyone wanting a really funky or custom boot system can roll their own initrd (or make a custom root.lrp if we stick with the initrd-archive patch use a tar.gz file). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
Charles Steinkuehler wrote: Well, I generall think almost EVERYTHING should be modules. You can regain IDE support for booting by adding the modules to the initial ramdisk (the linuxrc mods I posted a while ago for my SCSI-RAID support do this). When I first compiled kernels for LRP, I used the EigerStein kernel as my base. I later found that by NOT compiling modules, I could save space let me explain. If there is an item in the kernel configuration which is undesired, but generates only modules: it still takes up space even though all of the underlying items are modules. By removing the support altogether, a great deal of space can be regained. QoS comes to mind, and Linux Telephony. If you leave in QoS support, even though everything is modules, it still takes up space. If you disable QoS support, you gain a lot of space. You can always shift kernels around and make multiple configurations. Anyway, the best thing for a router would be to create your own kernel and remove kernel module support altogether - no more attacks from things like knark.o ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
On Sat, 21 Apr 2001, Mike Noyes wrote: [EMAIL PROTECTED], 2001-04-20 18:03 -0700 On Fri, 20 Apr 2001, Mike Noyes wrote: This still doesn't explain why Debian is trying to do the following for their boot floppies. http://lists.debian.org/debian-boot-0102/msg00435.html ~ Build in crams and ramfs. We're going to boot off of a cramfs initrd ~ and then set up and pivot_root into a ramfs filesystem. I;m not really familiar with the details, but I think the cramfs initrd is both disk- and ram-efficient, and pivoting the root means switching the root over to a writeable filesystem while maintaining access to the old filesystem. For a boot floppy there is no customization, but it is convenient to have a writeable root. Jeff, You have a better grasp of the details than I do. :) If I have this right, cramfs isn't flexible enough for our needs. That means that Midori isn't useful for a base, and we're back to vfat or minix for long file name support. The MontaVista rep. seemed to think ext2 wasn't out of the question for our needs. Now I am confused. In what way do you regard vfat as an alternative to minix or cramfs? I haven't been following the idea of using Midori as a base. One of the fundamental architectural characteristics of LRP is the separation of data into a ram fs and a storage (backup) fs. This has different advantages and drawbacks than a run-from-storage architecture. One of these is the ability to construct a custom LRP even if you only have a Windows box to work with. However, the run-from-storage approach has strong points, too. If you put LRP into a hard disk or flash disk, you may be using RAM rather less effectively than you might prefer. The Debian boot concept might be adapted to make some kind of hybrid, but cramfs is probably not going to replace fat/vfat. A combination of cramfs in "root.lrp", ramfs as the pivoted root with lots of symlinks into the cramfs, and packfs to move packages from disks to ramfs and then into cramfs, could combine to replace the existing minix ramdisk. I wonder though, whether the temporary ram usage wouldn't exceed the plain-jane system in use now. That is, would the extra complexity pay off? I don't know if any of this was what you were thinking about. I have tended to regard systems like Midori like machine shop, and LRP as a kind of Lego experience. There is a place for each, and there may be things one can learn from the other, but they _are_ different. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Work:[EMAIL PROTECTED] Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems
[EMAIL PROTECTED], 2001-04-21 12:51 -0700 On Sat, 21 Apr 2001, Mike Noyes wrote: You have a better grasp of the details than I do. :) If I have this right, cramfs isn't flexible enough for our needs. That means that Midori isn't useful for a base, and we're back to vfat or minix for long file name support. The MontaVista rep. seemed to think ext2 wasn't out of the question for our needs. Now I am confused. In what way do you regard vfat as an alternative to minix or cramfs? Jeff, I was looking for a solution to the 8.3 FAT file names on the floppy. Am I completely off base with cramfs? I haven't been following the idea of using Midori as a base. I think I'm the only one that's mentioned it as a possibility, so you didn't miss anything. One of the fundamental architectural characteristics of LRP is the separation of data into a ram fs and a storage (backup) fs. I thought cramfs, ramfs, and packramfs combination did that too. From this conversation I gather I'm wrong. This has different advantages and drawbacks than a run-from-storage architecture. One of these is the ability to construct a custom LRP even if you only have a Windows box to work with. However, the run-from-storage approach has strong points, too. If you put LRP into a hard disk or flash disk, you may be using RAM rather less effectively than you might prefer. I thought cramfs was a bootstrap file system for ramfs. cramfs = .lrp + fat ramfs = ramdisk packramfs = lrcfg - backup I obviously don't understand the capabilities of these file systems. :( -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] New list (leaf-cvs-commits)
Everyone, I created a new list that receives our CVS commit messages. I hope this will allow everyone to keep track of release development. I installed syncmail by following the SourceForge instructions below. If you have time, please test it by committing a change to our repository. Thanks. Getting email from CVS https://sourceforge.net/docman/display_doc.php?docid=772group_id=1 LEAF Mailing Lists https://sourceforge.net/mail/?group_id=13751 Also, all new tracker items are now posting to the leaf-devel list. If this traffic becomes to great I'll create a tracker list for it. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
I just hunted through my module archives and I've never built it as a module... I also did a google search, but the only ones I turned up in reasonable timeframe were compiled for NetBSD. Those are 51K (!). -- Jack Coates Monkeynoodle: It's what's for dinner! On Sat, 21 Apr 2001, Mike Noyes wrote: Jack Coates, 2001-04-21 08:31 -0700 ext2fs would be handy, but it makes things harder on the Windows users. I think vfat is the best thing to do. I use vfat in my kernel -- it's 15K in 2.2, 16K in 2.4. UPX would turn that into .003 bytes, right :-) Jack, It may make things a tad harder, but I believe winimage supports ext2. Do you know how much room ext2 takes? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
Jack Coates, 2001-04-21 16:08 -0700 I just hunted through my module archives and I've never built it as a module... I also did a google search, but the only ones I turned up in reasonable timeframe were compiled for NetBSD. Those are 51K (!). Jack, That's huge. How big is minix? We can subtract the minix size from the ext2 total. Is that correct, or am I out in left field still? fat + minix = ? fat + vfat + minix = ? ext2 = 51K On Sat, 21 Apr 2001, Mike Noyes wrote: Jack Coates, 2001-04-21 08:31 -0700 ext2fs would be handy, but it makes things harder on the Windows users. I think vfat is the best thing to do. I use vfat in my kernel -- it's 15K in 2.2, 16K in 2.4. UPX would turn that into .003 bytes, right :-) Jack, It may make things a tad harder, but I believe winimage supports ext2. Do you know how much room ext2 takes? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
On Sat, 21 Apr 2001, Mike Noyes wrote: Jack Coates, 2001-04-21 16:08 -0700 I just hunted through my module archives and I've never built it as a module... I also did a google search, but the only ones I turned up in reasonable timeframe were compiled for NetBSD. Those are 51K (!). Jack, That's huge. How big is minix? We can subtract the minix size from the ext2 total. Is that correct, or am I out in left field still? Not sure what you mean. If you mean from kernel size for the total size change, then yes. fat + minix = ? fat + vfat + minix = ? ext2 = 51K In 2.4.3 we have: -rw-r--r-- 1 wolfstar root46474 Apr 11 03:05 ext2.o -rw-r--r-- 1 wolfstar root15915 Apr 11 03:05 vfat.o In 2.2.18, we have: -rw-r--r-- 1 wolfstar root54013 Dec 16 02:55 ext2.o -rw-r--r-- 1 wolfstar root15458 Dec 16 02:55 vfat.o Of necessity, I compile DOS FAT and Minix into the kernel so as to avoid any messy situations. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare? -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
On Sat, 21 Apr 2001, David Douthitt wrote: When I first compiled kernels for LRP, I used the EigerStein kernel as my base. I later found that by NOT compiling modules, I could save space let me explain. Okay. Not that I can stop you in an e-mail. =) If there is an item in the kernel configuration which is undesired, but generates only modules: it still takes up space even though all of the underlying items are modules. By removing the support altogether, a great deal of space can be regained. QoS comes to mind, and Linux Telephony. And a few dozen other things as well. If you leave in QoS support, even though everything is modules, it still takes up space. If you disable QoS support, you gain a lot of space. You can always shift kernels around and make multiple configurations. And suddenly, the lightbulb comes on, and he knows where that other 30-50k of freed space came from. I didn't bother to compile QoS support. At all. That would explain why the kernel is so small now... must tweak more stuff. Anyway, the best thing for a router would be to create your own kernel and remove kernel module support altogether - no more attacks from things like knark.o That's a wee bit hard in an easy-to-use distributable floppy-based system that has no way to compile stuff, but I take your meaning. =) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare? -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
On Sat, 21 Apr 2001, Charles Steinkuehler wrote: Well, I generall think almost EVERYTHING should be modules. You can regain IDE support for booting by adding the modules to the initial ramdisk (the linuxrc mods I posted a while ago for my SCSI-RAID support do this). Yeah, Oxygen does the same, and I was planning on incorporating that into anything that I cranked out to begin with. I'm envisioning a single kernel (or perhaps 2, if we don't want the module hooks for RAID, IPSec, and various other higher-end functions taking up space on a single floppy firewall), along with a small number of pre-rolled initial ram-disks (floppy-only, IDE HDD, IDE HDD+CD-ROM, Flash/DOC support, etc). Anyone wanting a really funky or custom boot system can roll their own initrd (or make a custom root.lrp if we stick with the initrd-archive patch use a tar.gz file). Now this will take some pondering. Time to do some good old-fashioned market classification here. We have two base-level types of people using LRP: 1. People who want to have a firewall/router that will let them share IP addresses and don't want to spend the money on a commercially available one. 2. People who want to tinker, and as such have a fair bit of knowledge. I know this is severe overgeneralization, but bear with me. Anyone who would be using this for a commercial project, or would be setting it up as a server, is someone who wants to tinker with it. This ranges from the sysadmin that gets the 'net connectivity project for the company tossed at them because, hey, he's the tech guy right?, all the way up to those of us on this list that're crazy enough to do the devel work. The former will want something he or she knows, and the latter is already doing stuff with us. So, if we've got two targets, with two differing styles and needs, why not make two kernels as you suggest? The first one is the bare router kernel. It'll do firewalling, NAT, perhaps DMZ stuff, and be pretty much as we know LRP or EigerStein today. The second will be much more powerful, with all the goodies that any geek could want, everything from ext2 support on up through the PCMCIA devices and Disk-On-Chip stuff. (Ham Radio, anyone?) The problem then becomes where we draw the line between the two. For example, more and more people are getting USB DSL Modems foisted off on them, and so the USB stuff becomes necessary for the basic kernel, even though it's still somewhat on the bleeding edge. Advanced stuff like WAN Router, QoS, and packet radio can be reserved for the beefier kernel. IPSec/PPTP/VPN stuff should go for Basic, because a lot of people want an IPSec kernel to connect to their office LANs from home. The reason why I say that we can go with the more complex stuff for advanced users is, simply, these are the folks that are gonna be willing to give it a go with the CD-ROMs, CompactFlash, or even hard drives. The space will be available to them in general, one way or another. Any thoughts or ideas? I'm thinking that trimming the fat off of this stuff, combined with UPX, might be enough for us to go glibc 2.1.x or even 2.2.x for base router images. At least then, it would be easier to transition from the basics to the fun stuff. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare? -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
George Metz, 2001-04-21 21:34 -0400 On Sat, 21 Apr 2001, Mike Noyes wrote: That's huge. How big is minix? We can subtract the minix size from the ext2 total. Is that correct, or am I out in left field still? Not sure what you mean. If you mean from kernel size for the total size change, then yes. George, Yes. fat + minix = ? fat + vfat + minix = ? ext2 = 51K In 2.4.3 we have: -rw-r--r-- 1 wolfstar root46474 Apr 11 03:05 ext2.o -rw-r--r-- 1 wolfstar root15915 Apr 11 03:05 vfat.o In 2.2.18, we have: -rw-r--r-- 1 wolfstar root54013 Dec 16 02:55 ext2.o -rw-r--r-- 1 wolfstar root15458 Dec 16 02:55 vfat.o Of necessity, I compile DOS FAT and Minix into the kernel so as to avoid any messy situations. So if FAT+Minix support is approximately 30K, there is no difference in size. What potential problems are caused by using ext2 on floppies/ramdisks? Do vfat formatted floppies have a greater amount of writable area than ext2 formatted ones? Does Linux handle ext2 ramdisks more efficiently than minix ones? George, Jeff, Jack, Thanks for taking the time to educate me. :) -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
On Sat, 21 Apr 2001, George Metz wrote: On Sat, 21 Apr 2001, Mike Noyes wrote: Jack Coates, 2001-04-21 16:08 -0700 I just hunted through my module archives and I've never built it as a module... I also did a google search, but the only ones I turned up in reasonable timeframe were compiled for NetBSD. Those are 51K (!). Jack, That's huge. How big is minix? We can subtract the minix size from the ext2 total. Is that correct, or am I out in left field still? Not sure what you mean. If you mean from kernel size for the total size change, then yes. [...] Of necessity, I compile DOS FAT and Minix into the kernel so as to avoid any messy situations. I think the concept is to raise the bar by putting vfat into the kernel. If vfat doesn't depend on the msdos code, then omit msdos to reduce size and risk of manipulating vfat filenames as msdos filenames (which can strand LFN data in the FAT). --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Work:[EMAIL PROTECTED] Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] File Systems (was: CVS structure)
On Sat, 21 Apr 2001 [EMAIL PROTECTED] wrote: I think the concept is to raise the bar by putting vfat into the kernel. If vfat doesn't depend on the msdos code, then omit msdos to reduce size and risk of manipulating vfat filenames as msdos filenames (which can strand LFN data in the FAT). What about practically? For all technical purposes, we're using VFAT already - at least, *I* don't know anyone still using MS-DOS and Win3.x - so we might as well use the VFAT stuff instead of MSDOS and skip the 8.3 format. Technically we're using the wrong thing anyways. =) Also, no, vfat.o doesn't depend on msdos.o in any way; there's FAT hooks in the kernel that both of them rely on instead. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare? -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
