Re: [Leaf-user] LEAF routing private IP space

[Matt Schalit]

Ray Olszewski wrote:
> 
>  We need a FAQ answer for this one too (or do we have one?).
> 
> LEAF basic firewalls by default block ALL private-address traffic on the
> external interface. (At least Dachstein and Eigerstein do, and I think
> Oxygen is the same in that regard.)

Nope.  Oxygen has zero ipchains rules by default.
In fact, you'd be hard pressed to even find ipchains
on the boot diskette :)

But then again, it's meant to load from more than
one diskette, network, cdrom, ftp, tftp, whatever.
You can squeeze ipchains.lrp on the first diskette
though.  But that's another thread.

As far as Greg's question goes, he's done a good
job so far and made a good post.  But he left
out a few things like the output of

   [ which ipchains ] && ipchains -L -v -n || echo "Doh!"
lsmod 
which ipmasqadm

I realize that's along the lines of your post, though :)
We just don't know if he's even has ipchains yet.

(And the arp cache listing from the 192.168.1.50 would help
along with the exact failed ping output.)

Best,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] crontab vs /etc/cron.d/multicron

[Matt Schalit]

David Douthitt wrote:
> 
> On 2/5/02 at 10:56 AM, Matt Schalit <[EMAIL PROTECTED]> wrote:
> 
> > Secondly this whole discussion about setting the date
> > is a waste of time until David replaces the broken busybox
> > date with a working date binary.  What good is it to set
> > the clock with atomic precision when date doesn't even know
> > the difference between GMT and EST?
> 
> I don't program busybox.  I don't control busybox.  I didn't write
> busybox or the busybox date command.

I know.  And I remember seeing the post you cc'd to this list
from the busybox maintainer who told us of the broken date.
I was suggestion you make available a working date.lrp as a 
package to replace the busybox one.


> The "broken date" is only in the reporting of the timezone, as I
> remember.  If the system is set correctly, it doesn't matter.  rdate,
> ntpdate, hwclock - they all work just fine - and two of them are in
> busybox.  As a matter of fact - hwclock is not.


I disagree.  Hwclock does not function just fine because it's
functionality is affected by the broken date it uses as described 
in the man page I quoted in my other post.  I guess you could
say that's not hwclock's fault and that it's doing what it's
been told to do by a broken date, but it's late and I may be
drifting.


 
> > Most programs get the
> > date and time wrong, while the other half log with a shifted
> > timestamp?  The syslog goes kablooie.  You have no idea when
> > anything happened.
> 
> The programs that get the time wrong are their own problems (not
> problems with date) - syslogd, for example, is the full version.

Syslogd respects the system clock, and when it can't be set properly
via a call to a remote date server, then the problems have started.
The system clock and hardware clock and rdate refuse to all agree.  
Yet I can set this up perfectly in Dachstein or in Lrp 2.9.8.  
I thought I used to be able to get Oxygen to work perfectly, I think 
in May2001.  That's part of why this has been frustrating.  Don't
you remeber all the work we did getting the hwclock.sh script hashed
out and it was all perfect ( I think in a devel img ).  But then you and
I drifted away from working on Oxygen when I went on vacation and
when the next release of Oxygen came out a couple of months later,
the hwclock.sh fixes had reverted back to the old buggy ones and
then 2.1.3 and busybox updates and it was never the same again :-/



> ssmtp is ssmtp - if it gets the date wrong, it is its own fault as
> long as the timezones are set correctly.  Make sure TZ is set and
> /etc/localtime points to a file that exists and is correct.

Lord knows I've done that a gazillion times.  Remember when I pointed
out to CS that his web server was transferring the 1000 byte PST8PDT
file as ascii and it was ending up as 1005 bytes because he had left
his web server defaulting to ascii (messes up .lrp transfers).
Plus I can make this work without incident on other distros.


 
> In my mind, the TZ environment variable should be all that is required
> - but it would appear things are not that way any more.  It used to be
> simple... someone had to muck it up.

Well maybe the hwclock man page sheds some light in that is says
we must call hwclock --hctosys in order to initialize TZ into
the kernel.


 
> At worst - things are either in GMT or in localtime.  Period.

Not entirely.  When all my clocks are set for localtime, rdate
reports a shifted value when I'm sure the rdate servers isn't.
Plus syslog get's it wrong.  So the kludge "things are in localtime"
doesn't work completely.  The value could shift either way.  The
time subsystems do not behave sanely (as you other post mentions :-)

 
> If it's really bad - forget timezones and set the system hardware time
> to local time, not GMT.

That's what I always do (though I've tried every other combination
I can think of to be thorough).

Regards,
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] LEAF routing private IP space

[David Douthitt]

On 2/6/02 at 11:13 PM, Greg R <[EMAIL PROTECTED]> wrote:

> The LEAF Router is running Oxygen 1.8.

You didn't say what firewall you were using.  Dachstein and Eigerstein
have their firewall scripts; Oxygen relies on add on packages like
Echowall, Seawall, or rcf.

> My symptoms are these: from the LEAF router I
> can ping all of the devices on the local netork
> as well as the greater Internet. However from the
> workstation I can only ping as far as the external
> (eth0 - 192.168.68.254) interface of the LEAF
> router. I can not hit the internal interface of the
> DSL router.

As was mentioned, "can't ping" can mean four different things; how did
ping fail?

I can think of several things to check:

* Is ICMP allowed outside the firewall?
* Is eth0 really the outside interface?  Are you sure?
* Oxygen by default refuses to answer pings on its interfaces

Things to try:

* When you ping a DNS location (such as www.apple.com or
www.sourceforge.net) does the name resolve?
* If the name does resolve, do you get a ping?
* Try telnet instead.  If you get instant refusal (or acceptance!),
then there is connectivity to that machine.  If telnet hangs for a
LOOONG time (3 min) and then works - you don't have DNS.  If telnet
hangs and times out with no connection - you have no connectivity.
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] help with dhcp client internet setup

[Vic Berdin]

