Re: [Leaf-user] Silent_Deny by destination address ???
On Monday 10 December 2001 00:51, you wrote: Depending on the service provider the 10.x.x.x addresses could simply be the modems (as that is the usual IP scheme for @home modems - not nics) going through misconifgured ISP routers or something like that if it seems to be a problem for lots of customers. Not here, the Speedstream 2100 modems use 192.168.100.1 as they're ip, but I assume that the 10./8 class is RR's internel servers addy's. I call get on their butts weekly about getting rid of the crappy Win2K servers. They really don't seem to have a problem with them though. I can remember a couple of years ago setting up Samba for the first time w/o a firewall or router accidentally taking over their SQL database. That was a 10/8 addy. hehe, don't feel so bad about it know in retrospect!!! In any case, it's all web trash and should be safely denied with the added rule on eth0. ~Lynn Avants -- if linux isn't the answer, you've got the wrong question ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] What is This
Sean E. Covel wrote: Is this what they call FireWalking? This is my welcome to the new ATTBI network. Got more of these than Nimda or Code Red hits. Goes on for pages. 1888 today. Any thoughts? Firewalk uses a traceroute method with UDP and ICMP pings, gathering information of the network and hosts(s) with the TTL fields, very interesting, indeed...: http://www.packetfactory.net/Projects/Firewalk/firewalk-final.html -- Patrick Benson Stockholm, Sweden ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] What is This
Sean E. Covel wrote: Victor, I believe you are correct. After reading the banter going back and forth, and recalling previous posts (about that DAMN X10 popup) I reviewed my log. The log entries are bursts of hundreds in the same few seconds. Must have been while I was on MyYahoo. I remeber getting then X10 and Casino popups. Is there anyway we can reverse SPAM them to stop this ridiculus traffic? It's understandable that you want to retaliate but it wouldn't be very wise and it would cause further problems. Better to just deny and not log it, altogether...Remember that there are many others that are affected by this and maybe, pretty soon, it's possible that the people who supervise the backbones of the 'net will just get disgusted with all of this and will demand something be done to stop it, from those who are the cause of all this bandwidth consumption. Here is another one about an ISP using this technologu... http://lists.insecure.org/incidents/2001/May/0096.html To tell you the truth, that's what I did, myself, back in Feb.-March, look at these log entries, taken from your link: [140.239.176.162/17221] HarvardNet [165.121.70.75/64551] Earthlink [194.205.125.26/41123] European Regional Internet Registry [194.213.64.150/47642] European Regional Internet Registry [202.139.133.129/41595] Asia Pacific Network Information Center [203.194.166.182/38808] Asia Pacific Network Information Center [203.208.128.70/12235] Asia Pacific Network Information Center [207.55.138.206/61929] Verio, Inc. [208.184.162.71/53567] Abovenet Communications [209.249.97.40/45714] Abovenet Communications [212.23.225.98/57974] European Regional Internet Registry [212.78.160.237/29368] European Regional Internet Registry [216.220.39.42/21602] Myna Communications, Inc. [216.33.35.214/21092] Exodus Communications [216.34.68.2/45906] Exodus Communications [216.35.167.58/32470] Exodus Communications [62.23.80.2/55543] European Regional Internet Registry [62.26.119.34/56523] European Regional Internet Registry [63.209.147.246/54734] Level 3 Communications [64.14.200.154/32735] Exodus Communications [64.37.200.46/65042] Exodus Communications [64.56.174.186/14237] Exodus Communications [64.78.235.14/17768] Verado, Inc. (Firstworld Communications) which is more or less what I got, too. Notice the amount of entries from Exodus. What I did was place the source addresses in a web browser and I always got re-directed to a site called the Coyote Equalizer, the main site is located at http://www.coyotepoint.com/ Since these addresses were pointing to the same location, despite their geographical diversity, this must be the real culprit. Coyotepoint uses Exodus as their provider, by the way. The response? Dear Mr. Benson, Coyote Point Systems (http://www.coyotepoint.com) produces a geographical load balancing system called Envoy. This is a product which allows our customers to direct internet users to the nearest available data center for fastest processing. For instance, UK users may be processed in a London data center while US individuals will be processed in a US data center. This product makes the user's browsing speedier as well as providing additional redundancy (if a UK data center goes off-line, UK individuals will be processed in one of our US data centers). This product works by delegating DNS for a specific hostname (or hostnames) to our Envoy machines. Envoy then calculates the best possible location and serves up that IP. For instance, user X needs to resolve 'www.coyotepoint.com'. The user's machine queries its local DNS which does not have authoritative information for 'www.coyotepoint.com'. That DNS then queries the SOA for the 'bfast.com' domain which in turn directs it to one of the Envoy machines. Envoy then uses the IP of the user's local DNS to calculate the best geographical location. This is where the ping is attempted. If the ping is unsuccessful, a default site is used. Please note that because we have multiple sites for redundancy, a ping may be generated from each site in order to determine the closest site. One look-up may generate several from the Envoy system (two from each site). Your local DNS should cache this IP for several minutes before another look-up is required. We hope that you understand that we are in no way attempting to flood anybody's network. The Envoy product is used solely to make the individual's internet browsing experience faster and more robust. -- --- Bill Kish Ph: 650.969.6000 Chief Engineer,3350 Scott Blvd, Bldg 20 Coyote Point Systems Inc. Santa Clara California 95054 Email: [EMAIL PROTECTED] http://www.coyotepoint.com/ --- For support call:
Re: [Leaf-user] SYN packets
Matt Schalit wrote: Is there a way to deny any and all SYN packets altogether? ipchains -A input -j DENY -i eth0 -p tcp ! -y -l Very bad. Very bad. Very, very bad. ^^^You wanted to deny packets with SYN, and I posted how to deny packets *without* SYN. The following does what you asked and is what I should have posted. ipchains -A input -j DENY -i eth0 -p tcp -y -l Meaning: - -A input = add this rule to the input chain -j DENY= deny all packets which are -i eth0= coming in on eth0, the external nic -p tcp = and the packet is tcp -y = and the packet has the SYN flag set, -l = then log these denies to the syslog. Ok then :-o Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] What is This
Victor McAllisteer wrote: Matthew Schalit wrote: Victor McAllisteer wrote: This is some crazy method of geographic load balancing. A whole lot of boxes use TCP port 53 simultaneously to find out what part of the world. Victor, wouldn't the load balancing we've seen over the last months that hits port 53 be SYN traffic? Why are all his log entries refering to non-SYN traffic, i.e. responses? Matthew There was a lot of list traffic back in May on the LRP list concerning these port 53 weirdness. I remember it and read it, but the point of my question remains, the user is certainly not starting tcp connections to all 600 of those computers, so why would they all be *replying*. If the perpetrators of the load balancing we've discussed are now crafting reply traffic to do this balancing, that's what I'd like to know, because that would be mildly unethical and something for which I'd have to tailor my firewall I wrote. Thanks, Matthew My understanding is that tcp port 53 to port 53 is usually a zone transfer. Leaf boxes running tiny DNS will not respond to tcp queries. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] No masquerade access to private DMZ
Dear List, Using E2B with Extended Scripts, I have an email server sitting in a private address DMZ (172.20.x.x) with two internal networks (192.168.x.y). Connections from the internal network to an SMTP server in the DMZ are masqueraded so they look like connections from the firewall address on the 172.20. network. The SMTP server is also port forwarded from the outside world for mail delivery etc. In trying to lock down the server against being an unsecured relay, Postfix offers a few options for clients wishing to send email. One is to only allow clients from given networks or domains to send, another to only allow sending to a limited range of domains. :-( As far as I can see, all traffic to the server (from internal or external hosts) appears to come from the 172.20. network so I can't use this to discriminate against external senders (networks or domains). Restricting the destination domains is likewise not an option. Short of SMTP authorisation, what is the best/normal way to tackle this either on the firewall or email server? Is it possible/sensible to not masquerade this traffic from the internal networks to the SMTP port and block outside users from sending in this way? Are NOMASQ_DEST_BYPASS or NOMASQ_DEST of interest here? Seem to be oriented towards a different problem. Any suggetions? Thanks and regards, matt ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] newbie question on ipchains in dachstein cd 1.2
Where do I add, change, or open ports? I see no ipchains.input/.output in /etc. Ive been to the ipchains man an understand the syntax now I need help inputting in to dachstein. Isnt this Exciting
Re: [Leaf-user] newbie question on ipchains in dachstein cd 1.2
Where do I add, change, or open ports? I see no ipchains.input/.output in /etc. Ive been to the ipchains man an understand the syntax now I need help inputting in to dachstein. Isnt this Exciting Start with the settings in /etc/network.conf. You can do most of the 'usually required' things there, including opening TCP and UDP ports to the outside world, and even forwarding them to internal systems. There are comments inline, and a somewhat dated (but still reasonably accurate, especially for the simpler things) document covering the network.conf settings on my website: http://lrp.steinkuehler.net/files/packages/network.txt If you're still lost, post more specifics about exactly what you're trying to do... 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] No masquerade access to private DMZ
Using E2B with Extended Scripts, I have an email server sitting in a private address DMZ (172.20.x.x) with two internal networks (192.168.x.y). Connections from the internal network to an SMTP server in the DMZ are masqueraded so they look like connections from the firewall address on the 172.20. network. The SMTP server is also port forwarded from the outside world for mail delivery etc. In trying to lock down the server against being an unsecured relay, Postfix offers a few options for clients wishing to send email. One is to only allow clients from given networks or domains to send, another to only allow sending to a limited range of domains. :-( As far as I can see, all traffic to the server (from internal or external hosts) appears to come from the 172.20. network so I can't use this to discriminate against external senders (networks or domains). Restricting the destination domains is likewise not an option. Short of SMTP authorisation, what is the best/normal way to tackle this either on the firewall or email server? First, you need to get a clearer picture of how everything works. Your mail logs may be helpful here, if your server logs the IP of the connecting machine. If your internal systems use the private IP of the mail server, the connection will be masqueraded, and the mail server will see the DMZ IP of the firewall (172.20.x.x) If your internal systems use the public IP of the mail server, the connection will be port-forwarded (NOT masqueraded), and the mail server will see the private IP of the internal machine (192.168.x.y). I suggest configuring your internal systems to use the public IP of your mail server, rather than it's private IP, and that you use the domain name of your mail server, rather than the IP address, if you've got DNS setup. ALL connections from the outside world will be port-forwarded and the mail-server will see their real IP. Just because the firewall is port-forwarding the traffic doesn't mean the mail-server sees the firewall as the source of that traffic. The functionality I think you're associating with port-forwarding is actually that of a proxy-server. Anyway, all this means that you can easily impliment IP based relaying rules in your mail server. Simply allow traffic from 192.168.x.y (internal net) and 172.20.x.x (DMZ network), and don't relay from any other IP's. 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] Silent_Deny by destination address ???
255.255.255.255 is most likely an Class A DHCP request. For some strange reason, since @HOME has been having random outages, reports of tons of these requests have been made all over. Funny thing is the bulk of the ones I've been getting are from a private class 10.6.1.x address. I just figured someone jacked up their Win2K config seems to happen often around here. Windows servers spew DHCP replies out ALL their interfaces, not just the interface the request arrived on. When I see DHCP reply messages containing private IP's where they don't belong, I usually assume some poor soul is using windows for their internet firewall (and running a DHCP server on it as well)...better them than me, I guess ;-) 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] Silent_Deny by destination address ???
This entry in /etc/ipchains.input appears to do as I need: $IPCH -I input -j DENY -p all -s 0/0 -d 255.255.255.255 -i $EXTERN_IF One thing that concerns me is this statement from man ipchains: ``The mask can be either a network mask or a plain number, specifying the number of 1's at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.'' Do I need to specify /32? No. If you don't specify a netmask (or masklength), IPChains treats the IP as a single host (ie the default netmask is /32 or 255.255.255.255 if it is not provided). 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] Very Minor Bug in Eigerstein and Dachstein
This might properly be a bug in POSIXness, but I use Eigerstein and Dachstein and I don't know who's changed what. Anyway, the minor problem is that the first line of the mount.back() function in /bin/grep in Eigerstein and in /lib/POSIXness/POSIXness.linuxrouter is dev = rather than dev= The former causes an error to be written to stderr when mount.back() is called. The qt() function in lrcfg.back normally hides the error, but I'm calling mount.back() in my own script. Rodney ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Very Minor Bug in Eigerstein and Dachstein
This might properly be a bug in POSIXness, but I use Eigerstein and Dachstein and I don't know who's changed what. Anyway, the minor problem is that the first line of the mount.back() function in /bin/grep in Eigerstein and in /lib/POSIXness/POSIXness.linuxrouter is dev = rather than dev= The former causes an error to be written to stderr when mount.back() is called. The qt() function in lrcfg.back normally hides the error, but I'm calling mount.back() in my own script. Definately a bug...added to the list of things to fix. Thanks for the sharp eyeballs! 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] Dachstein CD from a floppy
All: I am using the Dachstein floppy image based on the 2.4 kernel and the openssh lrp packages created by jacques nilo. I have only one floppy drive and am using a 1680 KB floppyy disk. The openssh packages are installed into the ramdisk. I cannot back them up onto the floppy due to lack of space. Is it possible to create a CD from the Dachstein floppy and add other packages to it as needed, while at the same time reading the config from the floppy. Any info appreciated. thanks prabhakar ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein CD from a floppy
I am using the Dachstein floppy image based on the 2.4 kernel and the openssh lrp packages created by jacques nilo. I have only one floppy drive and am using a 1680 KB floppyy disk. The openssh packages are installed into the ramdisk. I cannot back them up onto the floppy due to lack of space. Is it possible to create a CD from the Dachstein floppy and add other packages to it as needed, while at the same time reading the config from the floppy. Any info appreciated. Sure, but it'd be a lot easier to just start with the CD version: http://lrp.steinkuehler.net/DiskImages/Dachstein-CD.htm It already includes OpenSSH, and several other useful packages... 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] stealth
Hi, I've been using LRP 2.9.8 (2.0 kernel) for some time now, and I like it very much. So I'm not a total newbie where LRP is concerned but I am to firewall-scripting (my current one was written by a friend of mine). There's just the little problem that I want my router/firewall to run stealth. Is it possible or should I try using smoothwall? Any help and/or advice would be greatly appreciated. Bartosz ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] eepro100.o module troubles...(HD install)
Hi all, I've managed to get my linux router to boot from a hard drive in a Dell Powerapp Web 100 (IDE, simpler than SCSI). This machine has dual on-board EtherExpress Pro 100's, which come up just fine using the floppy I made with Coyote. My problem comes into play when changing things to boot from the IDE drive. I syslinux'ed the HD, copied the linux-2.2.19-3-LEAF-normal-IDE.zImage.upx kernel to the HD from a floppy and renamed it, and copied everything (except ldlinux.sys and linux) from the floppy to the hard disk. Unfortunately, neither of the network interfaces will start, and all modules complain loudly about not being the same version as the kernel. I realized after looking at messages during boot that none of the ip modules (and the eepro100.o module) had version numbers that matched the kernel version, so as a test, I downloaded the eepro100.o module from http://lrp.steinkuehler.net/files/kernels/2.2.19-3-normal/ (same place I got the IDE-enabled kernel) , put it on a floppy, copied it to /lib/modules, and backed up the boot image. I can still boot, but now when the network moduled try to load, I get eepro100 - /lib/modules/eepro100.o: unresolved symbol acpi_set_pwr_state /lib/modules/eepro100.o: unresolved symbol pci_drv_unregister /lib/modules/eepro100.o: unresolved symbol pci_drv_register Anybody have any pointers on eepro100 modules and IDE-enabled kernels? Anything that can go wrong, will go wrong. -Finagle's Law If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it. -Edward A. Murphy, Jr. Murphy Was an optomist -O'Toole's commentary on Murpy's Law Adrian M. Stovall Senior Systems Engineer PFK Business Systems, Inc. [EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Still unable to run Dachstein
Hi, Did you make sure the module pci-scan was loaded BEFORE the tulip driver ? Regards Etienne - Original Message - From: Vince Schiller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 10, 2001 11:16 PM Subject: [Leaf-user] Still unable to run Dachstein I've tried to run both Eigerstein and Dachstein unsuccessfully. I have a PII 233 MMX processor on a generic motherboard with 32 Meg of RAM and 2 Linksys LNE 100tx Nics. I must be overlooking something. I first attempted to run Eiger. Apparently the tulip driver wasn't current enough and my NICs weren't recognized. I was getting the message that eth0 did not exist. Then I tried Dachstein. I got the following message: No subnet declaration for 'eth1' (0.0.0.0). Please write a subnet declaration in your dhcpd.conf file for the network segment to which eht1 is attached. Apparently that NIC was not being detected (at least that is what I thought I saw scrolling past as it was loading). I checked the dhcpd.conf file as well as the /etc/init.d/dhcpcd. The declaration seemed to be made?! I even tried using a different, older, Linksys card. I then attempted Oxygen. My machine seemed to register some key stroke input that made it difficult to even get it to boot. Then I did not understand how to configure my machine (yes I am a Linux newbie), but again there seemed to be a problem with dhcp and my NICs. I am certain I must be overlooking something, but it is unclear to me what that might be. I've made several attempts to get LEAF working and I am 0 for 4. Is there some missing step to getting dhcp running? Is there something funky about trying to use 2 of the same brand of network card? Can anyone offer some suggestions as to what I may be doing wrong or if I am overlooking something? ___ 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] What is This
Patrick Benson wrote: Firewalk uses a traceroute method with UDP and ICMP pings, gathering information of the network and hosts(s) with the TTL fields, very interesting, indeed...: http://www.packetfactory.net/Projects/Firewalk/firewalk-final.html Been a package for quite a while: http://leaf.sourceforge.net/pub/oxygen/packages/firewalk.lrp ...have at it... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] eepro100.o module troubles...(HD install)
I can still boot, but now when the network moduled try to load, I get eepro100 - /lib/modules/eepro100.o: unresolved symbol acpi_set_pwr_state /lib/modules/eepro100.o: unresolved symbol pci_drv_unregister /lib/modules/eepro100.o: unresolved symbol pci_drv_register Anybody have any pointers on eepro100 modules and IDE-enabled kernels? You're not loading all the required modules. The modules.dep file (found in the modules of the kernel you downloaded) will inform you that if you want to run eepro100.o, it depends on pci-scan.o, which must be loaded first. 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] What is This
David Douthitt wrote: Been a package for quite a while: http://leaf.sourceforge.net/pub/oxygen/packages/firewalk.lrp ...have at it... Hey, thanks for the reminder! :-) Do you need an extra lib* package for that if one is running Dachstein? -- Patrick Benson Stockholm, Sweden ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Still unable to run Dachstein
I had the same problem (t:t:t:t:) at the boot prompt with the latest oxygen release loading on a Gateway 2000 pentium-1 machine. A serial port (actually two) are certainly present on the Gateway -- so no serial port present shouldn't be the issue, unless having two of them causes no serial port to be spec'd. I will try the development version if you think that will help, David. David Douthitt wrote: [EMAIL PROTECTED]">Vince Schiller wrote: I then attempted Oxygen. My machine seemed to register some key strokeinput that made it difficult to even get it to boot. Then I did notunderstand how to configure my machine (yes I am a Linux newbie), but againthere seemed to be a problem with dhcp and my NICs. The "some key stroke" is rather vague; I can only guess you are referingto the startup process where a "boot:" prompt is given after SYSLINUXloads.The reason you see the (I'm guessing that this is what you refering to;I don't know for sure) "t:t:t:t:" prompt has to do with serialconsole support; this prompt garbage shows up when there is no serialport present and SYSLINUX is configured to use the serial port.Also, you didn't detail what the problems are with DHCP and with yourNIC cards.This description, though in reference to Oxygen and not Dachstein, makesit very hard to solve your Oxygen troubles. I am certain I must be overlooking something, but it is unclear to me whatthat might be. I've made several attempts to get LEAF working and I am 0for 4. Is there some missing step to getting dhcp running? Is theresomething funky about trying to use 2 of the same brand of network card?Can anyone offer some suggestions as to what I may be doing wrong or if I amoverlooking something? Whether you are using Eiger, Eigerstein, Dachstein, or Oxygen, thebiggest thing to do is to give more details. Here are some questionsyou might answer - especially for your Dachstein and Oxygen runs, asthese are the currently supported distributions:* What error messages did you get? What is their exact wording?* What dhcp client were you running? What version?* What DHCP server are you running - or where is your DHCP lease comingfrom?* What versions of the distributions did you try?* What errors did you see from the loading of the NIC card modules?* What sort of service are you using? Cable Modem? DSL?Another tip: if you press "Shift-PgUP" and "Shift-PgDn" you can scrollback to about four screen-fulls or so, to catch messages you missed...Another tip: go to the LEAF site at http://leaf.sourceforge.net andcheck out the FAQs, including especially the Troubleshooting FAQ.Another tip: try using a development version of Oxygen. If you'rewilling to try it, it may work. There's been substantial changes andbug fixes, all for the better, I'd say. The images are athttp://leaf.sourceforge.net/pub/oxygen/development/___Leaf-user mailing list[EMAIL PROTECTED]https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] uninstall option for lrpkg
Running dachstein RC2 floppy version:
I'm try to add an uninstall option into
lrpkg.
I've added this code to
/lib/POSIXness/POSIXness.linuxrouter in the lrpkg() function.
# uninstall ()
{
f="$1"
FN_LIST="$(cat
$lrpkgpath/$f.list)"
for FN in $FN_LIST; do
rm
/$FN
done
}#
this in the case function,
#
-u ) uninstall "$2" "$3"
;;#
and this in the usage function:
#
eecho " -u: uninstall Uninstall package. (explude
.lrp)"#
Is this messy/incorrect/etc? I havevery
littleexp. coding shell scripts,
that's why i'm asking, although it seems to work
ok.
Also, what can I add to this to update the
/var/lib/lrpkg/packages file
to remove the named package from the
list?
[Leaf-user] where s that comming from???
This was flooding my logs. Any ideas? My internal is 192.168.6.0/24 and external is 24.x.x.x Dec 10 21:43:06 LRP kernel: Packet log: input DENY eth0 PROTO=17 192.168.0.1:21157 255.255.255.255:21157 L=126 S=0x00 I= F=0x T=128 (#10)
RE: [Leaf-user] where s that comming from???
http://www.networkice.com/advice/Exploits/Ports/21157/default.ht m says that port 21157 is used by the Activision gaming protocol (UDP). The source IP, 192.168.0.1 is odd; are you connected to a cable modem, or a university or some other large network? -Richard -Original Message- This was flooding my logs. Any ideas? My internal is 192.168.6.0/24 and external is 24.x.x.x Dec 10 21:43:06 LRP kernel: Packet log: input DENY eth0 PROTO=17 192.168.0.1:21157 255.255.255.255:21157 L=126 S=0x00 I= F=0x T=128 (#10) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] eepro100.o module troubles...(HD install)
Adrian Stovall wrote: I can still boot, but now when the network moduled try to load, I get eepro100 - /lib/modules/eepro100.o: unresolved symbol acpi_set_pwr_state /lib/modules/eepro100.o: unresolved symbol pci_drv_unregister /lib/modules/eepro100.o: unresolved symbol pci_drv_register Anybody have any pointers on eepro100 modules and IDE-enabled kernels? Most frequently asked question these days. As Charles said, uncomment pci-scan and be sure it is loaded before eepro100 in /etc/modules.conf. Cheers, Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Still unable to run Dachstein
Etienne Charlier wrote: Hi, Did you make sure the module pci-scan was loaded BEFORE the tulip driver ? Regards Etienne I agree here with the pci-scan loading before the nic module(s) and that Dachstein is the simplest and most surefire release to get you up an running with little effort. There are two major things to setup: 1) # echo 'export EDITOR=e3vi' /etc/profile # exit and login again so that you can use vi. 2) use lrcfg to edit your Packages, then Modules so that it edits your /etc/modules.conf . You are trying to uncomment the pci-scan line and the line for your nic module. Others say that's tulip. I don't know. The one I needed for my friends SMC PCI card wasn't even on Dachstein, so I had to grab a copy off the kernel gzip archive and put epic100.o in /lib/modules/ and epic100 in my modules.conf. 3) I guess there's a third thing, you have to set root's password, backup etc and modules, and reboot. I think that this corrects the No Subnet Declaration error because eth0 and eth1 will be found. Dachstein worked flawlessly for my friends @Home^H^H^H^H^H attbi.net dhcp account. Regards, Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] 3Com PCI 3c905-tx
Title: 3Com PCI 3c905-tx Try Charles site http://www.lrp.steinkuehler.net. If not there then try Donald Beckers site http://www.scyld.com, but if you find it on Donald's site you will need to compile it for your kernel version. If you find it on Charles site, it may already be compiled for Dachstein. Robert Chambers Reginald R. Richardson wrote: 711BD99DAD7ED511984F0050FC0B65CD3162@GENEVA"> Does anyone know where I can find driver for a 3Com PCI 3c905-tx, or what compatable driver I can use...for DachStein Thnks reggie
RE: [Leaf-user] 3Com PCI 3c905-tx
Try: http://leaf.sourceforge.net/devel/cstein/files/kernels/Dachstein-normal/modu les/net/3c59x.o Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Reginald R. Richardson Sent: Monday, December 10, 2001 10:27 PM To: Mailing List __Leaf ([EMAIL PROTECTED]) Subject: [Leaf-user] 3Com PCI 3c905-tx Does anyone know where I can find driver for a 3Com PCI 3c905-tx, or what compatable driver I can use...for DachStein Thnks reggie ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] newbie question on ipchains in dachstein cd 1.2
Very useful info Charles but I want to open msnmessenger file transfer tcp ports 6891:6900 and open ldap port 389 for dns active integrated zone transfer. (ports in and out and all forwarded to appropriate machines) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Charles Steinkuehler Sent: Monday, December 10, 2001 6:14 AM To: Jim Van Eeckhoutte; , Subject: Re: [Leaf-user] newbie question on ipchains in dachstein cd 1.2 Where do I add, change, or open ports? I see no ipchains.input/.output in /etc. Ive been to the ipchains man an understand the syntax now I need help inputting in to dachstein. Isnt this Exciting Start with the settings in /etc/network.conf. You can do most of the 'usually required' things there, including opening TCP and UDP ports to the outside world, and even forwarding them to internal systems. There are comments inline, and a somewhat dated (but still reasonably accurate, especially for the simpler things) document covering the network.conf settings on my website: http://lrp.steinkuehler.net/files/packages/network.txt If you're still lost, post more specifics about exactly what you're trying to do... 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 mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
