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
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
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
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
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
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
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
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
[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
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
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
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
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
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
[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
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.
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
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
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,
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
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
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
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
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).
24 matches
Mail list logo
