[leaf-user] hardware requirements bering router 100 mbit+
hello I have been using bering for adsl /wireless routing a long time, and it's as stable as a rock. But i am now going to setup a DMZ for services. this will be on a 100 mbit switched network and it might become a 1000 mbit switched network in a year or so. what i am wondering is. what kind of hardware will i need to saturate a 100 mbit switched network. using bering, 2 nics and no vpn or masquerading this is pure routing. btw: can bering support ospf protocol ? mvh Ronny Aasen --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Changes in WISP-Dist
Ok. I tested wavemon with lucent. Maybe it doesn't work with newer hostap drivers. I'll check the MAC filter again. Please tell me the build number you're using. Jim TerWee wrote about Re: [leaf-user] Changes in WISP-Dist: Sure does The message you get is iwconfig netcs0 mode Master [: customer2: unexpected operator iwpriv netcs0 maccmd 1 What I did in this case was just uncomment the two examples you had in the ethers file Also on the wavemon I see the following error netcs0 (WE) : Buffer for request 8B0B too small (0436) fatal error: could not get range information Jim TerWee Does the same thing happen with the latest image? Jim TerWee wrote about Re: [leaf-user] Changes in WISP-Dist: Setting up multiple mac addresses under the MAC Filter doesn't work. Has been this way for quite a while now just never got around to mentioning it before. If you just set one mac address it's fine if you change to use multiple mac's it will error out when the macs load Jim -- Best Regards, Vladimir Systems Engineer (RHCE) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html -- Jim TerWee | Our capacity for understanding is [EMAIL PROTECTED] | inversely proportional to how Invisimax| much we think we know. The more I | know, the more I don't know! -- Best Regards, Vladimir Systems Engineer (RHCE) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] shorewall masquerading packets behind ipsec tunnel
Lynn thanks for the reply I finally got it running, it happened to be an error in the masq file. I masqued to ipsec0 instead of eth0. Tom has done a great job to document shorewall, now either I am not attentive enough to translate all this into a sensible configuration and thus stumble on all those gotchas or it really is still somewhat complex. My set up is probably not what you would call standard but with wireless being more and more frequent configurations like mine may pop up from time to time, so it might be interesting for others to have an example. I might try to document this. Erich At 20:11 16.02.2003 -0600, you wrote: On Sunday 16 February 2003 04:47 pm, Erich Titl wrote: OK, ipsec0 is listening on eth1 (valleygate), correct? After ipsec0 receives and un-encrypts the packets, the true ip information is also unwrapped and interpreted as the actual 192.168.20.0 address that the package was sent from. If this did not hold true, your mountaingate LAN client could never receive a reponse from the valleygate subnet. I imagine that treating the mountaingate subnet as a local network on valleygate via ipsec0 in Shorewall will likely solve your problem. This would also allow the wireless link to remain encrypted. THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bearing 1.1 winimage problems UPDATE
You can always boot the image, goto /lib/modules, delete unneeded ethernet card drivers and backup 'modules'. Then check your space ;) Carefull when you backup initrd if you added the ide-modules! -Original Message- From: Adrian Wooster [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 7:13 PM To: [EMAIL PROTECTED] Subject: [leaf-user] Bearing 1.1 winimage problems UPDATE First of all - I want to support all the other comments on 1.1 release. I'm a huge fan and have a growing base of customers who love it. So on that basis I'm hopefully this is not a trivial finger issues on my part. My head is getting scrambled at this point, but I can't see that I'm doing anything wrong. Excited that 1.1 became available that same day that I needed to build new Baring system from scratch I quickly downloaded the winimage and started to successfully create disks. All went well until I tried to back-up the packages I'd altered. On every occasion it claimed the disks had got sector problems on just about every sector. Just to check, I've retried this operation several times with no problems with 1.0 on the same machine using the same batch of blank disks, but can replicate the problem every time with the 1.1 image. I've even redownloaded the image from multiple mirrors. I'm trying to load CD ROM support to load additional lrps from bigger medium. At this stage, all I'm doing is: $ mount -t msdos /dev/fd0 /mnt $ cp /mnt/*.o /boot/lib/modules/. $ umount /mnt $ lrcfg Option 3.2 to edit initrd modules file Nothing new is run at this stage, just simple used everyday commands. Returning to the backup package screen and attempting to back-up anything screws the floppy with sector errors everywhere. Help please. Adrian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
AW: [leaf-user] Update: Short term LEAF project goals
GUI Pre-rollout Config == We are thinking it'd be cool, if you wanted to, to download a fat CD of everything LEAF on it, burn the thing, and use it to build yourself a custom LEAF floppy. You'd do this before you rollout that floppy to the LEAF box. You could save your changes. You could upgrade to a new LEAF version seamlessly. We could make the pre-config program a Java GUI, a Python GUI, or a Web/Cgi thing. This is very dependant on new packages and a new central-db. This is a good place to advertise my work: I have written a bunch of scripts I use for pre-configuring Bering firewalls. They are useful for separating hardware dependent and configuration dependent stuff from the standard packages. I also find it much simpler to upgrade kernels or packages, because of that separation. The scripts provide no GUI but I think they could be useful for generating packages with the configuration created in the GUI. Regards Alex --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: AW: [leaf-user] Update: Short term LEAF project goals
Alex Rhomberg [EMAIL PROTECTED] writes: This is a good place to advertise my work: I have written a bunch of scripts Could you add a link please? Regards, Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] hardware requirements bering router 100 mbit+
Ronny Aasen wrote: what kind of hardware will i need to saturate a 100 mbit switched network. using bering, 2 nics and no vpn or masquerading this is pure routing. A decent pentium class system should be capable of saturating a couple 100 MBit links. You will need to use server class PCI NIC's (like the DEC based cards using the tulip driver, or the 3COM 3C905...I've heard good things about the Intel based cards as well, but haven't tried them personally). You'll also want a good PCI chipset (hard to quantify without getting into lots of low-level hardware details). As a general rule of thumb, processing a packet takes a fairly fixed amount of CPU, so if your saturated 100 Mbits of traffic is lots of small packets, you'll need more CPU than if the traffic is mainly large packets for bulk transfers. I think anything over a P133/166 should work fine, and something like a P-2 or P-3 system with a BX chipset (or better...anything with a 100 MHz FSB) would give you quite a bit of headroom. -- Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
You asked for comments: I long ago created my own database, wherein XT_DEVICE=eth0 XT_IF= 204.001.001.001 XT_MASK=24 IT_DEVICE=wlan0 ROUTERTYPE=tunnel IT_DHCPS=yes A1_DEVICE=eth1 SPOOFING=no etc,etc. (about 80 variables) And a single python function which can be called from a command line as in: /var/www/cgi-bin/xlfixconf.pyXT_GW=204.001.001.254 or from another python program. This is simple. If you import the above, it is all valid bash and variables can be used in all the networking and firewall scripts. It takes a little extra code to build something like ipsec.conf or dhcpd.conf. Anyway, the point is its simple to look at and simple to edit and Python or Perl builds a hash table in milliseconds. Any sort of real database technology would be a burdensome complication. Now. Given an organization like above, with creative use of underlines to create a hierarchy, It would be quite simple to write a 2 way parser bash-variables -- XML. I should also mention, there is a subject which rarely mentioned on LEAF, Group Permits. This is where you use netfilter to allow access to subnets and servers and services by groups of ip's and maybe domains. This deserves some db kind of thinking. I've kind of brute forced this stuff so far and haven't designed a decent database yet. But it is worth thinking about in any design. I think Cisco calls thisAccess Lists. Oh, can't speak for Perl, but after 1.5, Python gets BIG. 1.5 is fine for my purposes. Anyway, size matters. Matt Schalit [EMAIL PROTECTED] on 02/17/2003 12:39:36 PM To: [EMAIL PROTECTED] cc:(bcc: Phillip Watts/austin/Nlynx) Subject: [leaf-user] Update: Short term LEAF project goals This is an unofficial message to let folks know what the short term goals are for the LEAF project, the hot topics being developed, just in case you're not monitoring the leaf-devel list. I wasn't asked to write this, but I figured it'd might help a bit. Please toss in your comments if you'd like. More communication is welcome. LEAF is a loose collection of kind people who share a common interest in embedded Linux. There's no top-down organization here, per se, but rather the following ideas are what people are most excited about and working on. They are listed in an order that likely denotes their place in our unoffical roadmap. The point here being that it'd be tough to build a GUI admin system when you know there's a new package system coming out shortly: 1) Central configuration database 2) Central package repository 3) New package system 4) GUI preconfig 5) GUI admin Central Configuartion Database This is a way of storing the variables and values that make your LEAF box unique, like your IP addresses, in one single location and making a new command, perhaps leaf-cdb, that is used to access the db. Values like IP, netmask,and hostname that are common across packages will be listed once. No more entering the same data 5 times across 5 packages! The current idea is to use a stucture similar to the linux /proc set of subdirectories. Another idea is to burp that structure out of an xml database, perhaps stored remotely. Simplicity is a main goal of this project, a goal that contrasts with XML to some extent, but XML may be essential for GUI admin. Central Package Repository === No more looking all over our website for packages. All of them will now be stored in a single repository. Probably still fat16 with 8.3 filenames. Not sure. New Package System == A new package system would use the new central-db to get it's values from. We are interested in making the packages a LOT smarter and making it possible to load them from remote locations. A smart package contains a manifest of all it's variables and all possible values, offering that information to and incorporating those into the central-db. The run-time files that each package uses, the ones we customize nowadays like /etc/dnscache/env/IP, will be generated at boot time in the future, similarly to the way the /etc/rc?.d directories are generated on the fly now. This packaging system will require each package to provide a template of it's dynamic files. Templates are like mad-libs. You get the values out of the db, and once you fill them in, it's funny. GUI Pre-rollout Config == We are thinking it'd be cool, if you wanted to, to download a fat CD of everything LEAF on it, burn the thing, and use it to build yourself a custom LEAF floppy. You'd do this before you rollout that floppy to the LEAF box. You could save your changes. You could upgrade to a new LEAF version seamlessly. We could make the pre-config program a Java GUI, a Python GUI, or a Web/Cgi thing.
[leaf-user] Re: Bering vs. Bering-Uclib
Hey! Yahoo and an increasing number of other sites are using a fsck'ed form of load-balancing that depends on your machine (firewall anyway) answering tons of requests from placed DNS servers around the world. The LEAF variants don't readily conform to making all these replies, so there are issues with this type of load-balancing working if the webpage does NOT specify a default or fall-back procedure does not work as expected. If this is your problem, you should see a ton of DNS requests in your logs denied at the firewall OR a ton of connect connections via DNS ports on the firewall (that sometimes chokes out a connection). In any case, this behaviour is non-rfc compliant and not readily fixable until it can be changed to behave in a rfc-compliant way. I can say that it may or may not work depending on the particular code of the html page that is processed. If you can link a 'failed page', I can tell you whether or not this is the problem. Two sites that work great when I connect directly to the dsl modem (using pppoe on a Debian Testing system) but are unusable when I go through LEAF are epicurious.com and winespectator.com. Yahoo.com too, as discussed. They're not blocked, just incredibly -- 10 minutes per page -- slow. Also, it helps to click on the links multiple times, as if most outgoing packets resulting from those clicks were being dropped. I'm not seeing any denied packets in the shorewall logs when running Bering. I don't have shorewall on the laptop. There are no ports open other than to 192.168.1.* (as per /etc/hosts.allow). Two other pieces of information. 1) Bering and Bering-uClib behave the same. I was wrong before about only the uClib version having the problem. I've had some perceived performance problems with Bering-uClib at one location but it was nothing like what I'm seeing now with stock Bering 1.0. 2) Bering does NOT have this problem when used on at ATT cable connection. Yahoo and the rest are fine. So it's somehow related to pppoe or maybe to PacBell/SBC. I've seen this with Mozilla and lynx and links. Have not yet checked whether it happens if the host is not running Linux, but can't see how that'd make a difference. Thanks, --Eric -- ** * From the desktop of: Eric House, [EMAIL PROTECTED]* *Crosswords 4.0 for PalmOS is out!: http://www.peak.org/~fixin/xwords * ** --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] hardware requirements bering router 100 mbit+
On Tue, 2003-02-18 at 15:07, Charles Steinkuehler wrote: Ronny Aasen wrote: what kind of hardware will i need to saturate a 100 mbit switched network. using bering, 2 nics and no vpn or masquerading this is pure routing. A decent pentium class system should be capable of saturating a couple 100 MBit links. You will need to use server class PCI NIC's (like the DEC based cards using the tulip driver, or the 3COM 3C905...I've heard good things about the Intel based cards as well, but haven't tried them personally). You'll also want a good PCI chipset (hard to quantify without getting into lots of low-level hardware details). As a general rule of thumb, processing a packet takes a fairly fixed amount of CPU, so if your saturated 100 Mbits of traffic is lots of small packets, you'll need more CPU than if the traffic is mainly large packets for bulk transfers. I think anything over a P133/166 should work fine, and something like a P-2 or P-3 system with a BX chipset (or better...anything with a 100 MHz FSB) would give you quite a bit of headroom. In other word i can't buy such prosessors anymore... I'v been using VIA's C3 a lot lately, since it don't need a cpu cooler, i guess i'll stick to that. and i have quite a lot of 3c905's around. Now i just need a fanless psu thx for the quick replies :) mvh Ronny Aasen Datapart AS --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Re: Bering vs. Bering-Uclib
Preliminary comment: I just connected to the two sites Eric mentions as problems, and I have none (I use Yahoo all the time, so that's OK here too). Although I don't run Bering, I do use SBC service (but not PPPoE). My test is from a NAT'd host running Windows 98 and Netscape 4.something. Specific comments below. At 08:05 AM 2/18/03 -0800, Eric House wrote: [...] Two sites that work great when I connect directly to the dsl modem (using pppoe on a Debian Testing system) but are unusable when I go through LEAF are epicurious.com and winespectator.com. Yahoo.com too, as discussed. They're not blocked, just incredibly -- 10 minutes per page -- slow. Also, it helps to click on the links multiple times, as if most outgoing packets resulting from those clicks were being dropped. I'm not seeing any denied packets in the shorewall logs when running Bering. If you check the actual rulesets (with shorewall status), do you see any rules that are DENYing or REJECTing a lot of packets without logging them? If you can tell ... *where* in the sequence is the loading slow? For example, does the URL *resolve* promptly but then take a long time to load? Does the main download proceed quickly but secondary downloads (e.g., images) slow things down? Is it someplace else? In the two situations you are comparing (Bering and Sarge), how are the systems doing DNS resolution? If (for example) the Sarge system uses the SBC resolvers directly but systems behind Bering access DNS through dnscache on the router, then try having them access the SBC resolvers directly to see if that helps. How do the two systems differ in their handling of auth (ident) queries? Sometimes having a firewall DENY or even REJECT such queries introduces delays (relative to either actually answering them or leaving the port unfirewalled but also not listening ... this was a big problem with SMTP and LRP a couple of years ago). How often does your PPPoE address change? Are you using the same workstation in both instances (I infer a laptop running Sarge from scattered parts of your report) ... one connected to a LAN NATd by Bering, the other connected directly to the DSL router? IF not, does doing so change anything? Oh, and not to quibble ... but is the 10 minutes per page a real, timed test, or just a falsely precise translation of incredibly ... slow? If the second, please do an actual timed test and tell us how long it takes to download some specific URL, for example, the home page of winespectator.com . (I ask this because some specific delay times, like just over 3 minutes, are magic numbers that suggest specific problem sources. But 10 minutes per page itself suggests nothing specific to me.) I don't have shorewall on the laptop. There are no ports open other than to 192.168.1.* (as per /etc/hosts.allow). I don't know what this means ... if the laptop is the Debian-Sarge system you mention above, it would need to be ACCEPTing traffic to its PPPoE address when run directly. So are you describing the settings of the Linux client when it is running behind the Bering firewall? Two other pieces of information. 1) Bering and Bering-uClib behave the same. I was wrong before about only the uClib version having the problem. I've had some perceived performance problems with Bering-uClib at one location but it was nothing like what I'm seeing now with stock Bering 1.0. 2) Bering does NOT have this problem when used on at ATT cable connection. Yahoo and the rest are fine. So it's somehow related to pppoe or maybe to PacBell/SBC. Or to differing DNS methods. How do they compare between SBC and ATT? I've seen this with Mozilla and lynx and links. Have not yet checked whether it happens if the host is not running Linux, but can't see how that'd make a difference. Me either. But I can't see why the other stuff you suggest as candidate causes would make a difference either. So I'd suggest you do this test. -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Re: Bering vs. Bering-Uclib
Eric House wrote: Two sites that work great when I connect directly to the dsl modem (using pppoe on a Debian Testing system) but are unusable when I go through LEAF are epicurious.com and winespectator.com. Yahoo.com too, as discussed. They're not blocked, just incredibly -- 10 minutes per page -- slow. Also, it helps to click on the links multiple times, as if most outgoing packets resulting from those clicks were being dropped. Have you set CLAMPMSS=Yes in /etc/shorewall/shorewall.conf? -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Re: Bering vs. Bering-Uclib
On Tue, Feb 18, 2003 at 09:16:16AM -0800, Tom Eastep wrote: Eric House wrote: Two sites that work great when I connect directly to the dsl modem (using pppoe on a Debian Testing system) but are unusable when I go through LEAF are epicurious.com and winespectator.com. Yahoo.com too, as discussed. They're not blocked, just incredibly -- 10 minutes per page -- slow. Also, it helps to click on the links multiple times, as if most outgoing packets resulting from those clicks were being dropped. Have you set CLAMPMSS=Yes in /etc/shorewall/shorewall.conf? No. I'll give it a try. Thanks! --Eric -- ** * From the desktop of: Eric House, [EMAIL PROTECTED]* *Crosswords 4.0 for PalmOS is out!: http://www.peak.org/~fixin/xwords * ** --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. Fwiw, dependancies are very much a fundamental part of the new package system. If you change, by hand or by script, your ip address for example, the built in dependancy checking triggers all packages that use the ip address to restart, in the correct order, and reread their configs. I just finished seeing monowall and the screenshots are great. It is just what I had in mind and Eric Wolzak has asked for ideas too. The monowall interface encapsulates most requirements. It may do good to invite Michael - the monowall author to participate here. Link to a screenshot? Apart from what has been listed below, the GUI must have a webmin like definition to allow authors to write new package screens easily and confirm to a standard. If this is done, then changing themes will change the look and feel across all packages. Thanks for the comments. One idea was that the package author completely describes all the variables and possible choices, then the new package screen is generated dynamically. Given a program written in Java or Python, which may be preferable because they can access drives and do other secure transactions much easier than a web script ever could, everyone would need to learn those if they wanted to code their own custom new package screens. Because that's not gonna happen, the idea for dynamic config pages seems more appealing. If the package author wants more latitude in design, a highly laudable goal, then I'm not adverse to adding whatever functionality is within reason. The joy here is that I can to tremendously powerful things with Java, in no time and very easily, simply because it is mature. We also need to look at SSL support if web based administration is contemplated. Mohan Java has ssh support built in. The LEAF system requirements are: sshd.lrp. That presents a space issue for any single floppy rollout, our classic format. cheers, matthew --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. pppoatm? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Tue, 18 Feb 2003, Matt Schalit wrote: S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. ppp.lrp. The problem with incorporating module dependencies into packages is that modules are supposed to present a standard application programming interface that decouples the application from the hardware. PPP can in fact be run over ethernet, or over standard serial ports, or over special multi-port serial interfaces. Even if you put something in the packaging system that can recognize the absence of a minimum functionality (some type of point to point communication channel), you will still have confusion where the application calls for multiple channel types used in different ways (PPPoE into a serial control channel for an embedded device, for example). I think that in most cases coupling the base user-level package with an application-specific set of kernel modules makes more sense than integrating the two. If you really want idiot-level integration, then fall back on application-specific floppy image-style delivery. Bering's documentation is much more effective in the general case than trying to integrate into packages items that don't belong together in all cases. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
[EMAIL PROTECTED] wrote: You asked for comments: I long ago created my own database, wherein Thanks for posting your information about the db you created. In our discussions, we've called this a flat databse, meaning that the entire database is a single bash sourceable text file containing name=value pairs and comments. We discussed the costs and benefits of this format at some length, and I encourage you to join the thread on leaf-devel to contribute your thoughts, or maybe just read it and see if you concur with the people who've been researching this for a few months. A single flat file was my initial choice. XT_DEVICE=eth0 XT_IF= 204.001.001.001 XT_MASK=24 IT_DEVICE=wlan0 ROUTERTYPE=tunnel IT_DHCPS=yes A1_DEVICE=eth1 SPOOFING=no etc,etc. (about 80 variables) And a single python function which can be called from a command line as in: /var/www/cgi-bin/xlfixconf.pyXT_GW=204.001.001.254 or from another python program. This is simple. If you import the above, it is all valid bash and variables can be used in all the networking and firewall scripts. It takes a little extra code to build something like ipsec.conf or dhcpd.conf. Yes we think sourcing a file like yours is beneficial. Anyway, the point is its simple to look at and simple to edit and Python or Perl builds a hash table in milliseconds. Any sort of real database technology would be a burdensome complication. A real database would be burdensome, that's true, when you take a first look, and we've agreed to some extent that a complex xml database on the LEAF box is bogus for this very reason. David and Charles are voicing their wish for this whole thing to increase simplicity. But we have not ruled this out, because XML makes it possible to easily maintain a GUI admin. Perhaps you agree with the point I made before that having to modify your front-end gui and back-end api every time a new package comes out with different config is not preferrable to doing all that dynamically. Now. Given an organization like above, with creative use of underlines to create a hierarchy, It would be quite simple to write a 2 way parser bash-variables -- XML. We agree on this, and I offered it as my request. If we use XML, it should also generate a flat file of bash sourcable var=values. I should also mention, there is a subject which rarely mentioned on LEAF, Group Permits. This is where you use netfilter to allow access to subnets and servers and services by groups of ip's and maybe domains. This deserves some db kind of thinking. I've kind of brute forced this stuff so far and haven't designed a decent database yet. But it is worth thinking about in any design. I think Cisco calls thisAccess Lists. Is netfilter a part of shorewall or a seperate .lrp or just part of the main distro? Any command can be described in the database I think. The database is _not_ my specialty ;-) Oh, can't speak for Perl, but after 1.5, Python gets BIG. 1.5 is fine for my purposes. Anyway, size matters. I think you're running python.lrp is that correct? Would you paste in console based python hello world? curious, matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] SSH question
Thanks Tom. Setting my buddies sshd to listen on 0.0.0.0 did the trick. I never noticed that it was set to internal IP. John === Work: http://www.olgclotteries.com [EMAIL PROTECTED] 888-345-7568 ext. 2205 Personal: http://www.mullan.ca [EMAIL PROTECTED] MSN:[EMAIL PROTECTED] === Tom Eastep [EMAIL PROTECTED] To: John Mullan [EMAIL PROTECTED] Sent by: cc: [EMAIL PROTECTED] [EMAIL PROTECTED]Subject: Re: [leaf-user] SSH question ceforge.net 14-02-03 10:04 AM John Mullan wrote: Yes, they are intentional. I want to keep the FTP server on port 1021. If anyone comes in from outside without specifying port 1021, they will still get to my FTP server. That leaves me the future opportunity to have another FTP server on 21 but only accessible from internal. At least, that is the way I figure it. Your first rule actually insists that the CLIENT port be 1021 -- rather odd requirement. I will attempt the Telnet idea later. Work doesn't open very many ports. I don't even get port 80 access from this workstation :( Also be sure that your sshd is listening on 0.0.0.0 and/or on the exernal IP address of your firewall. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Re: Bering vs. Bering-Uclib
Have you set CLAMPMSS=Yes in /etc/shorewall/shorewall.conf? Ha, that did it! I caught someone at home and walked her through the change and how all's well. Thanks! --Eric -- ** * From the desktop of: Eric House, [EMAIL PROTECTED]* *Crosswords 4.0 for PalmOS is out!: http://www.peak.org/~fixin/xwords * ** --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] upgrading procedures
Hi I was wondering what was the best way to upgrade to each new Bering version. - Retyping the configurations files from the previous ones (in case there are major changes in the config files) - Backing up the previous config files and copy them back to the current version - upgrading the current configuration with each new LRP manually - other ways ? I'm running the Bering's distro and have a diskless configuration, with an isdn dialup on demand connection, and 2 eth. Thank you for your help. Fabrice --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] rtl8139.o and Bering 1.1
Hello List! I'm trying to build a Bering 1.1 disk and am wondering if there are any known issues with the rtl8139.o and the Bering 1.1 image? I have put it in the /lib/modules and made the appropriate mods to get it to load. During the boot process, I see something like this: Loading modules rtl8139 - using /lib/modules insmod: unresolved symbol pci_drv_unregister insmod: unresolved symbol pci_drv_register I'm using the rtl8139.o in the same machine with the Eiger2Beta image, and I don't see the unresolved symbol messages with that image. Does anyone have ideas? Are these messages even important? Or can they safely be ignored? Also, after the image laods, when I log into the box, an ip link shows only the 'lo interface .. no eth0 or eth1 that I can find. If anyone can point me in the right direction, I'd sure appreciate it. Thanks!! Chris Hackett --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Re: Driver for Itex 1483 linux kernel 2.4.18
Le Mardi 18 Février 2003 09:07, Humberto Kelkboom a écrit : A quick google search seems to suggest that the module developed for the 2.4.16 kernel should work with the 2.4.18 kernel. Give it a try ! http://leaf.sourceforge.net/devel/jnilo/bering/1.0-stable/drivers/speedtouch-pci/1483/ Jacques Hello, Do you know where I can find a module for the Itex1483 for the linux kernel 2.4.18 Regards, Humberto Kelkboom --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] rtl8139.o and Bering 1.1
Le Mardi 18 Février 2003 21:05, Chris Hackett a écrit : Hello List! I'm trying to build a Bering 1.1 disk and am wondering if there are any known issues with the rtl8139.o and the Bering 1.1 image? I have put it in the /lib/modules and made the appropriate mods to get it to load. During the boot process, I see something like this: Loading modules rtl8139 - using /lib/modules insmod: unresolved symbol pci_drv_unregister insmod: unresolved symbol pci_drv_register As shown in the 2.4.20 modules.dep file: http://leaf.sourceforge.net/devel/jnilo/bering/1.1/modules/2.4.20/modules.dep rtl8139.o depens on pci-scan.o which must be loaded first. Jacques --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] upgrading procedures
Le Mardi 18 Février 2003 19:04, Fabrice CHARLEUX a écrit : There is no safe upgrade procedure. The manual one - even if it appears a bit cumbersome - is probably the safest... Start from a fresh disk and re-define your configuration. In most cases it does not take long especially it you have taken note of your personal settings on a sheet of paper :-) désolé... Jacques Hi I was wondering what was the best way to upgrade to each new Bering version. - Retyping the configurations files from the previous ones (in case there are major changes in the config files) - Backing up the previous config files and copy them back to the current version - upgrading the current configuration with each new LRP manually - other ways ? I'm running the Bering's distro and have a diskless configuration, with an isdn dialup on demand connection, and 2 eth. Thank you for your help. Fabrice --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] FWD: upgrading to stable bearing release
-- Original Message -- From: Jim Van Eeckhoutte [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 11 Feb 2003 12:30:52 -0800 Hey guys ... been running Bearing Kernel:Linux version 2.4.18 (bering5@debian) (gcc version 2.95.2 and ... i know i know (not supposed tooo) installed to hard drive because of packages. What do i need to do to upgrade to the stable release of bearing? Also running Shorewall 1.2.8. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] rtl8139.o and Bering 1.1
I've been using 8139too.o which I believe requires mii.o for a long time. I forget the issues. Chris Hackett [EMAIL PROTECTED] on 02/18/2003 02:05:55 PM To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] cc:(bcc: Phillip Watts/austin/Nlynx) Subject: [leaf-user] rtl8139.o and Bering 1.1 Hello List! I'm trying to build a Bering 1.1 disk and am wondering if there are any known issues with the rtl8139.o and the Bering 1.1 image? I have put it in the /lib/modules and made the appropriate mods to get it to load. During the boot process, I see something like this: Loading modules rtl8139 - using /lib/modules insmod: unresolved symbol pci_drv_unregister insmod: unresolved symbol pci_drv_register I'm using the rtl8139.o in the same machine with the Eiger2Beta image, and I don't see the unresolved symbol messages with that image. Does anyone have ideas? Are these messages even important? Or can they safely be ignored? Also, after the image laods, when I log into the box, an ip link shows only the 'lo interface .. no eth0 or eth1 that I can find. If anyone can point me in the right direction, I'd sure appreciate it. Thanks!! Chris Hackett --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] My Dachstein not quite up and running
Just got back to work today after a long weekend and ready to try tackling this prob again... First off, was it okay for me to remove the $ from: INTERN_SERVERS=tcp_$192.168.1.2_smtp_10.10.10.200_smtp or should I put it back in? MX records are the DNS entries that tell remote systems how to contact your mail server (as opposed to A records, which match system names to IP addresses). If you don't have an MX record tying your domain name to the IP of your mail server, you won't get mail from the internet at large. Note that this doesn't mean you won't get mail...your MX records could point somewhere else (like your ISP or the registrar for your domain name), and that system could forward mail to you. Do I need to update them with the following setup: Actual mail server address: 208.57.96.252, controlled by the ISP, forwards mail from their server to ours through their router to 192.168.1.2 (what used to be our Exchange server, but is now eth 0 on the firewall)? Since the firewall is set to forward traffic received at port 25 of 192.168.1.2 through to 10.10.10.200 (new ip of our Exchange server) wouldn't it work without having to change the MX records with our ISP? Assuming of course that portforwarding is actually setup and working correctly. Output from netstat -nr: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 eth0 Output from ipchains -nvL: Chain input (policy DENY: 0 packets, 0 bytes): pkts bytes target prot opttosa tosx ifname mark outsize sourcedestination ports 0 0 DENY udp -- 0xFF 0x00 eth0 192.168.1.1 0.0.0.0/0 * - 520 0 0 DENY udp -- 0xFF 0x00 eth0 0.0.0.0 0.0.0.0/0 * - 68 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/00.0.0.0/0 5 - * 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/00.0.0.0/0 13 - * 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/00.0.0.0/0 14 - * 0 0 DENY all l- 0xFF 0x00 eth0 0.0.0.0 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 255.255.255.255 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 127.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 224.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all -- 0xFF 0x00 eth0 10.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 172.16.0.0/120.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 0.0.0.0/80.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 128.0.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 191.255.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 192.0.0.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 223.255.255.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 240.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 10.10.10.0/240.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 eth0 192.168.1.2 0.0.0.0/0 n/a 0 0 REJECT all l- 0xFF 0x00 eth0 0.0.0.0/0127.0.0.0/8 n/a 0 0 REJECT all l- 0xFF 0x00 eth0 0.0.0.0/010.10.10.0/24 n/a 0 0 REJECT tcp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 137 0 0 REJECT tcp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 135 0 0 REJECT udp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 137 0 0 REJECT udp -- 0xFF 0x00 eth0 0.0.0.0/00.0.0.0/0 * - 135 0 0 REJECT tcp --
[leaf-user] Ann: LEAF Bering-uClibc 1.1 and LEAF Bering-uClibc 1.0.3
LEAF Bering-uClibc 1.1 is ready for download at: http://sourceforge.net/project/showfiles.php?group_id=13751 This release is an upgrade for LEAF Bering-uClibc 1.0.x, in sync with Bering-1.1 and partly based on the wonderful work of the original Bering crew. Some of the new features: - Kernel 2.4.20 - updates of various packages (shorewall, tinylogin, ipsec,...) - cleanup of etc.lrp - usual bugfixes For details, you may read the changelog: http://leaf.sourceforge.net/mod.php?mod=userpagemenu=91003page_id=39 A bootable ISO-image with all packages currently available for the Bering-uClibc environment can be downloaded from the cvs repository: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/bering-uclibc/cd/Bering-uClibc-1.1.iso This image is bootable via a floppy bootdisk image and not with isolinux - allowing it to boot on older PC's with a defect BIOS, but please note, some may still not work as noted by HP Anvin. For more information about syslinux/isolinux browse to: http://syslinux.zytor.com In addition LEAF Bering-uClibc 1.0.3 is available at: http://sourceforge.net/project/showfiles.php?group_id=13751 This is a maintenance release for Bering-uClibc 1.0 series. The only change to from 1.0.2 to 1.0.3 is a bugfix for ash compiled against uClibc, which solves a few problems with weblet.lrp. Every help improving Bering-uClibc and getting it ready for download, has been appreciated. Thanks for your attention. on behalf of Bering-uClibc team kp --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] My Dachstein not quite up and running
Chris Low wrote: Just got back to work today after a long weekend and ready to try tackling this prob again... First off, was it okay for me to remove the $ from: INTERN_SERVERS=tcp_$192.168.1.2_smtp_10.10.10.200_smtp or should I put it back in? The $ should be left out...you want: INTERN_SERVERS=tcp_192.168.1.2_smtp_10.10.10.200_smtp MX records are the DNS entries that tell remote systems how to contact your mail server (as opposed to A records, which match system names to IP addresses). If you don't have an MX record tying your domain name to the IP of your mail server, you won't get mail from the internet at large. Note that this doesn't mean you won't get mail...your MX records could point somewhere else (like your ISP or the registrar for your domain name), and that system could forward mail to you. Do I need to update them with the following setup: Actual mail server address: 208.57.96.252, controlled by the ISP, forwards mail from their server to ours through their router to 192.168.1.2 (what used to be our Exchange server, but is now eth 0 on the firewall)? Since the firewall is set to forward traffic received at port 25 of 192.168.1.2 through to 10.10.10.200 (new ip of our Exchange server) wouldn't it work without having to change the MX records with our ISP? Assuming of course that portforwarding is actually setup and working correctly. It doesn't sound like you need to update any MX records. You should test external e-mail connectivity (which tests all port-forwarding and masquerading) by attempting to connect to the public IP (208.57.96.252) via the internet (ie not from a local machine). Output from netstat -nr: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 eth0 Your routing looks OK. I can't comment on your IP address setup without the output of ip addr list, although it looks like things are setup OK from some of the details extracted from your ipchains listing. Output from ipchains -nvL: Chain input (policy DENY: 0 packets, 0 bytes): Looks OK, with a rule in place to accept inbound SMTP traffic. Chain forward (policy DENY: 0 packets, 0 bytes): Looks OK, with a reverse masquerade rule required for the SMTP port-forwading to work properly. Chain output (policy DENY: 0 packets, 0 bytes): Looks OK. Chain fairq (1 references): Looks OK. ### Output from net ipfilter list: IPChains rules snipped...see comments above. AutoFW: Type Prot Low High Vis Hid WhereLast CPto CPrt Timer Flags MarkFW: fwmark rediraddr rport pcnt pref PortFW: prot localaddrrediraddr lportrport pcnt pref TCP 192.168.1.2 10.10.10.200 25 251010 Looks like you're setup to port-forward from 192.168.2 to your internal exchange box on 10.10.10.200. ## Let us know what happens. If memory serves, there could be potential problems with the exchange server setup. If things aren't working, provide the networking setup of the exchange box for reference (IIRC, the output of route print and ipconfig /all, but I think this depends on your windows version). You should also verify exchange is properly listening to the 10.10.10.200 address by running netstat -an. You want to see something like the following: Proto Local Address Foreign AddressState TCP0.0.0.0:25 0.0.0.0:0 LISTENING -- Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
AW: [leaf-user] upgrading procedures
I was wondering what was the best way to upgrade to each new Bering version. - Retyping the configurations files from the previous ones (in case there are major changes in the config files) - Backing up the previous config files and copy them back to the current version - upgrading the current configuration with each new LRP manually - other ways ? I wrote some scripts for that, which should make upgrading and maintaing multiple firewalls really easy, if you have a linux / unix box with root access (could also be virtual): diffleaf: Show all the differences between your installed packages and the default packages, i.e. the configuration files you edited. makeleaf: Combine custom configuration files (normally few) with the standard packages to get a pre-configured firewall The packages are now available in the patches section (look for patches by alexrh) while I'm hoping for developer access. As soon as I get that, I shall upload a much improved version including e.g. automatic resolving of kernel module dependencies. Cheers Alex --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] My Dachstein not quite up and running
Here's the output of ip addr list: 1: lo: LOOPBACK,UP mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope global lo 2: ipsec0: NOARP mtu 0 qdisc noop qlen 10 link/ipip 3: ipsec1: NOARP mtu 0 qdisc noop qlen 10 link/ipip 4: ipsec2: NOARP mtu 0 qdisc noop qlen 10 link/ipip 5: ipsec3: NOARP mtu 0 qdisc noop qlen 10 link/ipip 6: brg0: BROADCAST,MULTICAST mtu 1500 qdisc noop link/ether fe:fd:02:00:45:3d brd ff:ff:ff:ff:ff:ff 7: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:90:47:01:98:80 brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0 8: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:90:47:01:a0:7a brd ff:ff:ff:ff:ff:ff inet 10.10.10.254/24 brd 10.10.10.255 scope global eth1 I think it looks good. I can't make the actual switch of the Exchange server to behind the firewall until everyone goes home for the night so I'll have to report back on that later. Thanks for your help! Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] upgrading procedures
The easiest way (in my mind) is to use a CDRom and do partial backups on floppies. In most cases an upgrade involves putting a new CDRom in the drive and rebooting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rhomberg Sent: Tuesday, February 18, 2003 6:00 PM To: Fabrice CHARLEUX; [EMAIL PROTECTED] Subject: AW: [leaf-user] upgrading procedures I was wondering what was the best way to upgrade to each new Bering version. - Retyping the configurations files from the previous ones (in case there are major changes in the config files) - Backing up the previous config files and copy them back to the current version - upgrading the current configuration with each new LRP manually - other ways ? I wrote some scripts for that, which should make upgrading and maintaing multiple firewalls really easy, if you have a linux / unix box with root access (could also be virtual): diffleaf: Show all the differences between your installed packages and the default packages, i.e. the configuration files you edited. makeleaf: Combine custom configuration files (normally few) with the standard packages to get a pre-configured firewall The packages are now available in the patches section (look for patches by alexrh) while I'm hoping for developer access. As soon as I get that, I shall upload a much improved version including e.g. automatic resolving of kernel module dependencies. Cheers Alex --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Bering Kernel Source?
I'd like to try Bering, but only have a 486SX to try it out on, so I believe that I'll need to recompile the kernel. The only sources that I can find are for 2.4.18, which was for Bering 1.0-RC1. Will this work with 1.1, or will I need to get the source for 2.4.20? Not having tried it, can a 2.4 kernel be recompiled to work on a 486SX, or am I going to slam into a brick-wall straight away on that front? Thanks Nick --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering Kernel Source?
Hi Nick, I'd like to try Bering, but only have a 486SX to try it out on, so I believe that I'll need to recompile the kernel. I think this is correct, Bering is compiled for 486DX by default.. The only sources that I can find are for 2.4.18, which was for Bering 1.0-RC1. Will this work with 1.1, or will I need to get the source for 2.4.20? http://leaf.sourceforge.net/devel/jnilo/bering/latest/ specifically, http://leaf.sourceforge.net/devel/jnilo/bering/latest/development/kernel/Ber ing-2.4.20.config and the packages from the image file are what you'll need. Not having tried it, can a 2.4 kernel be recompiled to work on a 486SX, or am I going to slam into a brick-wall straight away on that front? I think you should be O.K. as long as you recompile your kernel. Hope that helps, Peter --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Update: Short term LEAF project goals
While I'm not that aware of various options, I think a few modules are mandatory or have to go with some packages. E.g. ipsec.o with ipsec(509).lrp, bridge.o with bridge.lrp, netfilter with tc.lrp etc. I was looking at this. In addition, 90-95% of the users would use a common combination. Dial up connections use PPP over serial ports etc. Such popular combinations can also be packaged to gether. Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Newmiller Sent: Wednesday, February 19, 2003 12:27 AM To: Matt Schalit Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Update: Short term LEAF project goals On Tue, 18 Feb 2003, Matt Schalit wrote: S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. ppp.lrp. The problem with incorporating module dependencies into packages is that modules are supposed to present a standard application programming interface that decouples the application from the hardware. PPP can in fact be run over ethernet, or over standard serial ports, or over special multi-port serial interfaces. Even if you put something in the packaging system that can recognize the absence of a minimum functionality (some type of point to point communication channel), you will still have confusion where the application calls for multiple channel types used in different ways (PPPoE into a serial control channel for an embedded device, for example). I think that in most cases coupling the base user-level package with an application-specific set of kernel modules makes more sense than integrating the two. If you really want idiot-level integration, then fall back on application-specific floppy image-style delivery. Bering's documentation is much more effective in the general case than trying to integrate into packages items that don't belong together in all cases. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Update: Short term LEAF project goals
I'm referring to only packaging meaning having within the same lrp. Additionally, the package installer should load all modules that are tarred within the package as they are deemed necessary for the utilities to work. I'm not suggesting that the module be compiled or integrated. Can we do away with manual steps when it is obviously needed. That is all. Sorry if my earlier posts have conveyed otherwise. Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Newmiller Sent: Wednesday, February 19, 2003 12:27 AM To: Matt Schalit Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Update: Short term LEAF project goals I think that in most cases coupling the base user-level package with an application-specific set of kernel modules makes more sense than integrating the two. If you really want idiot-level integration, then fall back on application-specific floppy image-style delivery. Bering's documentation is much more effective in the general case than trying to integrate into packages items that don't belong together in all cases. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] rtl8139.o and Bering 1.1
I have successfully been using this combination as well. ie 8139too.o and mii.o. What is preferred for rtl8139 based adaptors? David Pitts IT Services Manager Reid Library University of Western Australia Telephone: (08) 9380 3492 Fax: (08) 9380 1012 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 February 2003 5:05 AM To: Chris Hackett Cc: '[EMAIL PROTECTED]' Subject: Re: [leaf-user] rtl8139.o and Bering 1.1 I've been using 8139too.o which I believe requires mii.o for a long time. I forget the issues. Chris Hackett [EMAIL PROTECTED] on 02/18/2003 02:05:55 PM To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] cc:(bcc: Phillip Watts/austin/Nlynx) Subject: [leaf-user] rtl8139.o and Bering 1.1 Hello List! I'm trying to build a Bering 1.1 disk and am wondering if there are any known issues with the rtl8139.o and the Bering 1.1 image? I have put it in the /lib/modules and made the appropriate mods to get it to load. During the boot process, I see something like this: Loading modules rtl8139 - using /lib/modules insmod: unresolved symbol pci_drv_unregister insmod: unresolved symbol pci_drv_register I'm using the rtl8139.o in the same machine with the Eiger2Beta image, and I don't see the unresolved symbol messages with that image. Does anyone have ideas? Are these messages even important? Or can they safely be ignored? Also, after the image laods, when I log into the box, an ip link shows only the 'lo interface .. no eth0 or eth1 that I can find. If anyone can point me in the right direction, I'd sure appreciate it. Thanks!! Chris Hackett --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] rtl8139.o and Bering 1.1
On Tuesday 18 February 2003 09:05 pm, David Pitts wrote: I have successfully been using this combination as well. ie 8139too.o and mii.o. What is preferred for rtl8139 based adaptors? The 8139too is the 'version 2' module that should work (possibly better) with all rtl8139 chipsets, IIRC, unlike my experience with the different tulip chipsets. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Testing dial-up modem
Please reply to the list; you'll get more useful responses. Have you followed the procedures in http://leaf.sourceforge.net/devel/jnilo/bumodem.html? -Richard On Tue, 2003-02-18 at 18:27, Greg Playle wrote: I checked the logs; it showed only that the chat script was failing. I inserted SAY messages to do println debugging in the chat scripts; the scripts either never quite communicate with the modem, or fail at the dial command. syslog does show some info, but didn't show details. I'll try setting the options for logging and see what I get. -Original Message- From: Richard Doyle [SMTP:[EMAIL PROTECTED]] Sent: Monday, 17 February, 2003 22:18 To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' Subject: Re: [leaf-user] Testing dial-up modem Check your logs. pppd should let daemon.info know when the serial connection is established. Should also show up in syslog, if memory serves. You can set logging level in /etc/ppp/options. -Ricahrd On Mon, 2003-02-17 at 13:18, Greg Playle wrote: I'm new to LEAF, using Bering 1.1, and attempting to set it up for a serial modem (exterior), with two ethernet interfaces. I've got a booting distro, but there seems to be problems talking to the modem. While I learn about PPP, can someone point me to a way to verify the serial interface is actually detected, and is in fact talking to the modem? Thank you --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html -- Richard Doyle [EMAIL PROTECTED] -- Richard Doyle [EMAIL PROTECTED] --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
S Mohan wrote: While I'm not that aware of various options, I think a few modules are mandatory or have to go with some packages. E.g. ipsec.o with ipsec(509).lrp, bridge.o with bridge.lrp, netfilter with tc.lrp etc. I was looking at this. In addition, 90-95% of the users would use a common combination. Dial up connections use PPP over serial ports etc. Such popular combinations can also be packaged to gether. I rather favor a mechanism whereby package-module dependencies can be expressed in the package. Including kernel modules in .lrp's like ppp, pppoa or shorwall (just to name one) will yield nightmarish results when we try to introduce a new kernel version. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Tuesday 18 February 2003 09:19 pm, Tom Eastep wrote: I rather favor a mechanism whereby package-module dependencies can be expressed in the package. Including kernel modules in .lrp's like ppp, pppoa or shorwall (just to name one) will yield nightmarish results when we try to introduce a new kernel version. -Tom I agree 100% with Tom. Some form of dependancy stating/checking is already on the board when the packaging format gets changed. The last thing you would _ever_ want to do is stick a kernel module within a package. Some packages change themselves to what form of modular dependancy/patching is needed from version to version, Allowing a 'dep check' would allow much easier updating on all fronts. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Tuesday 18 February 2003 12:36 pm, Matt Schalit wrote: Java has ssh support built in. The LEAF system requirements are: sshd.lrp. That presents a space issue for any single floppy rollout, our classic format. Matt, Are lshd, stunnel, or zebedee also feasible options with Java??? -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Testing dial-up modem
Richard: Thank you for the reply. Yes, I followed those procedures. I've set the system-wide options for ppp to debug, which was helpful. The /var/log/messages now has the chat scripts results in it. The ABORT commands appear to be sent, and the ATZ^M, but the chat script gives an expect (OK), then an alarm and a failed, with no further indication of what failed. For some reason, the SAY messages didn't show up either, so I removed them. There does not appear to be anything in syslog or ppp.log that adds any information; ppp.log indicates the same process. I never hear any dialing, and I see no change in the status lights on the modem. ifup shows ppp0 present. Are there other things I should try for debug? Richard sent: Have you followed the procedures in http://leaf.sourceforge.net/devel/jnilo/bumodem.html? -Richard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Update: Short term LEAF project goals
Granted, accepted and think it is better. I did not think of this angle that modules may not keep pace. In some cases, due to sequence of loading, older modules might replace newer ones. Maybe be check while loading using lsmod to see if appropriate/ required module is loaded would be preferable. Mohan -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: 19 February 2003 08:49 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Update: Short term LEAF project goals S Mohan wrote: While I'm not that aware of various options, I think a few modules are mandatory or have to go with some packages. E.g. ipsec.o with ipsec(509).lrp, bridge.o with bridge.lrp, netfilter with tc.lrp etc. I was looking at this. In addition, 90-95% of the users would use a common combination. Dial up connections use PPP over serial ports etc. Such popular combinations can also be packaged to gether. I rather favor a mechanism whereby package-module dependencies can be expressed in the package. Including kernel modules in .lrp's like ppp, pppoa or shorwall (just to name one) will yield nightmarish results when we try to introduce a new kernel version. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
