Re: [Leaf-user] ppp0 not loading in Dachstein

[Etienne Charlier]

Hi,

First of all, check that those modules are loaded (/etc/modules)
( lrcfg/ menu 3 packages, then select the "modules" entry then 1 to edit the
/etc/modules file )

slhc.o
ppp.o
ppp_deflate.o
bsd_comp.o

Regards,
Etienne

- Original Message -
From: "CaMiX CaMiX" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 6:23 PM
Subject: [Leaf-user] ppp0 not loading in Dachstein


> Seems to me that my problem is that the ppp0 adapter is not installing so
> the pppoe client can't broadcast and just timesout.  I've tried installing
> the ppp.o module manually but get the error:
>
> insmod: unresolved symbol slhc_init
> insmod: unresolved symbol slhc_free
> insmod: unresolved symbol slhc_uncompress
> insmod: unresolved symbol slhc_toss
> insmod: unresolved symbol slhc_remember
> insmod: unresolved symbol slhc_compress
>
> Isn't ppp0 taken care of by the ppp.lrp file? Well, here is my Debug file
> from the adsl-start(view from attachment also):
>
> -
> Fri Dec 21 13:11:10 UTC 2001
> Output of uname -a
> Linux firewall 2.2.19-3-LEAF-RAID #4 Sat Dec 1 17:27:59 CST 2001 i386
> unknown
> -
> Output of ifconfig -a
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   UP LOOPBACK RUNNING  MTU:3924  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>
> ipsec0Link encap:IPIP Tunnel  HWaddr
>   unspec addr:[NONE SET]  Mask:[NONE SET]
>   NOARP  MTU:0  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>
> ipsec1Link encap:IPIP Tunnel  HWaddr
>   unspec addr:[NONE SET]  Mask:[NONE SET]
>   NOARP  MTU:0  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>
> ipsec2Link encap:IPIP Tunnel  HWaddr
>   unspec addr:[NONE SET]  Mask:[NONE SET]
>   NOARP  MTU:0  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>
> ipsec3Link encap:IPIP Tunnel  HWaddr
>   unspec addr:[NONE SET]  Mask:[NONE SET]
>   NOARP  MTU:0  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>
> brg0  Link encap:Ethernet  HWaddr FE:FD:03:00:33:4B
>   unspec addr:[NONE SET]  Bcast:[NONE SET]  Mask:[NONE SET]
>   BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>
> eth0  Link encap:Ethernet  HWaddr 00:81:8F:71:3F:93
>   unspec addr:[NONE SET]  Bcast:[NONE SET]  Mask:[NONE SET]
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:513 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>   Interrupt:11 Base address:0xf000
>
> eth1  Link encap:Ethernet  HWaddr 00:81:8E:F0:11:75
>   inet addr:192.168.1.254  Bcast:192.168.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   Collisions:0
>   Interrupt:10 Base address:0x1000
>
> -
> Output of lsmod
> Module PagesUsed by
> ip_masq_vdolive 1180   0 (unused)
> ip_masq_user3708   0 (unused)
> ip_masq_raudio  2980   0 (unused)
> ip_masq_quake   1220   0 (unused)
> ip_masq_portfw  2416   0 (unused)
> ip_masq_mfw 3196   0 (unused)
> ip_masq_irc 1924   0 (unused)
> ip_masq_ftp 3576   0 (unused)
> ip_masq_cuseeme  964   0 (unused)
> ip_masq_autofw  2476   0 (unused)
> natsemi 8440   2
> pci-scan2300   0 [natsemi]
> isofs  17692   0
> ide-cd 22672   0
> cdrom  26712   0 [ide-cd]
> -
> Output of netstat -n -r
> Kernel IP routing table
> Destination Gateway Genmask Flags   MSS Window  irtt
> Iface
> 192.168.1.0 0.0.0.0 255.255.255.0   U 0 0  0
> eth1
> -
> Contents of /etc/resolv.conf
> # MADE-BY-RP-PPPOE
> nameserver 209.251.129.10
> nameserver 209.251.129.9
> 

Re: [Leaf-user] This is the exact same problem im haveing(RTL8139)(DachsteinCD 1.0.2)

[Jeff Newmiller]

On Fri, 21 Dec 2001, Jim Van Eeckhoutte wrote:

