RE: [leaf-user] Bering/Shorewall question
Actually I thought you asked the question quite well... The packets you are seeing are from your ISP's DHCP server. To conserve public IP address space, many ISPs are apparently using RFC1918 addresses for pieces of their internal network, including their DHCP servers. In theory, RFC1918 packets should not be seen on the Internet so a rule blocking them is entirely appropriate as a default. There are a couple of approaches you can take. My preference is to change the rule to just drop these packets without logging them. To do this, just go into the Shorewall menu, choose option 16 (RFC1918) and change the 'logdrop' to 'DROP'. Do a back up and then restart Shorewall and that should take care of it. Alternately, you could create a rule for this one particular address. Regards! Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Cass Tolken Sent: Sunday, July 21, 2002 11:28 AM To: Leaf User Subject: [leaf-user] Bering/Shorewall question Hi there, I'm a networking newbie so excuse me if this question or my terminolgy seems strange ;). I'm logging a whole LOT of these hits: [snip] Jul 21 13:57:20 firewall kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:9a:d0:ec:54:08:00 SRC=10.122.64.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=37032 PROTO=UDP SPT=67 DPT=68 LEN=308 Jul 21 14:03:11 firewall kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:9a:d0:ec:54:08:00 SRC=10.122.64.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=37054 PROTO=UDP SPT=67 DPT=68 LEN=308 I think the DPT=68 is related to bootpc which I believe is dhcp related. I am running dhcpd on eth1. Everything seems to be working great on my internal network (of mostly windows boxen) except for the above hits being logged EVERY few minutes. I've searched the mailing list archives and have found statements like the above message is probably generated by a rule in the mangle table and that the underlying problem is probably that 'norfc1918' is specified on an interface where it shouldn't be. (both from Tom Eastep in http://www.mail-archive.com/leaf-user@lists.sourceforge.net/msg07342.htm l .) I'm using the default Bering /etc/shorewall/interfaces lines: net eth0detect dhcp,routefilter,norfc1918 loc eth1detect routestopped Should I take out the norfc1918 from the eth0 line? If Tom says it shouldn't be there, why is it in the default Bering install? Thanks for any help! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- 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] Bering/Shorewall question
--- Kim Oppalfens [EMAIL PROTECTED] wrote: At 20:28 21/07/2002, Cass Tolken wrote: Taking out the norfc on should stop logging these. It is in there by default because you are not supposed to have an address in the 10.x.y.z range on an external interface. The norfc means to block anything in the source ip ranges of 10.x.y.z 169.254.y.z 172.16-31.y.z 192.168.0.1 224-239.x.y.z Looking at these logged messages I suspect you to have an external address of 10.x.y.z Just check by using the ip add command. If you are in the 10 range you should remove the norfc1918 Thanks for the quick response. Here is the output of ip add (I x-ed out my MAC addresses and eth0 IP which I get via pump from my cable modem ISP) # ip add 1: lo: LOOPBACK,UP mtu 16436 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 host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 24.46.xxx.xxx/22 brd 255.255.255.255 scope global eth0 4: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1 Could it be someone from the outside net that's doing this? Again, excuse my newbie-ness ;). I'll try taking out the norcf1918 after any replies I get from this message. Thanks again! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- 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] Bering/Shorewall question
At 21:13 21/07/2002, Cass Tolken wrote: Your external address 24.46.y.z doesn't appear to be in the rfc1918 range. So there is no reason to take the norfc1918 out. Is your intern dhcp server serving up addresses in this 10 range by any chance? I don't think so sonce your internal ip is in the 192.168 range. So apparently this is actually someone on the outside doing this. Most likely scenario is that someone on your segment got his configuration mixed up and is servicing up 10.x.y.z addressed on his external instead of his internal interface. I don't think an attack of some form is going on here. (Because there is no directed destination ip 255.255.255.255 means its a broadcast.) The guess that it is someone on your segment comes from the fact that it is a broadcast. If it is bothering you that it is being logged is bothering you you can allways add a line to the rfc1918 option file of shorewall (that is if you are using bering rc3 with the most recent shorewall). If you are using anything else just let me know and we will check to see what we can do. Just add a line above the 10.x.y.z logdrop with the folowing info in it. 10.122.64.1/32 DROP Kim Oppalfens --- Kim Oppalfens [EMAIL PROTECTED] wrote: At 20:28 21/07/2002, Cass Tolken wrote: Taking out the norfc on should stop logging these. It is in there by default because you are not supposed to have an address in the 10.x.y.z range on an external interface. The norfc means to block anything in the source ip ranges of 10.x.y.z 169.254.y.z 172.16-31.y.z 192.168.0.1 224-239.x.y.z Looking at these logged messages I suspect you to have an external address of 10.x.y.z Just check by using the ip add command. If you are in the 10 range you should remove the norfc1918 Thanks for the quick response. Here is the output of ip add (I x-ed out my MAC addresses and eth0 IP which I get via pump from my cable modem ISP) # ip add 1: lo: LOOPBACK,UP mtu 16436 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 host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 24.46.xxx.xxx/22 brd 255.255.255.255 scope global eth0 4: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1 Could it be someone from the outside net that's doing this? Again, excuse my newbie-ness ;). I'll try taking out the norcf1918 after any replies I get from this message. Thanks again! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- 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] Bering/Shorewall question
--- Kim Oppalfens [EMAIL PROTECTED] wrote: At 21:13 21/07/2002, Cass Tolken wrote: Your external address 24.46.y.z doesn't appear to be in the rfc1918 range. So there is no reason to take the norfc1918 out. Is your intern dhcp server serving up addresses in this 10 range by any chance? I don't think so sonce your internal ip is in the 192.168 range. Yes, it is on the 192.168 and not a 10 range. So apparently this is actually someone on the outside doing this. Most likely scenario is that someone on your segment got his configuration mixed up and is servicing up 10.x.y.z addressed on his external instead of his internal interface. Ah, that's what my guess was but I was not knowledgeable or confident enough to mention it ;). [snip] If it is bothering you that it is being logged is bothering you you can allways add a line to the rfc1918 option file of shorewall (that is if you are using bering rc3 with the most recent shorewall). [snip] My only concern is that it would totally fills up my log space. Just add a line above the 10.x.y.z logdrop with the folowing info in it. 10.122.64.1/32 DROP Ah, I'll do that. Man, this is one of the best supported project mailing-list I've ever used. Give yourselves all a good pat on the back ;). Thanks! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- 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] Bering/Shorewall question
On Sunday 21 July 2002 14:30, Kim Oppalfens wrote: At 21:13 21/07/2002, Cass Tolken wrote: Your external address 24.46.y.z doesn't appear to be in the rfc1918 range. So there is no reason to take the norfc1918 out. Is your intern dhcp server serving up addresses in this 10 range by any chance? I don't think so sonce your internal ip is in the 192.168 range. Some ISP's use private ip's on their DHCP and DNS servers, though this is a bad way to save real ip's, it works for them. This is not the case in your situation however, you would not have received a DHCP lease if it was. So apparently this is actually someone on the outside doing this. Most likely scenario is that someone on your segment got his configuration mixed up and is servicing up 10.x.y.z addressed on his external instead of his internal interface. MS boxes running Proxy and/or NAT services spew information out of _all_ interfaces and this is probably what is going on here. I would imagine that someone using a 10.x.x.x private network range behind a M$ NAT machine is spewing DHCP requests from it's internal interface out it's external interface. You can safely disregard the packets and set the firewall to DROP them instead of logging them. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Bering/Shorewall question
Some ISP's use private ip's on their DHCP and DNS servers, though this is a bad way to save real ip's, it works for them. This is not the case in your situation however, you would not have received a DHCP lease if it was. Lynn - I'm curious as to your reasoning on this. Doesn't the DHCP lease request occur before the firewall rules are started? My ISP is using an RFC1918 DHCP server and I get and maintain a lease even with the default Shorewall settings. Paul --- 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] Bering/Shorewall question
On Sunday 21 July 2002 16:02, Paul M. Wright, Jr. wrote: Lynn - I'm curious as to your reasoning on this. Doesn't the DHCP lease request occur before the firewall rules are started? My ISP is using an RFC1918 DHCP server and I get and maintain a lease even with the default Shorewall settings. Paul, There are tons of posts to the mailing list (even within the last day or rwo) from people without your experience. Tom also appears to think that this shouldn't happen (on lease renewal's anyway). I dunno why you haven't had any problems with this. Personally, my cox dhcp server is a 172.19.x.x server and pump won't renew the lease w/o allowing the address. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Ramdisk
I have been gettingwarning indications on the web interface for Bering-rc3 . I want to increase the ramdisk to clear the indication. How do I increase the ramdisk? Is it in the syslinux.cfg file? --- 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] Bering/Shorewall question
At 02:02 PM 7/21/02 -0700, Paul M. Wright, Jr. wrote: Some ISP's use private ip's on their DHCP and DNS servers, though this is a bad way to save real ip's, it works for them. This is not the case in your situation however, you would not have received a DHCP lease if it was. Lynn - I'm curious as to your reasoning on this. Doesn't the DHCP lease request occur before the firewall rules are started? My ISP is using an RFC1918 DHCP server and I get and maintain a lease even with the default Shorewall settings. The first DHCP lease request (and delivery) occurs before the firewall rules are started. Renewals have to get through the firewall, though, and that is the usual source of problems like the ones discussed in this thread. Without knowing more about your (and your ISP's) setup, I cannot say why it works while the other poster's does not. -- ---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] Portforward to a private address DMZ in Bering RC2
On 20 Jul 2002, Stephen Lee wrote: Hi, What is the Shorewall equivalent of port-forwarding to a private address DMZ as described in Dachstein? I only have 2 public static IPs so proxy arp and static NAT DMZ would appear to be out of the question. I can go as far as adding a second (eth2) internal private segment and getting it to work via masquerading but how do I get the eth1 private segment to see the DMZ (eth2) via the external ip address? Sorry if I missed this description in the Shorewall docs. That's FAQ #1 -- http://www.shorewall.net/FAQ.htm#faq1 -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [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] Portforward to a private address DMZ in Bering RC2
On Sun, 2002-07-21 at 15:51, Tom Eastep wrote: On 20 Jul 2002, Stephen Lee wrote: Hi, What is the Shorewall equivalent of port-forwarding to a private address DMZ as described in Dachstein? I only have 2 public static IPs so proxy arp and static NAT DMZ would appear to be out of the question. I can go as far as adding a second (eth2) internal private segment and getting it to work via masquerading but how do I get the eth1 private segment to see the DMZ (eth2) via the external ip address? Sorry if I missed this description in the Shorewall docs. That's FAQ #1 -- http://www.shorewall.net/FAQ.htm#faq1 My interpretation is that FAQ #1 addresses the needs of portforwarding to the private subnet (eth1) but it does not address access from the private net to the DMZ. FAQ #2 does answer the question and I discovered this as outlined in a subsequent message. In Dachstein, the documentation (network.txt) is more explicit about defining a Private DMZ which is masquerading plus some extra rules to allow for access to the DMZ from the private subnet. IMHO, this bit of glue logic doesn't seem to be obvious in the Shorewall (1.2) docs but is found in the FAQ. I would like to suggest including a brief description of the private DMZ segment example in the section on masquerading (or DMZ or snat) which references the need for Bind views or a split horizon Tinydns setup (perhaps links to FAQ #2?). On the whole though, the documentation is excellent and I certainly appreciate the amount sweat required to produce it. Thanks, Stephen --- 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] Portforward to a private address DMZ in Bering RC2
On 21 Jul 2002, Stephen Lee wrote: On Sun, 2002-07-21 at 15:51, Tom Eastep wrote: That's FAQ #1 -- http://www.shorewall.net/FAQ.htm#faq1 My interpretation is that FAQ #1 addresses the needs of portforwarding to the private subnet (eth1) but it does not address access from the private net to the DMZ. Sorry -- I've been away for the weekend and was too hasty in reading your post. FAQ #2 does answer the question and I discovered this as outlined in a subsequent message. In Dachstein, the documentation (network.txt) is more explicit about defining a Private DMZ which is masquerading plus some extra rules to allow for access to the DMZ from the private subnet. IMHO, this bit of glue logic doesn't seem to be obvious in the Shorewall (1.2) docs but is found in the FAQ. I would like to suggest including a brief description of the private DMZ segment example in the section on masquerading (or DMZ or snat) which references the need for Bind views or a split horizon Tinydns setup (perhaps links to FAQ #2?). On the whole though, the documentation is excellent and I certainly appreciate the amount sweat required to produce it. Thanks for the suggestion -- my current focus is to improve the documentation and I welcome your input. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [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
[leaf-user] shorwall 1.3.4 with Bering problem
The new version 1.3.4 of shorewall has moved some files to /var/lib/shorewall. My Bering rc3 doesn't copy these files when the shorwall.lrp package is installed. I'm trying Bering for the first time, and am migrating my Dachstein DMZ setup. I have gotten the older Shorewall version that comes with Bering to (mostly) work. Has any Bering user successfully upgraded Shoewall to 1.3.4? Tim --- 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] shorwall 1.3.4 with Bering problem
i believe this will help you to get shorewall 1.3.3 and above to work with bering http://leaf.sourceforge.net/devel/jnilo/bering/update/shorewall/README.txt brett --- Tim Wegner [EMAIL PROTECTED] wrote: The new version 1.3.4 of shorewall has moved some files to /var/lib/shorewall. My Bering rc3 doesn't copy these files when the shorwall.lrp package is installed. I'm trying Bering for the first time, and am migrating my Dachstein DMZ setup. I have gotten the older Shorewall version that comes with Bering to (mostly) work. Has any Bering user successfully upgraded Shoewall to 1.3.4? Tim --- 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 __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- 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] thttp and CGI
I've been trying to get the cute CGI scripts in weblet.lrp to run under thttp on my LEAF box...but I can't get it to go. If you run the cgi-scripts by hand, they generate the right code to STDOUT, but if you invoke them via browser, you get a blanki page. The standard SSI example in thttpd works, so I think the CGI is set up right. And the permissions look correct as show on Charles' site... Anybody done this, or gotten bourne shell cgi scriipts to run under thttpd under LEAF? Thanks Dave --- 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] thttp and CGI
On Sunday 21 July 2002 19:38, [EMAIL PROTECTED] wrote: Anybody done this, or gotten bourne shell cgi scriipts to run under thttpd under LEAF? The Mosquito LEAF-affiliated distribution is doing this. They are also using the uncgi binary, this may or may not be necessary for the cgi. I hope this helps, -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] shorwall 1.3.4 with Bering problem
Thanks Brett. I have now updated my Dachstein plus Seawall setup to Bering rc3 plus Shorewall 1.3.4 using the three interface (external, local, and DMZ) version. Migrating was easier than I expected. Bering is an outstanding piece of work. Thanks to Charles, Jacques, Eric, and Tom! Tim Wegner i believe this will help you to get shorewall 1.3.3 and above to work with bering http://leaf.sourceforge.net/devel/jnilo/bering/update/shorewall/README.txt brett --- Tim Wegner [EMAIL PROTECTED] wrote: The new version 1.3.4 of shorewall has moved some files to /var/lib/shorewall. My Bering rc3 doesn't copy these files when the shorwall.lrp package is installed. I'm trying Bering for the first time, and am migrating my Dachstein DMZ setup. I have gotten the older Shorewall version that comes with Bering to (mostly) work. Has any Bering user successfully upgraded Shoewall to 1.3.4? Tim --- 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 __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- 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