Hello all,
 
My box is running dachstein with dhcpd.lrp and 
dhclient.lrp. 
My preferred setup is:
 
Internet connection device:
ttyS0 ---> ppp dialup to an ISP
eth0 > external network with internet/or DSL 
ISP
 
dhcp client device:
eth1 > dhcp clients
 
The services that I've already managed to make 
work are:
1. DHCP server is already up.
2. ttyS0 dialup to an ISP is already 
working via ppp0
3. eth0 internet connection is also 
working
 
I'm sure that my internet hookups are working fine 
because
I can traceroute into known internet sites. And the 
way ppp0 
internet connection 
takes over the eth0 net connection is 

just fine with me.
 
Now my problem is, how to make my dhcp clients 
connect
to the net using which ever internet service 
is up on the box.
 
I bring up both eth0(192.168.1.211) and 
eth1(192.168.2.211) 
in network.conf. They have the same masklens 
(24), 
eth0GW is correct (as it can connect to the outer 
network layer 
and it's internet), but I'm not really sure 
what to use for
eth1's GW (I've tried using eth0's IP as 
eth1's GW -- don't
know what to do really).
 
Does this problem has something to do with fixing my ipchains?
If so, or otherwise, please give me a hint on how to make my
dhcp client machines access the internet using eth0 and ppp0.
 
And also, I've already managed to configure ttyS1 
as a dial-in port
to my box. I would also like to give internet 
access to this dial-in
port.
 
 
TIA!
 

[Leaf-user] How to find out the current masq timeout values?

[Ryan P. Matijcio]

I can’t seem to figure out a way to do this, and was hoping
someone on the list might know.  Is
there a way to display what the current masq timeouts
are set to?   

 

-R.

Re: [Leaf-user] Rebuilding the Dachstein CD

[Charles Steinkuehler]

> Charles I hate to bother again about this. I configured my router, backing
> up changes on the floppy of course, and I figured I would burn a bootable
CD
> using my newly configured floppy as the reference for the boot info on the
> CD (NERO gotta dig it). Any hoot I fired it up with just the CD expecting
it
> to all run from the CD (I like the speed of having just the CD) but
> somewhere in the middle of it's bootin' up it taps on the floppy lookin'
for
> somethin' there, when all is said and done the router is up and the
modules
> are loaded (as far as I can tell TCPDUMP and whatnot) but it isn't pullin'
> and addresses on the NICs. The only thing I can think of as to a reason
why
> it would look for a floppy while it's booting is because I changed I
believe
> three items in the backup menu to partial backup to FD0. Other than that I
> can think of no other reason. Once again sorry for takin' some of yer time
> with this, I appreciate your prompt response.

* Make sure you're doing FULL backups of packages to the floppy, and replace
the default CD-ROM packages with your new, modified ones when burning the
CD.

* The floppy will still be the default place the CD looks for writable
config information, so the floppy will be 'hit' on boot, to see if it
contains any packages that need to be loaded.

* If you really want to, you can remove the pkgpath varilable from the
floppy boot-image syslinux.cfg, and change the boot= device to your CD-ROM
drive.  This will stop the system from hitting the floppy, but will make it
impossible to change your configuration or automatically load any other
packages w/o burning a new CD.

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] Re: LEAF routing private IP space

[Greg R]

Thank you Matt & David for you replies.

Let me see if I can provide some more information for you.

I do not have any firewall enabled, nor is ipchains installed - the router
is wide open. eth0 is the outside interface - I am sure. From the router I
can ping anything anywhere, by IP and by FQDN.

I have enabled both interfaces to respond to ICMP, and like I said in my
first post I can ping both of the interfaces (eth0 & eth1) from the router
itself, I can ping the external interface (eth0) from the DSL router in
front of it, and I can ping the internal interface (eth1) from the
workstation behind it.

When I say that ping "fails" when I attempt to ping the internal interface
of the DSL router from the workstation behind the LEAF router I mean that
there is 100% packet loss - in other words ping just sits there until I
issue an interrupt at which point is shows the following message:

workstation:/root # ping 192.168.68.1
PING 192.168.68.1 (192.168.68.1): 56 data bytes

--- 192.168.68.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


Here is the output of the commands you requested:

# lsmod
Module  Size  Used by
ip_masq_autofw  2432   0 (unused)
ip_masq_portfw  2416   0 (unused)
smc-ultra   4168   2
83906340   0 [smc-ultra]

#which ipmasqadm
/usr/sbin/ipmasqadm

Please let me know if there is more info I can include in the
troubleshooting report and thanks for all your attention so far.

Greg R


--- Matt Schalit <[EMAIL PROTECTED]> wrote:
> Ray Olszewski wrote:
> >
> >  We need a FAQ answer for this one too (or do we have one?).
> >
> > LEAF basic firewalls by default block ALL private-address traffic on
> the
> > external interface. (At least Dachstein and Eigerstein do, and I think
> > Oxygen is the same in that regard.)
>
> Nope.  Oxygen has zero ipchains rules by default.
> In fact, you'd be hard pressed to even find ipchains
> on the boot diskette :)
>
> But then again, it's meant to load from more than
> one diskette, network, cdrom, ftp, tftp, whatever.
> You can squeeze ipchains.lrp on the first diskette
> though.  But that's another thread.
>
> As far as Greg's question goes, he's done a good
> job so far and made a good post.  But he left
> out a few things like the output of
>
>[ which ipchains ] && ipchains -L -v -n || echo "Doh!"
> lsmod
> which ipmasqadm
>
> I realize that's along the lines of your post, though :)
> We just don't know if he's even has ipchains yet.
>
> (And the arp cache listing from the 192.168.1.50 would help
> along with the exact failed ping output.)
>
> Best,
> Matthew
~

__
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Re: LEAF routing private IP space

[guitarlynn]