> FROM: Jeff Clark
> 
> 
> DATE: 08/09/2000 17:53:54
> 
> 
> SUBJECT:  [LRP] prob`s with dual rtl8139 cards
>  
> I`m attempting to help a friend set up an LRP box but am having great
> difficulties with the rtl8139 cards he`s using.
>  
> He`s running a Cyrix 686-90mhz w/ 64Mb and 2 rtl8139 based PCI cards.
>  
> He`s set BIOS PNP/PCI settings to NonPNP OS, auto configure resources,
> and
> has performed and ECSD update.
> He`s running the Eiger Dynamic image from Charles` site.
> He has downloaded and added the rtl8139 module from Charle`s site
> (v1.07)
>  
> Here`s the problem: when the LRP reaches the rtl8139 modules during boot
> up,
> the link light on both cards goes out and stays out.  The console shows
> the
> module finding both cards cleanly - good i/o`s and irq`s.  The system
> boots
> up all the way and attempts to to obtain a lease from the DHCP server at
> @home with no luck.

Good io/irq... okay, if you say so.

Then either the drivers are bad (don't recall this problem) or the network
settings are no good.

>  
> He`s tried connecting either of the the cards to a hub and the hub`s
> link
> light is on while the card`s is off.

That is odd.  I would say bad wiring, except for the following...

