[Leaf-user] What exactly is the uplink port?
I am a happy EigerStein user + Seawall user. I now have an increasing "farm" of various boxes behind my firewall/router that form my Leaf experimental testbed. Here's what I'm sure is a Newbie question. But alas, my linksys switch came with zero documentation, and while I'm an experienced software developer, my only network experience was getting my LRP box up and running, though that's a darn good education in itself. I have a Linksys 10/100 switch. It has 4 ports plus 2 uplink ports. One of the uplink ports is connected to my LRP box via a crossover cable, which is in turn connected to the DSL modem. My other boxes are connected to the regular ports. All is well. Now I am running out of ports on the Linksys switch due to a spurt of spending too many hours on Ebay (two Dell boxes and a really interesting Crystal rack-mount box). Undoubtedly I will buy another switch with more ports, but in the meantime, I thought, why not use the other uplink port? So I connected my Dell 166 mhz boxes (Ebay, $70 heh heh!) to the switch via the uplink port using a crossover cable. I fired upWin98/IE explorer, and Voila! my box was on the net. But even though the Dell box can access the internet through the uplink port(internet browsing works), the Dell box seemed to be insulated from the rest of the network for Windows networking - the uplink port Dell box can't see the others on the network neighborhood, nor can the other boxes see the uplink box. But when I connect the "uplink" box to the network via the normal ports (using a regular cable), everything works. Questions: 1. What is different about an uplink port and the regular ports on the switch, other than that the uplink port uses a crossover cable? (Looks like TCP/IP packets go over the uplink port but not Netbui.) 2. Can I exploit this seeming isolation from Windows networking caused by the uplink port to use the Dell box connected via the uplink port as a Web server (e.g. is this a poor man's DMZ?) I'm pretty sure this is a bad idea and I should get a second network card for the LRP box and have a really isolated web server on a DMZ, but I thought I'd ask. Tim Wegner ___ Leaf-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] What exactly is the uplink port?
Hilton, Your research is pretty good :-) I think the mystery is (mostly) solved with your help. You have the model number exactly right. It is called "Etherfast 10/100 Dual Speed 5 port Workgroup Switch, Model EZXS55W" There are 5 ports labelled 1 through 5, and another labelled "uplink". But there's a line from "uplink" to 5, that makes it look like 5 is also an "uplink" port. It is port 5 that I called the "uplink" port in my earlier message. In order to use it I did have to use a crossover cable. I just did an experiment. I unplugged the cable to my LRP box and plugged in back in port 5. Didn't work. But I then plugged port 5 to the LRP box with a regular cable, and it did work. > Normally, the last normal port and the uplink port are shared - in > other words these two connectors are *both* connected to the > same "port" and one is wired "straight" and the other "crossover". This part is exactly right. > This precludes the > use of 2 computers connected to both of these ports. This, amazingly, appears not to be right! By connecting port 5 (not crossed) to my Dell box using a crossover cable, I was effectively connecting the Dell box directly to the LRP box using a crossover. This means that the Dell box was not really connected to the other boxes on the network, but only to the LRP box. I just checked, and it's not just NETBUI that doesn't work between the Dell and the rest of the local network. I can't ping the other machines either. So the Dell box can communicate to the LRP box but is not on the local network. It sounds very weird. It does indeed sound like the Dell box is on a "DMZ". Your answer helped me understand what is happening. I'm still not sure whether this is supposed to work!! Thanks. Tim Wegner > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of Tim Wegner > > Sent: Monday, 25 June 2001 8:33 AM > > To: [EMAIL PROTECTED] > > Subject: [Leaf-user] What exactly is the uplink port? > > > > > > I am a happy EigerStein user + Seawall user. I now have an > > increasing "farm" of various boxes behind my firewall/router that > > form my Leaf experimental testbed. > > > > Here's what I'm sure is a Newbie question. But alas, my linksys > > switch came with zero documentation, and while I'm an > > experienced software developer, my only network experience was > > getting my LRP box up and running, though that's a darn good > > education in itself. > > > > I have a Linksys 10/100 switch. It has 4 ports plus 2 uplink ports. > > One of the uplink ports is connected to my LRP box via a > > crossover cable, which is in turn connected to the DSL modem. My > > other boxes are connected to the regular ports. All is well. > > I have not seen a hub or switch with multiple uplink ports. If you told > us the model number of your Linksys switch, then maybe I could look at > the product info on this device and give a better answer. The only > Linksys switch of this size I can find is the EZXS55W, and this has only > 1 uplink port. > > > Now I am running out of ports on the Linksys switch due to a spurt > > of spending too many hours on Ebay (two Dell boxes and a really > > interesting Crystal rack-mount box). Undoubtedly I will buy another > > switch with more ports, but in the meantime, I thought, why not > > use the other uplink port? So I connected my Dell 166 mhz boxes > > (Ebay, $70 heh heh!) to the switch via the uplink port using a > > crossover cable. I fired upWin98/IE explorer, and Voila! my box > > was on the net. > > Normally, the last normal port and the uplink port are shared - in other > words these two connectors are *both* connected to the same "port" and > one is wired "straight" and the other "crossover". This precludes the > use of 2 computers connected to both of these ports. > > > But even though the Dell box can access the internet through the > > uplink port(internet browsing works), the Dell box seemed to be > > insulated from the rest of the network for Windows networking - the > > uplink port Dell box can't see the others on the network > > neighborhood, nor can the other boxes see the uplink box. But > > when I connect the "uplink" box to the network via the normal ports > > (using a regular cable), everything works. > > Strange. > > > Questions: > > > > 1. What is different about an uplink port and the regular ports on > > the switch, other than that the upli
[Leaf-user] Extended Script questions (was More packaging enhancements)
Charles, (Moving this to leaf-user from leaf-dev, it's more a user message.) First thanks for everything you have done on LRP, especially EigerStein and the documentation and packages at your site. I have just been spending a lot of time studying network.txt and have found it very thorough and well-written. I am really in your debt, more than you know! What I am doing is migrating my EigerStein2Beta system to Extended Scripts 1.0. My first goal (now achieved) was to make the extended scripts work like EigerStein (that is, with DHCP working on eth0). My second goal, to be done today, I hope, is to add a DMZ. 1. I finally figured out that if am using DHCP to get an IP for eth0, that eth0 should not be included in IF_AUTO. Just want to verify that I have this right. I should have IF_AUTO="eth1 eth2" and not IF_AUTO="eth0 eth1 eth2" since I am using DHCP on eth0. Is that correct? If this is right, it probably deserves a comment in network.conf and a mention in network.txt. 2. There appears to be a bug in the extended scripts 1.0 /etc/init.d/network file. I'm guessing you already know about this, but what the heck, here it is: In the code fragment: if [ "$IPALWAYSDFRG" ]; then if [ "$IPALWAYSDEFRAG_KERNEL" = "YES" ]; then echo "1" >/proc/sys/net/ipv4/ip_always_defrag && vb echo -n "[IP Always Defrag: ENABLED] " else echo "0" >/proc/sys/net/ipv4/ip_always_defrag \ && vb echo -n "[IP Always Defrag: DISABLED] " fi fi There is no continuation character "\" after the first ip_always_defrag The funny thing is I didn't notice this at all in my EigerStein2Beta setup, but I got an error message about it when for a lark I dropped my versions of network.conf, ipfilter.conf, and network into Ewald's version of EigerStein2Beta. That version almost works for me, but not quite, but rather than debug it I am going to wait for your version of the EigerStein upgrade. I will migrate my setup to your new version when it is available, and would be more than happy to help debug it. Now on to trying out a DMZ on eth2 :-) Tim Wegner Date sent: Thu, 12 Jul 2001 08:00:53 -0500 From: Charles Steinkuehler <[EMAIL PROTECTED]> Subject:Re: [Leaf-devel] More packaging enhancements To: [EMAIL PROTECTED] Send reply to: [EMAIL PROTECTED] > > A couple of requests. > > > > 1. It would be useful to integrate one the extended scripts unto > > DachStein. (You probably already thought of this :-) > > > > > So it would be nice for DachStein to be EigerStein2beta workalike > > (e.g. with the network defaults as I mentioned above) with the > > added functionality of the extended scripts already in there in case > > the user decided he or she needed them. > > Yes, this is planned. The scripts released with Dachstein will likely be > the last of the 'Mountain' firewall scripts, as future plans are to support > several pre-packaged firewall scripts (seawall, rcf, &c). > > > 2. One irritation it would be nice to fix (though it may go beyond the > > "quick upgrade to EigerStein2Beta philosophy) would be to > > somehow extend the 256 character limit of the syslinux.cfg > > APPEND= line. When I add a second drive to PKGPATH and add > > serial support, I'm over the limit. I can't do both. (I recall that David > > did something in Oxygen to get around this.) > > The 256 character limit is a kernel restriction, so is unlikely to change > soon. It is possible to load non-critical LRP packages AFTER the kernel has > booted, from a config file stored on disk, dramatically reducing the size of > the LRP= part of the kernel command line. I believe this is what David is > doing with O2. > > > Finally, a quick question. If all I want to do is add a simple DMZ to > > my EigerStein2Beta network via a third ethernet board for a web > > server at the public IP of the LRP box (which is using dhcp), which > > is better: > > > > 1. upgrade to the extended scripts 1.0 > > 2. upgrade to the extended scripts 1.1 > > 3. upgrade to the CD scripts > > > > It looks to me like the extended scripts 1.0 have enough > > functionality, but it also looks to me like the DHCP section in those > > scripts doesn't have improvements you added to EigerStein2Beta. > > If I recall correctly, bothe extended scripts 1.1 and the CD scripts > > have the newer DHCP code. But I could easily just paste that > > section into network.conf from scripts 1.0. As near as I can tell > > that
[Leaf-user] Migration to Dachstein PR4
Charles and all, I have successfully migrated my EigerStein + extended scripts to DacStein PR4. This took very little time and there were no major problems, just a few nits (see below). I have a local network and a DMZ with a web server. However I am not really testing the firewall aspects of the script since I am using Seawall. As near as I can tell (I'm neither newbie nor expert) the variables in network.conf that apply to setting up IP's matter and anything to do with what ipchains lets through doesn't matter because Seawall overwrites it. I like the way Seawall manages the firewall, it's pretty easy. I should probably try to get my setup to work without seawall as a means of improving my understanding of network.conf. The only problem I noticed is that lrcfg brings up the editor in Pico mode even though it is set to the Wordstar mode. I changed the editor link to point to vi which works for me. I also inserted a few lines of codes into the dhclient exit hooks to set twegner.dynodns.net to my dhcp IP. A long time ago you suggested a few lines of script to check the result of http_get: # tell dynodns that the IP has changed if http_get -a twegner.dynodns.net:mypassword \ http://www.dynodns.net/pr/updatens.cgi | \ grep NOERROR >/dev/null ; then logger -t dynodns "update successful" else logger -t dynodns -s "update WAS NOT sucessful" fi #end dynodns changes The above code is inserted in the dhclient exit hooks right where the new IP is detected. But even though the code correctly updates my dynamic IP, apparently the grep doesn't return values as expected, because this code always reports "success" even though I edit the account and make it wrong. I simply redirected the output of the grep to /var/log/dynodns.result which serves the purpose OK. BTW the dynodns.net service is still there. The guy who created it sold to Deerfield.com but you can still use it. I like it because the method of updating the IP is super simple, basically just hit a web page and log in as I did above. See www.dynodns.net. The web page will encourage you to use deerfield.com, but the old dynodns.net still works. Thanks to you Charles and everyone here. This stuff is great! I use Dachstein on my router and Oxygen on my (somewhat simple and stupid) web site at twegner.dynodns.net in the DMZ, and seawall in both places. Tim Wegner ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] dialup with leaf - how?
I am sure this question is so obvious that I can't see the answer right in front of my nose! I am a happy user of Dachstein with dhcp DSL, but I have a friend who wants to use Dachstein with dialup. What is needed to use leaf (e.g. Dachstein) with ppp dialup? ppp.lrp? pppd.lrp? Can Kenneth Hadley's instructions for pppoe (which support pppoe over ethernet) be modified for dialup? I have seached the mail archives and a few of the leaf sites and haven't quite figure this out. I'm guessing this is very simple once one knows the answer :-) Tim Wegner ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] dialup with leaf - how?
Wow, Kenneth, nearly instant response!! Thanks. I'll have my friend try it out and let you know. In fact even though I have DSL, I also have dialup so I could try it also. Tim > You can try http://leaf.sourceforge.net/devel/khadley/ppp.html > there is right now no direct link on my web pages to it cause I need some > testers > Let me know if it works for you > > > - Original Message - > From: "Tim Wegner" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, February 02, 2002 12:25 PM > Subject: [Leaf-user] dialup with leaf - how? > > > > I am sure this question is so obvious that I can't see the answer > > right in front of my nose! I am a happy user of Dachstein with dhcp > > DSL, but I have a friend who wants to use Dachstein with dialup. > > > > What is needed to use leaf (e.g. Dachstein) with ppp dialup? ppp.lrp? > > pppd.lrp? Can Kenneth Hadley's instructions for pppoe (which support > > pppoe over ethernet) be modified for dialup? I have seached the mail > > archives and a few of the leaf sites and haven't quite figure this > > out. > > > > I'm guessing this is very simple once one knows the answer :-) > > > > Tim Wegner > > > > ___ > > Leaf-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] dialup with leaf - how?
Date sent: Sat, 02 Feb 2002 12:30:59 -0800 From: Kenneth Hadley <[EMAIL PROTECTED]> Subject:Re: [Leaf-user] dialup with leaf - how? To: [EMAIL PROTECTED] Copies to: LEAF-user <[EMAIL PROTECTED]> > You can try http://leaf.sourceforge.net/devel/khadley/ppp.html > there is right now no direct link on my web pages to it cause I need some > testers > Let me know if it works for you > > > - Original Message - > From: "Tim Wegner" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, February 02, 2002 12:25 PM > Subject: [Leaf-user] dialup with leaf - how? > > > > I am sure this question is so obvious that I can't see the answer > > right in front of my nose! I am a happy user of Dachstein with dhcp > > DSL, but I have a friend who wants to use Dachstein with dialup. > > > > What is needed to use leaf (e.g. Dachstein) with ppp dialup? ppp.lrp? > > pppd.lrp? Can Kenneth Hadley's instructions for pppoe (which support > > pppoe over ethernet) be modified for dialup? I have seached the mail > > archives and a few of the leaf sites and haven't quite figure this > > out. > > > > I'm guessing this is very simple once one knows the answer :-) > > > > Tim Wegner > > > > ___ > > Leaf-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Seawall scripts.
Jason asked: > What do some of you think of the Seawall firewall scripts? > I find they work well, and I like the file layout. Anyone > not think they are good firewall scripts? Would it be better > to use the built in Dachstein rules? I really love Dachstein, and it's predecessor Eigerstein. Charles is a genius! But I always use Seawall with Dachstein because it is easier to use and understand, and integrates well with Dachstein. I have a simple three NIC setup with a DMZ. I could not figure out how to set this up with Charles's extended scripts (and later with Dachstein, which includes the scripts). But with Seawall this is a piece of cake. Seawall is very organized and easy to use. There is a systematic way to specify what ports should be accessible to where and from where. Also, Seawall by default makes a very secure stealth firewall. Having said this, I should add that Dachstein by itself has a very decent firewall. I just understand Seawall better. The only downside I can see of using Seawall with Dachstein is it isn't always obvious which settings in the Dachstein setup can be ignored because Seawall overwrites them. I have always intended to go through and mark what those are (since I have only medium knowledge level this would be a good learning exercise). The Seawall ipchains setup appears to be loaded after the Dachstein ipchains setup, so all the port filtering rules Dachstein does are replaced. So I assume everything in the Dachstein setup that results in ipchains setup can safely be ignored. Finally, Tom Eastep gives super support for Seawall. Of course Charles Steinkuehler is equally heroic in helping perople out with Dachstein. Remember that Seawall is for ipchains so it is only for 2.2 kernel versions of leaf. For 2.4 kernel versions you can use Tom's Shorewall. I think the Bering developers were very smart to integrate Shorewall from the getgo. I am intending to migrate my Dachstein+Seawall setup to Bering. Tim Wegner ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Dachstein plus Seawall problem - network reset
I have been a happy user of Eigerstein (and descendents) plus Seawall
for quite a while. I am currently using Dachstein RC2 + the latest
Seawall. I have three NICS, a local network, and a DMZ behind a DSL
modem. In the DMZ I am using Oxygen as a thin client and running a
tiny web site.
Recently I noticed that the small web server I keep in the DMZ at
http://twegner.dynodns.net (a very modest web site) would become
inaccessible periodically (every few hours). After executing "seawall
restart" everything is OK for a while. Then bad again.
I sent the results of "seawall status" before and after the web site
disappeared to Tom Eastep. He told me it appeared that somehow the
Dachstein network was getting reset, essentially undoing seawall.
This makes sense because (as has been mentioned recently) seawall
runs after the Dachstein network was been set up, and essentially
overwrites the ipchains rules.
It didn't take me long to find the problem. It is in /etc/dhclient-
exit-hooks. My DSL connection uses DHCP. I noticed this problem
because apparently the logic in that detects that the IP has changed
executes every time the lease is renewed. Since that logic ends by
causing the network to be reloaded, voila! Seawall is undone.
My workaround was to add the command "seawall restart" after
"reload_all" (see below). [Note: you will see in this code some logic
I added to tell my dynamic dns service that my IP has changed. This
code also logs when that logic executes. Actually, my IP has changed
once in the last two years, I have the poor man's static IP! :-)]
My question is NOT what is the bug in the ip changing logic below, I
can probably figure that out (though if someone sees it instantly
there is no harm in writing me). This code is supposed to have a bug
fix I saw in the list from Charles. Maybe I dropped it or did it
wrong. I will upgrade the the Latest Dachstein and see if this IP
change detection has changed
Here are the questions:
1. Are there any other places in Dachstein that update the network,
and need to be followed by "seawall restart"?
2. Is there a better fix for this problem? (This fix works, my humble
web site has been visible continuously since I edited dhclient-exit-
hooks.) Unfortuantely my fix entangles seawall.lrp and dhclient.lrp.
Thanks everyone, I love this list! (Oops "these lists" because I sent
this to the seawalll list as well.)
Tim Wegner
#!/bin/sh
# dhclient-exit-hooks script for LRP
# Charles Steinkuehler, January 2000
# Updated June 27, 2000 to restart dnscache, if present
# Notes:
# 0. This script restarts the following when a new address is aquired
# a: Firewall filter rules
reload_all() {
svi network ipfilter reload
}
if [ x$reason = xBOUND ] || [ x$reason = xRENEW ] || \
[ x$reason = xREBIND ] || [ x$reason = xREBOOT ]; then
# If our IP address changed, or we just got a new address,
# restart the IP filters, using the new address
if [ x$old_ip_address = x ] || [ x$old_ip_address !=
x$new_ip_address ] || \
[ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then
# tell dynodns that the IP has changed
date >> /var/log/dynodns.txt
http_get -a twegner.dynodns.net: \
http://www.dynodns.net/pr/updatens.cgi | \
grep twegner >> /var/log/dynodns.txt
#end dynodns changes
# Reload networking to see new address
reload_all
seawall restart
fi
fi
if [ x$reason = xEXPIRE ] || [ x$reason = xFAIL ]; then
# No dhcp lease - Shutdown packet forwarding
/etc/init.d/network ipfilter flush
fi
if [ x$reason = xTIMEOUT ]; then
if [ x$timeout_using_old_lease = xTRUE ]; then
# Succsfully using an old lease, even though we can't talk to the
# dhcp server, so reload network to configure with 'new' address
reload_all
else
# Couldn't find the dhcp server, and can't ping the last default
router
# so let's just give up and stop forwarding packets
/etc/init.d/network ipfilter flush
fi
fi
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein plus Seawall problem - network
Charles wrote, re the problem of Seawall's ipchains getting
overwritten in dhclient exit hooks,
> > 2. Is there a better fix for this problem? (This fix works, my
> > humble web site has been visible continuously since I edited
> > dhclient-exit- hooks.) Unfortuantely my fix entangles seawall.lrp
> > and dhclient.lrp.
>
> The dhclient enter and exit hooks scripts are the cleanest location
> for this sort of code, AFAIK.
Thank you Charles. I will consult with Tom Eastep and revise the
Seawall with LRP Howto after we agree on the best solution. It does
appear that a Dachstein/Seawall user using dhclient does need to make
a small edit ot two in dhclienmt exit hooks.
Which brings us to the other problem. How often is the code in the
dhclient exit hook supposed to execute? I thought it was only
supposed
to execute when the IP changed.The code in reload_all executes on my
Dachstein system (which I have now upgraded to the 1.02 release)
every
time the lease is renewed even though the IP does not change.
Is the code intentionally conservative (e.g. intentionally reloading
the network fairly often)? If not, I should think the reload_all
should not execute if the IP has not changed.
For convenience, I have copied the exit hooks routine below. This
time
I have used Dachstein 1.02 as my starting point.
Look where I added my dynodns hook. There are some conditions
combined
with "or". Looks to me like an "and" is needed, but I am not sure
what
is intended. The comment
# If our IP address changed, or we just got a new address,
# restart the IP filters, using the new address
does not seem to match what the logic does.
Shouldn't the inside if statement be have [ x$reason = xBOUND ] ||
removed, so it looks like this:
# If our IP address changed, or we just got a new address,
# restart the IP filters, using the new address
if [ x$old_ip_address = x ] || [ x$old_ip_address !=
x$new_ip_address ] || \
[ x$reason = xREBOOT ]; then
Then the if reads "if the old IP is zero OR the new IP differs from
the old OR we just did a reboot". With the old logic, it is
sufficient
to run reload_all() to have [ x$reason = xBOUND ] be true.
Another minor point. I moved seawall restart into reload_all. This
works, but does cause seawall restart to be executed (harmlessly)
before it should be. I should probably move it back to just after
reload_all in the same if-clause as my dynodns code.
Tim
Copy of dhclient exit hooks based on Dachstein 1.02 follows
#!/bin/sh
# dhclient-exit-hooks script for LRP
# Charles Steinkuehler, January 2000
# Updated June 27, 2000 to restart dnscache, if present
# Notes:
# 0. This script restarts the following when a new address is aquired
# a: Firewall filter rules
reload_all() {
svi network ipfilter reload
seawall restart
}
if [ x$reason = xBOUND ] || [ x$reason = xRENEW ] || \
[ x$reason = xREBIND ] || [ x$reason = xREBOOT ]; then
# If our IP address changed, or we just got a new address,
# restart the IP filters, using the new address
if [ x$old_ip_address = x ] || [ x$old_ip_address !=
x$new_ip_address ] || \
[ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then
# tell dynodns that the IP has changed
date >> /var/log/dynodns.txt
http_get -a twegner.dynodns.net: \
http://www.dynodns.net/pr/updatens.cgi | \
grep twegner >> /var/log/dynodns.txt
#end dynodns changes
# Reload networking to see new address
reload_all
#seawall restart was here - moved to inside reload_all
fi
fi
if [ x$reason = xEXPIRE ] || [ x$reason = xFAIL ]; then
# No dhcp lease - Shutdown packet forwarding
/etc/init.d/network ipfilter flush
fi
if [ x$reason = xTIMEOUT ]; then
if [ x$timeout_using_old_lease = xTRUE ]; then
# Succsfully using an old lease, even though we can't talk to the
# dhcp server, so reload network to configure with 'new' address
reload_all
else
# Couldn't find the dhcp server, and can't ping the last default
router # so let's just give up and stop forwarding packets
/etc/init.d/network ipfilter flush
fi
fi
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein plus Seawall problem - network reset
Charles wrote: > The dhclient enter and exit hooks scripts are the cleanest location > for this sort of code, AFAIK. Charles, or anyone, help! I was trying to diagnose why the code that reloads the network in the Dachstein dhclient_exit_hooks gets executed every time the lease renews. I printed out the new and old ip address variables and the reason variable, and waited for my setup to renew the lease. And waitied for the lease to be renewed. Reason was BOUND, new_ip_address was 208.191.181.169 (this hasn't changed since November last year), and old_ip_address was blank! This certainly explains why the reload_all() routine in dhclient_exit_hooks gets called so often! $old_ip_address never equals $new_ip_address! I grepped for this variable everywhere and don't see where it is set. Can you tell me where it is set, or should be set? It looks to me like this logic is not quite right and hasn't been for quite a while. But it's very close to being right! Tim Wegner ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Dachstein dhclient experiment help needed
I would appreciate it if any Dachstein users using dhclient would do
the following experiment and tell us the result. I guess I would be
equally interested in pre-Dachstein LEAF versions of dhclient, or
other leaf users with dhclient.lrp similar to Charles'.
In the file /etc/dhclient-exit-hooks, add the lines just before the
comment #Reload networking to see new address:
#Begin instrumentation
date >> /var/log/dhclient.txt
echo old_ip_address = $old_ip_address >> /var/log/dhclient.txt
echo new_ip_address = $new_ip_address >> /var/log/dhclient.txt
echo reason = $reason >> /var/log/dhclient.txt
#End instrumentation
See below where to add the lines.
Then after the lease is renewed, or at least that particular code
executes, post to the list the results. In my case I get this:
Mon Feb 18 16:24:52 UTC 2002
old_ip_address =
new_ip_address = 208.191.181.169
reason = BOUND
The variable old_ip_address never has a value.
I would like to know if other users's dhclient behaves like mine.
Thanks,
Tim Wegner
My instrumented copy of /etc/dhclient-exit-hooks, so you can see
where the lines go:
#!/bin/sh
# dhclient-exit-hooks script for LRP
# Charles Steinkuehler, January 2000
# Updated June 27, 2000 to restart dnscache, if present
# Notes:
# 0. This script restarts the following when a new address is aquired
# a: Firewall filter rules
reload_all() {
svi network ipfilter reload
}
if [ x$reason = xBOUND ] || [ x$reason = xRENEW ] || \
[ x$reason = xREBIND ] || [ x$reason = xREBOOT ]; then
# If our IP address changed, or we just got a new address,
# restart the IP filters, using the new address
if [ x$old_ip_address = x ] || [ x$old_ip_address !=
x$new_ip_address ] || \
[ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then
#Begin instrumentation
date >> /var/log/dhclient.txt
echo old_ip_address = $old_ip_address >> /var/log/dhclient.txt
echo new_ip_address = $new_ip_address >> /var/log/dhclient.txt
echo reason = $reason >> /var/log/dhclient.txt
#End instrumentation
# Reload networking to see new address
reload_all
fi
fi
if [ x$reason = xEXPIRE ] || [ x$reason = xFAIL ]; then
# No dhcp lease - Shutdown packet forwarding
/etc/init.d/network ipfilter flush
fi
if [ x$reason = xTIMEOUT ]; then
if [ x$timeout_using_old_lease = xTRUE ]; then
# Succsfully using an old lease, even though we can't talk to the
# dhcp server, so reload network to configure with 'new' address
reload_all
else
# Couldn't find the dhcp server, and can't ping the last default
router
# so let's just give up and stop forwarding packets
/etc/init.d/network ipfilter flush
fi
fi
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein plus Seawall problem - network reset
(Note: I read the list so I don't needs answers cc'ed to me, not that I mind.) Charles wrote: > These variables should be setup by the dhclient program before the > dhclient script is called. The available variables are documented by > the dhclient-script man page: > http://lrp.steinkuehler.net/Packages/man/dhclient-script.8.man.htm Thanks for the pointer to the docs. That helped a lot! > > Note that BOUND is an initial binding to an IP, and does *NOT* have > the $old_* variables set. RENEW is what should be sent as a reason > when a lease is renewed, which should have both the $old_* and $new_* > variables set... For whatever reason, things are not working quite as I would expect, though results are OK with the workaround for seawall that I am using. The following applies to a setup based on Dachstein 1.02. I have instrumented the code in dhclient-exit-hooks. About every seven ours or so, I see in syslog something like this: Feb 18 16:24:48 firewall dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 18 16:24:48 firewall dhclient: DHCPNAK from 208.191.191.254 Feb 18 16:24:48 firewall dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 Feb 18 16:24:48 firewall dhclient: DHCPOFFER from 208.191.191.254 Feb 18 16:24:51 firewall dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 18 16:24:51 firewall dhclient: DHCPACK from 208.191.191.254 Feb 18 16:25:13 firewall root: Seawall Restarted Feb 18 16:25:13 firewall dhclient: bound to 208.191.181.169 -- renewal in 14398 seconds. Note in the above that seawall restarted. This is due to my workaround in dhclient-exit-hooks. and the result of my instrumentation looks like this: Mon Feb 18 16:24:52 UTC 2002 old_ip_address = new_ip_address = 208.191.181.169 reason = BOUND The IP doesn't change, but from your earlier message, since $reason is BOUND, for some reason for some reason dhclient thinks it is getting the ip for the first time. I have no special problem, though I wish I knew if this behavior was limited to mys setup. I'll ask the list in another message. Charles, I doubt there is any more for you to add, but if you see something, let me know, and thanks! Tim ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein plus Seawall problem - network reset
Charles wrote: > Actually, I do have a comment or two :). Good ! :-) > It looks like your ISP's > DHCP server is not allowing you to renew a lease, but instead is > giving you a new lease with the same IP. This is strange behavior, > and is what's causing your problem...as far as dhclient is concerned, > it's lease renewal was rejected (the first DHCPREQUEST and the > DHCPNAK, above), so it had to ask for a completely new lease (the > second DHCPDISCOVER, and the DHCPOFFER, DHCPREQUEST, and DHCPACK, > above). Very interesting! > I'd wager a guess that your ISP is lacking a bit in the "clue" > department...have you had any other problems with them? I suppose it > could also be wacky behavior by a windows DHCP server...they tend to > have other "not quite correct" observed behavior, like spitting the > DHCP broadcast packets out *EVERY* interface...it's not correct > behavior, but if you're not watching the traffic on the wire, you > wouldn't necessarily know it's happening. Do you know if your ISP is > an NT or unix shop? I have no idea whether my ISP is Unix or Windows, but I'm not sure I want to mess with them and help them fix their DHCP. My ISP swbell.net is Southwestern Bell. They have contracted with Prodigy for new DSL users, who have to use PPPOE. I have DHCP service grandfathered. My IP stayed constant for most of the entire time I have had DSL until about a year ago, when their dhclient server broke. When they fixed it, for a day or so I had new IPs, and then it stabilized and has not changed in the last year. I like having a more- or-less fixed IP. As I said earlier, it is a "poor man's static IP". Since I have the domain name fractint.org, and have www.fractint.org hosted by a friend, I have asked the administrator of the fractint.org host to make tim.fractint.org to point to my IP. Since he doesn't have an automated way for me to update that IP, this only works because it rarely changes. I have only had to ask him to change it once in more than two years :-) However the behavior you mentioned does make a problem with seawall as we have discussed. From what you are describing, if my ISP's DHCP server were working right, the seawall problem of the network reloading, and hence requiring a seawall restart, would not happen. But my adding the "seawall restart" line in dhclient-exit-hooks makes everything OK. I think I will let sleeping dogs lie, unless you can see any way my ISP having the right DHCP behavior would help me. Thanks, looks like I can tell Tom Eastep there is not really a Dachstein/Seawall issue after all. In another message I asked folks to report how their DHCLIENT setup works. We'll see if the behavior I reported is unique to me or not. Tim ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[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
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
Re: [leaf-user] Ethernet card config - Bering
Dave, Look in: http://twegner.dynodns.net/dave You can download either the executable http://twegner.dynodns.net/dave/mii-diag or the tar.gz (tgz) package. http://twegner.dynodns.net/dave/miidiag.tgz The only reason to download the package is that the compression provides a degree of confidence that the downloaded file is OK. The source file is there also. To the list - this mii diagnostic tool looks useful. Should I package it as a lrp package? I suppose I could compile a few other NIC diagnostic programs and add them to the package. BTW, Dave, you could have compiled this yourself. It doesn't seem to use any special libraries. I compiled it on my Dell Optiplex in a Debian Slink environment using: cc -o mii-diag mii-diag.c However I'm guessing it could have been compiled under just about any linux (or even Unix). It runs on the Debian Slink I compiled it on, and I also ran it under the Leaf Oxygen that my web server runs on. You should be able to run it under Bering. I highly recomment you try that 3com board I lent you with one of your dlink boards if you are still having trouble. Tim > I also posted this issue to the realtek list. Donald Becker suggests I run > mii-diag. > http://www.scyld.com/diag/index.html > ftp://ftp.scyld.com/pub/diag/ > > Is mii-diag compiled and available for Bering_1.0-rc3? If not, PLEASE? > > DPD > > > From: David Dannemiller <[EMAIL PROTECTED]> > > Date: Sat, 27 Jul 2002 00:04:27 -0500 > > To: <[EMAIL PROTECTED]> > > Subject: [leaf-user] Ethernet card config - Bering > > > > I'm having a problem I think is related to ethernet card configuration. > > > > My LEAF distribution is Bering_1.0-rc3 configured per chapter 4 of the users > > guide for PPPoE. > > > > > > --- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > > 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] Does ne.o work with Bering Uclib?
I am a long time Eigerstein/Bering user who has been happily using a three-interface Bering box for some time. I have a friend also using Bering, and he told me he could not get the ne.o module to work with his box when he attempted to migrate to the latest Bering uclib. So I thought I'd try to do the same thing on my three interface box. I downloaded Bering Uclib 2.1 and the corresponding modules and copied ne.o to /lib/modules, and configured the modules package the same way I did before: 8390 ne io=0x340,0x240,0x300 Upon boot, I did see a message saying those modules were being used, but I did not see the message I am used to seeing with Bering telling me the exact port and interrupt used with the ne2000 boards. I also saw error messages telling me that eth0 did not exist. Then I looked in /var/log/messages and saw these two lines: root: modutils module 8390 could not be loaded root: modutils module ne could not be loaded Does anyone have any idea why these two modules are not loading? (Note that the 8390.o is the one already on the Bering uclib disk. I supplied the ne.o module from the Bering Uclib 2.1 module tarball). I am assuming this is a real problem because my friend and I both attempted to migrate from Bering to Bering Uclib independently and neither one of us could get the ne.o module to work. Tim Wegner --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click 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] Does ne.o work with Bering Uclib?
Ah so, the solution is to load the crc32 module before the 8390 module. This is probably a FAQ that I missed, but if not, this would be a good thing to add to the installation docs since it's a difference from Bering, > I am a long time Eigerstein/Bering user who has been happily using a > three-interface Bering box for some time. > > I have a friend also using Bering, and he told me he could not get > the ne.o module to work with his box when he attempted to migrate to > the latest Bering uclib. So I thought I'd try to do the same thing on > my three interface box. I downloaded Bering Uclib 2.1 and the > corresponding modules and copied ne.o to /lib/modules, and configured > the modules package the same way I did before: > > 8390 > ne io=0x340,0x240,0x300 > > Upon boot, I did see a message saying those modules were being used, > but I did not see the message I am used to seeing with Bering telling > me the exact port and interrupt used with the ne2000 boards. I also > saw error messages telling me that eth0 did not exist. > > Then I looked in /var/log/messages and saw these two lines: > > root: modutils module 8390 could not be loaded > root: modutils module ne could not be loaded > > Does anyone have any idea why these two modules are not loading? > (Note that the 8390.o is the one already on the Bering uclib disk. I > supplied the ne.o module from the Bering Uclib 2.1 module tarball). > > I am assuming this is a real problem because my friend and I both > attempted to migrate from Bering to Bering Uclib independently and > neither one of us could get the ne.o module to work. > > Tim Wegner > > > --- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > > 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: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click 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] Shorewall version with Bering
I noticed that the just released Bering-uClibc 2.1.1 uses Shorewall updated to version 1.4.10e. When I recently migrated my three interface router from Bering to Bering-uClibc I went straight to Shorewall 2.0.1. I had no problems at all. Is there any profound reason that Bering-uclib hasn't gone to Shorewall 2.x other than fear of major version increments and there being only 24 hours in a day? :-) I also wish to express my heartfelt thanks to all the leaf developers, especially Charles Steinkuehler, the Bering and the Bering-uclib teams. I better include the fast-recovering Mike Noyes too! Tim Wegner --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click 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 version with Bering
KP asked (referring to the 2.X version of shorewall in my Bering- uClibc setup): > Sounds good; how big is shorwall.lrp? My configured three interface Shorewall 2.x version is 83563 bytes . That is 15000 or so bytes bigger than my 1.4X version. As I said the upgrade was painless. My Bering three interface setup took a second floppy drive. After migrating to Bering-uClibc, I'm down to one floppy. A lot of that is dropbear vs Openssh. In my earlier email I expressed heartfelt thanks to several Leaf people and teams, I dunno how I forgot to add Tom Eastep to that list!!! Thanks Tom! Tim --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click 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 version with Bering
Tom wrote: > And I apologize for being so grumpy -- time to go to bed Since my original message included thanks to Tom, this message hereby legitimately continues the thread ... I hereby announce to the world that Tom's being grumpy in no way lessens my appreciation for him, and I am glad he went to bed to get some well-deserved rest Tim --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click 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] DNAT vs ACCEPT for bittorrent/Shorewall
I am a happy long time user of Bering uCLIB and the three-interface Shorewall (and their predessecors) with my DSL line. The uClib team and Tom Eastep are the greatest! Not to mention other folks on this list. Thanks! Either of these two entries in shorewall rules on my Leaf router appears to enable me to use Bittorrent: DNAT net loc:192.168.1.203 tcp 6881:6889,6969 - $ETH0_IP or: ACCEPT net loc tcp 6881:6889,6969 Of course the DNAT works only on one machine (192.168.1.203 ). The ACCEPT form allows me to use BitTorrent on any of several machines. Here is my question: is there any down side to using the ACCEPT form? Is it less secure? Since I am on a home network I am controlling all the machines, and am the only one running BitTorrent. Tim Wegner --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl 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] CF Card Issues
Bob wrote: > I get the sense that all the grief I see people have with CF cards > just isn't worth it. ... Is anyone running CF with absolutely no > issues?? I recently migrated my Leaf ucLibc with three-interface shorewall to a Soekris 4801. I used a 512MB compact flash that came with a Canon camera. Took some time to sort out the little details (add serial support, make CF bootable with fdisk, etrc.) but it works really well. It was irrational to migrate to the Soekris because the 486 was working well - but I love reducing the power consumption from 40 watts to under 10 watts and the Soekris is very cool (pun intended). So CF is causing no problems so far. The problem of not unmounting causing corruption can affect any media, it's not a CF problem. Tim Wegner --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] dyndns
Hector wrote: > But I cannot access my http server through dyndns, I > think that somewhat is missconfigured at shorewall > rules. I have these two shorewall rules: # redirect port 80 for web server DNATnet dmz:192.168.2.1 tcp 80 DNATloc dmz:192.168.2.1 tcp 80 - $ETH0_IP The second rule permits access to the web server 192.168.2.1 in my dmz from my local network. The variable $ETH0_IP is set to the external IP. I set it in the init file via: ETH0_IP=`find_first_interface_address eth0` All of this is was gleaned from Tom Eastep's excellent docs. I hope this helps. To get more help you need to show us your shorewall rules and network setup. Tim --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Azereus bit torrent NAT problem
Jim Ford asked: > My Dachstein setup appears to be working fine but Azereus reports a > NAT problem. As I'm still struggling up the ipchains learning curve, > I don't want to fiddle with anything and unwittingly throw the doors > open to attackers. I'd welcome suggestions for an ipchains line to > fix this and allow other peers to download from my torrents. First see: http://btfaq.com/serve/cache/25.html This contains various ways to set up port forwarding for bittorrent. I found this by googling "bittorrent nat". There is all kinds of information on this subject. To get rid of the NAT problem warning, I did this in shorewall rules: # Allow BitTorrent traffic through - port 6969 is if you run a tracker # And ports 6881 through 6889 are for incoming BitTorrent connections. DNAT net loc:192.168.1.203 tcp 6881:6889,6969 - $ETH0_IP Where $ETH0_IP is my external IP. I realize this doesn't address Dachstein directly, but I hope it helps. Tim --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Webserver with PHP support
Lionel wrote: > I am a new user of Bering uClibc and I was wondering if there were > other web servers than sh-httpd or mhttpd because there is not much > documentation available on those servers (I remember Bering was using > thttpd, which is more documented on acme.com website). I have been running the thttpd web server (see www.acme.com) on the Leaf Oxygen release for years. It is very reliable for serving up static web pages - Charles Steinkuehler packaged it up for his Eigerstein LRP distribution, and this package ran fine under Oxygen. Thttpd would have to be recompiled for Bering uClibc. I expect this is not hard, I might even attempt it. The docs say it supports PHP - see http://halplant.com:88/server/thttpd_FAQ.html#PHP but this might not be a good idea, especially running on a Leaf distribution. If anyone has already compiled thttpd for uClibc I would like to know. Tim --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] SNAT with Bering 3.0
Steve wrote: > I have found an "inconsistency" with Tom's documentation and the > latest Bering- uClib/Shorewall release. This is not an inconsistency in Tom's documentation. You were reading Tom's three-interface documentation, and Leaf as distributed is set up for two interfaces. So you should be reading Tom's two interface documentation. I have been happily using Leaf/Seawall/Shorewall for many years through many versions, and always modifed the stock Leaf by downloading the three-interface files from Tom's site. Tim - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Problems with Bering uclibc 3.1.1 beta3 on Soekris
I have been happily running various verions of lrp for many years. most recently, LEAF Bering-uClibc 2.3 uClibc 0.9.20 Rev 3 on a headless Soekris net 4801 box. This has been running for five years are so with no problems. I want to upgrade to 3.1.1, but can't get the boot process to quite complete, gets hung with "Starting periodic command scheduler: cron. can't open /dev/tty1: No such d LEAF Bering-uClibc 3.1.1 Rev 6 uClibc 0.9.28 firewall ttyS0 can't open /dev/tty1: No such device can't open /dev/tty2: No such device ..." To simplify things, I took the floppy image and copied the files to a compact flash card that already had syslinux (albeit an older version - does that matter?), and made the following changes: 0. did not overwrite ldlinux.sys from syslinux. 1. edited leaf.cfg to change to: PKGPATH="/dev/hda1:msdos" 2. edited syslinux.cfg in same way to use /dev/hda1, and also add support for serial port (only way to see what's happening on a Soekris) 3. copied initrd_ide_cd.lrp to initrd.lrp 4. Edited inittab in etc.lrp to add a getty line for serial port. I haven't added the natsemi.o module yet, but that shouldn't prevent boot process from completing (I would think). I just want to get to a login prompt, then I think I can get the rest of the way. There's no problem with the old setup, I just would like to get current. Also, there's a broken link to the usb image: http://prdownloads.sourceforge.net/leaf/Bering-uClibc_3.1.1- beta3_usb_bering-uclibc-iso.bin.img.gz?download This link gives the models file by mistake. Is the USB image someplace? Any advice would be appreciated. There is a lot on the web for leaf/soekris, but it's all older than my old setup. Is there something else I have to do to set up the serial port? Thanks, Tim Here's what I get through the serial port, with a little bit snipped: DMI not present. Kernel command line: reboot=bios console=ttyS0,19200n8, nodma=hda ide=nodma BOOT_IMAGE=linux initrd=initrd.lrp init=/linuxrc rw root=/dev/ram0 LEAFCFG=/dev/hda1:msdos Initializing CPU#0 Detected 266.661 MHz processor. Calibrating delay loop... 532.48 BogoMIPS Memory: 127244k/131072k available (865k kernel code, 3440k reserved, 97k data, 60k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) Inode cache hash table entries: 8192 (order: 4, 65536 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) CPU: NSC Unknown stepping 01 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.01 entry at 0xf7861, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4) Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ DETECT_IRQ SERIAL_PCI enabled ÿttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10f floppy0: no floppy controllers found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 8192 bind 16384) ip_tables: (C) 2000-2002 Netfilter core team arp_tables: (C) 2002 David S. Miller NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 402k freed VFS: Mounted root (minix filesystem). Freeing unused kernel memory: 60k freed LINUXRC: Bering - Initrd - 3.1.1 Rev 6 uClibc 0.9.28 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hda: Hitachi XX.V.4.2.0.0, CFA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: attached ide-disk driver. hda: 62592 sectors (32 MB) w/1KiB Cache, CHS=489/4/32 Partition check: hda: hda1 hda: hda1 hda: hda1 LINUXRC: Mounting a 6M TMPFS filesystem... hda: hda1 hda: hda1 LINUXRC: Installing - root: /dev/hda1 config: /dev/hda1 etc: /dev/hda1 modules: /dev/hda1 iptables: /dev/hda1 dhcpcd: /dev/hda1 keyboard: /dev/hda1 shorwall: /dev/hda1 ulogd: /dev/hda1 dnsmasq: /dev/hda1 dropbear: /dev/hda1 mhttpd: /dev/hda1 openntpd: /dev/hda1 webconf: /dev/hda1 configdb: configdb(nf!) moddb: /dev/hda1 - Finished. sh: argument expected LINUXRC: Loaded Packages Loading keymap: us.maploadkmap: can't open console . Loading modules: ip_conntrack version 2.1 (1024 buckets, 8192 max) - 312 bytes per conntrack IPP2P v0.8.2 loading Soft
[leaf-user] Leaf on Soekris 4801
These notes (mostly) discuss running Leaf 4.x on a Soekris 4801 box, since there is little in the wiki. I will add a few notes to the Leaf Soekris 4801 wiki page after I get permission. The good news is that there is not too much to say since there are no special problems. I have been using Leaf and it's predecessors through various incarnations back to the original LRP days. I started on a repurposed 486 machine but for quite a while have been using a Soekris 4801 box with Leaf on compact flash. The Soekris box has three RJ45 ports connected to a DSL modem as a router to a local network and a DMZ with a small web server. I like the Soekris box because it is small, silent, and has low power consumption. Yesterday I upgraded Leaf on the Soekris from 3.X to 4.01, and then today upgraded again to beta 4.1 without any problems. The Soekris box requires the natsemi module for the network ports, which is autodetected nicely in both 4.01 and 4.1. Therefore there are no special instructions required on the Soekris box different than would be needed on any headless box installed using a serial connection with the Leaf distribution on compact flash. I used an old Canon branded Sandisk 32 MB Compact Flash card that came with a camera, so I had to leave out a few files. I'm not sure it's a good idea to have the entire Leaf distribution on a production system anyway, so I might try to delete any packages I am not actually using, and maybe try KP's suggestion earlier today to get rid of extra modules. I have a few tiny questions that aren't related to Soekris. 1. I can never get Dropbear's scp to work with a program like Winscp. I briefly tried, but switched to sshd and sftp, which works fine. If anyone knows how to get Dropbear's scp to work, I'd be interested. 2. I had recently been using an alternate resolve.conf file for dnsmasq because it gets overwritten by dhcp. I noticed that resolv.conf is now in configdb.lrp, so if I edit it with opendns server IPs,the changes are saved. Have I got this right, or is there still a danger resolv.conf is overwritten? I could always make an alternate resolv.conf file, put it in configdb, and have dnsmasq use it, which might be safer. I just want to use opendns and not my DSL provider's dns servers. Thanks to the Bering-uClibc 4.x team for all their hard work! Tim -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Leaf on Soekris 4801
Eric wrote (in response to my query about resolv.conf getting overwritten) > If it gets overwritten by dhcp then it will be overwritten whatever > you do to configdb. As it may well be overwritten any time during > operation. > > The following link > http://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/ may help > to avoid this. I read the link, thanks. My objective is to use the opendns dns servers for all the boxes on my local network by listing their dns server as 192.168.1.254. What I did before was create a file /etc/my_resolv.conf containing the opendns dns servers, and then having a line in dnsmasq.conf as follows: # Change this line if you want dns to get its upstream servers from # somewhere other that /etc/resolv.conf resolv-file=/etc/my_resolv.conf and then put my_resolv.conf in the etc.lrp package, which was awkward but seemed to work. So far my Leaf box's /etc/resolv.conf has not been overwritten. But since it might be, I guess I will go back to my old method, except that configdb.lrp provides a much handier (and more appropriate) place to put /etc/my_resolv.conf than etc.lrp. Thanks for your help. Please let me know if this doesn't make sense. Tim -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [ANN] LEAF Bering-uClibc 4.1 Release Candidate 1
I upgraded from 4.1 beta2 to Releaswe Candidate 1 with no significant problems. I have been using leaf since the lrp days, and I really appreciate how much easier the upgrade is now. The one very small issue I had is that I am running on a Soekris 4801 from Compact Flash. The syslinux in mtools works with a 32mb CF from the Soekris Leaf box but not with a newer 4gb CF - gives a message about file system too large. That simply meant I had to run syslinux on another Linux box to add the bootloader, then it worked fine. I know this is super paranoid, but it seems to me that I should not have the whole distribution on the CF flash for security reasons, especially since these days we are not booting off a write-protected floppy. So I will to pare down the files to just what I am using. I use the Leaf/Soekris box as a router for my home network. Shorewall is set up with a DMZ on which a small web server is running Leaf Oxygen and the thttpd web server on a truly ancient HP Vectra machine. I should really update the web server to a newer Leaf, but I wan't able to get the latest version to work. I believe 3.1.1 beta 3 works. I will try the latest again. Thanks to the team for a wonderful project! Tim -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [ANN] LEAF Bering-uClibc 4.1 Release Candidate 1
KP wrote: > Using a boot partition with 512MB solved issue - and 512MB on a CF > was about ten times the space I needed to install all packages, > thereforeI didn't investigate further. Just for my education I reduced the main partition on the 4gb boot CF to 512 mb as you suggested. Then the syslinux from the mtools.lrp package on my Leaf/Soekris 4801 box was able to make the CF bootable as you said. > Still looking foward how to make use of the remaining 3GB :) I'm sure you know this, but again for my remedial education I made a second DOS partition with the remaining space. It was accessible from within Leaf by mounting /dev/sda5. All this can be avoided by making the entire 4gb CompactFlash a dos32 partition and using syslinux on another Linux machine (64 bit Fedora 14 in my case) to make it bootable. Still not sure why the Leaf syslinux is limited to 512 mb, but I have exhausted my scientific curiosity :-) Tim -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] changing leaf ip from 192.168.1.254
I have just gotten a new DSL modem that is accessed at 192.168.1.254. Unless I discover the IP of the modem can be changed, I will need to change my leaf router which also uses 192.168.1.254. My previous modem was accessed at 192.168.1.1, and I was able to set up the networking to access it at that address via eth0. Is there anything to change other than /etc/network/interfaces and /etc/shorwall/masq? A grep of "192.168.1.254" turned up those two places. Thanks - been using leaf a long time and love it. Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] changing leaf ip from 192.168.1.254
Thanks to n22e113 for also responding. KP wrote: > I have an DSL connection with pppoe and currently set the DSL pppoe > pass through - that way the IP address of the DSL modem can be > negletced. In my case in Houston I am an early adopter of DSL and have DHCP grandfathered. I already knew to put the modem into bridge mode. I have purchased a new Motorola 3360, which has a configuration screen at 192.168.154. It was an easy matter to connect my computer directly to the modem, and access the setup screen at 192.168.1.254, and change to bridged mode. When I then hook my computer back to the switch/Leaf box, and reconnect the modem to the Leaf Soekris box, everything works perfectly - except, of course, I can't any longer access the modem via 192.168.1.254. My previous Westell 2200 modem has a setup screen at 192.168.1.1. I was able to access it by adding one line in the interfaces file: # Step 1: configure external interface # uncomment/adjust one of the following 4 options # Option 1.1 (default): eth0 / dynamic IP from dhcpcd auto eth0 iface eth0 inet dhcp up ip route add 192.168.1.1 dev eth0 I had to also make a two-line shorewall/masq change: +eth0::192.168.1.1 0.0.0.0/0 192.168.1.254 eth0 192.168.1.0/24 (This is the shorewall instance of 192.168.1.254 I had that Kp didn't.) Of course I cannot just edit the "up ip" line to read: up ip route add 192.168.1.254 dev eth0 since that modem IP conflicts with Leaf router IP so this doesn't work. I can't access the modem config screen from my computer bwhen using the Leaf router. I am pretty sure I could solve the problem by changing all instances of 192.168.1.254 to something else, e.g. 192.168.1.253. This may all be pretty silly, because the new Motorola 3360 has a much less full featured setup screen than the old Westell 2200, plus it takes all of 15 seconds to unhook and rehook two wires to access the configuration. In any case, from your answer, I take it there aren't any complications. Yes, I have a 192.168.1.254 in my hosts file. The shorewall line was: shorewall/masq:+eth0::192.168.1.1 0.0.0.0/0 192.168.1.254 which was a firewall rule added to allow access to the old modem via 192.168.1.1. This pretty much exhausts the subject. Now I need to decide what to do! (later) I changed 192.168.1.254 to 192.168.1.253 in network/interfaces, shorewall/masq, and hosts, and changed two instances of 192.168.1.1 in interfaces and masq to 192.168.1.254, and voila! I can access the modem via 192.168.1.254! Webconf still works, only it is at 192.168.1.253:8080! All is well! I found the information about accessing the modem config screen via eth0 in various now-forgotten sources, probably mainly the shorewall docs. I should probably write this up and add it to the wiki, since I would think others might enjoy making their modem more easily accessible from their local network. Thanks again! Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