On Thursday 07 February 2002 11:12, Greg R wrote:
> Thank you Matt & David for you replies.
>
> Let me see if I can provide some more information for you.
>
> I do not have any firewall enabled, nor is ipchains installed - the
> router is wide open. eth0 is the outside interface - I am sure. From
> the router I can ping anything anywhere, by IP and by FQDN.

You need to install the ipchains package and enable forwarding, 
preferrably with one of the firewalling add-ons (shorewall, echowall,
or rc.firewall).

Your just not forwarding anything _through_ the router.

-- 

~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!

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Re: LEAF routing private IP space

[Phillip . Watts]

  But you didn't say if you could ping the DSL router from the LEAF router
(or anywhere else)
Does the DSL router respond to ping?   probably does
You said you can ping anywhere from LEAF so icmp is probably enabled
in proc/sys/net/ipv4.
I assume forwarding is enabled.

FOR ME, that only leaves that your DSL router doesn't have a route to
your internal net.  You said you have no firewall, I assumes that means
no NAT, so the DSL router needs a route to you.






Greg R <[EMAIL PROTECTED]> on 02/07/2002 11:12:15 AM

To:   [EMAIL PROTECTED]
cc:   [EMAIL PROTECTED] (bcc: Phillip Watts/austin/Nlynx)

Subject:  [Leaf-user] Re: LEAF routing private IP space



Thank you Matt & David for you replies.

Let me see if I can provide some more information for you.

I do not have any firewall enabled, nor is ipchains installed - the router
is wide open. eth0 is the outside interface - I am sure. From the router I
can ping anything anywhere, by IP and by FQDN.

I have enabled both interfaces to respond to ICMP, and like I said in my
first post I can ping both of the interfaces (eth0 & eth1) from the router
itself, I can ping the external interface (eth0) from the DSL router in
front of it, and I can ping the internal interface (eth1) from the
workstation behind it.

When I say that ping "fails" when I attempt to ping the internal interface
of the DSL router from the workstation behind the LEAF router I mean that
there is 100% packet loss - in other words ping just sits there until I
issue an interrupt at which point is shows the following message:

workstation:/root # ping 192.168.68.1
PING 192.168.68.1 (192.168.68.1): 56 data bytes

--- 192.168.68.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


Here is the output of the commands you requested:

# lsmod
Module  Size  Used by
ip_masq_autofw  2432   0 (unused)
ip_masq_portfw  2416   0 (unused)
smc-ultra   4168   2
83906340   0 [smc-ultra]

#which ipmasqadm
/usr/sbin/ipmasqadm

Please let me know if there is more info I can include in the
troubleshooting report and thanks for all your attention so far.

Greg R


--- Matt Schalit <[EMAIL PROTECTED]> wrote:
> Ray Olszewski wrote:
> >
> >  We need a FAQ answer for this one too (or do we have one?).
> >
> > LEAF basic firewalls by default block ALL private-address traffic on
> the
> > external interface. (At least Dachstein and Eigerstein do, and I think
> > Oxygen is the same in that regard.)
>
> Nope.  Oxygen has zero ipchains rules by default.
> In fact, you'd be hard pressed to even find ipchains
> on the boot diskette :)
>
> But then again, it's meant to load from more than
> one diskette, network, cdrom, ftp, tftp, whatever.
> You can squeeze ipchains.lrp on the first diskette
> though.  But that's another thread.
>
> As far as Greg's question goes, he's done a good
> job so far and made a good post.  But he left
> out a few things like the output of
>
>[ which ipchains ] && ipchains -L -v -n || echo "Doh!"
> lsmod
> which ipmasqadm
>
> I realize that's along the lines of your post, though :)
> We just don't know if he's even has ipchains yet.
>
> (And the arp cache listing from the 192.168.1.50 would help
> along with the exact failed ping output.)
>
> Best,
> Matthew
~

__
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

___
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

[Leaf-user] Dachstein CD, LaBrea IP addresses

[William Brinkman]

Being rather new at this I have what is a beginner
question.

LaBrea option on the D-CD will trap port scanner (like
Code Red worm) on "virtual" machines to keep them from
bothering other computers.  From what I understand in
the documentation, LaBrea will examine your
sub-network and select non-used ip addresses to use as
the 
"virtual" machine.

I am using the Dachstein firewall with a DSL for my
home and the only sub-net I have is the 192.168.x.x. 
Will LaBrea still function with this "protected" group
of ip addresses or is it truly suited to working with
sub-nets of REAL ip addresses?

Thanks for the help.  

__
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Re: LEAF routing private IP space

[Ray Olszewski]

At 09:12 AM 2/7/02 -0800, Greg R wrote:
>Thank you Matt & David for you replies.
>
>Let me see if I can provide some more information for you.
>
>I do not have any firewall enabled, nor is ipchains installed - the router
>is wide open. eth0 is the outside interface - I am sure. From the router I
>can ping anything anywhere, by IP and by FQDN.

Oh. If you literally "do not have any firewall enabled" or "ipchains
installed", then you do not have NAT (IP Masq) enabled, since it is the
forward chain of the ipchains ruleset that handles NAT. As a result, the
packets from the LAN (probably) go out just fine, but return packets from
off-LAN don't arrive because outside devices (the DSL router itself and the
Internet in general) don't know that your router is their route to
192.168.1.0/24 (they don't know this quite properly; "private address"
*means* unroutable, requiring NAT to work).

To make this setup work, you must install ipchains and, at a bare minimum,
add a rule that MASQs the internal network.

I've deleted the rest of your message because as you describe your setup,
this omission is almost certainly your problem. The easiest solution is to
add one of the drop-in firewall packages that David suggested in the e-mail
he sent last night.


--
"Never tell me the odds!"---
Ray Olszewski-- Han Solo
Palo Alto, CA[EMAIL PROTECTED]



___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] LEAF routing private IP space

[Greg R]

Yes, the DSL router responds to ping on it's internal interface. Yes ICMP
is enabled and yes forwarding is enabled.

Maybe something very fundamental I am missing here - does the Oxygen
release 1.8 not set up the router to perform NAT between interfaces eth0 &
eth1 by default? I am working on the assumption that it is, but if all it
is doing is routing, then of course - i am missing a route on the DSL
router.