> He can ping successfully from an NT box to eth1 but can`t ping from the
> LRP
> to the NT box over eth1.

ping requires both ends to be able to route out through those interfaces.

There is a difference between NT ping and LRP ping, though... LRP ping
uses ICMP packets and NT uses UDP packets.  UDP was chosen as an
alternative to ICMP because many firewalls block it.  I don't recall this
being a problem before with Dachstein, though.

>  
> The only way to get the link lights back on is to hard reset the box.

If it ever worked with the light off, maybe the light isn't supposed to be
on. (10BaseT vs 100BaseT?)

> Any suggestions?

Proceed to try to get a lease from ATT.  You may need to enter a special
"hostname" for dhclient to send in its request, or you may need to
power-cycle the cable modem (leave it off for a few minutes).  Or, you may
need to release the lease from the NT box before switching the LRP box in
place.

---
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] ppp0 not loading in Dachstein

[Jeff Newmiller]

On Fri, 21 Dec 2001, CaMiX CaMiX wrote:

> Seems to me that my problem is that the ppp0 adapter is not installing so 
> the pppoe client can't broadcast and just timesout.  I've tried installing 
> the ppp.o module manually but get the error:
> 
> insmod: unresolved symbol slhc_init
> insmod: unresolved symbol slhc_free
> insmod: unresolved symbol slhc_uncompress
> insmod: unresolved symbol slhc_toss
> insmod: unresolved symbol slhc_remember
> insmod: unresolved symbol slhc_compress
> 
> Isn't ppp0 taken care of by the ppp.lrp file?

No, modules are taken care of by modules.lrp.

You need to load slhc.o before ppp.o.

[...]

---
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] PPPd image

[Larry Platzek]

Kenneth,
I see you updated your PPPOE image to be Dachstein based
will you shortly be  updating your PPPd image?


Also when we had written before you said that users should have
a dedicated phone line, That is allwell and good but does not
help when in middle of doing something when my connection time is
240 minutes and the ISP hangs up the line. The PPP demand dialing does
work but never hangs up for inactivity The ISP sends a multicast
packet every 30 seconds. I do DENY the packets with no logging
so the rest of my network does not see the packets. My SSH connection will
just wait untill some timeout occurs or I kill  SSH.

Will I have to diald?

Thank You for your work on LEAF!

PS just as I was about to send this email my 240 minutes was up!
BA HUM BUG but at least this is the right season to say it

Larry Platzek  [EMAIL PROTECTED]




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

Re: [Leaf-user] Ipupdate with Proxy support

[Kim Oppalfens]

On Fri, 21 Dec 2001 20:52:29 +0100, Kim Oppalfens wrote:
>On Thu, 20 Dec 2001 10:38:22 -0800 (PST), Jeff Newmiller wrote:
>>On Thu, 20 Dec 2001 [EMAIL PROTECTED] wrote:
>
>Ok, your right I stated the problem kinda wrong. So let's try again.
>My ISP requires all http traffic to pass through the proxy. Since
>ez-ipupdate uses http I think so it doesn't work anymore. I believe
>the problem is that my ISP is blocking everything below port 1024
>with the exception of pop, smtp & https (that are the only
>exceptions
>I found out about through testing).
>
>Kim
>>
>>> Hi all,
>>>
>>> My new ISP requires all trafic to pass its proxy server.
>>> I was happily using ez-ipupdate to update my dyndns account, but
>>>that doesn't
>>> seem to work through the proxy. So my question is does anybody
>>>know either how
>>> to configure ez-ipupdate for proxies, or has anonther updater
>>>available that
>>> supports the dyndns service as an lrp package. Or if you know
>>>about another
>>> program that doesnot require python or perl I could try and make
>>>that into an
>>> lrp myself. (I dont want to have add a perl or python package to
>>>my floppy)
>>
>>Of what value is dynamic dns if all traffic has to pass through a
>>proxy?
>>Proxies only support protocols they are designed to support, and
>>connections that originated "internally".  Something doesn't make
>>sense.
>>Have you been able to, say, ssh into your system from outside by
>>using the
>>ip number?
>>
>>

>>-
>
>>--
>>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
>>
>
>
>-- Kim Oppalfens, [EMAIL PROTECTED] on 21/12/2001
>


-- Kim Oppalfens, [EMAIL PROTECTED] on 21/12/2001



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

Re: [Leaf-user] serial console

[guitarlynn]

On Friday 21 December 2001 13:32, you wrote:
> hyperterminal should do what you want.  assuming you have an
> appropriately wired serial cable connected between your laptop and
> your dachstein box, open hyperterminal
> (start->programs->accessories->communications->hyperterminal) or
> something similar.  Create a new connection and select the serial
> port (probably com1) the cable is attached to, then adjust the port
> settings appropriately (usually 9600 Baud, no parity, 1 stop bit
> works fine), and start the connection.  Try hitting return once or
> twice and see what shows up.


That is what I couldn't find, thanks everyone. I was trying to find a
non-tcp/ip connection option guess I looked in the wrong place(s).

Thanks again!
~Lynn Avants

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

Re: [Leaf-user] can't decompress dachstein kernels

[Charles Steinkuehler]

> I have tried to decompress it using upx :  ./upx -d linux...upx
> (on three different systems) and each time I get the error "not packed
> by UPX".

This is unnecessary.  I have never tried doing this...it may not work.  If
you really want to uncompress the kernel, make sure you're using the
unstable version of UPX that knows how to compress the kernel.

> I have also tried to just rename it "linux" and boot with it, but it is
> not recognized as a kernel.

This should work...

> Also, my dos system is having trouble reading the floppy that way.  I
> get read errors.
> (I have downloaded it twice, first to harddisk..)
>
> What silly, basic, giz-wiz-I-should-have-known-that, thing am I doing
> wrong???

Hard to say, but I can think of a couple of possibilities:

1) You're being bitten by the "netscape download bug", and your web-browser
is adding carrige returns before line-feeds when downloading, because it
thinks the kernel is a text file.  Check the file-size on the web and on the
file you downloaded...they should match EXACTLY

2) You're writing the file to floppy on a system that isn't properly
supporting the 1680K (or other high-capacity) disk format.  To make sure
this isn't happening, write the kernel to a standard 1.44 Meg floppy.  Take
this floppy to your LEAF system, and copy the file to the ramdisk, then
mount your actual boot floppy and copy the downloaded file to the file
"linux" on your boot floppy.

If neither of these methods gets you better results, post as much detail as
you can on anything that looks suspect.

Good Luck!

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] Advanced firewall tricks

[Charles Steinkuehler]

For those of you who don't subscribe to Sys Admin, there are a couple of
interesting articles in the latest issue (Jan 2002) that are somewhat
applicable to LEAF.

In "Halted Firewalls", Mike Murray discusses the interesting fact that you
can shut-down the linux kernel (ie "halt"), but kernel processes will keep
running.  Having the kernel running without any user processes is not
generally very useful, but if you don't explicitly bring down ethernet
interfaces and flush the ipchains rules, your system will still route,
firewall, and forward packets.  Without any user processes running, there's
no swap space (LEAF systems don't typically have any swap anyhow), and
dynamic connections using dhclient, PPPoE, and similar won't work, but it's
still kind of a neat concept.  It's pretty hard to hack into (or remote
administer) a system with no running processes.

Even more interesting is "Redundant Internet Connections Using Linux" by
Seann Herdejurgen.  He describes a simple method for bandwidth sharing
between two interfaces, a topic that surfaces occasionally on this list.
While not quite a complete solution, the equal weight default routing looks
like it would work for masqueraded firewalls.  I'll have to test the
masquerading code on 2.2 and see if it properly divides reqests between
multiple external interfaces, and correctly mangles the source IP for both
interfaces.  Anyone try this already and know if it works?  If the
masquerading works properly with multiple external NIC's, it's a (fairly)
straight-forward matter to integrate this support into the firewall scripts,
duplicating the public rules for more than one interface.  The hard part is
making some scripts to properly route traffic if one of the links goes
down...since typically the ethernet link between the firewall and the
cable/DSL modem is always up, periodic pings or some other link test needs
to happen to swap routing tables around if a link fails.

Anyone know if SeaWall or any of the other firewall scripts will handle
multiple external interfaces?

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] can't decompress dachstein kernels

[Ray Olszewski]

At 04:18 PM 12/21/01 -0600, Charles Steinkuehler wrote:
>> If this is the cause ... Charles, you really should fix this on your end
>> (actually, you should fix it whether or not it the cause in this
>particular
>> instance -- this problem occurs over and over with http downloads).
>
>I know, I know...it's just that thttpd requires a re-compile to add new
>mime-types :<

I'd forgotten about this. Would it be practical to change the *default*
mime-type from text to binary?


--
"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] can't decompress dachstein kernels

[Charles Steinkuehler]

> >I know, I know...it's just that thttpd requires a re-compile to add new
> >mime-types :<
>
> I'd forgotten about this. Would it be practical to change the *default*
> mime-type from text to binary?

Yes...I even did this once.  Then I upgraded thttpd and forgot to make the
modification to the mime-types file...


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] Is this newbie even in the right ballpark with LEAF?

[Tony]

But, isn't LEAF limited to 64M for the ramdisk?  MINIX is the filesys right?  And I 
thought that was limited to 64M total.  

Now, 64M with the PIII and some quality PCI cardsshould be more than enough for 
what he needs.  I know 3com and Intel have cards with the 3DES decoding chips onboard 
to offload the work, but I don't know if they work with Linux (I know they work with 
W2K). 

I looked at 3com's site, and they have beta version drivers for the 2.2 and 2.4 
kernels, but I am not totally sure they support the offloading of the 
encryption/decryption and tcp checksum calcs.  If they did, then you could get away 
with even less CPU.

Later

Tony


[snip]
> 
> You're talking about 
> 
>   Low end Intel  High End Intel
>  -
>   233 MHz Cpu733 MHz Cpu
>   3 Mbps 3DES throughput 95 Mbps 3DES throughput
> 
> That's a big difference.   I'm sure you could put together
> a LEAF box with a PIII 800 and 512 MB ram, but you're asking
> for other companies solutions, and I'll let someone else
> answer that.  I'd like to think a LEAF box could keep
> up until it's compared to some fancy hardware with a modified 
> PCI bus or multiple PCI buses.
> 
> Good Luck,
> Matthew 
 


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

Re: [Leaf-user] ppp0 not loading in Dachstein

[CaMiX CaMiX]

Ok, well I've made sure that those modules are now loading in /etc/modules 
but still no dice.  I really don't know why it's not connecting now.  Is 
ppp0 supposed to be showing, because it still doesn't show under "ifconfig 
-a"?  When I ran the debug what caught my eye was at the very end which was:
-
ioctl(TIOCSETD(PPP)): Invalid argument(22)
/usr/sbin/pppd: This system lacks kernel support for PPP.  This could be 
because
the PPP kernel module could not be loaded, or because PPP was not
included in the kernel configuration.  If PPP was included as a
module, try `/sbin/modprobe -v ppp'.  If that fails, check t
-
If this is the problem, which I'm sure it is, what could I look at or do to 
fix it? Here is the whole copy of my debug file just in case:

