[leaf-user] Total bandwidth on external interface
Hi all I'm running Dachstein 1.02 with a public IP range server farm, (half a dozen domains) one of which proxies client web traffic. What's the simplest way to obtain a record of the total traffic (in and out) on the external card? Actually, I'd like hourly totals of network traffic, showing * incoming bytes on external card * outgoing bytes on external card * traffic received via my ISPs router i.e. traffic directed from 1.2.3.1 to 1.2.3.2 * traffic forwarded by the firewall - broken down by IP / Port for priviledged ports (ftp,www,https, imap, smtp, pop) - broken down by ip for remaining ports The ISP connection is through a broadband (fibre optic) connection which contains a large number of nodes, which generate a lot of Martians in the logs. (There appear to be machines with ips in the 192.168.* range on the network). I've currently turned LOG_MARTIANS off, as I think maybe this traffic is unavoidable. I have DENY_MARTIANS = yes on the external card. I have a Linux box on the internal network that I could use to run wget or run syslogd for remote logging. Any suggestions? Greg Ford ReddFish intergalactic ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering bootable cd (Help)
Kim, have you read my documentation on how to boot Bering from a CDROM? It's available @ http://leaf.sourceforge.net/devel/jnilo/bucdrom.html Have fun! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:56 AM To: Eric Wolzak Cc: Kim Oppalfens; [EMAIL PROTECTED] Subject: Re: [leaf-user] Bering bootable cd (Help) Comments inline Try to remove or uncomment the modules. Ok I' ll try that and see what happens. Btw the new kernel was necessary to boot from flashmodule from apacer which is an idedrive. At the end of /boot/etc/modules isofs.o is trying to load. I said trying, because it is failing stating insmod: init_modules isofs.o device or resource busy Did you use your own created modules, or did you download the modules ( in that case you could have a problem due to the fact that the modules on the bering site, are from a patched kernel. I used downloaded versions, but I used the same patches for the kernel so I don't think that is the problem, especially in combination with the next comment. (read on) Afterwards I get the tempfs linuxrc Installing packages : (all my packages are the (nf!) or not found I get a kernel panic stating that I tried to kill init. It seems that your cdrom is not recognized that reason the packages are not found. If I use all the same .lrp files kernel on the flash module everything runs fine except for the above mentioned ide-probe isofs problem. Which isn't a real concern when booting from the module. I expect that you included the flash rom ide support in the kernel itself. After you boot from the ide-rom, can you mount the cdrom or at least try to insmod the modules from boot/lib one by one and try to mount the cdrom then. Perhaps a conflict betweeen the ide driver for the cdrom and the disk ( Master slave conflict ? ) Hope I have given you a few hints where you might look for a solution. After I boot all modules are loaded (according to lsmod) except for isofs.o. If i try to insmod isofs.o I get the same problem, but a mount -t iso9660 /dev/cdrom /mnt works like a charm. So I think I can conclude that there is nothing wrong with the modules, can't I? I am affraid this also rules out master/slave problems. Correction this definitely rules out master/slave since flashrom is on ide channel 0 cdrom on ide channel 1. I didn't include ideflash support in the kernel by the way, the apacer module uses the ide specifiaction and does not need anything special to work. Kim - This mail sent through Tiscali Webmail (http://webmail.tiscali.be) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] [OT] Recommendations for minimal Linux?
On Thursday 02 May 2002 19:48, Charles Steinkuehler wrote: Sorry to be (way) off topic here, Not that far off topic. O.K. cool :) Sounds like a pretty basic system. I hope there's a CPU and some memory! :-) Well.. if you really think that's *needed*... ;-D oriented towards the role of 'device-controller'? I think you're barking up the wrong tree to some extent. Nyeah... yes and no. Though I see what you mean... Traits I'm looking for: The first two traits describe the linux platform you need. Pretty much *ANY* of the firewall/rescue type floppy disk linux's should work well for you with a bit of customization. Yes, I realize this. What I was thinking was to minimize the amount of customization needed, by starting with something as close as possible to my goal in network.conf, or remove the firewall setup scripts entirely, replacing the whole thing with a simple script to configure your one interface Sounds like a fairly straightforward MO. Except I don't have a particularly precise picture of which scripts do what, when or how... Not that that's that big of a deal, who knows, I might even learn something in the process ;) Anyway, when looking at the various single-disk linux options, there are a few things you might want to check for that could make your job easier: init: Some of the single-disk linux disto's come with a customized or minimal version of init. Dachstein (and all other LEAF disto's, AFAIK) comes with standard SysV init, and supports the /etc/rc?.d runlevel directories, making it easy to get your custom program(s) running automatically. Good point. cron: Since you're talking about an alarm type function, you may find cron handy if you don't want to keep track of time in your application. Again, cron is included on Dachstein and other LEAF disto's. *Very* good point. Indeed this has me thinking that since, by nature, this host is going to be very 'time-centric', I might as well complicate matters further by making it a time 'mirror'. That is, let it synchronize with some timeserver 'out there', and then having it act as a local timeserver for my LAN... Any 'xntp.lrp' packages available? Runtime Environment: You only mention the requirement for a shell, but there are probably other things you need as well. You can add these yourself if something is missing, but ideally you want as much as possible included out of the box. Which was my point exactly, in asking for opinions :) I think Dachstein, Bering, Oxygen, and most any of the myriad other single-disk disto's would likely work fine for your application. I'd probably pick one based on either your current experience (ie stick with what you know), or what you would like to learn (ie I've been itching to try out that Bering release). Yeah, you're right. I think Bering looks like a nice place to start... I *have* been wanting to get started on that. You might also want to consider using some X-10 controllers, and slowly turning on a light (or lights). You can get all the bits pieces at radio-shack, and you can still controll it with linux... Yeah I suppose, but since my electricity bill is big enough as it is, and light is readily available anyway, I think I'm going to stick with the concept of just selectively letting it in (the light, that is...) Also getting stuff from Radio Shack could prove pretty expensive, getting the stuff shipped to Denmark, and all... ;-P Thanks very much for the input. Nice to get some confirmation that even if I'm barking up trees, more or less at random, at least I'm in the right neck of the woods ;) Jon Clausen -- .signature ;) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Testing IPsec pass-through
Tom, I am still a newbie here and I wanted to make sure that I understood what you meant so here is where I am at on this. What you suggested was this [1]: ACCEPT net loc:local endpoint ip udp 500 - all ACCEPT net loc:local endpoint ip 50 - - all I decided not to include the endpoint ip address because I wanted be able to use any machine on my local network. So... I did this [2]: ACCEPT net loc udp 500 ACCEPT net loc 50 all Following your suggestion of how I can identify the difference I used the command shorewall show net2loc. Below was my process: ReBOOT with Rule [1] in place. make ipsec connection break ipsec connection run shorewall show net2loc record results (see [1] below) modify shorewall config to use Rule [2] backup config ReBOOT with Rule [2] in place make ipsec connection break ipsec connection run shorewall show net2loc record results (see [2] below) results from [1] this connection was only up for a couple of minutes. # shorewall show net2loc Shorewall-1.2.8 Chain net2loc at firewall - Thu May 2 15:42:01 UTC 2002 Chain net2loc (1 references) pkts bytes target prot opt in out source destination 27 4277 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.1.10 state NEW udp dpt:500 188 ACCEPT esp -- * * 0.0.0.0/0 192.168.1.10 state NEW 0 0 net2allall -- * * 0.0.0.0/0 0.0.0.0/0 results from [2] this connection was up for 25 minutes. # shorewall show net2loc Shorewall-1.2.8 Chain net2loc at firewall - Thu May 2 16:12:20 UTC 2002 Chain net2loc (1 references) pkts bytes target prot opt in out source destination 1331 156K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:500 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 net2allall -- * * 0.0.0.0/0 0.0.0.0/0 The only difference here are the esp (protocol: 50) packets that were logged. Is this the difference that you were expecting me to find. I am not in control of the other end. Would you typically expect that a rekeying attempt would have been made in the 25 minutes that I had left the tunnel up? Thanks for your assistance thus far. /Eric -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 11:24 AM To: Eric B Kiser Cc: [EMAIL PROTECTED] Subject: RE: [leaf-user] Testing IPsec pass-through On Wed, 1 May 2002, Eric B Kiser wrote: Since installing Bering 1.0-rc1 the only thing that I have changed in my shorewall config is adding the lines below. My understanding is that this is not static since it is my single publicly routable address on one side and I have three workstations using 192.168.1.x on the other side. Is static NAT the same as a 1:1 mapping? Yes -- in that case, I doubt that the rules that you posted have any effect. Most people using IPSEC have found that they also need incoming rules that forward UDP 500 and protocol 50 to the endpoint (as I recommended in a previous post). Without such rules, the tunnel will eventually die during a re-keying attempt. Look at the output of shorewall show net2loc -- I'm betting that the packet counts for those rules are zero. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Testing IPsec pass-through
On Fri, 3 May 2002, Eric B Kiser wrote: What you suggested was this [1]: ACCEPT net loc:local endpoint ip udp 500 - all ACCEPT net loc:local endpoint ip 50 - - all I decided not to include the endpoint ip address because I wanted be able to use any machine on my local network. So... I did this [2]: ACCEPT net loc udp 500 ACCEPT net loc 50 all results from [1] this connection was only up for a couple of minutes. # shorewall show net2loc Shorewall-1.2.8 Chain net2loc at firewall - Thu May 2 15:42:01 UTC 2002 Chain net2loc (1 references) pkts bytes target prot opt in out source destination 27 4277 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.1.10 state NEW udp dpt:500 188 ACCEPT esp -- * * 0.0.0.0/0 192.168.1.10 state NEW 0 0 net2allall -- * * 0.0.0.0/0 0.0.0.0/0 results from [2] this connection was up for 25 minutes. # shorewall show net2loc Shorewall-1.2.8 Chain net2loc at firewall - Thu May 2 16:12:20 UTC 2002 Chain net2loc (1 references) pkts bytes target prot opt in out source destination 1331 156K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:500 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 net2allall -- * * 0.0.0.0/0 0.0.0.0/0 The only difference here are the esp (protocol: 50) packets that were logged. Is this the difference that you were expecting me to find. I am not in control of the other end. Would you typically expect that a rekeying attempt would have been made in the 25 minutes that I had left the tunnel up? Depends on how you have set the re-key interval for the tunnnel. Also, remember that re-keying only involves the UDP connection. I no longer have any IPSEC tunnels so I don't have immediate access to the docs to see what the default interval is. In order for either of rules [2] to have been invoked, the ORIGINAL destination IP would have had to have been in your local network; clearly that is never going to be the case (my point from the last post). You may as well remove the rules since they will never do anything. The basic problem is that IPSEC tunnels are quiet when there is no traffic and the re-keying interval hasn't expired. In that time, the connection tracking entries created when the local endpoint first sent packets to the remote one will time out. Then, if a packet is received from the remote end-point, the RELATED,ESTABLISHED rule (first Shorewall-generated rule in both cases) won't match the incoming packet and the packet will be rejected. As long as the local endpoint speaks first after such a quiet time, everything works -- otherwise, it may not. By having rules [1], if the remote end sends a packet (either ESP or UDP/500) and there is no matching connection-tracking entry, the appropriate rule will: a) Re-establish a connection tracking entry between the end-points for that protocol[/port]; and b) Route the packet to the appropriate local host. If your tunnels are fairly busy when they are up and you have a short re-key interval, you should be fine without any IPSEC-related rules. If you leave these tunnels up overnight with no traffic, you will almost certainly encounter problems. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Testing IPsec pass-through
Very interesting, Tom... Thanks for taking the time to get into more detail. I have modified my rules back to your original suggestion, however, I still have one question. [snip] In order for either of rules [2] to have been invoked, the ORIGINAL destination IP would have had to have been in your local network; clearly that is never going to be the case (my point from the last post). You may as well remove the rules since they will never do anything. [end snip] These rules did do something. They made it possible for me to bring up the tunnel. I understand the importance of doing it as per your example, I changed my rules accordingly. If I understand you correctly, based on the snip above, my rules shouldn't have worked at all? Respectfully, Eric -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 9:44 AM To: Eric B Kiser Cc: [EMAIL PROTECTED] Subject: RE: [leaf-user] Testing IPsec pass-through On Fri, 3 May 2002, Eric B Kiser wrote: What you suggested was this [1]: ACCEPT net loc:local endpoint ip udp 500 - all ACCEPT net loc:local endpoint ip 50 - - all I decided not to include the endpoint ip address because I wanted be able to use any machine on my local network. So... I did this [2]: ACCEPT net loc udp 500 ACCEPT net loc 50 all results from [1] this connection was only up for a couple of minutes. # shorewall show net2loc Shorewall-1.2.8 Chain net2loc at firewall - Thu May 2 15:42:01 UTC 2002 Chain net2loc (1 references) pkts bytes target prot opt in out source destination 27 4277 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.1.10 state NEW udp dpt:500 188 ACCEPT esp -- * * 0.0.0.0/0 192.168.1.10 state NEW 0 0 net2allall -- * * 0.0.0.0/0 0.0.0.0/0 results from [2] this connection was up for 25 minutes. # shorewall show net2loc Shorewall-1.2.8 Chain net2loc at firewall - Thu May 2 16:12:20 UTC 2002 Chain net2loc (1 references) pkts bytes target prot opt in out source destination 1331 156K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:500 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 net2allall -- * * 0.0.0.0/0 0.0.0.0/0 The only difference here are the esp (protocol: 50) packets that were logged. Is this the difference that you were expecting me to find. I am not in control of the other end. Would you typically expect that a rekeying attempt would have been made in the 25 minutes that I had left the tunnel up? Depends on how you have set the re-key interval for the tunnnel. Also, remember that re-keying only involves the UDP connection. I no longer have any IPSEC tunnels so I don't have immediate access to the docs to see what the default interval is. In order for either of rules [2] to have been invoked, the ORIGINAL destination IP would have had to have been in your local network; clearly that is never going to be the case (my point from the last post). You may as well remove the rules since they will never do anything. The basic problem is that IPSEC tunnels are quiet when there is no traffic and the re-keying interval hasn't expired. In that time, the connection tracking entries created when the local endpoint first sent packets to the remote one will time out. Then, if a packet is received from the remote end-point, the RELATED,ESTABLISHED rule (first Shorewall-generated rule in both cases) won't match the incoming packet and the packet will be rejected. As long as the local endpoint speaks first after such a quiet time, everything works -- otherwise, it may not. By having rules [1], if the remote end sends a packet (either ESP or UDP/500) and there is no matching connection-tracking entry, the appropriate rule will: a) Re-establish a connection tracking entry between the end-points for that protocol[/port]; and b) Route the packet to the appropriate local host. If your tunnels are fairly busy when they are up and you have a short re-key interval, you should be fine without any IPSEC-related rules. If you leave these tunnels up overnight with no traffic, you will almost certainly encounter problems. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED]
RE: [leaf-user] Testing IPsec pass-through
On Fri, 3 May 2002, Eric B Kiser wrote: Very interesting, Tom... Thanks for taking the time to get into more detail. I have modified my rules back to your original suggestion, however, I still have one question. [snip] In order for either of rules [2] to have been invoked, the ORIGINAL destination IP would have had to have been in your local network; clearly that is never going to be the case (my point from the last post). You may as well remove the rules since they will never do anything. [end snip] These rules did do something. They made it possible for me to bring up the tunnel. I understand the importance of doing it as per your example, I changed my rules accordingly. If I understand you correctly, based on the snip above, my rules shouldn't have worked at all? No -- the two rules you added had NO EFFECT WHATSOEVER on the outcome. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Order of PCI ethernet cards:
Matt, hoping you can help with this. My boss designed a board with two 8139 cards on board. One is harwired to a connector intended to be eth0 the other to a switch intended to be eth1. Naturally the reverse occurred. If we can't fix this in BIOS he'll have to rewire. The question is why is the BIOS, which I assume is doing a bus scan selecting the particular order? What is it in the address or whatever lines which determines the order. Thanx, Phil ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Testing IPsec pass-through
Okie-dokie, here is my sanity check... Establish IPsec connection ...done Tear down IPsec connection ...done Remove rules from config...done save...done backup ...done reboot ...done Establish IPsec connection ...done ...what? ...it failed every other time! urgh! All has now been revealed... [sigh]. My misconception in this was based on the belief that my rules actually were having an effect. This being due to the fact that I was never able to bring the tunnel up prior to adding the rules. In all fairness it had been quite a while since I had tried to establish an ipsec connection through my Bering box and it now seems entirely likely that their was something else in the path that was blocking my connection. This something else seems to have been fixed thus I am now able to make a connection without any trouble and without any extra rules. I only tunnel in to check my mail and such then I take down the tunnel so in all likelihood I would never even need Tom's extra rules. On the other hand if I was attempting to maintain constant connectivity between my workstation and the far end then I would possibly begin to see trouble because the rules would not be in place to allow the other end to initiate a key exchange. I realize that I am repeating things that Tom has already said, I just didn't understand them before because I was /confused/. Thanks Tom, your patience through this was much appreciated. Regards, Eric -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 10:39 AM To: Eric B Kiser Cc: [EMAIL PROTECTED] Subject: RE: [leaf-user] Testing IPsec pass-through On Fri, 3 May 2002, Eric B Kiser wrote: Very interesting, Tom... Thanks for taking the time to get into more detail. I have modified my rules back to your original suggestion, however, I still have one question. [snip] In order for either of rules [2] to have been invoked, the ORIGINAL destination IP would have had to have been in your local network; clearly that is never going to be the case (my point from the last post). You may as well remove the rules since they will never do anything. [end snip] These rules did do something. They made it possible for me to bring up the tunnel. I understand the importance of doing it as per your example, I changed my rules accordingly. If I understand you correctly, based on the snip above, my rules shouldn't have worked at all? No -- the two rules you added had NO EFFECT WHATSOEVER on the outcome. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Order of PCI ethernet cards:
It has to do with the PCI ID order. How did your boss made the PCI ID? He must have defined that one of the 8139 card has let's say ID 1 the other ID 2. I guess that all of the PCI, PNP and ACPI specs must have a way to say which device is which. So I guess that he will have to rewire or change the PCI IDs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 5:37 PM To: Matt Schalit Cc: [EMAIL PROTECTED] Subject: [leaf-user] Order of PCI ethernet cards: Matt, hoping you can help with this. My boss designed a board with two 8139 cards on board. One is harwired to a connector intended to be eth0 the other to a switch intended to be eth1. Naturally the reverse occurred. If we can't fix this in BIOS he'll have to rewire. The question is why is the BIOS, which I assume is doing a bus scan selecting the particular order? What is it in the address or whatever lines which determines the order. Thanx, Phil ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Testing IPsec pass-through
Good information, thanks for the insight. /Eric -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 11:04 AM To: Eric B Kiser Cc: [EMAIL PROTECTED] Subject: RE: [leaf-user] Testing IPsec pass-through On Fri, 3 May 2002, Tom Eastep wrote: No -- the two rules you added had NO EFFECT WHATSOEVER on the outcome. To clarify -- since the packet and bytes counts for those two rules were zero after your second test, the rules could not have had any possible effect. One other thing -- be very careful when performing back-to-back tests using Netfilter-based firewalls. The connection-tracking entries for most protocols (TCP being the exception) live on after the connection has been terminated. If you establish a similar connection before these tracking entries have expired, the entries can be reused (this is especially true of protocols that do not make use of ports or that use the same port number for source and destination). This can lead you to believe that your latest set of rules worked when in fact it did not. A shorewall restart does not clear the tracking table (it can't because there is no way way for it to do so). There has been a lot of grumbling on the Netfilter mailing list about the lack of a means for removing connection-tracking entries. Until that grumbling results in a change though, caution is advised. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Bering v1.0-rc2 with diskonchip?
I'm trying to install Bering on a PC104 board with DiskonChip2000, but I'm not sure how/where to load the proper driver. I'm at a disadvantage here, my background is windows development. I'm also trying to locate an Ethernet driver for an i82557 chip. I may be on my own with the net driver, but can anyone assist me on the diskonchip? I have Bering booting off a floppy, next step is to add the driver support and somehow move Bering to the diskonchip. Darren ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Help with LaBrea - is it working?
Jabez: Heya. As you probably know, that log looks like a CodeRed worm (an IIS web-server virus from early last year). It also looks like your firewall is simply blocking this packet before any other process can see it, including LaBrea. This seems to me a Good Thing. :) -Scott I just finished installing LaBrea in my Dachstein firewall, and I'm not sure it's actually working. Can someone help? The install seemed to go smoothly, and it seems to be running, but I'm not getting any messages in syslog when a port scan comes in. Just the usual: May 2 03:27:23 firewall kernel: Packet log: input DENY eth0 PROTO=6 66.13.219.74:3816 66.92.149.119:80 L=48 S=0x00 I=31217 F=0x4000 T=114 SYN (#40) May 2 03:27:26 firewall kernel: Packet log: input DENY eth0 PROTO=6 66.13.219.74:3816 66.92.149.119:80 L=48 S=0x00 I=31660 F=0x4000 T=114 SYN (#40) Shouldn't there be some activity from LaBrea on this type of scan? The version I installed was obtained from Charles Steinkuehler's site - v. 2.2, I believe. I followed the advice and installed ifconfig.lrp and made sure eth0 went into promiscuous mode. Here's an excerpt from my boot up syslog: May 1 23:43:07 firewall /usr/sbin/LaBrea: Initiated on interface eth0 May 1 23:43:07 firewall kernel: LaBrea uses obsolete (PF_INET,SOCK_PACKET) May 1 23:43:07 firewall kernel: device eth0 entered promiscuous mode May 1 23:43:07 firewall kernel: device eth0 left promiscuous mode May 1 23:43:09 firewall kernel: device eth0 entered promiscuous mode If I do a ps -ef, I get 822 root S /usr/sbin/LaBrea -i eth0 -l -p 8 -z which says to me LaBrea is running with logging turned on. I didn't mess with any of the settings in /etc/init.d/LaBrea - just used whathever was there already. For reference, my kernel is: Linux version 2.2.19-3-LEAF (root@debian) (gcc version 2.7.2.3) #1 Sat Dec 1 12:15:05 CST 2001 Can someone shed some light? Thanks! Jabez ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering v1.0-rc2 with diskonchip?
I'm trying to install Bering on a PC104 board with DiskonChip2000, but I'm not sure how/where to load the proper driver. I'm at a disadvantage here, my background is windows development. Interesting issue. Let's try it (note: I do not have the hardware here so we might have to iterate a bit) 1/ Step one: create the mtd device. According to: http://www.linuxhq.com/kernel/v2.4/doc/devices.txt.html We have: 90 charMemory Technology Device (RAM, ROM, Flash) 0 = /dev/mtd0 First MTD (rw) 1 = /dev/mtdr0First MTD (ro) ... 30 = /dev/mtd1516th MTD (rw) 31 = /dev/mtdr15 16th MTD (ro) So from linux Bering shell edit root.dev.mk cd /var/log/lrpkg ae root.dev.mk at the bottom of the file add: # ubd devices for UML (J. Nilo) mknod /dev/ubd0 b 98 0 null 21 mknod /dev/ubd1 b 98 1 null 21 mknod /dev/mtd0 b 90 0 null 21 -- line to add cd / Save the file and backup initrd !!! That will take care of device creation /dev/mtd0 at boot time. 2/ Step two: load the appropriate modules. They are here: http://leaf.sourceforge.net/devel/jnilo/bering/latest/modules/drivers/mtd/ My guess is that you need to load first mdtcore.o then ntfl.o If you get unresolved reference it means that you need some more :-) Put the 2 modules in /lib/modules, declare them in /lib/modules and save module.lrp Then see if you can mount and access mtd0 Let me know so that I can update the doc on this issue I'm also trying to locate an Ethernet driver for an i82557 chip. I may be on my own with the net driver, but can anyone assist me on the diskonchip? The appropriate module is eepro100. It's available on the Bering boot floppy. Jacques ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering bootable cd (Help) Problem resolved
At 10:21 3/05/2002, Luis.F.Correia wrote: Kim, I did, it was quite helpful, and was the main raison why I considered trying it out. It was written pretty clearly so I thought if it is this simple even I as an (mct) should be able to do it. :-) Guess again ;-) Well I kinda found the problem fixed although not in the clean and nice way as I want to fix it. It will require some more tweaking though. In the end my problem had nothing to do with the modules (although isofs.o is still failing during boot). My problem was that I tried to boot from /dev/cdrom which doesn't exist. I tried to create it afterwards backup root initrd but that didn't help. I noticed just now that the /dev contents is recreated each time from a file called /var/lib/lrpkg/root.dev.mk unfortunately that file is being backed up executed from the root.lrp package which is the first package on /dev/cdrom. Kinda a chicken egg problem. I resolved it temporarily by specifying /dev/hdc (which is my actual cdromdrive) in isolinux.cfg in the boot variable in the pkgpath variable. You might want to change this in your documentation because I think I won't be the only bietekwiet who might make that mistake. Kim Oppalfens have you read my documentation on how to boot Bering from a CDROM? It's available @ http://leaf.sourceforge.net/devel/jnilo/bucdrom.html Have fun! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:56 AM To: Eric Wolzak Cc: Kim Oppalfens; [EMAIL PROTECTED] Subject: Re: [leaf-user] Bering bootable cd (Help) Comments inline Try to remove or uncomment the modules. Ok I' ll try that and see what happens. Btw the new kernel was necessary to boot from flashmodule from apacer which is an idedrive. At the end of /boot/etc/modules isofs.o is trying to load. I said trying, because it is failing stating insmod: init_modules isofs.o device or resource busy Did you use your own created modules, or did you download the modules ( in that case you could have a problem due to the fact that the modules on the bering site, are from a patched kernel. I used downloaded versions, but I used the same patches for the kernel so I don't think that is the problem, especially in combination with the next comment. (read on) Afterwards I get the tempfs linuxrc Installing packages : (all my packages are the (nf!) or not found I get a kernel panic stating that I tried to kill init. It seems that your cdrom is not recognized that reason the packages are not found. If I use all the same .lrp files kernel on the flash module everything runs fine except for the above mentioned ide-probe isofs problem. Which isn't a real concern when booting from the module. I expect that you included the flash rom ide support in the kernel itself. After you boot from the ide-rom, can you mount the cdrom or at least try to insmod the modules from boot/lib one by one and try to mount the cdrom then. Perhaps a conflict betweeen the ide driver for the cdrom and the disk ( Master slave conflict ? ) Hope I have given you a few hints where you might look for a solution. After I boot all modules are loaded (according to lsmod) except for isofs.o. If i try to insmod isofs.o I get the same problem, but a mount -t iso9660 /dev/cdrom /mnt works like a charm. So I think I can conclude that there is nothing wrong with the modules, can't I? I am affraid this also rules out master/slave problems. Correction this definitely rules out master/slave since flashrom is on ide channel 0 cdrom on ide channel 1. I didn't include ideflash support in the kernel by the way, the apacer module uses the ide specifiaction and does not need anything special to work. Kim - This mail sent through Tiscali Webmail (http://webmail.tiscali.be) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get
[leaf-user] Mounting /var/log on a ext2 partition
Hi, I switched from dachtein to bering, all works perfectly. I replaced my slow bind-8/exim by tinydns/qmail. Perhaps I'm tired but I don't find where the TMPFS on /var/log is created (wich script???) I use a little hard disk for storage and I would like to store logs on a partition. What to do? Thanks Sylvain ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Recommendations for 10/100 NICs?
OK, I want to upgrade my NICs, not only in my Dachstein box (thanks again Charles!), but also in a couple of servers (Compaq Proliant 1500s), for a total of 5 PCI 100 or 10/100 NICs. I don't want to spend more than I have to, but I'd like good quality cards. Searching the archives, I found recommendations for the following, with prices from Tom's Hardware/PriceGrabber * 3Com 3c905 $26.50 (3c905BTX) * Intel EtherExpress Pro 100$18.90 (PILA8460) * Netgear FA-310TX specifically $12.00 (but not other Netgear NICS) I currently have a couple of boxes using SMC 1255TX's, they seem to work OK, and can be had for $15.63. But I didn't find them mentioned much in the archive. So the question is, what is the most bang for the buck? Or are there other models I should consider as well? What else should I consider in making this selection? They all appear to be supported for LEAF/LRP. Thanks in advance... Ken = J. Kenneth Gentle (Ken)| Phone: (610) 255-0361 Gentle Software, LLC | Email: [EMAIL PROTECTED] = ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Recommendations for 10/100 NICs?
On Fri, 2002-05-03 at 13:21, Ken Gentle wrote: OK, I want to upgrade my NICs, not only in my Dachstein box (thanks again Charles!), but also in a couple of servers (Compaq Proliant 1500s), for a total of 5 PCI 100 or 10/100 NICs. snip So the question is, what is the most bang for the buck? Or are there other models I should consider as well? What else should I consider in making this selection? They all appear to be supported for LEAF/LRP. Ken, The best evaluation of Ethernet chip sets for Linux I've found is here: http://www.scyld.com/expert/100mbps.html Many of our project members like the DFE-570TX. http://www.dlink.com/products/adapters/dfe570tx/ -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering bootable cd (Help) Problem resolved
At 23:24 3/05/2002, Eric Wolzak wrote: Your absolutetely right, and that is where it should go and will fix my problem, I only have create a /dev/cdrom link to /dev/hdc and I am set. Sorry for not checking first but I assumed because the file started out with root it would be backed up in root. My bad for not verifying before bothering the list. Damn I hate to be wrong ;-) although I don't mind telling someone else he is right. Kim Hello Kim Others Well I kinda found the problem fixed although not in the clean and nice way as I want to fix it. It will require some more tweaking though. In the end my problem had nothing to do with the modules (although isofs.o is still failing during boot). My problem was that I tried to boot from /dev/cdrom which doesn't exist. I tried to create it afterwards backup root initrd but that didn't help. I noticed just now that the /dev contents is recreated each time from a file called /var/lib/lrpkg/root.dev.mk unfortunately that file is being backed up executed from the root.lrp package I have no actuall image booted at hand but root.dev.mk is backed up with initrd on bering. look in /var/lib/lrpkg/initrd.list here var/lib/lrpkg/root.dev.mk should be listed. and is there for backed up with initrd = at the boot device. Eric Wolzak which is the first package on /dev/cdrom. Kinda a chicken egg problem. I resolved it temporarily by specifying /dev/hdc (which is my actual cdromdrive) in isolinux.cfg in the boot variable in the pkgpath variable. You might want to change this in your documentation because I think I won't be the only bietekwiet who might make that mistake. Kim Oppalfens have you read my documentation on how to boot Bering from a CDROM? It's available @ http://leaf.sourceforge.net/devel/jnilo/bucdrom.html Have fun! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:56 AM To: Eric Wolzak Cc: Kim Oppalfens; [EMAIL PROTECTED] Subject: Re: [leaf-user] Bering bootable cd (Help) Comments inline Try to remove or uncomment the modules. Ok I' ll try that and see what happens. Btw the new kernel was necessary to boot from flashmodule from apacer which is an idedrive. At the end of /boot/etc/modules isofs.o is trying to load. I said trying, because it is failing stating insmod: init_modules isofs.o device or resource busy Did you use your own created modules, or did you download the modules ( in that case you could have a problem due to the fact that the modules on the bering site, are from a patched kernel. I used downloaded versions, but I used the same patches for the kernel so I don't think that is the problem, especially in combination with the next comment. (read on) Afterwards I get the tempfs linuxrc Installing packages : (all my packages are the (nf!) or not found I get a kernel panic stating that I tried to kill init. It seems that your cdrom is not recognized that reason the packages are not found. If I use all the same .lrp files kernel on the flash module everything runs fine except for the above mentioned ide-probe isofs problem. Which isn't a real concern when booting from the module. I expect that you included the flash rom ide support in the kernel itself. After you boot from the ide-rom, can you mount the cdrom or at least try to insmod the modules from boot/lib one by one and try to mount the cdrom then. Perhaps a conflict betweeen the ide driver for the cdrom and the disk ( Master slave conflict ? ) Hope I have given you a few hints where you might look for a solution. After I boot all modules are loaded (according to lsmod) except for isofs.o. If i try to insmod isofs.o I get the same problem, but a mount -t iso9660 /dev/cdrom /mnt works like a charm. So I think I can conclude that there is nothing wrong with the modules, can't I? I am affraid this also rules out master/slave problems. Correction this definitely rules out master/slave since flashrom is on ide channel 0 cdrom on ide channel 1. I didn't include ideflash support in the kernel by the way, the apacer module uses the ide specifiaction and does not need anything special to work. Kim - This mail sent through Tiscali Webmail (http://webmail.tiscali.be) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED]
Re: [leaf-user] Mounting /var/log on a ext2 partition
Le Vendredi 3 Mai 2002 22:17, sylvain pelletier a écrit : Hi, I switched from dachtein to bering, all works perfectly. I replaced my slow bind-8/exim by tinydns/qmail. Perhaps I'm tired but I don't find where the TMPFS on /var/log is created (wich script???) It's created by /linuxrc (symlink to /var/lib/lrpkg/root.linuxrc): SNIP [ $VERBOSE ] echo Generating /tmp /var/log files ... if [ `sed '/tmp_size/d' /proc/cmdline` = ]; then TMPSIZE=`sed 's/.*tmp_size=/\1/; s/ .*//1' /proc/cmdline` qt $BB mount -t tmpfs tmpfs /tmp -o size=$TMPSIZE else qt $BB mount -t tmpfs tmpfs /tmp fi SNIP I use a little hard disk for storage and I would like to store logs on a partition. What to do? 1/ Choose a FS for your HD (for example ext2, but could be reiserfs, ..;) and download the corresponding modules 2/ Format your HD 3/ Mount it If you choose minix, you do not need to load the module and you have access to mkfs.minix in the distro (but there is a max limit to 64M) If you choose ext2 you will have to donload the ext2.o module and you will need mke2fs and fsck.ext2. Also Charles has an how-to on this issue: http://leaf.sourceforge.net/devel/cstein/Documentation/LRPHardDiskHOWTO.txt Jacques ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] PPP over ATM with ADSL PCI card
Trying to get some sort of communication with my ADSL PCI card from Bering v1.0 RC2. Jacques has kindly been helping me with getting to this stage. I should now be able to get some communication going, but my device drivers don't appear to me to be recognising the card - I'm not really sure what sort of tests and commands I can use. Below is some info about my system. I'd appreciate it if anyone could make one or two suggestions about what I can do next. The driver is for a Bewan card based on the unicorn chipset. thanks Dave # lsmod Module PagesUsed by unicorn_atm10520 0 (unused) ip_nat_irc 2032 0 (unused) ip_nat_ftp 2672 0 (unused) ip_conntrack_irc2144 0 (unused) ip_conntrack_ftp2848 0 (unused) unicorn_pci 372992 0 (unused) bsd_comp3900 0 (unused) ppp_synctty 4376 0 (unused) n_hdlc 5760 0 (unused) pppoatm 2164 0 (unused) ppp_deflate39604 0 (unused) ppp_async 5932 0 (unused) ppp_generic14888 0 [bsd_comp ppp_synctty pppoatm ppp_deflate ppp_async] slhc4264 0 [ppp_generic] 8139too13084 1 mii 912 0 [8139too] # cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Class 0600: PCI device 8086:7030 (rev 1). Master Capable. Latency=64. Bus 0, device 7, function 0: Class 0601: PCI device 8086:7000 (rev 0). Bus 0, device 7, function 1: Class 0101: PCI device 8086:7010 (rev 0). Master Capable. Latency=64. I/O at 0xffa0 [0xffaf]. Bus 0, device 13, function 0: Class 0203: PCI device 104a:0500 (rev 16). IRQ 10. Master Capable. Latency=64. Min Gnt=9.Max Lat=40. Non-prefetchable 32 bit memory at 0xffbd [0xffbd]. Bus 0, device 15, function 0: Class 0300: PCI device 5333:5631 (rev 6). Master Capable. Latency=64. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xf800 [0xfbff]. Bus 0, device 16, function 0: Class 0200: PCI device 10ec:8139 (rev 16). IRQ 11. Master Capable. Latency=66. Min Gnt=32.Max Lat=64. I/O at 0xfc00 [0xfcff]. Non-prefetchable 32 bit memory at 0xffbefc00 [0xffbefcff]. # cat /etc/ppp/options # /etc/ppp/options lock ipparam ppp0 noipdefault noauth default-asyncmap defaultroute hide-password noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp lcp-echo-interval 20 lcp-echo-failure 3 sync maxfail 0 persist # cat /etc/ppp/peers/dsl-provider # Adjust here VP/VC - depends on country ISP # UK/BT: 0.38 - US/BE/FR: 8.35 plugin /usr/lib/pppd/pppoatm.so 0.38 lock ipparam ppp0 noipdefault noauth defaultroute hide-password noccp nobsdcomp nodeflate nopcomp novj novjccomp lcp-echo-interval 20 lcp-echo-failure 3 maxfail 0 persist # cat interfaces # /etc/network/interfaces -- configuration file for LEAF network # J. Nilo, April 2002 # # Loopback interface. auto lo eth0 ppp0 iface lo inet loopback # ADSL PCI PPP modem iface ppp0 inet ppp provider dsl-provider # Step 2: configure internal interface iface eth0 inet static address 192.168.0.10 masklen 24 broadcast 192.168.0.255 kernel.log May 3 21:09:16 firewall kernel: Linux version 2.4.18 (root@debian) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Sun Apr 21 12:50:34 CEST 2002 May 3 21:09:16 firewall kernel: BIOS-provided physical RAM map: May 3 21:09:16 firewall kernel: BIOS-e820: - 0009fc00 (usable) May 3 21:09:16 firewall kernel: BIOS-e820: 0010 - 0100 (usable) May 3 21:09:16 firewall kernel: BIOS-e820: fffc - 0001 (reserved) May 3 21:09:16 firewall kernel: On node 0 totalpages: 4096 May 3 21:09:16 firewall kernel: zone(0): 4096 pages. May 3 21:09:16 firewall kernel: zone(1): 0 pages. May 3 21:09:16 firewall kernel: zone(2): 0 pages. May 3 21:09:16 firewall kernel: Kernel command line: BOOT_IMAGE=linux initrd=initrd.lrp init=/linuxrc diskwait=yes root=/dev/ram0 boot=/dev/fd0u1680:msdos PKGPATH=/dev/fd0u1680 LRP=root,etc,local,modules,keyboard,shorwall,dnscache,libz,sshd,ppp-atm,webl et May 3 21:09:16 firewall kernel: Initializing CPU#0 May 3 21:09:16 firewall kernel: Detected 166.195 MHz processor. May 3 21:09:16 firewall kernel: Console: colour VGA+ 80x25 May 3 21:09:16 firewall kernel: Calibrating delay loop... 331.77 BogoMIPS May 3 21:09:16 firewall kernel: Memory: 14012k/16384k available (853k kernel code, 1984k reserved, 204k data, 60k init, 0k highmem) May 3 21:09:16 firewall kernel: Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) May 3 21:09:16 firewall kernel: Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) May 3 21:09:16 firewall kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes) May 3 21:09:16 firewall kernel: Buffer-cache hash table entries:
[leaf-user] DCD: Special Second External Interface ???
DCD: Special Second External Interface ??? [1] Summary diagram: +---+ | | | Remote Vendor| | Private Network | | | +---+ Florida ^ | Chicago v +---+ | | | ISDN Router | | Auto Dial, NAT, c. | | | +---+ ^ 192.168.14.252 | | 192.168.14.0/24 | v 192.168.14.254 +---+ | eth1 | ++ | | T-1 || | DCD wan1 |-| Internet | | | || | eth0 | ++ +---+ ^ 192.168.11.254 | v ++ ||- 192.168.10.0/24 | Internal | | Network | ||- 192.168.11.0/24 ++ ^ ^ | | | +- 192.168.12.0/24 | +- 192.168.13.0/24 [2] This Chicago DCD user has a fully functioning network -- everything below `eth1' in the diagram. [3] There is no problem exchanging data with their Florida vendor while the T-1 is working. [4] When the T-1 goes down, Chicago must continue to be able to send data to Florida! [5] Prior to the T-1, all data exchange was done via ISDN -- so, that is already available. [6] All that is required to make (initiate?) the ISDN connection is to ping the ISDN Router -- while it is powered on ; [7] We are only interested in initiating connection from Chicago -- one-way. [8] Since this is point-to-point, firewall rules are not required; but, they are highly desirable. [9] We should be able to use Andrew Hoying's ifcheck.lrp to automatically manage the routing tables -- shouldn't we? [10] I just spent six (6) hours trying to figure out how to add this design for eth1 to this existing DCD -- I am very frustrated! [11] How can this design be implemented under these conditions? What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Order of PCI ethernet cards:
Matt, hoping you can help with this. My boss designed a board with two 8139 cards on board. One is harwired to a connector intended to be eth0 the other to a switch intended to be eth1. Naturally the reverse occurred. If we can't fix this in BIOS he'll have to rewire. The question is why is the BIOS, which I assume is doing a bus scan selecting the particular order? What is it in the address or whatever lines which determines the order. For the why, you'll have to look at the kernel (and maybe the bios) source. I don't know if linux uses any of the BIOS calls for PCI configuration, or if it talks to the chipset hardware directly... Regardless, why not just reverse the bus scanning order in the driver? There are other drivers that do this (see the Tulip and aic7xxx drivers, for instance), so it shouldn't be too hard to mod the software, especially if you've got folks around wo are savy enough to be building custom hardware (and with the added incentive of covering their a** :-) The beauty of open-source :) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Re: FWD Through Put, Vol 1 #847 - 12 msgs
1. Re: FW Through Put (Dennis Stephens) 2. DCD, icmp NAT ??? (Michael D. Schleif) 3. RE: Testing IPsec pass-through (Eric B Kiser) 4. RE: Testing IPsec pass-through (Tom Eastep) 5. relay-ctrl (Bill Hults) 6. RE: Testing IPsec pass-through (Eric B Kiser) 7. RE: Testing IPsec pass-through (Tom Eastep) 8. proxy arp diagram for shorewall (Victor McAllister) 9. Re: relay-ctrl (Ray Olszewski) 10. Re: proxy arp diagram for shorewall (Tom Eastep) 11. Re: DCD, icmp NAT ??? (Ray Olszewski) 12. Re: DCD, icmp NAT ??? (Michael D. Schleif) --__--__-- Message: 1 Date: Wed, 01 May 2002 09:13:21 -0500 To: [EMAIL PROTECTED],[EMAIL PROTECTED] From: Dennis Stephens [EMAIL PROTECTED] Subject: Re: [leaf-user] FW Through Put This is the first time I've used mailing lists, so if I'm doing anything wrong, or doing something that is considered ill-mannered, please tell me. I am under the impression that to contribute to the mailing list, you use an email client, and reply to messages (after changing the subject to something more specific.) Is this so? And if so, then how come it seems in a single digest it seems issues can be brought up and resolved in a single email? Hopefully someone can tell me exactly how this works...I'm a bit confused atm. Sorry for asking so many questions...below is my contribution. First thanks all for feedback As usual for me, my haste injects problems. As a new information lead in I specifically suspect the cable company. The cable modem over a period of time of low to no use, that is, when I'm away will be displaying upon my return an indication that it is having a signal strength problem. Connectivity to the outside world from the workstation will have been lost. A modem reset, svi dhclient restart and svi network reload will get the firewall back up. An ipconfig /renew on the workstation and I'm back in business. The cable company will be out Monday morning to check this out. I don't know how relevant this is, but it might be something you might want to consider. A friend of mine had a similar problem, using a cable service and using Coyote Linux. His internet would drop out for no reason occasionally if he used Coyote, but using his pre-bought Netgear standalone router, there would be no problems. As a result, he specifically suspected the cable company somehow blocking his Linux machine. (I never agreed, but found no other explanation at the time.) His idea was because the Linux box was always still working on the LAN side. To get back onto the internet, a modem reset, and restarting the DHCP client etc (as described in your situation) was required. However, after I proved my image worked on my hardware (with his connection), he discovered it was a problem with his hardware. He said something about having Full Duplex Enabled (via a utility for the card) instead of disabled, and also said something to the effect that that card couldn't handle Full Duplex. Once he used the utility to disable Full Duplex, it worked perfectly. Just thought the situation sounded similar. Might not be exactly the same problem, but, it might help. At 11:39 AM 4/30/2002 -0700, you wrote: At 12:04 PM 4/30/02 -0500, Dennis Stephens wrote: Have started this morning with a cable modem problem and worked through it with Tech Support. Now the through put is less than half of what it should be. How can I determine that the problem is on the provider's side of the system and not in my firewall or home network? For our purposes, a good starting place would be describing what you mean by through put is less than half of what it should be. What throughput are you expecting, what are you getting, and how are you measuring it (include between where and where)? The system in question is a Win 2k workstation behind a Dachstein firewall connected to a cable modem. This provides me email, news and web surfing access. The VPN is client software run on the workstation that is port forwarded to/through the firewall and connects to a VPN server at the company I work for. No real VPN on the firewall except using ip_masq_ipsec. The advertised rate the cable company is supposed to be supporting is 764k down and 128k up. Now that is bits so I need to divide by eight (give or take a bit) that would be ~95.5kb/sec. A sample 5mb file they have at their site comes over at 45kb/sec peak to a low in single digits and sometimes times out. A lot of internet surfing can time out, accessing the email account can time out. I have been able to document speeds on a test file in the past, one and two months ago, that were closer to 900k down and 200k up. I ask because the traceroute result you report below is not really a local throughput measure, and response delays of the sort you mention there are far from surprising. I couldn't repliacte your experience this morning, but then I'm closer to Yahoo (only 10 steps) than you apparently are. snip,
[leaf-user] Help with LEAF Bering and the correct modules settings for an embedded Netelligent 10/100 TX controller on a Compaq Deskpro 4000
I am using the latest version posted on sourceforge. I have been fighting with it for a solid week now, and am finally admitting defeat. Here are copies of what config files I could find. I searched the internet everyway I could and just could not find much info on setting up any other .o files I needed to make the network card work. The ppp side seems to work ok, I can ping the internet from the Bering box and it auto dials when it boots up. I cannot ping any internal address from the Bering box and cannot ping the bering box from the internal network. The yellow light is all that comes on on the Compaq, but the switch it is hooked to shows a 100mb connection. This is my first foray into Linux, so try to be patient with me as I am sure it is something stupid I am overlooking. :) Thanks for any and all help! Bob Smith Erwin, Tennessee SYSLOG May 1 22:43:58 firewall syslogd 1.3-3#31.slink1: restart. May 1 22:43:58 firewall kernel: klogd 1.3-3#31.slink1, log source = /proc/kmsg started. May 1 22:43:58 firewall kernel: Cannot find map file. May 1 22:43:58 firewall kernel: Loaded 73 symbols from 9 modules. May 1 22:43:58 firewall kernel: Linux version 2.4.18 (root@debian) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Sun Apr 21 12:50:34 CEST 2002 May 1 22:43:58 firewall kernel: BIOS-provided physical RAM map: May 1 22:43:58 firewall kernel: BIOS-e801: - 0009f000 (usable) May 1 22:43:58 firewall kernel: BIOS-e801: 0010 - 0800 (usable) May 1 22:43:58 firewall kernel: On node 0 totalpages: 32768 May 1 22:43:58 firewall kernel: zone(0): 4096 pages. May 1 22:43:58 firewall kernel: zone(1): 28672 pages. May 1 22:43:58 firewall kernel: zone(2): 0 pages. May 1 22:43:58 firewall kernel: Kernel command line: BOOT_IMAGE=linux initrd=initrd.lrp init=/linuxrc root=/dev/ram0 boot=/dev/fd0u1680:msdos PKGPATH=/dev/fd0u1680 LRP=root,etc,local,modules,ppp,shorwall,dnscache,weblet,log,dhcpd May 1 22:43:58 firewall kernel: Initializing CPU#0 May 1 22:43:58 firewall kernel: Detected 166.589 MHz processor. May 1 22:43:58 firewall kernel: Console: colour VGA+ 80x25 May 1 22:43:58 firewall kernel: Calibrating delay loop... 331.77 BogoMIPS May 1 22:43:58 firewall kernel: Memory: 126896k/131072k available (853k kernel code, 3788k reserved, 204k data, 60k init, 0k highmem) May 1 22:43:58 firewall kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) May 1 22:43:58 firewall kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) May 1 22:43:58 firewall kernel: Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) May 1 22:43:58 firewall kernel: Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) May 1 22:43:58 firewall kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) May 1 22:43:58 firewall kernel: CPU: Before vendor init, caps: 008001bf , vendor = 0 May 1 22:43:58 firewall kernel: Intel Pentium with F0 0F bug - workaround enabled. May 1 22:43:58 firewall kernel: CPU: After vendor init, caps: 008001bf May 1 22:43:58 firewall kernel: CPU: After generic, caps: 008001bf May 1 22:43:58 firewall kernel: CPU: Common caps: 008001bf May 1 22:43:58 firewall kernel: CPU: Intel Pentium MMX stepping 03 May 1 22:43:58 firewall kernel: Checking 'hlt' instruction... OK. May 1 22:43:58 firewall kernel: POSIX conformance testing by UNIFIX May 1 22:43:58 firewall kernel: PCI: PCI BIOS revision 2.10 entry at 0xee25f, last bus=0 May 1 22:43:58 firewall kernel: PCI: Using configuration type 1 May 1 22:43:58 firewall kernel: PCI: Probing PCI hardware May 1 22:43:58 firewall kernel: PCI: Using IRQ router VIA [1106/0586] at 00:14.0 May 1 22:43:58 firewall kernel: Activating ISA DMA hang workarounds. May 1 22:43:58 firewall kernel: Linux NET4.0 for Linux 2.4 May 1 22:43:58 firewall kernel: Based upon Swansea University Computer Society NET3.039 May 1 22:43:58 firewall kernel: Initializing RT netlink socket May 1 22:43:58 firewall kernel: Starting kswapd May 1 22:43:58 firewall kernel: pty: 256 Unix98 ptys configured May 1 22:43:58 firewall kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ DETECT_IRQ SERIAL_PCI enabled May 1 22:43:58 firewall kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A May 1 22:43:58 firewall kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A May 1 22:43:58 firewall kernel: ttyS02 at 0x03e8 (irq = 5) is a 16550A May 1 22:43:58 firewall kernel: Software Watchdog Timer: 0.05, timer margin: 60 sec May 1 22:43:58 firewall kernel: block: 128 slots per queue, batch=32 May 1 22:43:58 firewall kernel: RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize May 1 22:43:58 firewall kernel: Floppy drive(s): fd0 is 1.44M May 1 22:43:58 firewall kernel: FDC 0 is a National Semiconductor PC87306 May 1 22:43:58 firewall kernel: NET4:
[leaf-user] Scary message from sh-httpd
Hello all - Today I got this repeated 16 times: sh-httpd[3203]: refused connect from 63-216-161-10.sdsl.cais.net with no DENY log of the attempt - I thought sh-httpd was configured only to listen to my internal interface! In fact, if I do try to connect to the external interface on port 80, it is denied and logged - so what happened here? Was the masquarading of my internal interface somehow subverted? Thanks in advance - Dave Yerger ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering v1.0-rc2 with diskonchip?
Darren Martz [EMAIL PROTECTED] wrote: snip I'm at a disadvantage here, my background is windows development. Alot of us started as Windows only. No biggie. It will expand your background. I'm also trying to locate an Ethernet driver for an i82557 chip. I may be on my own with the net driver, Here's two links from the Intel site. But I'd try the eepro100.o driver first. I get the impression from the Intel site that this is just another version of the pro100 series of cards. I am using the eepro100 on my i82555 chipped cards with no problems. One is an old epro100B and the other is Intel's newer In Business 10/100 card. They look a little different, but work the same with the eepro100.o driver. You will also have to uncomment the pci-scan.0 driver too. The pci-scan driver has to be first in the modules.conf file before pci style adapters. Further information on the Linux driver can be found at http://www.scyld.com/network/eepro100.html.(This driver will work with the 10mbps PCI Pro-Plus boards that use the i82557 chip) This driver is available on all LEAF distros. http://www.intel.com/support/network/sb/1013651991539069-prd38.htm which redirects you to http://support.intel.com/support/network/adapter/pro100/21397.htm snip Darren How this helps, Greg ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