Greg R


--- [EMAIL PROTECTED] wrote:
> 
> 
>   But you didn't say if you could ping the DSL router from the LEAF
> router
> (or anywhere else)
> Does the DSL router respond to ping?   probably does
> You said you can ping anywhere from LEAF so icmp is probably enabled
> in proc/sys/net/ipv4.
> I assume forwarding is enabled.
> 
> FOR ME, that only leaves that your DSL router doesn't have a route to
> your internal net.  You said you have no firewall, I assumes that means
> no NAT, so the DSL router needs a route to you.
> 
> 
> 
> 
> 
> 
> Greg R <[EMAIL PROTECTED]> on 02/07/2002 11:12:15 AM
> 
> To:   [EMAIL PROTECTED]
> cc:   [EMAIL PROTECTED] (bcc: Phillip Watts/austin/Nlynx)
> 
> Subject:  [Leaf-user] Re: LEAF routing private IP space
> 
> 
> 
> Thank you Matt & David for you replies.
> 
> Let me see if I can provide some more information for you.
> 
> I do not have any firewall enabled, nor is ipchains installed - the
> router
> is wide open. eth0 is the outside interface - I am sure. From the router
> I
> can ping anything anywhere, by IP and by FQDN.
> 
> I have enabled both interfaces to respond to ICMP, and like I said in my
> first post I can ping both of the interfaces (eth0 & eth1) from the
> router
> itself, I can ping the external interface (eth0) from the DSL router in
> front of it, and I can ping the internal interface (eth1) from the
> workstation behind it.
> 
> When I say that ping "fails" when I attempt to ping the internal
> interface
> of the DSL router from the workstation behind the LEAF router I mean that
> there is 100% packet loss - in other words ping just sits there until I
> issue an interrupt at which point is shows the following message:
> 
> workstation:/root # ping 192.168.68.1
> PING 192.168.68.1 (192.168.68.1): 56 data bytes
> 
> --- 192.168.68.1 ping statistics ---
> 3 packets transmitted, 0 packets received, 100% packet loss
> 
> 
> Here is the output of the commands you requested:
> 
> # lsmod
> Module  Size  Used by
> ip_masq_autofw  2432   0 (unused)
> ip_masq_portfw  2416   0 (unused)
> smc-ultra   4168   2
> 83906340   0 [smc-ultra]
> 
> #which ipmasqadm
> /usr/sbin/ipmasqadm
> 
> Please let me know if there is more info I can include in the
> troubleshooting report and thanks for all your attention so far.
> 
> Greg R
> 
> 
> --- Matt Schalit <[EMAIL PROTECTED]> wrote:
> > Ray Olszewski wrote:
> > >
> > >  We need a FAQ answer for this one too (or do we have one?).
> > >
> > > LEAF basic firewalls by default block ALL private-address traffic on
> > the
> > > external interface. (At least Dachstein and Eigerstein do, and I
> think
> > > Oxygen is the same in that regard.)
> >
> > Nope.  Oxygen has zero ipchains rules by default.
> > In fact, you'd be hard pressed to even find ipchains
> > on the boot diskette :)
> >
> > But then again, it's meant to load from more than
> > one diskette, network, cdrom, ftp, tftp, whatever.
> > You can squeeze ipchains.lrp on the first diskette
> > though.  But that's another thread.
> >
> > As far as Greg's question goes, he's done a good
> > job so far and made a good post.  But he left
> > out a few things like the output of
> >
> >[ which ipchains ] && ipchains -L -v -n || echo "Doh!"
> > lsmod
> > which ipmasqadm
> >
> > I realize that's along the lines of your post, though :)
> > We just don't know if he's even has ipchains yet.
> >
> > (And the arp cache listing from the 192.168.1.50 would help
> > along with the exact failed ping output.)
> >
> > Best,
> > Matthew


__
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] Any one using the DCD1.02 with

[Victor McAllister]

I wonder who has tried the new dachstein-1.0.2-glibc-2.1.3.iso
which is found here:
 http://leaf.sourceforge.net/devel/kapeka/lrp-packages.html

It should only require a reboot without making any changes to the
floppy with the .conf files.  In other words it should be a painless
experience only needing to burn a new CD.
Some of the things the Cd contains in addition to Charles' packages

xntpd.lrp  - ntp from Todd Horsman
seawall-lrp - seawall 4.0.1 from Tom Eastep
rexx.lrp  - REXX scripting language based on Regina
keyboard.lrp  - package supporting 45 different kmaps
tz.lrp  - timezones for lrp boxes (more need to be added)
isdn.lrp  - where did I found this package for ISDN??
lua.lrp - lua scripting language packaged by David Douthitt
ntpclient.lrp  - packaged by David Douthitt
snort.lrp  - v 1.7 packaged by David Douthitt
libm.lrp - updated to glibc 2.1.3
libz.lrp  - updated to glibc 2.1.3
squid-2.lrp - updated to squid-2.4Stable and build with glibc 2.1.3
(user squid added to passwd/shadow)
perl5.lrp  - David's package updated to glibc 2.1.3 and removed
libm.so
python.lrp - David's package updated to glibc 2.1.3 and removed
libm.so

I hate to reboot my router when the uptime is already at 2 months -
like to hear some feedback from those who have tried it.
--
Victor McAllister



___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] DCD firewall, except 1 unprotected interface ???

[Michael D. Schleif]

What is the best way to setup this scenario:

eth0 -- internet
eth1 -- LAN, firewall protected
eth2 -- DMZ, typical
eth3 -- LAN, public IP, *NO* firewall

What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Re: LEAF routing private IP space

[Jeff Newmiller]

On Thu, 7 Feb 2002, Ray Olszewski wrote:

> At 09:12 AM 2/7/02 -0800, Greg R wrote:
> >Thank you Matt & David for you replies.
> >
> >Let me see if I can provide some more information for you.
> >
> >I do not have any firewall enabled, nor is ipchains installed - the router
> >is wide open. eth0 is the outside interface - I am sure. From the router I
> >can ping anything anywhere, by IP and by FQDN.
> 
> Oh. If you literally "do not have any firewall enabled" or "ipchains
> installed", then you do not have NAT (IP Masq) enabled, since it is the
> forward chain of the ipchains ruleset that handles NAT. As a result, the
> packets from the LAN (probably) go out just fine, but return packets from
> off-LAN don't arrive because outside devices (the DSL router itself and the
> Internet in general) don't know that your router is their route to
> 192.168.1.0/24 (they don't know this quite properly; "private address"
> *means* unroutable, requiring NAT to work).

I disagree with the explanation, though not the advice. "Private address"  
means that no public routers will enter it into their routing tables...
those IP numbers are just as routable as any other numbers within your
organization.  This point is confusing to many newbies... it certainly was
for me.

The place it makes a difference is in the "modem", which was providing NAT
services to 192.168.68.0.  If you could modify its routing table to route
through 192.168.68.1 to arrive at 192.168.1.0/24, and NAT 192.168.1.0/24
as well as 192.168.68.0/24, you would be fine.  The problem is that boxes
like that are not usually so configurable, so Ray's advice below is indeed
a straightforward approach... the "modem" would only think there was one
address to deal with.

A different approach might be to use a bridging or proxy-arp
configuration, and omit the 192.168.1.0/24 network entirely.  Without a
firewall, there isn't much reason to bother having the LEAF box here, so I
would assume that is part of the eventual goal. Unlike Ray's solution, I
don't know of a firewall script that does this out-of-the-box... I set one
up manuallly last year.

> To make this setup work, you must install ipchains and, at a bare minimum,
> add a rule that MASQs the internal network.
> 
> I've deleted the rest of your message because as you describe your setup,
> this omission is almost certainly your problem. The easiest solution is to
> add one of the drop-in firewall packages that David suggested in the e-mail
> he sent last night.

---
Jeff NewmillerThe .   .  Go Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#.   ##.#.  Live Go...
  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.  rocks...2k
---


___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Any one using the DCD1.02 with

[Mike Noyes]

At 2002-02-07 10:12 -0800, Victor McAllister wrote:
>I wonder who has tried the new dachstein-1.0.2-glibc-2.1.3.iso
>which is found here:
>  http://leaf.sourceforge.net/devel/kapeka/lrp-packages.html

Victor,
I dropped the ball on this one. KP announced this iso a while ago, and I 
forgot to announce it on our home page.

KP,
I'll try to get an article posted today.

--
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf.sourceforge.net/content.php?menu=1000&page_id=4


___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Re: LEAF routing private IP space

[Ray Olszewski]

At 10:15 AM 2/7/02 -0800, Jeff Newmiller wrote:
[...]
>> 192.168.1.0/24 (they don't know this quite properly; "private address"
>> *means* unroutable, requiring NAT to work).
>
>I disagree with the explanation, though not the advice. "Private address"  
>means that no public routers will enter it into their routing tables...
>those IP numbers are just as routable as any other numbers within your
>organization.  This point is confusing to many newbies... it certainly was
>for me.

Jeff makes the right technical distinction here. I should have been more
specific -- they will be unroutable on the public Internet, by
convention/standard. 

With respect to a private network, you can never make ANY assumptions about
routing of ANY addresses, public or private, since all depends on what the
network administrator set up in the network's routing tables. You simply
have to find out (or set it up right, if you are the netadmin).

>The place it makes a difference is in the "modem", which was providing NAT
>services to 192.168.68.0.  

Maybe. From what Greg actually reported, all we actually *know* is that the
DSL router has a route to 192.168.68.1. This *may* be through support of
192.168.68.0/24. Or it *may* be a /32 point-to-point route. Or it may be
under Greg's control (use of the "68" subnet is uncommon, making me like
this possibility), in which case it is whatever he made (or in the future
makes) it. We have no way of knowing.

With that caveat, either of Jeff's suggestions below could work ... the
first if Greg can configure the DSL router's interfaces and routes, the
second if Jeff has guessed right about the DSL router's current routing table.

>If you could modify its routing table to route
>through 192.168.68.1 to arrive at 192.168.1.0/24, and NAT 192.168.1.0/24
>as well as 192.168.68.0/24, you would be fine.  The problem is that boxes
>like that are not usually so configurable, so Ray's advice below is indeed
>a straightforward approach... the "modem" would only think there was one
>address to deal with.
>
>A different approach might be to use a bridging or proxy-arp
>configuration, and omit the 192.168.1.0/24 network entirely.  Without a
>firewall, there isn't much reason to bother having the LEAF box here, so I
>would assume that is part of the eventual goal. Unlike Ray's solution, I
>don't know of a firewall script that does this out-of-the-box... I set one
>up manuallly last year.
[...]


--
"Never tell me the odds!"---
Ray Olszewski-- Han Solo
Palo Alto, CA[EMAIL PROTECTED]



___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] LEAF routing private IP space

[Phillip . Watts]

I use Eigerstein.
  In network.conf there is a setting  MASQ=YES
What this does, in ipfilter.conf, is turn on a  masquerading rule.

If your config is entirely different from this then you need a single command

ipchains -A forward -j MASQ  -p all  -s 192.  . 0/24(internal net) -d  ! 192.  .
0/24(internal netl)

i.e   add a rule to the forward chain to send to MASQ all protocols
  FROM  the internal net  TO NOT the internal net

You can enter this from the command line for now.

Otherwise your DSL router will have to have a route to you.





Greg R <[EMAIL PROTECTED]> on 02/07/2002 11:50:06 AM

To:   [EMAIL PROTECTED]
cc:(bcc: Phillip Watts/austin/Nlynx)

Subject:  Re: [Leaf-user] LEAF routing private IP space



Yes, the DSL router responds to ping on it's internal interface. Yes ICMP
is enabled and yes forwarding is enabled.