-
Sat Dec 22 10:24:22 UTC 2001
Output of uname -a
Linux firewall 2.2.19-3-LEAF-RAID #4 Sat Dec 1 17:27:59 CST 2001 i386 
unknown
-
Output of ifconfig -a
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:3924  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0

ipsec0Link encap:IPIP Tunnel  HWaddr
  unspec addr:[NONE SET]  Mask:[NONE SET]
  NOARP  MTU:0  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0

ipsec1Link encap:IPIP Tunnel  HWaddr
  unspec addr:[NONE SET]  Mask:[NONE SET]
  NOARP  MTU:0  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0

ipsec2Link encap:IPIP Tunnel  HWaddr
  unspec addr:[NONE SET]  Mask:[NONE SET]
  NOARP  MTU:0  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0

ipsec3Link encap:IPIP Tunnel  HWaddr
  unspec addr:[NONE SET]  Mask:[NONE SET]
  NOARP  MTU:0  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0

brg0  Link encap:Ethernet  HWaddr FE:FD:04:00:5C:EA
  unspec addr:[NONE SET]  Bcast:[NONE SET]  Mask:[NONE SET]
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0

eth0  Link encap:Ethernet  HWaddr 00:81:8F:71:3F:93
  unspec addr:[NONE SET]  Bcast:[NONE SET]  Mask:[NONE SET]
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:480 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0
  Interrupt:11 Base address:0xf000

