[Leaf-user] pppd problem
Hello, Sorry to bug you guys like this, and it's a sunday! Anyways, I'm really desperate. I've already sent a message to the LEAF user mailing list, and still awaiting any replies. I'm having a permission denied problem if I run pppd using a non-root account. This is the reason why I can't log (dial-in) non-root accounts into my Dachstein box. If I were to change the property of the binary to execute on all users (chmod 777 pppd), I get a -pppd: must be root to run -pppd, since it is not setuid-root message. If I change the permission further in order to get a suid bit (chmod 4755 pppd), the said message remains, and more than that, the binary will fail to work at all. This problem applies to all pppd v2.3.xx found on the LEAF site. Are there any special requirements on the accounts that I must create in order for pppd (or login???) to accept my dial-in attemps? Any suggestions? Thanks. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] problems with IPIP protocol (94) and SecuRemote
Hi Marcin ipip.o is to build tunnels. It uses IP protocol 4, not 94. Hmm, I don't know anything about SecuRemote but I believe that the Linux masq code can masq every IP connection (Is this correct?) I can imagine two points of failure: 1. IPCHAINS rules are not properly configured for IP 94 2. SecuRemote uses a special protocol which is incompatible with normal masq'ing, like PPTP, FTP and so on. For FTP and PPTP, there are masq modules but for SecuRemote?! Please send us your IPCHAINS rule listing (see http://sourceforge.net/docman/display_doc.php?docid=1891group_id=13751 for instructions) and what exactly you're doing when you added straight rules which allowing ip proto=94 to pass/forward through LRP. Thank you --- Sandro Minola | LEAF Developer (http://leaf.sourceforge.net) mailto:[EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] http://www.minola.ch| http://leaf.sourceforge.net/devel/sminola -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marcin Sent: Saturday, February 16, 2002 2:30 PM To: [EMAIL PROTECTED] Subject: [Leaf-user] problems with IPIP protocol (94) and SecuRemote Hi, I'm trying to use CheckPoint SecuRemote from Windows box through LRP box. I'm using NAT at LRP host. Authorisation (which uses UDP) are working well, but after that IP packets (with protocol field set to 94) are being silently dropped at LRP box. Digging through mail archives I've found only two suggestions: first one, that watch out IPIP, not all firewalls like that, and another one which suggest a problem with CheckPoint FW-1 protocol. I've added ipip.o to the LRP box, but it doesnt resolve the problem. I've also added straight rules which allowing ip proto=94 to pass/forward through LRP - unfortunatelly with the same result. Thanks in advance for any help, Marcin ___ 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] Bering and DOC2000
At 2002-02-16 22:52 -0500, Patrick Nixon wrote: I'm relatively new at the whole development, unusual requirements thing, so while I am confident about compiling a kernel and whatnot, getting it t boot properly is shaky ground for me. Pat, Have you read Developer Guide? http://leaf.sourceforge.net/pub/doc/guide/developer.rtf Also, look at the developer FAQs in sec13. http://leaf.sourceforge.net/content.php?menu=1105page_id=19 -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] pppd problem
At 2002-02-17 17:57 +0800, Vic Berdin wrote: Hello, Sorry to bug you guys like this, and it's a sunday! Anyways, I'm really desperate. I've already sent a message to the LEAF user mailing list, and still awaiting any replies. I'm having a permission denied problem if I run pppd using a non-root account. This is the reason why I can't log (dial-in) non-root accounts into my Dachstein box. If I were to change the property of the binary to execute on all users (chmod 777 pppd), I get a -pppd: must be root to run -pppd, since it is not setuid-root message. If I change the permission further in order to get a suid bit (chmod 4755 pppd), the said message remains, and more than that, the binary will fail to work at all. This problem applies to all pppd v2.3.xx found on the LEAF site. Are there any special requirements on the accounts that I must create in order for pppd (or login???) to accept my dial-in attemps? Vic, Have you diffed the old /etc/ppp/options file against the new one? I did a quick search on Google for possible solutions. I hope this helps. http://google.com/search?hl=enq=pppd+setuid+site%3Alinuxdoc.org -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Unused IP's with LaBrea
Good Day all, I am wondering what could I use as a unused IP for LaBrea? Is it possible to use a class C number ie; 192.168.x.x? I only receive one IP from AT$T to connect to the net, so I was thinking maybe I could hook up a spare computer to the network behind the LRP (DCD v1.0.2) box, and let some of those annoying port 80 machines come in and get tar-pitted. Thing is, I have been sending my logs to AT$T and complaining about them weekly now for about a month. Seems some of the IP's from AT$T have been taken care of but still receiving hundreds of entries in the logs on a daily routine. Of coarse I could also just stop logging those messages as well. Just thought I would be a nice guy and keep AT$T informed - seems they do not care! Anybody using LaBrea like this or know a way I could use it with 1 IP? Thanks for any guidance. Steve ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] router?
hello all, i am trying to setup a router that will share my cable internet connection with the rest of my house please could some one tell me how to do this, i under stand the bit upto getting the image on floppy ( i am not even sure i have the right one ) and putting two network cards in the box etc etc but i dont under stand the config files and the last time i tryed it ( about a year ago with LRP ) i failed i could not get the machines on the inside of the network to ping stuff on the out side of the network. and the lrp box kept saying something about a martian ip address. i am getting to know linux quite well now, so you dont have to explain things at a begginers level, and if i dont know it i will pick it up along the way. please please can some one help thank you all for your time antken ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein plus Seawall problem - network reset
My workaround was to add the command seawall restart after reload_all (see below). [Note: you will see in this code some logic I added to tell my dynamic dns service that my IP has changed. This code also logs when that logic executes. Actually, my IP has changed once in the last two years, I have the poor man's static IP! :-)] My question is NOT what is the bug in the ip changing logic below, I can probably figure that out (though if someone sees it instantly there is no harm in writing me). This code is supposed to have a bug fix I saw in the list from Charles. Maybe I dropped it or did it wrong. I will upgrade the the Latest Dachstein and see if this IP change detection has changed Here are the questions: 1. Are there any other places in Dachstein that update the network, and need to be followed by seawall restart? Other than on initial startup (which apparently works OK already), the only other thing that comes to mind is if someone's manually bringing network services up/down (ie using svi network reload or similar)...presumably anyone doing so would also remember to manually restart seawall... 2. Is there a better fix for this problem? (This fix works, my humble web site has been visible continuously since I edited dhclient-exit- hooks.) Unfortuantely my fix entangles seawall.lrp and dhclient.lrp. The dhclient enter and exit hooks scripts are the cleanest location for this sort of code, AFAIK. 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] Unused IP's with LaBrea
I am wondering what could I use as a unused IP for LaBrea? Is it possible to use a class C number ie; 192.168.x.x? I only receive one IP from AT$T to connect to the net, so I was thinking maybe I could hook up a spare computer to the network behind the LRP (DCD v1.0.2) box, and let some of those annoying port 80 machines come in and get tar-pitted. Thing is, I have been sending my logs to AT$T and complaining about them weekly now for about a month. Seems some of the IP's from AT$T have been taken care of but still receiving hundreds of entries in the logs on a daily routine. Of coarse I could also just stop logging those messages as well. Just thought I would be a nice guy and keep AT$T informed - seems they do not care! Anybody using LaBrea like this or know a way I could use it with 1 IP? Thanks for any guidance. Steve If you want to run LaBrea using a private space IP, you'll probably need another Dachstein system to run it on. Then just stick it on your internal network, and port-forward anything you want blocked to an unused IP on the internal net. This is not a particularly clean solution, but may be easiest if you don't understand netfilter rules, and have an extra machine handy. You also have less chance of messing anything up this way, since LaBrea is not directly connected to your upstream link... The cleaner way to do this is to setup LaBrea to listen on your external IP. Any traffic that is DENIED by the firewall rules can be captured by LaBrea, but you have to write filter rules for it. I experimented some with this, but never got something I'd be happy packaging. PLEASE NOTE: LaBrea is an advanced networking tool, that talks *DIRECTLY* to the network, and can potentially be VERY DANGEROUS to properly operating networks. Please *DO NOT* run LaBrea if you don't feel comfortable you've got a reasonable understanding of how it works. Remember, LaBrea is a tool to to annoy port-scanners, which it does a very good job at. A bit of mis-application, however, and you could inadvertently kill access to a good chunk of your cable-modem segment, possibly keeping your friends and neighbors offline until a cable-modem technician figures out he needs to flush the arp-cache on your head-end router...anyone want to bet on exactly how long that might take? With the disclaimer out of the way, the basic procedure would be: - Configure LaBrea to *NOT* capture IP addresses (you've only got a single IP anyway, and while those on cable-modems might be able to grab additional IP's, you should play nice with your neighbors and the cable company, and grabbing extra IP's (even for tarpitting) would probably violate your terms of use). Use the -x switch for LaBrea to disable IP address capturing - Stop the interface from running in promiscuous mode. Edit /etc/init.d/LaBrea, and add a minus - in front of the promisc flag for the ifconfig command. It should now read: ifconfig eth0 -promisc - Write a BPF (Berkeley Packet Filter) ruleset for the packets you want LaBrea to see (and hence respond to). The traffic you want processed by LaBrea should meet the following criteria: * Destined to your public IP * TCP traffic * Inbound packets will be *DENIED* by firewall rules For normal Dachstein systems, all low TCP ports (ie ports between 0 and 1023 inclusive) meet this criteria, unless there are some you're actually using (ie port-forwarding www, smtp, ssh, c). A BPF file that does this would be: dst host 1.2.3.4 and tcp[2:2] 0xfc00 == 0 and not dst port (ssh or ftp or www) The first line matches your IP address (set 1.2.3.4 to whatever your IP address is...you'll have to use a script to generate the BPF file if your IP is dynamic). The second line matches all low TCP ports (ie the destination port field of the TCP header is less than 1024). This rule also matches only TCP traffic, since we specified a field in a TCP header. The third rule prevents any expected traffic from being matched, allowing port-forwarded services to work properly. If you're not running any services you can delete the last line...if you *ARE* running services, make sure each is properly listed or strange things will happen. This example system is running an ssh, ftp, and web server. Note you can also use port-numbers...ie: (22 or 21 or 80) is identical to the above (ssh or ftp or www). 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 + Wireless
Seems like lots of folks are interested in wireless, so I thought I'd forward this to the list... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) - Original Message - From: Pete Dubler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 17, 2002 11:53 AM Subject: lrp.steinkuehler.net Feedback Charles, Your website is a great resource! Thanks! We have used it to get everything we needed to create a firewalls/radio hosts for our neighborhood 802.3 network. I have documented the installation and created a set of zip files which correspond to the floppies needed to complete an install from scratch. Would you like these files for your website, or a pointer to a place we might keep them? See this at http://www.dublerfamily.com/leaf Thanks again for your good work! Pete Dubler Fort Collins, CO ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Unused IP's with LaBrea
Thank you for your suggestions Charles. I think I will take the easy way on this and just add an extra computer on the internal side and go with port forwarding, I think I want to stay on the good side of the neighbors! LOL If you want to run LaBrea using a private space IP, you'll probably need another Dachstein system to run it on. Then just stick it on your internal network, and port-forward anything you want blocked to an unused IP on the internal net. This is not a particularly clean solution, but may be easiest if you don't understand netfilter rules, and have an extra machine handy. You also have less chance of messing anything up this way, since LaBrea is not directly connected to your upstream link... The cleaner way to do this is to setup LaBrea to listen on your external IP. Any traffic that is DENIED by the firewall rules can be captured by LaBrea, but you have to write filter rules for it. I experimented some with this, but never got something I'd be happy packaging. PLEASE NOTE: LaBrea is an advanced networking tool, that talks *DIRECTLY* to the network, and can potentially be VERY DANGEROUS to properly operating networks. Please *DO NOT* run LaBrea if you don't feel comfortable you've got a reasonable understanding of how it works. Remember, LaBrea is a tool to to annoy port-scanners, which it does a very good job at. A bit of mis-application, however, and you could inadvertently kill access to a good chunk of your cable-modem segment, possibly keeping your friends and neighbors offline until a cable-modem technician figures out he needs to flush the arp-cache on your head-end router...anyone want to bet on exactly how long that might take? With the disclaimer out of the way, the basic procedure would be: - Configure LaBrea to *NOT* capture IP addresses (you've only got a single IP anyway, and while those on cable-modems might be able to grab additional IP's, you should play nice with your neighbors and the cable company, and grabbing extra IP's (even for tarpitting) would probably violate your terms of use). Use the -x switch for LaBrea to disable IP address capturing - Stop the interface from running in promiscuous mode. Edit /etc/init.d/LaBrea, and add a minus - in front of the promisc flag for the ifconfig command. It should now read: ifconfig eth0 -promisc - Write a BPF (Berkeley Packet Filter) ruleset for the packets you want LaBrea to see (and hence respond to). The traffic you want processed by LaBrea should meet the following criteria: * Destined to your public IP * TCP traffic * Inbound packets will be *DENIED* by firewall rules For normal Dachstein systems, all low TCP ports (ie ports between 0 and 1023 inclusive) meet this criteria, unless there are some you're actually using (ie port-forwarding www, smtp, ssh, c). A BPF file that does this would be: dst host 1.2.3.4 and tcp[2:2] 0xfc00 == 0 and not dst port (ssh or ftp or www) The first line matches your IP address (set 1.2.3.4 to whatever your IP address is...you'll have to use a script to generate the BPF file if your IP is dynamic). The second line matches all low TCP ports (ie the destination port field of the TCP header is less than 1024). This rule also matches only TCP traffic, since we specified a field in a TCP header. The third rule prevents any expected traffic from being matched, allowing port-forwarded services to work properly. If you're not running any services you can delete the last line...if you *ARE* running services, make sure each is properly listed or strange things will happen. This example system is running an ssh, ftp, and web server. Note you can also use port-numbers...ie: (22 or 21 or 80) is identical to the above (ssh or ftp or www). Charles Steinkuehler ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Bering and DOC2000
Jacques Nilo wrote: I am :-). It takes some time to reach Europe :-) :-) Bering is a miniature Linux OS that lives entirely on a 1.68 MB diskette, and it's purpose is to act as a router/firewall that connects two networks, filtering the content to protect the internal network. Bering is based upon a tried and true router/firewall called Dachstein (version rc2), created by Charles St[ei][ie]nk[ue][eu]l[h]er, sigh. The Bering firewall uses iptables for the firewall rules and Linux kernel 2.4.x as the base OS. Running Bering on an old Pentium with 32 MB of RAM is like using one of those Linksys or DLink router-firewalls, except that Bering is much more powerful, capable, and extensible. I'll buy that description if there is no copyright attach to it. Everything I post to the internet, by it's nature, can't be copyrighted, because the internet is the essence of free exchange. Just because I arranged a series of 1's and 0's in an interesting pattern does not give me the right to claim that I am the only one who can do so. But that's a whole 'nother thread for a differernt newsgroup :-o In other words, you're welcome to it without restriction. The problem I noticed with it right after I hit send was that it didn't mention Shorewall, a fundamental aspect of making it a router/firewall. So maybe the line would need to say: upon a tried and true router called Dachstein rc2, created by Charles S_ and upon the Shorewall firewall by Tom Eastep. Some news about Bering beta-4 about to be released: the initial loading of modules from boot/lib/modules now works properly ifupdown has been fixed and do not use ifconfig and route anymore (only ip) latest shorewall to be included Should be ready for testing tomorrow I would like to include in the doc two paragraphs about: Booting Bering from an hard disk This varies a lot with the syslinux version used and the available tools to prepare the hard drive. If you have a stable set of tools like mkdosfs, syslinux, and the like, then this wouldn't be too hard. David made a lot of these tools into .lrp packages. I'll mess around with them some more. But I've syslinuxed an IDE drive and still had remenants from System Commander in the master boot block that screwed with booting to the syslinux boot: prompt. So it's never a piece of cake, especially with syslinux going through so many revisions. I'll see if anyone knows the best version so far. Booting Bering from DOC From an M-Systems Disk On Chip? Any volunteer ? Next on the list: ipsec Cheers Jacques ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] PPTP forward IN through Dachstein CD firewall?
Is it possible to route GRE (protocol 47) to an internal VPN server? I have a Dachstein CD firewall (1.0.2) at the entry point into my network and a win2k pdc which accepts VPN connections. Thanks for any help. -Scott ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] How to backup Dachstein packages to floppy?
Hi folks, I'm using the Dachstein CD, and I've uncommented the correct entries for my NIC's. I just don't know how to backup to the floppy (I'm sorry, I'm fairly new to Linux). Thank you, have a great day! Craig ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Unused IP's with LaBrea
This may be a horrible kludge (I dunno - not much of a scripter), but here goes: 1. Write the first portion of your filter (up to the IP address) into a file (i.e. /etc/LaBrea.tmp) - contents for mine would be: tcp dst port 80 or 21 and dst host 2. Create a script (i.e. /etc/ipupdate) that writes the filter and checks the IP of the external interface (eth0 on my box, change if needed). The script's contents should look like this: #Creates /etc/LaBrea.bpf #!/bin/sh cat filter /etc/LaBrea.bpf ip addr show eth0 | grep inet | sed s/// | cut -d' ' -f 2 | cut -d'/' -f1 /etc/LaBrea.bpf #Done (that should only be 2 lines - not 3 - the second line wrapped) 3. Chmod /etc/ipupdate to 744 (command would be chmod 744 /etc/ipupdate to do this). 4. Edit the dhclient-exit-hooks to with the following changes: # Reload networking to see new address reload_all Add a line so you have # Reload networking to see new address reload_all /etc/ipupdate Save the file and it _should_ work (of course I can't test whether it works or not as my ip hasn't changed in over a year). If anyone sees any obvious mistakes please point them out. S From: Steve Jeppesen [EMAIL PROTECTED] To: Simon Bolduc [EMAIL PROTECTED], leaf-user [EMAIL PROTECTED] Subject: Re: [Leaf-user] Unused IP's with LaBrea Date: Sun, 17 Feb 2002 17:38:19 -0600 On Sun, 17 Feb 2002 17:27:21 -0500 Simon Bolduc [EMAIL PROTECTED] wrote: As long as you aren't dynamic you can always just use these settings in the options file: Thats the problem so far, I have a dynamic IP. Suppose I could just monitor my IP and change it manually. However that doesn't cut it in case it changes in the middle of the night ;) I have never created a script, but that sounds like the way to go like Charles suggested - a script to monitor the IP assigned to eth0, and when it changes have the script update the /etc/LaBrea.bpf If writing script is anything like Lisp code for AutoCAD, then I have a chance at creating one! However, I am going to study what has been suggested before ever getting to the point of letting LaBrea loose on the LRP box. # Options for start/restart the daemons OPTIONS=-i eth0 -l -v -p 8 -z -x -F /etc/LaBrea.bpf and this is my /etc/LaBrea.bpf: tcp dst port 80 or 21 and dst host my.ext.ip.address and then you won't upset your neighbours/ISP, and don't have to have another machine running all the time. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Re: How to backup Dachstein packages to floppy?
Craig Caughlin writes: Hi folks, I'm using the Dachstein CD, and I've uncommented the correct entries for my NIC's. I just don't know how to backup to the floppy (I'm sorry, I'm fairly I assume that you're using DCD. if you are already in the LRP-configuration menu, type b to choose Back-up ramdisk. since NIC's settings is in 2) etc, so now type d 2. and then type 2 to choose fd0 as the back up destination. don't forget to insert a DOS formatted floppy into your floppy drive. and finally type b 2 to do the back up. when a question appears, just pres Y. if the back up is finished, you will then type q until you enter the command prompt. in the command prompt type svi network reload, so that your changes take effect. regards, Gregor WATCHOUT! 3RD INTERNATIONAL SEMINAR ON SUSTAINABLE ENVIRONTMENTAL ARCHITECTURE + DIGITAL ARCHITECTURE, 9-10 MARCH 2002, YOGYAKARTA http://senvar.virtue.nu or http://senvar.uajy.web.id NATIONAL DESIGN COMPETITION http://senvar.uajy.web.id/lombadesain ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein plus Seawall problem - network reset
Charles wrote: The dhclient enter and exit hooks scripts are the cleanest location for this sort of code, AFAIK. Charles, or anyone, help! I was trying to diagnose why the code that reloads the network in the Dachstein dhclient_exit_hooks gets executed every time the lease renews. I printed out the new and old ip address variables and the reason variable, and waited for my setup to renew the lease. And waitied for the lease to be renewed. Reason was BOUND, new_ip_address was 208.191.181.169 (this hasn't changed since November last year), and old_ip_address was blank! This certainly explains why the reload_all() routine in dhclient_exit_hooks gets called so often! $old_ip_address never equals $new_ip_address! I grepped for this variable everywhere and don't see where it is set. Can you tell me where it is set, or should be set? It looks to me like this logic is not quite right and hasn't been for quite a while. But it's very close to being right! Tim Wegner ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Re: How to backup Dachstein packages to floppy?
Very True Gregor! I might also add that the default backup is full and cdrom so I had to go to each section I wanted to back up and change them from full cdrom to partial floppy. There is a letter switch for all three options, 1. backup itself, 2. change destination, and 3. change type of backup (full or partial). The correct sequence for a package to back up would be to change the destination (floppy) type (partial) then follow up with the backup which will write to the floppy. I take it you were successful in getting the modules you wanted to load on the floppy in the lprcfg.cfg file. R- Bill --- GREGOR [EMAIL PROTECTED] wrote: Craig Caughlin writes: Hi folks, I'm using the Dachstein CD, and I've uncommented the correct entries for my NIC's. I just don't know how to backup to the floppy (I'm sorry, I'm fairly I assume that you're using DCD. if you are already in the LRP-configuration menu, type b to choose Back-up ramdisk. since NIC's settings is in 2) etc, so now type d 2. and then type 2 to choose fd0 as the back up destination. don't forget to insert a DOS formatted floppy into your floppy drive. and finally type b 2 to do the back up. when a question appears, just pres Y. if the back up is finished, you will then type q until you enter the command prompt. in the command prompt type svi network reload, so that your changes take effect. regards, Gregor __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] port 53 flooding my log
Message: 2 Date: Fri, 15 Feb 2002 10:14:52 -0800 From: Victor McAllister [EMAIL PROTECTED] To: leaf-user [EMAIL PROTECTED] Subject: Re: [Leaf-user] port 53 flooding my log GREGOR wrote: I'm using DCD, I set it up as firewall, with IP aliasing on eth0, DMZ switch=PRIVATE on eth2 and internal network on eth1.(thank's to bela,charles and ray). I've got tons of logs of hits on port 53 like the following examples : Since you are using DCD - try adding all the port 53 flood servers in SILENT_DENY. Here is a copy of my list - note that they are all on one line each machine separated by a space. I have modified my list. # grep SILENT_DENY /etc/network.conf SILENT_DENY=tcp_64.78.235.14_53 tcp_64.56.174.186_53 tcp_64.37.200.46_53 tcp_64.14.200.154_53 tcp_62.26.119.34_53 tcp_62.23.80.2_53 tcp_216.35.167.58_53 tcp_216.34.68.2_53 tcp_216.33.35.214_53 tcp_216.220.39.42_53 tcp_212.78.160.237_53 tcp_203.208.128.70_53 tcp_203.194.166.182_53 tcp_202.139.133.129_53 tcp_194.213.64.150_53 tcp_194.205.125.26_53 svi network ipfilter reload If it stops the log noise - then backup etc. Victor McAllister --__--__-- I have observed several other port 53 floods. Am I the only one? tcp_128.121.10.146_53 tcp_128.242.105.34_53 tcp_129.250.244.10_53 tcp_203.81.45.254_53 tcp_209.157.68.18_53 tcp_213.38.75.193_53 -- Mike Sussman [EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Sýnýrsýz Bedava Sms , Bedava Onbilerce Mp3
Servis 1 Yepyeni Sms Servsimiz hiç Bir Ücret Ödemeden sýnýrsýz Sayýda dünyanýn Her Tarafýna Bedava Sms Yollaya Bileceksiniz Üstelik Ýnternet Baðlanamadan Sevdiðiniz Kiþiye Binlerce Seni Seviyorum Mesajý Atabilecesiniz Artýk Hiç Sms Göndermek Bu Kadar Kolay Olmamýþtý Sýnýrsýz Sayýda Sms Göndermek Ýçin Sadece Programý Yüklemeniz Ve Çalýþtýrmanýz Yeterli Olacaktýr!!! http://meheh.kolayweb.com/garantisms.exe Servis 2 Ýnternette Mp3 Aramaktan , Kýrýk Linklerle Uðraþmak ve Çalýþmayan Linklerden Býktýnýzmý Size Vereceðimiz Bu Servisle Tüm Türk ve Yabancý Sanatçýlarýn Full Albümlerini ÇOK HIZLI Birþekilde Yükleye Bileceksiniz Vede Ýnternete Baðlanmak Saatlerce Beklemek Yok Ýnternete Baðlanmadan Sýnýrsýz Sayýda Mp3 Yüklemek Ýçin Sadece Size Vereceðimiz Programý Yükleyin!!! Hýzýna Size inanamayacaksýnýz... http://meheh.kolayweb.com/mp3_indir.exe y§î±êæj)b b²ÒÞiû¬z¹b²Û,¢êÜyú+éÞ¶m¦Ïÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~åy§î±ê