Maybe something very fundamental I am missing here - does the Oxygen
release 1.8 not set up the router to perform NAT between interfaces eth0 &
eth1 by default? I am working on the assumption that it is, but if all it
is doing is routing, then of course - i am missing a route on the DSL
router.

Greg R


--- [EMAIL PROTECTED] wrote:
>
>
>   But you didn't say if you could ping the DSL router from the LEAF
> router
> (or anywhere else)
> Does the DSL router respond to ping?   probably does
> You said you can ping anywhere from LEAF so icmp is probably enabled
> in proc/sys/net/ipv4.
> I assume forwarding is enabled.
>
> FOR ME, that only leaves that your DSL router doesn't have a route to
> your internal net.  You said you have no firewall, I assumes that means
> no NAT, so the DSL router needs a route to you.
>
>
>
>
>
>
> Greg R <[EMAIL PROTECTED]> on 02/07/2002 11:12:15 AM
>
> To:   [EMAIL PROTECTED]
> cc:   [EMAIL PROTECTED] (bcc: Phillip Watts/austin/Nlynx)
>
> Subject:  [Leaf-user] Re: LEAF routing private IP space
>
>
>
> Thank you Matt & David for you replies.
>
> Let me see if I can provide some more information for you.
>
> I do not have any firewall enabled, nor is ipchains installed - the
> router
> is wide open. eth0 is the outside interface - I am sure. From the router
> I
> can ping anything anywhere, by IP and by FQDN.
>
> I have enabled both interfaces to respond to ICMP, and like I said in my
> first post I can ping both of the interfaces (eth0 & eth1) from the
> router
> itself, I can ping the external interface (eth0) from the DSL router in
> front of it, and I can ping the internal interface (eth1) from the
> workstation behind it.
>
> When I say that ping "fails" when I attempt to ping the internal
> interface
> of the DSL router from the workstation behind the LEAF router I mean that
> there is 100% packet loss - in other words ping just sits there until I
> issue an interrupt at which point is shows the following message:
>
> workstation:/root # ping 192.168.68.1
> PING 192.168.68.1 (192.168.68.1): 56 data bytes
>
> --- 192.168.68.1 ping statistics ---
> 3 packets transmitted, 0 packets received, 100% packet loss
>
>
> Here is the output of the commands you requested:
>
> # lsmod
> Module  Size  Used by
> ip_masq_autofw  2432   0 (unused)
> ip_masq_portfw  2416   0 (unused)
> smc-ultra   4168   2
> 83906340   0 [smc-ultra]
>
> #which ipmasqadm
> /usr/sbin/ipmasqadm
>
> Please let me know if there is more info I can include in the
> troubleshooting report and thanks for all your attention so far.
>
> Greg R
>
>
> --- Matt Schalit <[EMAIL PROTECTED]> wrote:
> > Ray Olszewski wrote:
> > >
> > >  We need a FAQ answer for this one too (or do we have one?).
> > >
> > > LEAF basic firewalls by default block ALL private-address traffic on
> > the
> > > external interface. (At least Dachstein and Eigerstein do, and I
> think
> > > Oxygen is the same in that regard.)
> >
> > Nope.  Oxygen has zero ipchains rules by default.
> > In fact, you'd be hard pressed to even find ipchains
> > on the boot diskette :)
> >
> > But then again, it's meant to load from more than
> > one diskette, network, cdrom, ftp, tftp, whatever.
> > You can squeeze ipchains.lrp on the first diskette
> > though.  But that's another thread.
> >
> > As far as Greg's question goes, he's done a good
> > job so far and made a good post.  But he left
> > out a few things like the output of
> >
> >[ which ipchains ] && ipchains -L -v -n || echo "Doh!"
> > lsmod
> > which ipmasqadm
> >
> > I realize that's along the lines of your post, though :)
> > We just don't know if he's even has ipchains yet.
> >
> > (And the arp cache listing from the 192.168.1.50 would help
> > along with the exact failed ping output.)
> >
> > Best,
> > Matthew


__
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] How can I implement system generated email messages?

[JMullan]

I have seen reference to LRP generating email messages to the administrator
upon certain events.  I think perhaps this was in respect to logs.


Is there a tutorial on how to implement this kind of functionality (but not
limited to just logs)??


John





___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] LEAF routing private IP space

[Matt Schalit]

Greg R wrote:
> 
> Yes, the DSL router responds to ping on it's internal interface. Yes ICMP
> is enabled and yes forwarding is enabled.
> 
> Maybe something very fundamental I am missing here - does the Oxygen
> release 1.8 not set up the router to perform NAT between interfaces eth0 &
> eth1 by default? I am working on the assumption that it is, but if all it
> is doing is routing, then of course - i am missing a route on the DSL
> router.
> 
> Greg R
> 


> > Thank you Matt & David for you replies.
> >
> > Let me see if I can provide some more information for you.
> >
> > I do not have any firewall enabled, nor is ipchains installed - the
> > router
> > is wide open. eth0 is the outside interface - I am sure. From the router
> > I
> > can ping anything anywhere, by IP and by FQDN.


You need ipchains to masq you internal net.  

Put the ipchains.lrp package onto one of your disks and have it 
load with the others.Then get to a command prompt and type:

  ipchains -A forwared -j MASQ -s 192.168.1.0/24


Then consider installing rcf, pfw, Seawall, Shorewall, or Echowall
for you firewall needs (or do it yourself using those as examples).

Regards,
Matthew