eth1  Link encap:Ethernet  HWaddr 00:81:8E:F0:11:75
  inet addr:192.168.1.254  Bcast:192.168.1.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  Collisions:0
  Interrupt:10 Base address:0x1000

-
Output of lsmod
Module PagesUsed by
ip_masq_vdolive 1180   0 (unused)
ip_masq_user3708   0 (unused)
ip_masq_raudio  2980   0 (unused)
ip_masq_quake   1220   0 (unused)
ip_masq_portfw  2416   0 (unused)
ip_masq_mfw 3196   0 (unused)
ip_masq_irc 1924   0 (unused)
ip_masq_ftp 3576   0 (unused)
ip_masq_cuseeme  964   0 (unused)
ip_masq_autofw  2476   0 (unused)
natsemi 8440   2
pci-scan2300   0 [natsemi]
isofs  17692   0
ide-cd 22672   0
cdrom  26712   0 [ide-cd]
-
Output of netstat -n -r
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt 
Iface
192.168.1.0 0.0.0.0 255.255.255.0   U 0 0  0 
eth1
-
Contents of /etc/resolv.conf
# MADE-BY-RP-PPPOE
nameserver 209.251.129.10
nameserver 209.251.129.9
-
Contents of /etc/ppp/options
# /etc/ppp/options
#
# $Id: options,v 1.4 1996/05/01 18:57:04 alvar Exp $
#
# Originally created by Jim Knoble <[EMAIL PROTECTED]>
# Modified for Debian by alvar Bray <[EMAIL PROTECTED]>
# Modified for PPP Server setup by Christoph Lameter <[EMAIL PROTECTED]>
#
# Use the command  egr

[Leaf-user] fsck.ext2: erro in loading shared libraries

[Pete Dubler]

So... I finally got nice clean download and got the hard disk going on
my Dachstein system.
(pick the right mirror and stomp on the shift key...)

So, being faithful to Charles' HOWTO, I installed the hdsupp_s.lrp
package.  Fsck cannot find a shared library and neither can I...  when
the system boots or when I try to run fsck.ext2, I get the following
message:

Parallelizing fsck version 1.12 (9-Jul-98)
fsck.ext2: error in loading shared libraries
libuuid.so.1: cannot open shared object file: no such file or
directory

I am running Dachstein and loaded the Materhorn hdsupp_s, which is the
latest version I have found.  The disk is set-up precisely per Charles'
HOWTO, except for the partition sizes (the names were not even changed
to protect the innocent.)

Any ideas... I am running out of them myself...

Thanks to all,

Pete Dubler
Fort Collins, CO




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

RE: [Leaf-user] Is this newbie even in the right ballpark with LEAF? (Summary)

[Dan Schwartz]

Dear Charles and Tony,

Thank you very much - Again! - for the capacity planning help.

[More]

