Re: [Leaf-user] DCD vs. netsnmpd ???
Jeff Newmiller wrote: [snip] AFAIK, ld -s and strip -s should have the same effect, but if you omit the -s when you link (or compile/link, as with gcc) then you can debug it before you strip it for shipping. An interesting read is http://www-106.ibm.com/developerworks/library/l-shobj/ That's a really great link Jeff. Thanks a lot for the help. Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Beep on logged packet?
Hi All I'm trying to make my Dachstein (floppy) system beep whenever a packet gets logged in messages. I've got beep.lrp installed, and seem to have found a way to make suitable not-too annoying but still audible little noises by typing beep commands at the console prompt, but I don't know how to make the system trigger the beeping automatically. I'm hoping it's going to be a fairly simple matter of adding a beep command to a script somewhere, but I don't really know which script to edit or even if it is that simple. Hopefully it'll be fairly easy to disable later too. If it's really complicated I probably won't want to bother, so if there's no simple answer please just say. Can anyone suggest anything? cheers Julian -- [EMAIL PROTECTED] www.ljchurch.co.uk ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Problems with 192.168 type ISP DHCP IP Address
I just found LEAF yesterday after my hard drive in my old linux router crashed. I thought this was a good way of doing things and I didn't want to have to buy another hard drive to put in there. I downloaded the 1.0.2 version (Dachstein Floppy Based) of LEAF and started about 5:30pm to get it working. I booted up and configured the modules for my 2 NIC cards just fine. I got DHCP working famously and from there it all went to hell. I couldn't PING anything and couldn't get out on the network from the box. After calling my Cable Modem company to insure they didn't need to flip any switches to get my going again, I scoured the mail list archives. I found the faq that told me what was happening and why I couldn't PING. It was an ipchains problem but I didn't know what to do to fix it. See my cable company doesn't give out real IPs they use a form of IPMasq themselves so my IP address is 192.168.107.40 on their internal network. Also my gateway is an internal IP address 192.168.96.0. Well all these addresses are being denied via ipchains. About midnight I finally just flushed everything in ipchains and set it up (somehow) so I could forward packets for my specific IP address and I finally got out. This approach will only work till I reboot the machine however. I would like to find out what I need to do to get the ipchains to accept my private IP via the cable company and let it forward out but still secure myself against attack. I'm at work now and don't have access to my box but can provide any info when I get home of what is needed. Thanks, Lance ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Another Question
Does the LEAF software give me any added advantage over going with something like a Linksys cable modem router? They say that have firewall settings and such and it would be nice to get rid of the extra computer. Lance ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Problems with 192.168 type ISP DHCP IP Address
At 06:54 12/02/02 -0700, Lance Robertson wrote: See my cable company doesn't give out real IPs they use a form of IPMasq themselves so my IP address is 192.168.107.40 on their internal network. Also my gateway is an internal IP address 192.168.96.0. Well all these addresses are being denied via ipchains. About midnight I finally just flushed everything in ipchains and set it up (somehow) so I could forward packets for my specific IP address and I finally got out. The solution is as simple as commenting out a line in the file /etc/ipfilter.conf. Find the part of ipfilter.conf that says # RFC 1918/1627/1597 blocks It'll be at about line 220 in a virgin Dachstein setup. A couple of lines below this you'll see the line $IPCH -A $LIST -j DENY -p all -s 192.168.0.0/16 -d 0/0 -l $* This is the one that's causing you problems, so comment it out. Backup your boot floppy and reboot, and you should be all set. cheers Julian -- [EMAIL PROTECTED] www.ljchurch.co.uk ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Problems with 192.168 type ISP DHCP IP Address
Thanks for the fast and simple response. I knew it had to be easy. Does this fix open me up to people trying to hack in via the cable modems internal network? Date: Tue, 12 Feb 2002 14:24:17 + From: Julian Church [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Leaf-user] Problems with 192.168 type ISP DHCP IP Address At 06:54 12/02/02 -0700, Lance Robertson wrote: See my cable company doesn't give out real IPs they use a form of IPMasq themselves so my IP address is 192.168.107.40 on their internal network. Also my gateway is an internal IP address 192.168.96.0. Well all these addresses are being denied via ipchains. About midnight I finally just flushed everything in ipchains and set it up (somehow) so I could forward packets for my specific IP address and I finally got out. The solution is as simple as commenting out a line in the file /etc/ipfilter.conf. Find the part of ipfilter.conf that says # RFC 1918/1627/1597 blocks It'll be at about line 220 in a virgin Dachstein setup. A couple of lines below this you'll see the line $IPCH -A $LIST -j DENY -p all -s 192.168.0.0/16 -d 0/0 -l $* This is the one that's causing you problems, so comment it out. Backup your boot floppy and reboot, and you should be all set. cheers Julian ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Problems with 192.168 type ISP DHCP IP Address
Hi Lance At 07:40 12/02/02 -0700, Lance Robertson wrote: Thanks for the fast and simple response. I knew it had to be easy. Does this fix open me up to people trying to hack in via the cable modems internal network? No. It just means that packets with source IP's in the 192.168 range aren't rejected at such an early stage. To get to your network they'll still have to go through the rest of Dachstein's firewall rule set, just as if they came from the Internet at large. Nefarious packets will still be filtered out, whether they come from your ISP's semi-local network or the other side of the world. cheers Julian -- [EMAIL PROTECTED] www.ljchurch.co.uk ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] 802.11/pcmcia/ide
I would like to make a series of statements here and appreciate anyone's comments as to their truth or idiocy. The IDE interface is not a true disk controller, like SCSI, it is more like a memory mapping, with the the controller residing in the disk drive. Either: PCMCIA is a true independent bus with its own controller chip set. Or. PCMCIA is a 68 pin adaptation which must piggy back on PCI et. al. SanDisk, et all, produce a flash memory device in the PCMCIA form factor. This device has IDE emulation logic built in (this is true). SanDisk, et al, produce an adapter, converting the 68 pin flash memory to a 50 pin IDE cable (also true). A new form factor has emerged called Compact Flash (digital cameras, 50 pin ) which can also be treated as an IDE drive ( also true). This is NOT a PCMCIA device (???) DLink, et al, are putting a 802.11b wireless card with antenna on Compact Flash. Somewhere ?? there is an effort underway to provide access point software on Linux for these IDE wireless cards. ?? ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] 802.11/pcmcia/ide
I would like to make a series of statements here and appreciate anyone's comments as to their truth or idiocy. The IDE interface is not a true disk controller, like SCSI, it is more like a memory mapping, with the the controller residing in the disk drive. IDE interfaces look like a handful of I/O ports to the system. While the first IDE/ATA devices were simple clones of dumb AT HDD Controller cards, modern ATA systems speak a high-level protocol, allowing for things like tape drives, CD-ROM burners, and is a lot more like SCSI than it used to be... Either: PCMCIA is a true independent bus with its own controller chip set. Or. PCMCIA is a 68 pin adaptation which must piggy back on PCI et. Or both...and then some. PCMCIA is actually a broad spectrum...ranging from simple memory interfaces (like a flash or DRAM add-on card) to what's basically a hot-plug ISA bus, to a full-blown PCI bus. SanDisk, et all, produce a flash memory device in the PCMCIA form factor. This device has IDE emulation logic built in (this is true). Yes, there are flash memory devices in the PCMCIA form-factor. Some of these look like IDE drives, while some of them look like memory arrays. SanDisk, et al, produce an adapter, converting the 68 pin flash memory to a 50 pin IDE cable (also true). I don't know exactly which product you're talking about, but there are some PCMCIA flash memory cards that can be attached to an IDE bus with a mechanical adaptor. A new form factor has emerged called Compact Flash (digital cameras, 50 pin ) which can also be treated as an IDE drive ( also true). This is NOT a PCMCIA device (???) Actually, compact Flash cards *CAN* be attached as a PCMCIA device, using a mechanical adapter. They can also be attached as an IDE device with a mechanical adapter, as well. 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] DHCP Relay Agent
Does anyone know if theirs a away to have Dachstein v1.02 to re-direct DHCP request to a DHCP server on a nother SubNet.. or is there and .LRP package to do this.. Something like the NT DCHP Relay AGENT feature or the Cisco IP-helper addresss thnks - Reginald R. Richardson [EMAIL PROTECTED] on 2/12/2002 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
AW: [Leaf-user] DHCP Relay Agent
Hi Reginald, hi all There is a dhcrelay.lrp package on Koon Wong's package archive. But Koon Wong's archive seems to be offline. But Rick is mirroring it: http://c0wz.steinkuehler.net/files/kwarchive/dhcrelay.lrp --- Sandro Minola | LEAF Developer (http://leaf.sourceforge.net) mailto:[EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] http://www.minola.ch| http://leaf.sourceforge.net/devel/sminola -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Reginald R. Richardson Gesendet: Dienstag, 12. Februar 2002 17:37 An: __Leaf Betreff: [Leaf-user] DHCP Relay Agent Does anyone know if theirs a away to have Dachstein v1.02 to re-direct DHCP request to a DHCP server on a nother SubNet.. or is there and .LRP package to do this.. Something like the NT DCHP Relay AGENT feature or the Cisco IP-helper addresss thnks - Reginald R. Richardson [EMAIL PROTECTED] on 2/12/2002 ___ 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] DHCP Relay Agent
At 05:36 PM 2/12/02 +0100, Reginald R. Richardson wrote: Does anyone know if theirs a away to have Dachstein v1.02 to re-direct DHCP request to a DHCP server on a nother SubNet.. or is there and .LRP package to do this.. Something like the NT DCHP Relay AGENT feature or the Cisco IP-helper addresss The underlying Linux application you want is called dhcp-relay. I don't know if it has been packaged for Dachstein. -- 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: AW: [Leaf-user] DHCP Relay Agent
thnks On Tue, 12 Feb 2002 17:49:36 +0100, Sandro Minola wrote: Hi Reginald, hi all There is a dhcrelay.lrp package on Koon Wong's package archive. But Koon Wong's archive seems to be offline. But Rick is mirroring it: http://c0wz.steinkuehler.net/files/kwarchive/dhcrelay.lrp --- Sandro Minola | LEAF Developer (http://leaf.sourceforge.net) mailto:[EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] http://www.minola.ch | http://leaf.sourceforge.net/devel/sminola -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Reginald R. Richardson Gesendet: Dienstag, 12. Februar 2002 17:37 An: __Leaf Betreff: [Leaf-user] DHCP Relay Agent Does anyone know if theirs a away to have Dachstein v1.02 to re- direct DHCP request to a DHCP server on a nother SubNet.. or is there and .LRP package to do this.. Something like the NT DCHP Relay AGENT feature or the Cisco IP-helper addresss thnks - Reginald R. Richardson [EMAIL PROTECTED] on 2/12/2002 ___ 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 - Reginald R. Richardson [EMAIL PROTECTED] on 2/12/2002 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Potential virus in IPsec pre 1.5.
hi, Here is a note from Sophos about detecting Linux viruses: So if you have the binary, running it through the Sophos scanner will give you the correct results. j. start Sophos Anti Virus currently detects all known variants of the Elf/Obsidian virus family. Infections by this family of viruses are very rare and we would not consider this virus to be 'in the wild'. ELF/Obsidian-E was first discovered in March 2000 and displays the following characteristics: This virus walks through the PATH and infects all ELF binary executables which the user has enough rights to write to. If the superuser (root) starts an infected program, it will block both infection and starting of the host program and display the message Hell no! Do not run this as root!. If you require any further information, please don't hesitate to contact me. /end -- .. . 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] dhcp connection
Hello- I am having a problem connecting to my isp's dhcp server and i don't know what i am doing wrong. I am using the Dachstein floppy on a Pentium one. Here are the steps I have made so far. I have one nic (3 com 3c509B isa irq 7 mem address 350) in the machine currently. I know the card works because I have tried it on my local network. I will add another when I get it to communicate with the dhcp server. 1) I registered the mac address with my isp (road runner). They asked me if I was running windows or MacOS. I just told them windows, even though it is Linux ( i figure that shouldn't matter what i tell them). 2) I uncommented the 3c509 line for my nic in the /etc/modules file. 3) I reboot and during the boot process it says it cannot authenticate with the dhcp server. I did a dmesg | grep eth0 : my card is on eth0. If anyone could give me a direction or help me find the problem that would be great. Thank you. Brian ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] dhcp connection
You are going to have to give us more detail than you provide in this message to get meaningful help. Please read the Troubleshooting Request HowTo, or the more concise list of needed basic information I posted to this list just a few days ago, to see the sorts of information we need. For now ... Assuming RR still uses MAC-address authentication, your step 1 should be fine. From what you do report, it looks like your step 2 is OK (but you want to be sure that the MAC address you provided to RR is the same NIC that is eth0). Your description of step 3 is simply too vague to say anything about. At 11:21 AM 2/12/02 -0600, Henning, Brian wrote: Hello- I am having a problem connecting to my isp's dhcp server and i don't know what i am doing wrong. I am using the Dachstein floppy on a Pentium one. Here are the steps I have made so far. I have one nic (3 com 3c509B isa irq 7 mem address 350) in the machine currently. I know the card works because I have tried it on my local network. I will add another when I get it to communicate with the dhcp server. 1) I registered the mac address with my isp (road runner). They asked me if I was running windows or MacOS. I just told them windows, even though it is Linux ( i figure that shouldn't matter what i tell them). 2) I uncommented the 3c509 line for my nic in the /etc/modules file. 3) I reboot and during the boot process it says it cannot authenticate with the dhcp server. I did a dmesg | grep eth0 : my card is on eth0. If anyone could give me a direction or help me find the problem that would be great. -- 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] DHCP Relay Agent
I have a dhcrelay package that should work under Dachstein, if Koon Wong's does not. Let me know if you need it and I'll send it to you. -Richard Hi Reginald, hi all There is a dhcrelay.lrp package on Koon Wong's package archive. But Koon Wong's archive seems to be offline. But Rick is mirroring it: http://c0wz.steinkuehler.net/files/kwarchive/dhcrelay.lrp --- Sandro Minola | LEAF Developer (http://leaf.sourceforge.net) mailto:[EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] http://www.minola.ch| http://leaf.sourceforge.net/devel/sminola -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Reginald R. Richardson Gesendet: Dienstag, 12. Februar 2002 17:37 An: __Leaf Betreff: [Leaf-user] DHCP Relay Agent Does anyone know if theirs a away to have Dachstein v1.02 to re-direct DHCP request to a DHCP server on a nother SubNet.. or is there and .LRP package to do this.. Something like the NT DCHP Relay AGENT feature or the Cisco IP-helper addresss thnks - Reginald R. Richardson [EMAIL PROTECTED] on 2/12/2002 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] dhcp connection
On Tuesday 12 February 2002 11:21, Henning, Brian wrote: 1) I registered the mac address with my isp (road runner). They asked me if I was running windows or MacOS. I just told them windows, even though it is Linux ( i figure that shouldn't matter what i tell them). 2) I uncommented the 3c509 line for my nic in the /etc/modules file. 3) I reboot and during the boot process it says it cannot authenticate with the dhcp server. Brian, The results of ip addr show and ip route show would be helpful here? What is the failure message in the dhclient request (in dmesg)? The How To Request Help FAQ in the LEAF FAQ section is very helpful in getting us some good information to go from http://sourceforge.net/docman/display_doc.php?docid=1891group_id=13751 This being said, some RR ISP's require a valid subnet gateway address before giving a lease (as does mine). I would enter your valid default gateway address for you ISP on the eth0 gateway line in /etc/network.conf. You can then check your change with the commands: dhclient stop dhclient start svi network reload ip addr show ip route show ping www.yahoo.com Another smaller possibility is the system not liking your irq or io settings. I've never had a problem with irq's 10 11 and io's 300 320. You did disable PnP and select server instead of DOS/OS2 options right??? Good cards, but some setup is required. I've covered this card @ http://www.geocities.com/guitarlynn/3c509.html I hope this helps! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] LRP Dachstein Vs. Coyote.
I asked the same question of Coyote developer Joshua Jackson, and he told me [snip] Coyote Linux was split from the LRP over 2 years ago and very little, if anything is still compatible. While most .lrp packages can be retro-fitted to work with Coyote due to the fact that both distros used glibc 2.0.7, the init system for Coyote was completely rewritten. [/snip] I have been told, (and could be wrong), that Dachstein uses glibc 2.0.7. So there are similarities, but incompatibilities. -Nathaniel Jason C. Leach wrote: hi, What are some of the significant differences between Coyote and Charls' versionf of LRP? j. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Net-SNMP vulnerability??
Hey all, I found a couple of bits and pieces of information on the 'net regarding to the BSD release of Net-snmp and certain SNMP vulnerabilities. I'm not sure whether this impacts the LEAF version but I figured I'd post it anyways just in case - sorry for wasting your time if it doesn't. http://www.cert.org/advisories/CA-2002-03.html Basically what it says is if you are using a version of Net-SNMP below 4.2.3 (I believe the current release is 4.2.2) you are vulnerable. S _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] SSH access error
Running DCD 102 booting off a floppy using openssh 3.0p1. When I attempt to ssh into the DCD router from the local network using the latest puTTY client, I receive the following error message: Network error: connection refused. The hosts.allow file allows access from the local network as follows: ALL: 192.168.1.0/255.255.255.0 ps aux shows the following: PID Uid Stat Command 1 root Sinit 2 root S[kflushd] 3 root S[kupdate] 4 root S[kswapd] 5 root S[keventd] 6 root S[mdrecoveryd] 1086 root S/usr/sbin/dhclient eth0 1275 root S/sbin/syslogd -m 240 1277 root S/sbin/klogd 1281 root S/usr/sbin/inetd 1285 root S/usr/sbin/watchdog 1288 root S/usr/sbin/cron 1309 tinydns S/usr/bin/tinydns 1334 dnscache S/usr/bin/dnscache 1335 root S-sh 1336 root S/sbin/getty 38400 tty2 2331 sh-httpd Ssh /usr/sbin/sh-httpd 2367 sh-httpd Ssh /var/sh-www/cgi-bin/viewsys 2368 sh-httpd Ssleep 1 2369 sh-httpd Scat 2370 sh-httpd Ssh /var/sh-www/cgi-bin/viewsys 2447 sh-httpd Rps aux I don't see any entry for the sshd daemon. I followed the instructions in the DCD documentation for generating the keys and made a partial backup. But no dice. What am I missing here? ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Re: Obsidian.E virus?
How much effor would be required to update DUCLING to include use the newer version of FreeS/wan? I would guess not a lot. By updating the potential problems are removed and a better version is obtained. Besides maybe needing a second diskette any reason that the external interface be analog modem instead of an ethernet connection? The reason I ask someone asked me, so thought would ask here. Thank you. Larry Platzek [EMAIL PROTECTED] On Mon, 11 Feb 2002, Charles Steinkuehler wrote: Date: Mon, 11 Feb 2002 10:45:42 -0600 From: Charles Steinkuehler [EMAIL PROTECTED] To: Duncan Napier [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Leaf-user] Re: Obsidian.E virus? Message: 1 Date: Fri, 8 Feb 2002 08:21:49 -0600 I have been informed that Panda Antyvirus Platinum on Windows XP reports that the file /usr/bin/tr contained as part of ipsec.lrp (apparently version 1.5 or earlier, since there is no tr command included in my latest ipsec 1.91 package) is infected by the Linux/Obsidian.E virus. I'm currently trying to verify this, and track down exactly what the Obsidian virus is supposed to do. If anyone has any information on this virus, or can help verify the file is/is not infected, I would greatly appreciate it. I currently have no idea if this is simply a false positive, or if there is actually a problem, but wanted to let everyone know just in case. Any news on the status of this? I am somewhat concerned too, since the DUCLING release uses the Eigerstein FreeS/WAN 1.5 distribution. It is now available at LEAF: http://sourceforge.net/project/showfiles.php?group_id=13751 courtey of Mike Noyes. Should I ask for it to be taken down? No, I think everything is OK. For those concerned about the reported Obsidian virus contained in the /usr/bin/tr utility of my IPSec packages, here's the current status: - Marcin Bulandra reported that Panda Antyvirus Platinum on his Windows XP machhine listed /usr/bin/tr (contained within the ipsec.lrp tar.gz file) as being infected with the Obsidian.E virus. - Several folks have checked this file with alternate virus scanners, and the file is not listed as infected - The information I have been able to gather online indicates that Obsidian.E is a linux elf virus, which infects files by pre-pending it's apx 8K virus payload to an executable file, creating a file with two elf headers (one for the original file, and one for the virus. - Examination of the file in question indicates only a single elf header - The file-size (19008 bytes) does not seem to allow for an 8K virus payload...this is one of the smallest tr binaries on any of my systems. - Examination of the output of strace does not reveal anything that looks out of the ordinary (ie virus code running prior to the actual tr functions) when running the tr utility I suspect at this point that something about how Panda Antyvirus Platinum is scanning files for the Obsidian virus yields a false positive for the tr binary included in my older IPSec 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 mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Loading packages via TFTP on boot
Hello all, I have been toying with Oxygen 1.9.1 with loading lrp modules from the network on bootup. I have succesfully gotten packages loaded on bootup via HTTP using the packagelist directive in the oxygen.cfg file, but when I attempt to do the same via TFTP it fails. I know my TFTP server is operational because once booted and in a shell on my LEAF router I can transfer files using the tftp client without any problems. I am also certain that the network is configured and operational at the stage of bootup when I attempt to load the packages because it loads packages via HTTP. The line I am using is as follows: # this fails packagelist tftp://192.168.2.5/lrp.conf # this works packagelist http://192.168.2.5/oxygen/lrp.conf of course the lrp.conf file shown in the TFTP URL refers to the root of the TFTP directory, and the HTTP URL refers to a subdirectory off of the root docs directory of my http server. any ideas on why TFTP would not work during boot? __ 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] SSH access error
I guess I should say that I am quite familiar with SSH in general. I am unsure whether I should copy the public key from the sshd server to the client. Or whether I should enable SSH1 or SSH2 authentication on the client machine. I worked on an Eigerstein set-up in the past and it was relatively simple to set up SSH on that machine. I did not copy the key over to the client machine nor did I make any changes to the client configuration. Unfortunately it isn't so simple with this Dachstein CD set-up... But then I've only set up SSH once before. Any pointers or tips would be greatly appreciated. ~Doug -Original Message- From: Doug Sampson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 12:33 PM To: '[EMAIL PROTECTED]' Subject: SSH access error Running DCD 102 booting off a floppy using openssh 3.0p1. When I attempt to ssh into the DCD router from the local network using the latest puTTY client, I receive the following error message: Network error: connection refused. The hosts.allow file allows access from the local network as follows: ALL: 192.168.1.0/255.255.255.0 ps aux shows the following: PID Uid Stat Command 1 root Sinit 2 root S[kflushd] 3 root S[kupdate] 4 root S[kswapd] 5 root S[keventd] 6 root S[mdrecoveryd] 1086 root S/usr/sbin/dhclient eth0 1275 root S/sbin/syslogd -m 240 1277 root S/sbin/klogd 1281 root S/usr/sbin/inetd 1285 root S/usr/sbin/watchdog 1288 root S/usr/sbin/cron 1309 tinydns S/usr/bin/tinydns 1334 dnscache S/usr/bin/dnscache 1335 root S-sh 1336 root S/sbin/getty 38400 tty2 2331 sh-httpd Ssh /usr/sbin/sh-httpd 2367 sh-httpd Ssh /var/sh-www/cgi-bin/viewsys 2368 sh-httpd Ssleep 1 2369 sh-httpd Scat 2370 sh-httpd Ssh /var/sh-www/cgi-bin/viewsys 2447 sh-httpd Rps aux I don't see any entry for the sshd daemon. I followed the instructions in the DCD documentation for generating the keys and made a partial backup. But no dice. What am I missing here? ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] dhcp connection
On Tuesday 12 February 2002 13:19, Henning, Brian wrote: Thanks for the valuable information. It gives me things to try. Yep, hard to say w/o more info if these don't work. what does the command 'svi network reload' do? It stops, then restarts the /etc/init.d/network boot script. This will refresh any options and changes that are set by this scripts The link for the driver disk (3c5x9cfg.exe) on your page is bad. I went on the web and found an older version of it but, i could not find a recent version. also, I could not find it on 3com's site? do you think you could send me a copy of the one you have? The old one is the only one in existence ... 3Com quit destributing it sometime ago. Donald Becker has one for Linux at his site, but I haven't bothered to try it yet. I'll check on my link to see why it's dead. Maybe Geocities decided they didn't like it ;) Thanks again, np -- ~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: Obsidian.E virus?
Hi, On Tue, 12 Feb 2002, Larry Platzek wrote: How much effor would be required to update DUCLING to include use the newer version of FreeS/wan? Probably not much. The easiest route would require stripping the IPSec-enabled Dachstein distribution down. The purpose of DUCLING was to put a working VPN/Firewall on a single diskette for people to play with. It was more of a proof-of-concept than a serious tool. As far as going adding a second floppy ... its been done. Dachstein works well, unless you feel you can improve upon this. I don't know if everything would still fit (I believe it still would). I found the most time-consuming part of the whole thing was testing and documentation. I would readily do an update, but I'm pretty busy right now. If anyone wishes to update DUCLING, I would gladly encourage them to do so. Regards, Duncan. On Tue, 12 Feb 2002, Larry Platzek wrote: How much effor would be required to update DUCLING to include use the newer version of FreeS/wan? I would guess not a lot. By updating the potential problems are removed and a better version is obtained. Besides maybe needing a second diskette any reason that the external interface be analog modem instead of an ethernet connection? The reason I ask someone asked me, so thought would ask here. Thank you. Larry Platzek [EMAIL PROTECTED] On Mon, 11 Feb 2002, Charles Steinkuehler wrote: Date: Mon, 11 Feb 2002 10:45:42 -0600 From: Charles Steinkuehler [EMAIL PROTECTED] To: Duncan Napier [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Leaf-user] Re: Obsidian.E virus? Message: 1 Date: Fri, 8 Feb 2002 08:21:49 -0600 I have been informed that Panda Antyvirus Platinum on Windows XP reports that the file /usr/bin/tr contained as part of ipsec.lrp (apparently version 1.5 or earlier, since there is no tr command included in my latest ipsec 1.91 package) is infected by the Linux/Obsidian.E virus. I'm currently trying to verify this, and track down exactly what the Obsidian virus is supposed to do. If anyone has any information on this virus, or can help verify the file is/is not infected, I would greatly appreciate it. I currently have no idea if this is simply a false positive, or if there is actually a problem, but wanted to let everyone know just in case. Any news on the status of this? I am somewhat concerned too, since the DUCLING release uses the Eigerstein FreeS/WAN 1.5 distribution. It is now available at LEAF: http://sourceforge.net/project/showfiles.php?group_id=13751 courtey of Mike Noyes. Should I ask for it to be taken down? No, I think everything is OK. For those concerned about the reported Obsidian virus contained in the /usr/bin/tr utility of my IPSec packages, here's the current status: - Marcin Bulandra reported that Panda Antyvirus Platinum on his Windows XP machhine listed /usr/bin/tr (contained within the ipsec.lrp tar.gz file) as being infected with the Obsidian.E virus. - Several folks have checked this file with alternate virus scanners, and the file is not listed as infected - The information I have been able to gather online indicates that Obsidian.E is a linux elf virus, which infects files by pre-pending it's apx 8K virus payload to an executable file, creating a file with two elf headers (one for the original file, and one for the virus. - Examination of the file in question indicates only a single elf header - The file-size (19008 bytes) does not seem to allow for an 8K virus payload...this is one of the smallest tr binaries on any of my systems. - Examination of the output of strace does not reveal anything that looks out of the ordinary (ie virus code running prior to the actual tr functions) when running the tr utility I suspect at this point that something about how Panda Antyvirus Platinum is scanning files for the Obsidian virus yields a false positive for the tr binary included in my older IPSec 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 -- -- Duncan Napier email:[EMAIL PROTECTED] Napier Systems Research Ph:(604) 781-2398 http://www.napiersys.bc.ca ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Problems with 192.168 type ISP DHCP IP Address
Lance Robertson wrote: Thanks for the fast and simple response. I knew it had to be easy. Does this fix open me up to people trying to hack in via the cable modems internal network? If you allow all the private 192.168 address range through, I would think that you are not as secure as you would be if you didn't. Are you saying that all the users on your cable loop all have 192.168 addresses? snip Find the part of ipfilter.conf that says # RFC 1918/1627/1597 blocks It'll be at about line 220 in a virgin Dachstein setup. A couple of lines below this you'll see the line $IPCH -A $LIST -j DENY -p all -s 192.168.0.0/16 -d 0/0 -l $* You could also experiment with adding the particular computers that keep hitting the logs in /etc/network.conf SILENT_DENY=192.168.this.machine _port 192.168.next.macnine_port My silent deny is like three or four lines long each machine separated by a space. Here is the nice part about SILENT_DENY. It inserts the deny rules without logging at the front end of the filter AHEAD of any general rules. You can still find out how many packets have been denied by a particular rule with weblet under firewall rules. In short you deny specific targets that you don't want to get through or get logged and the other bad boys get logged. You could have the general rule open to all 192.168 traffic and still block specific machines from that network that were showing up in the log. You can edit network.conf or ipfilter.conf and just do a svi network ipfilter reload to try out your changes. When you get them the way you want them, then backup etc. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] SSH access error
On Tuesday 12 February 2002 15:08, Doug Sampson wrote: I guess I should say that I am quite familiar with SSH in general. I am unsure whether I should copy the public key from the sshd server to the client. Or whether I should enable SSH1 or SSH2 authentication on the client machine. I worked on an Eigerstein set-up in the past and it was relatively simple to set up SSH on that machine. I did not copy the key over to the client machine nor did I make any changes to the client configuration. Unfortunately it isn't so simple with this Dachstein CD set-up... But then I've only set up SSH once before. Any pointers or tips would be greatly appreciated. Doug, Are you loading the sshd package? This isn't stock on the DF floppy. Their are server, client, and key packages for DF. You said floppy in the first post, now the cd version I'm getting confused, exact details of what you _are_ using and what you have done will help. When you back-up the key, you either have to back up root.lrp or add /root to local.lrp... otherwise it's lost forever (or every reboot). What version of ssh you use will depend on how you set sshd up, I believe the default config will use either You don't need to copy a key over unless you get tired of logging in. Hope this helps, -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Net-SNMP vulnerability??
Simon Bolduc wrote: I found a couple of bits and pieces of information on the 'net regarding to the BSD release of Net-snmp and certain SNMP vulnerabilities. I'm not sure whether this impacts the LEAF version but I figured I'd post it anyways just in case - sorry for wasting your time if it doesn't. http://www.cert.org/advisories/CA-2002-03.html Basically what it says is if you are using a version of Net-SNMP below 4.2.3 (I believe the current release is 4.2.2) you are vulnerable. The version that I released last weekend is the *most current* -- v4.2.3 -- compiled directly from the source on http://sourceforge.net/project/showfiles.php?group_id=12694 -- 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] SSH access error
On Tuesday 12 February 2002 16:05, Doug Sampson wrote: Am running DCD 102 booting off a floppy because the mobo doesn't boot off a CD drive. openssh.lrp is stock on a DCD 102. I have /usr/sbin/sshd in my ps ax, so as I thought, you are _not_ loading the package. Check the lrpkg.cfg file on your floppy. The lrpkg.cfg file overrides the LRP= line in syslinux.cfg. You will also need to add this line to /etc/hosts.allow: sshd: 192.168.1 127. Am backing up sshd.lrp partially as described in Steinkuehler's README.txt documentation on the LRP-CD. Do I need to back up the root.lrp as well as the sshd.lrp each time a new key is generated? I didn't have any luck with that, but I am also running a stand-alone cd, so I can't say for sure. I always backup both to make sure, someone else might shed better light on this for me. Am setting it up the way Steinkuehler described in his documentation. All I want to do is set up SSH and get going. There are multiple problems I am having with the router but must solve the sshd thing in order to do a copy and paste function of relevant information for troubleshooting purposes. Yep, sneakernet comes in handy in times such as this. There are a lot of lib* dependancies with DCD you have to check. It has been working great for me here for about 4 months w/o a reboot. Hope what I've given is helpful. Let me know if there's anything else I should provide. Yep, it has helped, thx. You really have to get sshd loaded before you're going to have any luck. Good luck! -- ~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] SSH access error
There are multiple problems I am having with the router but must solve the sshd thing in order to do a copy and paste function of relevant information for troubleshooting purposes. Ahaa. The copy and paste problem. It's great to have ssh to help, but it's not always there. ip addr show /tmp/pout 21 will place the output of that command in the file /tmp/pout. mount -t msdos /dev/fd0u1680 /mnt will mount your LEAF floppy. gzip -c /tmp/pout /mnt/pout.gz zip the file and puts it on the floppy. umount /mnt unmount the floppy. Now you can take the diskette over to any other computer and copy it on there because it's a DOS format diskette. Regards, Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] SSH access error
I have /usr/sbin/sshd in my ps ax, so as I thought, you are _not_ loading the package. Check the lrpkg.cfg file on your floppy. The lrpkg.cfg file overrides the LRP= line in syslinux.cfg. You will also need to add this line to /etc/hosts.allow: sshd: 192.168.1 127. I already have the config file listed in the lrpkg.cfg file. However I had appended :R to it- i.e. sshd:R. I took the :R parameter out and rebooted. Upon rebooting it reports as follows: sshd dev/cdrom dev/fd0u1680 (nf!) I don't understand why I have to specify sshd: 192.168.1.xxx in the /etc/hosts.allow file when it contains ALL: 192.168.1.0/255.255.255.0? This line exists in DCD's default hosts.allow file. Am backing up sshd.lrp partially as described in Steinkuehler's README.txt documentation on the LRP-CD. Do I need to back up the root.lrp as well as the sshd.lrp each time a new key is generated? I didn't have any luck with that, but I am also running a stand-alone cd, so I can't say for sure. I always backup both to make sure, someone else might shed better light on this for me. Looks like I have to regenerate the keys and back up root.lrp as well as sshd.lrp, eh? ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] SSH access error
I noticed two entries for sshd in the back up menu of LRCFG. I changed the first entry's backup destination back to /dev/cdrom leaving the other entry pointing to the dev/fd0u1680 as its backup destination. Upon rebooting, sshd loaded correctly and now I am able to ssh in from my Windoze machine! I did not have to add an entry in the hosts.allow file as Guitarlynn suggested. I did not regenerate the keys- I merely used the ones that were originally generated. This means that root.lrp does not have to be backed up after the keys are generated- only the local configuration file of the sshd.lrp. Now that I have conquered the ssh thing (hurrah for this newb!), on to the silent_deny issue! Which will be in the next post from me! ~Doug I have /usr/sbin/sshd in my ps ax, so as I thought, you are _not_ loading the package. Check the lrpkg.cfg file on your floppy. The lrpkg.cfg file overrides the LRP= line in syslinux.cfg. You will also need to add this line to /etc/hosts.allow: sshd: 192.168.1 127. I already have the config file listed in the lrpkg.cfg file. However I had appended :R to it- i.e. sshd:R. I took the :R parameter out and rebooted. Upon rebooting it reports as follows: sshd dev/cdrom dev/fd0u1680 (nf!) I don't understand why I have to specify sshd: 192.168.1.xxx in the /etc/hosts.allow file when it contains ALL: 192.168.1.0/255.255.255.0? This line exists in DCD's default hosts.allow file. Am backing up sshd.lrp partially as described in Steinkuehler's README.txt documentation on the LRP-CD. Do I need to back up the root.lrp as well as the sshd.lrp each time a new key is generated? I didn't have any luck with that, but I am also running a stand-alone cd, so I can't say for sure. I always backup both to make sure, someone else might shed better light on this for me. Looks like I have to regenerate the keys and back up root.lrp as well as sshd.lrp, eh? ~Doug ___ 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] silent_deny not working
Awhile ago was a post to this newsgroup about repeat entries in the message logs by a DHCP server as follows: Feb 12 16:18:00 CX269409-C kernel: Packet log: input DENY eth0 PROTO=17 10.8.238.1:67 255.255.255.255:68 L=328 S=0x00 I=30881 F=0x T=255 (#10) I'm on a Cox Communication network and this looks like a DHCP server sending out broadcast packets. The post earlier said to put udp_108.238.1_67 after the SILENT_DENY variable in network.conf as follows: SILENT_DENY=udp_10.8.238.1_67 Even with that in, the logs are still filling up. After 30 minutes the logs show approximately 2,500 of these! Am running DCD 102. What am I missing? ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] silent_deny not working
Doug Sampson wrote: Awhile ago was a post to this newsgroup about repeat entries in the message logs by a DHCP server as follows: Feb 12 16:18:00 CX269409-C kernel: Packet log: input DENY eth0 PROTO=17 10.8.238.1:67 255.255.255.255:68 L=328 S=0x00 I=30881 F=0x T=255 (#10) I'm on a Cox Communication network and this looks like a DHCP server sending out broadcast packets. The post earlier said to put udp_108.238.1_67 after the SILENT_DENY variable in network.conf as follows: SILENT_DENY=udp_10.8.238.1_67 Even with that in, the logs are still filling up. After 30 minutes the logs show approximately 2,500 of these! Am running DCD 102. What am I missing? I maintain that this is the cleanest solution: http://sourceforge.net/mailarchive/message.php?msg_id=686657 -- 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] silent_deny not working
On Tuesday 12 February 2002 18:33, Doug Sampson wrote: Awhile ago was a post to this newsgroup about repeat entries in the message logs by a DHCP server as follows: Feb 12 16:18:00 CX269409-C kernel: Packet log: input DENY eth0 PROTO=17 10.8.238.1:67 255.255.255.255:68 L=328 S=0x00 I=30881 F=0x T=255 (#10) I'm on a Cox Communication network and this looks like a DHCP server sending out broadcast packets. The post earlier said to put udp_108.238.1_67 after the SILENT_DENY variable in network.conf as follows: SILENT_DENY=udp_10.8.238.1_67 # SILENT_DENY=ProtoNumber_SourceAddress/Netmask_DestinationPort Try: SILENT_DENY=udp_10.8.238.1_68 -or- SILENT_DENY=17_10.8.238.1_68 -or drop the destination port altogether- SILENT_DENY=all_10.8.238.1 The last field is the destination port rather than the sender's port and you don't have to designate it at all if you don't want to. Hope this helps, -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] silent_deny not working
I maintain that this is the cleanest solution: http://sourceforge.net/mailarchive/message.php?msg_id=686657 I've copied your proposed solution here for reference. # cat /etc/ipchains.input $IPCH -I input -j DENY -p all -s 0/0 -d 255.255.255.255 -i $EXTERN_IF Exactly what does the ipchain statement say? Exactly what does it deny? Obviously I'm not at all familiar with ipchaining... and I want to understand it fully before I implement it... ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Re: Obsidian.E virus?
On Tue, 12 Feb 2002, Larry Platzek wrote: How much effor would be required to update DUCLING to include use the newer version of FreeS/wan? Probably not much. The easiest route would require stripping the IPSec-enabled Dachstein distribution down. The purpose of DUCLING was to put a working VPN/Firewall on a single diskette for people to play with. It was more of a proof-of-concept than a serious tool. As far as going adding a second floppy ... its been done. Dachstein works well, unless you feel you can improve upon this. I don't know if everything would still fit (I believe it still would). I found the most time-consuming part of the whole thing was testing and documentation. I would readily do an update, but I'm pretty busy right now. If anyone wishes to update DUCLING, I would gladly encourage them to do so. If anyone wants to do this, it should be pretty easy. Dachstein is substantially smaller than EigerStein, so AFAIK, you'd basically only have to rip out the fluff (ie weblet, dhcpd c...maybe some NIC modules too...) from Dachstein to get enough space to add ipsec.lrp. I *think* things are enough smaller now you could put the DUCLING functionality on a 1680K disk, rather than a 1720K disk... 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 not working
# SILENT_DENY=ProtoNumber_SourceAddress/Netmask_DestinationPort Try: SILENT_DENY=udp_10.8.238.1_68 -or- SILENT_DENY=17_10.8.238.1_68 -or drop the destination port altogether- SILENT_DENY=all_10.8.238.1 The last field is the destination port rather than the sender's port and you don't have to designate it at all if you don't want to. Ah, the destination port instead of the source port! I tried using 68 as the destination port and now the logs have stopped filling up with entries from Cox's DHCP server! Hope this helps, Yup, sure does! Thanks! ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] silent_deny not working
Doug Sampson wrote: I maintain that this is the cleanest solution: http://sourceforge.net/mailarchive/message.php?msg_id=686657 I've copied your proposed solution here for reference. # cat /etc/ipchains.input $IPCH -I input -j DENY -p all -s 0/0 -d 255.255.255.255 -i $EXTERN_IF Exactly what does the ipchain statement say? Exactly what does it deny? Obviously I'm not at all familiar with ipchaining... and I want to understand it fully before I implement it... $IPCH -- /etc/ipfilter.conf: IPCH=/sbin/ipchains --no-warnings -d 255.255.255.255 -- destination address -i $EXTERN_IF -- interface via which a packet is received -I input-- Insert one or more rules in the selected chain as the given rule number -j DENY -- what to do if the packet matches this rule -p all -- protocol of the rule or of the packet to check -s 0/0 -- Source specification I struggled with this for sometime last December, after being dragged into attbi.com. Since it is possible that that source ip can change and that I have never found any reason to _log_ packets broadcast to the entire universe (e.g., -d 255.255.255.255); therefore, I conclude that such packets deserve anonymity in that great bit bucket somewhere near /dev/null . . . HTH -- 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] NIC card switching
I have a 3C509b and a RTL8139 PCI card in my router. The rtl8139 is assigned eth0 while 3c509b is assigned eth1. The router runs DCD 102. The rtl8139 is a 10/100 PCI card and thus I would like to use as the internal card instead of as the external card. The external card connects to a cable modem. I've identified two possibilities for switching these two cards around as follows: 1) rearrange the order in which the NICs are listed in the /etc/modules file. 2) identify eth1 as the external card in /etc/network.conf and allow dlclient to retrieve an ip address for eth0. What's the best way to switch so that the rtl8139 card is assigned as eth1 and the 3c509b is eth0? ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] DCD port forwarding
I'm having trouble port forwarding on a DCD 102 router. Standard
public/private network set-up with a web server behind the router. Since I'm
on a Cox network, I cannot run a web server using port 80 as it's being
blocked by Cox. So I've resorted to using port 8080 in the past which has
worked out rather well. However, since switching to Dachstein, I've never
been able to get web site requests redirected to the web server via port 8080.
Here's my configuration files:
# ip addr
1: lo: LOOPBACK,UP mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope global lo
2: ipsec0: NOARP mtu 0 qdisc noop qlen 10
link/ipip
3: ipsec1: NOARP mtu 0 qdisc noop qlen 10
link/ipip
4: ipsec2: NOARP mtu 0 qdisc noop qlen 10
link/ipip
5: ipsec3: NOARP mtu 0 qdisc noop qlen 10
link/ipip
6: brg0: BROADCAST,MULTICAST mtu 1500 qdisc noop
link/ether fe:fd:09:00:3f:ff brd ff:ff:ff:ff:ff:ff
7: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:40:f4:2a:f3:d4 brd ff:ff:ff:ff:ff:ff
inet 68.7.207.39/22 brd 68.7.207.255 scope global eth0
8: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:60:97:78:8c:16 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1
# ip route
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254
68.7.204.0/22 dev eth0 proto kernel scope link src 68.7.207.39
default via 68.7.204.1 dev eth0
# netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 65630 0 0 09840 0 0 0 BMRU
eth1 1500 0 16628 3 0 0 18807 0 0 0 BMRU
lo 3924 0 7 0 0 0 7 0 0 0 LRU
# network.conf
# ICMP types to open
# Indexed list: SrcAddr/Mask type [ DestAddr[/DestMask] ]
#EXTERN_ICMP_PORT0=0/0 : 1.1.1.12
## UDP Services open to outside world
# Space seperated list: srcip/mask_dstport
# NOTE: bootpc port is used for dhcp client
# EXTERN_UDP_PORTS=0/0_domain 0/0_bootpc
EXTERN_UDP_PORTS=0/0_domain
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_UDP_PORT0=0/0 domain
#EXTERN_UDP_PORT1=5.6.7.8 500 1.1.1.12
# TCP services open to outside world
# Space seperated list: srcip/mask_dstport
EXTERN_TCP_PORTS=216.70.236.234/29_ssh 0/0_www 0/0_1023 0/0_8080
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_TCP_PORT0=5.6.7.8 domain 1.1.1.12
#EXTERN_TCP_PORT1=0/0 www
#EXTERN_TCP_PORT0=216.70.236.234/29 ssh
#EXTERN_TCP_PORT1=0/0 www
#EXTERN_TCP_PORT2=0/0 1023
#EXTERN_TCP_PORT3=0/0 8080
# Generic Services open to outside world
# Space seperated list: protocol_srcip/mask_dstport
#EXTERN_PORTS=50_5.6.7.8 51_5.6.7.8
# -or-
# Indexed list: Protocol SrcAddr/Mask [ DestAddr[/DestMask] ]
#EXTERN_PROTO0=50 5.6.7.8/32
#EXTERN_PROTO1=51 5.6.7.8/32
#EXTERN_PROTO0=8080 0/0 192.168.1.1/32
##
#
# Internal Interface
##
#
# Comment 3 settings below for no internal network (DMZ only configuration)
INTERN_IF=eth1# Internal Interface
INTERN_NET=192.168.1.0/24 # One (or more) Internal network(s)
INTERN_IP=192.168.1.254 # IP number of Internal Interface
# (to allow forwarding to external IP)
MASQ_SWITCH=YES # Masquerade internal network to outside
# world - YES/NO
# These services are not masqueraded from int to ext/DMZ, preventing access
# Space seperated list: proto_destIP/mask_port
#NOMASQ_DEST=tcp_0/0_ssh
# Override for above...only the listed dest IP's can be accessed
# Space seperated list: proto_destIP/mask_port
#NOMASQ_DEST_BYPASS=tcp_10.0.0.1_ssh
##
#
# Port Forwarding
##
#
# Remember to open appropriate holes in the firewall rules, above
# Uncomment following for port-forwarded internal services.
# The following is an example of what should be put here.
# Tuples are as follows:
# protocol_local-ip_local-port_remote-ip_remote-port
#INTERN_SERVERS=tcp_${EXTERN_IP}_ftp_192.168.1.1_ftp
tcp_${EXTERN_IP}_smtp_192.
INTERN_SERVERS=tcp_${EXTERN_IP}_8080_192.168.1.1_8080
# These lines use the primary external IP address...if you need to
port-forward
# an aliased IP address, use the INTERN_SERVERS setting above
#INTERN_FTP_SERVER=192.168.1.1 # Internal FTP server to make available
INTERN_WWW_SERVER=192.168.1.1 # Internal WWW server to make available
#INTERN_SMTP_SERVER=192.168.1.1 # Internal SMTP server to make available
#INTERN_POP3_SERVER=192.168.1.1 # Internal POP3 server to make available
[Leaf-user] dhcp connection revisited
Hello- I am still having a problem connecting to, road runner, my isp's dhcp server and i don't know what i am doing wrong. I am using the Dachstein floppy on a Pentium one. Here is what i have done so far. I registered the mac address with my isp (road runner) nic config -- irq: 10 memory io address: 300 Boot ROM: disable Transever type: auto network driver optimize: server max modem speed: 9600 baud pnp: disable full duplex: disable machine config --- I uncommented the 3c509 line for my nic in the /etc/modules file. eth0_DEFAULT_GW=66.41.136.1 commands ip addr show 1: lo LOOPBACK, UP mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope global lo 2: eth0 BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:06:97:79:7B:7C brd ff:ff:ff:ff:ff:ff ip route show #returns nothing inetstat -nr #returns nothing errors: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 No DHCPOFFER recieved no working leases in persistant database. Thanks for the help so far. I hope this is a better discription of my problem... Brian ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] DCD RAMLOG
I have a Pentium 166 MHz router that has 82 MB RAM running DCD 102. It seems to me that the default ramlog configuration was designed for machines with smaller amount of RAM. Here is what I've done to my router: #/ETC/RAMDISK.CONF: # [-c | -l filename] [-nXX] [-iXX] /dev/name [blocks] dev/ram1 8192 # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procnoauto 0 0 /dev/ram0 / minix rw,noauto 1 1 /dev/ram1 /var/logminix defaults1 2 # free total:used:free: shared: buffers: cached: Mem: 81174528 21143552 60030976 6213632 8908800 4788224 Swap:000 MemTotal: 79272 kB MemFree: 58624 kB MemShared: 6068 kB Buffers: 8700 kB Cached:4676 kB SwapTotal:0 kB SwapFree: 0 kB What can I do to optimize the use of available RAM on this router? ~Doug ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] dhcp connection revisited
On Tuesday 12 February 2002 23:08, Henning, Brian wrote: Hello- I am still having a problem connecting to, road runner, my isp's dhcp server and i don't know what i am doing wrong. I am using the Dachstein floppy on a Pentium one. Here is what i have done so far. snip good information The good news is that the hardware looks fine, but your not getting a lease from the DHCP server. Put a blank, formatted floppy in your drive and get us the network config: mount -t msdos /dev/fd0 /mnt cat /etc/network.conf /mnt/network.txt umount /mnt Then you can cut-n-paste the network.txt file on the floppy to your email client (in any OS) so we can figure out what is wrong with the network config. Almost there! Thx -- ~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] dhcp connection revisited
What you've sent us so far looks OK from the Dachstein end. Why you aren't getting a lease is puzzling. Lynn already asked some of the right questions. Let me ask a few more. 1. How is the router *physically* connected to RR? It should be a regular (not crossover) Ethernet cable to an RJ45 port on the cable modem. Do you *know* that the cable is good (*know* = does it work with other Ethernet connections)? Do you know that the cable modem's connection to RR is good? 2. My memory of 3C509 NICs is hazy, but I seem to recall that they had multiple connectors. Are you sure the UTP connector (the RJ45 one) is active on the NIC, and not the BNC connector (if there is one)? 3. I see you specified a gateway address manually -- eth0_DEFAULT_GW=66.41.136.1 The gateway address typically comes as part of the lease information. Why are you setting the value manually? At 11:08 PM 2/12/02 -0600, Henning, Brian wrote: Hello- I am still having a problem connecting to, road runner, my isp's dhcp server and i don't know what i am doing wrong. I am using the Dachstein floppy on a Pentium one. Here is what i have done so far. [...] DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 No DHCPOFFER recieved no working leases in persistant database. [...] -- 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] dhcp connection revisited
On Wednesday 13 February 2002 00:47, Ray Olszewski wrote: 3. I see you specified a gateway address manually -- eth0_DEFAULT_GW=66.41.136.1 The gateway address typically comes as part of the lease information. Why are you setting the value manually? I asked him to do this, it doesn't hurt and some ISP's (like mine Cox/RR locally) requires a valid subnet (ie... 111.222.333.444 does not work). It's unusual, but I can validate that some do. Thanks Ray! -- ~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