> > I have enabled both interfaces to respond to ICMP, and like I said in my
> > first post I can ping both of the interfaces (eth0 & eth1) from the
> > router
> > itself, I can ping the external interface (eth0) from the DSL router in
> > front of it, and I can ping the internal interface (eth1) from the
> > workstation behind it.
> >
> > When I say that ping "fails" when I attempt to ping the internal
> > interface
> > of the DSL router from the workstation behind the LEAF router I mean that
> > there is 100% packet loss - in other words ping just sits there until I
> > issue an interrupt at which point is shows the following message:
> >
> > workstation:/root # ping 192.168.68.1
> > PING 192.168.68.1 (192.168.68.1): 56 data bytes
> >
> > --- 192.168.68.1 ping statistics ---
> > 3 packets transmitted, 0 packets received, 100% packet loss
> >
> >
> > Here is the output of the commands you requested:
> >
> > # lsmod
> > Module  Size  Used by
> > ip_masq_autofw  2432   0 (unused)
> > ip_masq_portfw  2416   0 (unused)
> > smc-ultra   4168   2
> > 83906340   0 [smc-ultra]
> >
> > #which ipmasqadm
> > /usr/sbin/ipmasqadm


That's all as it should be.  You were just missing ipchains,
and the command I gave you should have output,  "Doh!"

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

RE: [Leaf-user] FTP Timeout Problems with Oxygen

[Ryan P. Matijcio]

Well changing the masq timeout values doesn't to have done anything.
Unfortunately I can't seem to find a status screen that will tell me the
current timeout values so I can verify they have been changed. But as
far as the seawall configuration goes, they are set and the firewall
script has been restarted.  From the testing I've been doing the same
problem is apparent.

One strange thing I've noticed is that doing a netstat -M doesn't make
any output at all when I know it should.  Weird.

Anyways, if anyone has any suggestions I'd love to hear 'em.

Cheers,
Ryan


-Original Message-
From: Jeff Newmiller [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, February 06, 2002 4:35 PM
To: Ryan P. Matijcio
Cc: [EMAIL PROTECTED]
Subject: Re: [Leaf-user] FTP Timeout Problems with Oxygen

On Wed, 6 Feb 2002, Ryan P. Matijcio wrote:

> Hey everyone,
> 
> I've started to notice FTP problems with an Oxygen firewall I have
> running.  The problem occurs on both unix and NT systems located
behind
> the firewall.  I have found that all ftp transfers be they incoming or
> outgoing eventually freeze.  Although it appears that NT -> NT
transfers
> are more stable, they too freeze after about 800-1500 files have been
> transferred.
> 
> The firewall configuration is pretty simple.  It has two 2 ethernet
> interfaces, and proxyarp is being used.  I've included the
seawall.conf
> file below.  One thing about my config is that I do not have any masq
> timeouts specified.  I was wondering if perhaps I should?  
> 
> One thing I've noticed that I think is interesting to note is that
this
> problem does not occur when using LeechFTP.   I believe this because
> LeechFTP tends to keep sending commands to keep the connection active.
> That's why I was wondering if it could have something to do with the
> masq timeouts.

I would say you have the answer, so proceed.

Alternatively, get away from ftp and use ssh/scp/rsync/unison or the
like.

[...]


---
Jeff NewmillerThe .   .  Go
Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#.   ##.#.  Live
Go...
  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.
rocks...2k

---


___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] DCD vs. netsnmpd ???

[Michael D. Schleif]

netsnmpd.lrp (4.2.1-1-CS) from DCD v1.0.2 appears to be broken.

[1] Changes to /etc/snmp/snmpd.conf do *not* affect snmpd. 
Specifically, modifying syscontact and syslocation are *not* accessible
via snmpget nor snmpwalk, &c.

[2] Such (example) changes can be effected if snmpd is started with
args: -c /etc/snmp/snmpd.conf

[3] If arg -c is used, then snmpwalk will not end gracefully; rather:

# snmpwalk -v 1 localhost public system
system.sysDescr.0 = Linux trout 2.2.19-3-LEAF-RAID #4 Sat Dec 1
17:27:59 CST 2001 i486
. . .
system.sysORTable.sysOREntry.sysORUpTime.9 = Timeticks: (5) 0:00:00.05
Timeout: No Response from localhost

[4] In fact, no matter how the default startup is used, any community
string has access to snmpd -- public, private or *none*!

[5] Several attributes allowed here:



like this:

sysname STRING

*fail* on startup (using -c):

# /etc/snmp/snmpd.conf: line 101: Warning: Unknown token: sysname.


What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] New Load Balancing HOWTO posted

[Jack Coates]

http://www.monkeynoodle.org/lrp/LRP-Load-Balancing-HOWTO.html

Somewhere on my todo list (along with updating all the other HOWTOs) is
to CVS all of these into SF...

-- 
Jack Coates
Monkeynoodle: A Scientific Venture...


___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] DCD vs. netsnmpd ???

[Charles Steinkuehler]

> netsnmpd.lrp (4.2.1-1-CS) from DCD v1.0.2 appears to be broken.

It's possible...this was a last minute addition, and is still considered
"experimental".  I intend to switch to netsnmpd (and make some shell-script
reporting agents for ipchains accounting rules), but have yet to do so.



> [1] Changes to /etc/snmp/snmpd.conf do *not* affect snmpd.
>
> [2] Such (example) changes can be effected if snmpd is started with
> args: -c /etc/snmp/snmpd.conf
>
> [3] If arg -c is used, then snmpwalk will not end gracefully; rather:
>
> [4] In fact, no matter how the default startup is used, any community
> string has access to snmpd -- public, private or *none*!
>
> [5] Several attributes allowed here:
>
> 
>
> *fail* on startup (using -c):
>
> What do you think?

Gak!  Sounds like lots of problems...I thought I'd at least tried the
default configuration, but maybe not.  I'll do some tests and report back
(probably take a day or two)...

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] LEAF routing private IP space w/ IPSEC

[Jason C. Leach]

hi,

I have a question on this with a twist.

If I have several nodes connected to a sentral HUB 
via IPSec, how can I route from node A to node B?
Right now, the HUB can ping every node, but nodes
can only pin the HUB.

Thanks,
j.

-- 
..
. Jason C. Leach
.. 

PGP/GPG Public key at http://www.keyserver.net/
Key ID: 1CF6DA85

 

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] Seawall scripts.

[Jason C. Leach]

hi,

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?

Thanks,
j.

-- 
..
. Jason C. Leach
.. 