>-Original Message 2-
>From: Charles Steinkuehler
>To: #LEAF ListSERV
>Subject: Re: [Leaf-user] Is this newbie even in the right ballpark with
>LEAF?
>
>
>> Over the past few days I've received some very helpful guidance about
>> assembling LEAF VPN appliances to handle multi-megabit 3DES encryption
>> throughput rates; and I really appreciate the guidance given this Mac & NT
>> geek (& linux newbie).
>>
>> However, since LEAF is essentially a small, stripped down (yet robust!)
>> router that fits on 1 or 2 floppies, is there another router/encryption
>> project out there in *nix land that's more suited for high capacity, i.e.
>> something on the order of an Intel NetStructure 31xx VPN gateway
>> ?
>
>Do not make the mistake of equating "stripped down" with "low capacity".

I'm not confusing the two. However, I've already identified two optimizations
that can't be used with the standard LEAF distro

1) No linux support for hardware encryption accelerators;

2) No IP stack multithreading in the 2.2 kernel, which effectively neuters
dual CPU hardware.

>The capacity of a LEAF system is related to the hardware you install it on.
>Use a 486 with NE2000 ISA NIC's, and you'll be lucky to get 5 or 6 MBits/sec
>(although this is fine for most cable/DSL users).  Upgrade to a Pentium
>class system with good PCI NIC's, and you'll get a router system that can
>come close to saturating several 100 MBit links.
>
>Since you're mainly interested in encryption throughput, I refer you again
>to the FreeS/WAN performance page:
>http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/performance.html

Actually, when I looked at that document last week launched a host of new
questions. From the freeswan.org article, comments [in brackets]:

 ---

The crypt boxes are Compaq DL380s - Uniprocessor PIII/733 with 256K
cache. [This is about the same as the high end Intel appliances] They have
128M main memory.  Nothing significant was running on
the boxes other than freeswan.  The kernel was a 2.2.19pre7 patched
with freeswan and ext3.

Without an ipsec tunnel in the chain (ie the 2 inner boxes just being
100BaseT routers), throughput (measured with ttcp) was between 10644
and 11320 KB/sec [This is 100 to 110 megabits per second, unencrypted]

With an ipsec tunnel in place, throughput was between 3268 and 3402
KB/sec [Which is 32 to 34 megabits per second encryption rate]

 ---

This 3.3 megabit 3DES encryption rate with the PIII/733 is only about that of
a pair of T-1 lines; while the similar hardware in the Intel box has an
encryption rate of 95 megabits.


[more]

>Testing with single processor 733 MHz Pentium III systems, and measuring
>with ttcp, unencrypted traffic moved at 10644-11320 KB/s, or about 92
>MBits/s (that's a pretty saturated 100Mbit ethernet link!).  Adding
>encryption overhead caused these speeds to drop by about 1/3, to 3268-3402
>KB/s, or about 27 MBits/s.

My point exactly: The Intel reference design - Now being sold by H-P as
well - seems to be about 3 times as efficient in 3DES encryption as FreeS/WAN
with (essentially) the same PIII/733 architecture.

>With much faster systems are available today, and taking into account the
>fact that the encrypted throughput numbers above are for the end-end TCP
>connection (ie the acutal traffic on the encrypted link is running at a
>higher bandwidth, due to the IPSec protocol overhead),  and I don't think
>you're going to have trouble saturating your internet connections.

Well... With the tariffs rigged by Verizon the way they are, that T-1 frame
relay line could quickly jump to a burstable OC-3 155 megabit ATM circuit...

>IIRC, you indicated you were starting with a T1, which can easily be kept
>saturated by a Pentium-1 class system (ie P90-133), even when running
>encryption.  The 733 MHz systems above provide you with about a 20X margin
>for future growth, with a modern 1.5 MHz

You mean 1.5 gHz...

>single CPU system likely providing
>40-50x your initial T1 requirement.  The intel system with hardware crypto
>acceleration only provides a peak performance of 95 MBits/s.  You should be
>able to match this using linux and FreeS/WAN with a 2.5-3 GHz CPU...these
>may not be availble today, but it won't be long until they are.
>
>If you're customers are seriously going to be using more bandwidth than a
>modern fast CPU can encrypt/decrypt, you should have no problem jumping to a
>high-end dedicated VPN endpoint solution...while these systems are quite
>expensive, the purchase price will likely be lost in the noise of your
>monthly bandwidth charges...

Not necessarily, due to the difference between a committed rate ("all you can
eat" for a fixed monthly price) and a burstable rate ("I'll give you a fat
p