PGP/GPG Public key at http://www.keyserver.net/
Key ID: 1CF6DA85

 

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Seawall scripts.

[Tim Wegner]

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

Re: [Leaf-user] FTP Timeout Problems with Oxygen

[Matt Schalit]

"Ryan P. Matijcio" wrote:
> 
> Well changing the masq timeout values doesn't to have done anything.

When having ftp problems, it's time to dust off telnet and
brush up on your ftp commands.  You can simulate the ftp client
and get some feedback and see what's working and what's not.

You may need to determine if the command connection is timing out
and if it still works when you have the problem.  It'd help if
you had some cut and paste output of the exact problem and a
repeatable test case.  I have an oxygen distro I can test from.


> Unfortunately I can't seem to find a status screen that will tell me the
> current timeout values so I can verify they have been changed. 

I couldn't find how to get it to tell you the values.
If you set it, you might try a brute force grep through
the proc directory, with care :), and seach for those
values.

I found somewhere that the  -M -S tcp tcpfin udp  style
command defaults to  15min, 2min, 5min.

Are your transferring many small files in rapid succession
or many big files?  How big?




> But as
> far as the seawall configuration goes, they are set and the firewall
> script has been restarted.  From the testing I've been doing the same
> problem is apparent.

Again please post a repeatable test case and description if at
all possible.



 
> One strange thing I've noticed is that doing a netstat -M doesn't make
> any output at all when I know it should.  Weird.

Not even after getting on a masq'd internal computer and surfing the net?
Really?


 
> Anyways, if anyone has any suggestions I'd love to hear 'em.
> 

> I've started to notice FTP problems with an Oxygen firewall I have
> running.  The problem occurs on both unix and NT systems located
> behind the firewall.  I have found that all ftp transfers be they 
> incoming or outgoing eventually freeze.  Although it appears that 
> NT -> NT transfers are more stable, they too freeze after about 
> 800-1500 files have been transferred.


After a certain number of files?  Repeatable?
Are you doing PORT or PASV transfers?

Check that you're not running out of masq ports.
I think there's 4096 ports available on a LEAF
box for masqing outgoing connections.

The ftpd, if serving incoming PASV request from
behind a masq'ing firewall, will only have a certain
number of ports dedicated to the data transfer connection.
If you use too many of them in rapid succession, then some
of them may not be completely "unESTABLISHED", iirc they
may go into some time-out wait state.  I had this exact
problem when I allowed less than 100 ports for incoming
ftpd data connections to my masqd ftpd.   I also recall
that the newer oxygen handled the reuse of ports much
better and that the problem may have gone away.  I think
it was part of the kernel upgrade in the new distro.

So maybe lowering your tcpfin or examining what's
going on in netstat -an.



> One thing I've noticed that I think is interesting to note is that this
> problem does not occur when using LeechFTP.   


Force leech ftp into debugging mode and check what's it's doing
against the ftpd server's syslog to determine what commands,
if any, it's sending on the command channel during a download.
Or do you mean it's sending NOOPs when it's idle?

Also a tcpdump of the LeechFTP commands might be interesting 
if you can't get the info from the syslog.



>I believe this because
> LeechFTP tends to keep sending commands to keep the connection active.
> That's why I was wondering if it could have something to do with the
> masq timeouts.

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Seawall scripts.

[Matt Schalit]

Tim Wegner wrote:
> 

> 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.

Does Seawall clobber the QoS stuff, leave it alone,
or create it's own?  Any lack of QoS would be a downer
and would be noticable in some setups, not all.  It was
nifty that CS put the QoS stuff in there.

Regards,
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

RE: [Leaf-user] Seawall scripts.

[Tom Eastep]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On Behalf Of 
> Matt Schalit
> Sent: Thursday, February 07, 2002 5:24 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Leaf-user] Seawall scripts.
> 
> Does Seawall clobber the QoS stuff, leave it alone,
> or create it's own?  Any lack of QoS would be a downer
> and would be noticable in some setups, not all.  It was
> nifty that CS put the QoS stuff in there.

Seawall doesn't run the 'tc' utility so any queuing disciplines and
classes you have established will survive seawall starting and
restarting. If you are using an fwmark classifier, you should
reestablish your marking rules in /etc/seawall/start.

-Tom



___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Seawall scripts.

[Matt Schalit]

Tom Eastep wrote:
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of
> > Matt Schalit
> > Sent: Thursday, February 07, 2002 5:24 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [Leaf-user] Seawall scripts.
> >
> > Does Seawall clobber the QoS stuff, leave it alone,
> > or create it's own?  Any lack of QoS would be a downer
> > and would be noticable in some setups, not all.  It was
> > nifty that CS put the QoS stuff in there.
> 
> Seawall doesn't run the 'tc' utility so any queuing disciplines and
> classes you have established will survive seawall starting and
> restarting. If you are using an fwmark classifier, you should
> reestablish your marking rules in /etc/seawall/start.
> 
> -Tom


  Ok, I've had so little experience with DF and QoS that I'm 
a bit confused, but not much :)

  Thanks for the reply, btw.  I'm sure you're busy with two
applications and their broad appeal.

  CS made ipchains rules that are part of his QoS approach, 
as evidenced by the output of ipchains -L -v -n having a "fairq" 
chain.  I guess what you mean is that you don't flush the "fairq" 
chain when you flush the other chains (input output forward)?

Thanks,
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

RE: [Leaf-user] Seawall scripts.

[Tom Eastep]

> 
>   CS made ipchains rules that are part of his QoS approach, 
> as evidenced by the output of ipchains -L -v -n having a "fairq" 
> chain.

Which means that he is probably classifying packets in "fairq" by
assigning a mark value.

> I guess what you mean is that you don't flush the "fairq" 
> chain when you flush the other chains (input output forward)?

Correct -- but any rules in input, output and forward that might refer
to fairq are deleted by a "seawall [re]start" command and must be
replaced by user-provided rules in /etc/seawall/start.



-Tom



___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user