RE: [leaf-user] Is it worth making LEAF work on 386?
Hi Brock Thanks for your concerns on power consumption and I would have to agree about using an AP, particularly if buying everything from the start it would be better. The wireless cards only cost me $13USD each and I have everything else except coax and connectors so even with the extra power consumption it will work out a bit cheaper for me to use a LEAF system. I can put money that would be spent on an AP towards the extra required for solar panel. It's also a project for me to learn more about Linux/routing/wireless etc. Another big advantage for me is if there is a problem with hardware I have spare cards and mother boards as replacements. Along with a friend that can do the replacing if I'm away. Again if I had nothing in my junk bin and starting with nothing, AP's would be the best way. Steve. > > Not wanting to rain on anyone's parade, but I am of the > opinion that this is > a *bad* idea... for one main reason: > > Power Consumption. > > As Steve alluded to, solar equipment is not cheap. I think > the key to a > cost-effective solution is to buy a real access point that > can function as a > repeater. The smaller and simpler the better. What you pay for this > hardware over and above the cost of a LEAF box will likely be > less than the > additional solar panels, batteries and grief of building and > maintaining a > LEAF install in a less than hospitable environment. The AP > is more likely > to keep going in the cold of winter and heat of summer than > that 386 is. > > A simple repeater has no need for firewall abilities, dhcp, > ssh or any of > the other goodies in LEAF! These abilities are better used > at the ends to > prevent unauthorized access via the repeater. If you can get > the repeater > concept to go, perhaps something like nocatauth from > nocat.net would be a > better solution to keep the neighbours from stealing your > bandwidth (if > that's a concern). > > Brock > > | > I'm putting in a wireless link from friends in city to > farm for faster > | > Internet access and need to have a remote repeater site > on hill running > | > from battery and solar power. LEAF should be ideal for > this. I will make > | > a power supply to run the mother board direct from the > battery to reduce > | > losses (about %15) from using Inverter and PC supply. > Sun power might > | > be free but solar panels are not cheap, so the lower the > losses and > | > power requirements the better. > > > >
Re: [leaf-user] Dachstein /proc/pci missing
> Their all PCI, all use tulip.o, > > I've tried mixing the nic's around to see if there is order to this, oddly > regardless of what slot the 10bT nic is in it is always comes up eth2. > While the other two can be interchanged. Though this motherboard seems to > assign eth0 starting on the nic furthest from the io ports. Could this be > an ordering issue inside the driver? the 10bT probably uses a earlier > variation than the other two. > > Just in case it matters... > Bering 1.0 rc2 > 2x SMC 1255TX (10/100) > 1x D-Link 530 CT (10bT) has digital 21041-PB > Motherboard ASUS TXP4, 32MB ram, P166 ethX to physical card mapping can get to be a bit confusing. Basically, there are two layers that affect this mapping. The first is the module load order. If you have cards that use different driver modules, the driver module loaded first will assign the lower ethernet device numbers. Once a module is loaded, it is the responsability of *THAT MODULE* to assign device numbers to the cards that module is talking to. The device ordering of multiple cards supported by a single driver is *DRIVER DEPENDENT*. ISA drivers typically assign device numbers in the order you pass the physical I/O address on the command line, except for some wacky 3-Com cards, which have a built-in "plug-n-play" type auto-detect feature, which causes cards to get device numbers assigned in order of MAC address. PCI drivers typically assign device numbers in the order the cards are found on the PCI bus, which is motherboard and chipset dependant, but normally starts at one end of the PCI bus and goes to the other. In your case using the tulip driver, you're also using cards with multiple PCI device/vendor ID's. In this case, it would appear the tulip driver is doing something like: for each CardID in supported device/vendor ID FoundCards = Scan PCI bus for CardID for each Card in FoundCards assign device ID to Card done done Thus, the two matching cards follow the PCI bus scanning order when getting assigned ethernet numbers, but the 'odd man out' is always seen last... Of course for the final word on how multiple cards will be handled, you'll have to look at the code... HTH, Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
Re: [leaf-user] FW Through Put
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. 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, snip... >In practice, with equipment of the quality you are using, I've seen about a >10% hirt on throughput. But only at the higher levels of LAN-to-LAN routing >(nominally 10 Mbps; in practice, about 5 Mbps). The usual range of offsite >connections -- 384 Kbps to 1544 Kbps -- does not normally induce >router-based throughput losses. > > >They are taking the > >position (of course they would), that they can not see a reason for the > >reduction. The Dachstien floppy is working fine, with only a slight hole > >poked through it for my VPN connection to the corporation. > >A 486/66 is plenty fast for a normal NAT'ing router, but it isn't very much >horsepower for running a VPN. From what you wrote, I can't tell where in the >system the VPN'ing is being done. If on the router, that could be slowing >things down. > >When you are having speed problems, what does the router's CPU utilization >look like? (Can someone remind me how to check this in Dachstein? I usually >use top for this, but I don't think Dachstein includes it.) I give, that was the basis of my question(s). How do I document what the firewall is doing other than the packet handling results in system logs. > >Everything is > >working, the weblet, the bandwidth monitor et al. Just working > >slowly. > >Do you really mean that a connection from the Weblet to a host on the LAN is >"working slowly"? If so, this suggests a local problem, not a cable-side >problem. No, that (weblet page) pops up crisp and fast. > >How do I determine where a bottleneck or degradation is > >occurring? Did a traceroute from here to yahoo and had a hop that was 200+ > >ms and one other of the 22 hops that was 700+.ms. > >Where was "here"? The router or a host on the LAN behind the router? Was the >VPN involved? As described above here is where this email was created a workstation behind the Dachstein firewall. >Depending on time of day and other details, delays of this sort can occur >without the cable company (or anything else local) being at fault. > > >Truly appreciate any > >guidance and greatly appreciate the programming and work of all that helped > >with this great application. > > snip... Ditto the last paragraph. This forum always shows up in spades and for that I am grateful. As Always...
[leaf-user] DCD, icmp & NAT ???
As you know, I sometimes run into seemingly inexplicable anomalies, for which I do not know what corroborative evidence is appropriate. This is another one of those ;> [1] My question is, *how* can an icmp packet get through DCD _and_ get to an internal, NAT'ed system ??? [2] Stock DCD, regarding icmp -- no mods. [3] LEAF/LRP development box: # uname -a Linux Frigg 2.2.19-3-LEAF #4 Sun Dec 16 18:10:46 CST 2001 i586 unknown # ifconfig loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:28 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0 eth0 Link encap:Ethernet HWaddr 00:60:97:67:74:9A inet addr:192.168.123.130 Bcast:192.168.123.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3274464 errors:118 dropped:0 overruns:122 frame:118 TX packets:935885 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0 Interrupt:11 Base address:0xd800 [4] Strange message logged this morning: # grep icmp /var/log/syslog May 1 07:02:55 Frigg icmplogd: destination unreachable from [12.244.72.230] May 1 07:09:19 Frigg icmplogd: destination unreachable from [12.244.72.230] [5] 12.244.72.230 is somewhere on AT&T network; but, doesn't have a dns name nor reverse lookup: # dnsname 12.244.72.230 # dnsqr any 230.72.244.12.in-addr.arpa 255 230.72.244.12.in-addr.arpa: 44 bytes, 1+0+0+0 records, response, authoritative, nxdomain query: 255 230.72.244.12.in-addr.arpa # dnsqr any 72.244.12.in-addr.arpa 255 72.244.12.in-addr.arpa: 40 bytes, 1+0+0+0 records, response, noerror query: 255 72.244.12.in-addr.arpa # dnsqr any 244.12.in-addr.arpa 255 244.12.in-addr.arpa: 198 bytes, 1+5+0+0 records, response, noerror query: 255 244.12.in-addr.arpa answer: 244.12.in-addr.arpa 172800 NS cbru.br.ns.els-gms.att.net answer: 244.12.in-addr.arpa 172800 NS dbru.br.ns.els-gms.att.net answer: 244.12.in-addr.arpa 172800 NS cmtu.mt.ns.els-gms.att.net answer: 244.12.in-addr.arpa 172800 NS dmtu.mt.ns.els-gms.att.net answer: 244.12.in-addr.arpa 172800 SOA cbru.br.ns.els-gms.att.net rm-hostmaster.ems.att.com 29 86400 1 60 172800 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 . . .
RE: [leaf-user] Testing IPsec pass-through
Tom, thanks for getting back to me so quickly yesterday. I have success! I am using NAT and these rules... ACCEPT net loc udp 500 ACCEPT net loc 50 all Thanks for your help, works like a charm. /Eric -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 8:15 PM To: Eric B Kiser Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Testing IPsec pass-through On Tue, 30 Apr 2002, Eric B Kiser wrote: > I have finally gotten the opportunity to test this out... > > I added these lines to the bottom /etc/shorewall/rules and I am still unable > to connect to my IPsec endpoint on the other side of my Bering box. These > are the only modifications from the default install of Bering. > > ACCEPTnet loc udp 500 > ACCEPTloc net udp 500 > ACCEPTnet loc 50,51 all > ACCEPTloc net 50,51 all > > Did I miss something? > Put these in the wrong place? > um ...? Theww things: a) If you are using NAT or Masquerade, you must use port forwarding rules for net->loc. b) In that case, you don't need to pass protocol 51 since ESP and NAT don't mix. c) The default Bering loc->net policy is ACCEPT so your loc->net rules are just so much extra noise. The port forward rules would look like: ACCEPT net loc: udp 500 - all ACCEPT net loc: 50 - - all -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED]
RE: [leaf-user] Testing IPsec pass-through
On Wed, 1 May 2002, Eric B Kiser wrote: > Tom, thanks for getting back to me so quickly yesterday. > > I have success! I am using NAT and these rules... > > ACCEPTnet loc udp 500 > ACCEPTnet loc 50 all > > Thanks for your help, works like a charm. > /Eric > Eric, You must be using static NAT then? -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED]
[leaf-user] relay-ctrl
Hi We have a q-mail server set up using relay-ctrl for e-mail relay control. It is a stand alone machine with a public IP address. People are able to get their e-mail everywhere except from our internal network (that uses a different ISP & a different set of IP #'s) which is behind a Dachstein FW. It also occasionally works from inside or works for a while & then stops. I'm wondering if the FW is the problem and if I need to open a port for relay-ctrl to come back in on? Anyone know anything about the behavior of this program and/or if I'm on the right track? It appears to use a random port above 5100 0. TIA Bill
RE: [leaf-user] Testing IPsec pass-through
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? /Eric -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 10:55 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: > Tom, thanks for getting back to me so quickly yesterday. > > I have success! I am using NAT and these rules... > > ACCEPTnet loc udp 500 > ACCEPTnet loc 50 all > > Thanks for your help, works like a charm. > /Eric > Eric, You must be using static NAT then? -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED]
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]
[leaf-user] proxy arp diagram for shorewall
I am looking to build a transparent firewall with proxy arp so that internal boxes can use public IPs. I have been using the LEAF mountain series and switched to Dachstein about 5 months ago. I have been trying to read up on the Bering LEAF system which is a derivative of Dachstein. Bering uses Shorewall. Looking at the diagram of your system I am interested in how your workstations have both a private IP and a public IP as you describe and diagram here: http://www.shorewall.net/myfiles.htm Victor McAllister
Re: [leaf-user] relay-ctrl
Am I right in thinking that this question refers to the package that identifies itself as qmail (www.qmail.org), not q-mail? Assuming so ... I'm a bit confused from the way you pose your question. For qmail, relay-ctrl (http://untroubled.org/relay-ctrl/) seems to be a plug-in that handles *outgoing* mail by requiring POP3- or IMAP-password authentication before accepting outgoing mail for relaying. It appears to have nothing whatsoever to do with *receiving* e-mail. So, if I understand this correctly, telling us you use relay-ctrl doesn't describe the characteristics of your setup for *receiving* mail. This leads me to ask the following questions -- 1. Am I correct in inferring that you are using Dachstein as a router/firewall but NOT for NAT'ing? Since you say your LAN uses "a different ISP & a different set of IP #'s", I infer that ... but I may be assuming too much here. 2. How do your users normally "get" their mail from this relay? Is it forwarding to SMTP servers on their hosts? Responding to POP3 requests for downloads? To IMAP requests? Running a Web-based mail interface? Something else? 3. When you say qmail "appears to use a random port above 5100 0" (a typo for 51000, I assume), are you referring to its source or destination port? If source, what is the destination port? If destination, what do clients use that listens on (or sends download requests from) that port (range)? 4. When you say users can get mail "everywhere except from our internal network", how large a value are you using for "everywhere"? That is, how many places outside your LAN actually are used by your user base? If the number is small, what are their characteristics? 5. With respect to whatever service is your answer to question #2, do you have any specific firewall or port-forwarding rules on your system that apply to it? At 11:00 AM 5/1/02 -0400, Bill Hults wrote: >Hi >We have a q-mail server set up using relay-ctrl for e-mail relay >control. It is a stand alone machine with a public IP address. >People are able to get their e-mail everywhere except from our internal >network (that uses a different ISP & a different set of IP #'s) which is >behind a Dachstein FW. It also occasionally works from inside or works >for a while & then stops. >I'm wondering if the FW is the problem and if I need to open a port for >relay-ctrl to come back in on? Anyone know anything about the behavior >of this program and/or if I'm on the right track? It appears to use a >random port above 5100 0. >TIA >Bill > > > -- "Never tell me the odds!"--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED]
Re: [leaf-user] proxy arp diagram for shorewall
On Wed, 1 May 2002, Victor McAllister wrote: > I am looking to build a transparent firewall with proxy arp so that internal boxes > can use public IPs. I have been using the LEAF mountain series and switched to > Dachstein about 5 months ago. I have been trying to read up on the Bering LEAF > system which is a derivative of Dachstein. Bering uses Shorewall. > > Looking at the diagram of your system I am interested in how your workstations > have both a private IP and a public IP as you describe and diagram here: > http://www.shorewall.net/myfiles.htm > > Because they are using Static NAT rather than Proxy ARP. Only the Server in the DMZ uses Proxy ARP. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED]
Re: [leaf-user] DCD, icmp & NAT ???
If I had to *guess*, my guess would be that what you logged is an icmp reply from a router on the path to some host you were trying to reach. The router in question is *supposed* to be AT&T's route to the address you were trying to reach, but it actually cannot reach it. (For example, it is a dial-up IP address not in use at the moment you tried to reach it.) At 09:20 AM 5/1/02 -0500, Michael D. Schleif wrote: [...] >[1] My question is, *how* can an icmp packet get through DCD _and_ get >to an internal, NAT'ed system ??? By being a reply to an outgoing icmp (or other) packet. If you enable icmp NAT'ing, the router can handle this just fine. I don't actually recall, but I'd expect stock DCD to work that way. [...] >[4] Strange message logged this morning: > > # grep icmp /var/log/syslog > May 1 07:02:55 Frigg icmplogd: destination unreachable from >[12.244.72.230] > May 1 07:09:19 Frigg icmplogd: destination unreachable from >[12.244.72.230] I assume this log is on a NAT'd host, not on the router itself. >[5] 12.244.72.230 is somewhere on AT&T network; but, doesn't have a dns >name nor reverse lookup: Not unusual for routers. -- "Never tell me the odds!"--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED]
Re: [leaf-user] DCD, icmp & NAT ???
Thank you, for your ideas. Ray Olszewski wrote: > > If I had to *guess*, my guess would be that what you logged is an icmp reply > from a router on the path to some host you were trying to reach. The router > in question is *supposed* to be AT&T's route to the address you were trying > to reach, but it actually cannot reach it. (For example, it is a dial-up IP > address not in use at the moment you tried to reach it.) Yes, that makes sense, except that this box has _no_ reason -- that I know about -- for contacting the outside world. It is a development-only box, from which I have never accessed anything outside of my own internal network. > At 09:20 AM 5/1/02 -0500, Michael D. Schleif wrote: > [...] > >[1] My question is, *how* can an icmp packet get through DCD _and_ get > >to an internal, NAT'ed system ??? > > By being a reply to an outgoing icmp (or other) packet. If you enable icmp > NAT'ing, the router can handle this just fine. I don't actually recall, but > I'd expect stock DCD to work that way. > > [...] > >[4] Strange message logged this morning: > > > > # grep icmp /var/log/syslog > > May 1 07:02:55 Frigg icmplogd: destination unreachable from > >[12.244.72.230] > > May 1 07:09:19 Frigg icmplogd: destination unreachable from > >[12.244.72.230] > > I assume this log is on a NAT'd host, not on the router itself. Yes -- on Frigg. > >[5] 12.244.72.230 is somewhere on AT&T network; but, doesn't have a dns > >name nor reverse lookup: > > Not unusual for routers. OK, that, too, makes sense . . . -- 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 . . .
Re: [leaf-user] dachstein question
Yes, it appears the NICs are not initializing. As another thread observed, there is no /proc/pci file, either. I am using rtl8139.o driver from http://lrp.steinkuehler.net/files/kernels/Dachstein-normal/modules/net/rtl81 39.o If I try manual install: insmod /lib/modules/rtl8139.o the response is: insmod: unresolved symbol pci_drv_unregister insmod: unresolved symbol pci_drv_register Next place to look? Thanks, Steve - Original Message - From: "Simon Bolduc" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, April 30, 2002 4:16 PM Subject: Re: [leaf-user] dachstein question > This message may come up if your NICs aren't being initialized. Log in and > run ifconfig or ip addr - chances are your nic aren't there. Double check > your modules file, make sure the correct modules are uncommented, if they > are PCI nics make sure that pci-scan is loading before the NIC modules. > > S > > > >From: "steve crowl" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Subject: [leaf-user] dachstein question > >Date: Tue, 30 Apr 2002 11:50:39 -0500 > > > >Hello. I received the following log message attempting to run dachstein (I > >have successfully run eigerstein on same configuration): > > > >firewall dhcpd: No subnet declaration for eth1 (0.0.0.0). > >firewall dhcpd: Please write a subnet declaration in your dhcpd.conf file > >for the > >firewall dhcpd: network segment to which interface eth1 is attached. > >firewall dhcpd: exiting. > > > >Suggestions?? Thanks > > > >Regards, > >Steve > > > > > > > >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 > > > > > _ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > ___ > > 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] Is it worth making LEAF work on 386?
Steve, You will indeed learn a lot from this project, and of course you can do that learning while tethered to the power pole. Having dealt with alternate energy systems since 1985, including remote sites operating radio and telecommunications gear, I can assure you that you will not be operational for any length of time using solar/battery power unless you are willing to spend many times the cost of an AP for solar panels, batteries, and energy management equipment. Even using an off-the-shelf AP, (two if you want to repeat), is not a simple excercise using solar power. To my knowledge, there is no AP today that has been designed with minimal energy usage as a primary goal. By all means play with LEAF and wireless networking, but don't expect much from a surplus 386. Even an old laptop would suck too much energy to run on a simple solar/battery system. Have fun. -- Sincerely, David Smead http://www.amplepower.com. On Wed, 1 May 2002, steve wrote: > Hi Brock > Thanks for your concerns on power consumption and I would have to agree > about using an AP, particularly if buying everything from the start it > would be better. > > The wireless cards only cost me $13USD each and I have everything else > except coax and connectors so even with the extra power consumption it > will work out a bit cheaper for me to use a LEAF system. I can put > money that would be spent on an AP towards the extra required for solar > panel. It's also a project for me to learn more about > Linux/routing/wireless etc. > > Another big advantage for me is if there is a problem with hardware I > have spare cards and mother boards as replacements. Along with a friend > that can do the replacing if I'm away. > > Again if I had nothing in my junk bin and starting with nothing, AP's > would be the best way. > > Steve. > > > > > Not wanting to rain on anyone's parade, but I am of the > > opinion that this is > > a *bad* idea... for one main reason: > > > > Power Consumption. > > > > As Steve alluded to, solar equipment is not cheap. I think > > the key to a > > cost-effective solution is to buy a real access point that > > can function as a > > repeater. The smaller and simpler the better. What you pay for this > > hardware over and above the cost of a LEAF box will likely be > > less than the > > additional solar panels, batteries and grief of building and > > maintaining a > > LEAF install in a less than hospitable environment. The AP > > is more likely > > to keep going in the cold of winter and heat of summer than > > that 386 is. > > > > A simple repeater has no need for firewall abilities, dhcp, > > ssh or any of > > the other goodies in LEAF! These abilities are better used > > at the ends to > > prevent unauthorized access via the repeater. If you can get > > the repeater > > concept to go, perhaps something like nocatauth from > > nocat.net would be a > > better solution to keep the neighbours from stealing your > > bandwidth (if > > that's a concern). > > > > Brock > > > > | > I'm putting in a wireless link from friends in city to > > farm for faster > > | > Internet access and need to have a remote repeater site > > on hill running > > | > from battery and solar power. LEAF should be ideal for > > this. I will make > > | > a power supply to run the mother board direct from the > > battery to reduce > > | > losses (about %15) from using Inverter and PC supply. > > Sun power might > > | > be free but solar panels are not cheap, so the lower the > > losses and > > | > power requirements the better. > > > > > > > > > > >
Re: [leaf-user] DCD, icmp & NAT ???
At 11:22 AM 5/1/02 -0500, Michael D. Schleif wrote: [...] >Ray Olszewski wrote: >> >> If I had to *guess*, my guess would be that what you logged is an icmp reply >> from a router on the path to some host you were trying to reach. The router >> in question is *supposed* to be AT&T's route to the address you were trying >> to reach, but it actually cannot reach it. (For example, it is a dial-up IP >> address not in use at the moment you tried to reach it.) > >Yes, that makes sense, except that this box has _no_ reason -- that I >know about -- for contacting the outside world. It is a >development-only box, from which I have never accessed anything outside >of my own internal network. Well ... certainly there is no one in a better position than you to know what services, cron jobs, and the like actually run on this host. Not to mention what, if anything, you were doing on it at the relevant time. But paranoids have enemies too. So I'd be inclined, if I saw this on one of my machines, to guess that something running on the host had a reason I *didn't* know about to do an occasional off-site connection. YMMV, of course. -- "Never tell me the odds!"--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED]
Re: [leaf-user] dachstein question
Did you uncomment pci-scan and make sure its entry is above the nic module entry in your modules file as mentioned in my previous post? That is probably the problem. S >From: "steve crowl" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: Re: [leaf-user] dachstein question >Date: Wed, 1 May 2002 11:33:58 -0500 > >Yes, it appears the NICs are not initializing. As another thread observed, >there is no /proc/pci file, either. I am using rtl8139.o driver from >http://lrp.steinkuehler.net/files/kernels/Dachstein-normal/modules/net/rtl81 >39.o > >If I try manual install: insmod /lib/modules/rtl8139.o >the response is: insmod: unresolved symbol pci_drv_unregister >insmod: unresolved symbol pci_drv_register > >Next place to look? > >Thanks, >Steve > > >- Original Message - >From: "Simon Bolduc" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Sent: Tuesday, April 30, 2002 4:16 PM >Subject: Re: [leaf-user] dachstein question > > > > This message may come up if your NICs aren't being initialized. Log in >and > > run ifconfig or ip addr - chances are your nic aren't there. Double >check > > your modules file, make sure the correct modules are uncommented, if >they > > are PCI nics make sure that pci-scan is loading before the NIC modules. > > > > S > > > > > > >From: "steve crowl" <[EMAIL PROTECTED]> > > >To: <[EMAIL PROTECTED]> > > >Subject: [leaf-user] dachstein question > > >Date: Tue, 30 Apr 2002 11:50:39 -0500 > > > > > >Hello. I received the following log message attempting to run dachstein >(I > > >have successfully run eigerstein on same configuration): > > > > > >firewall dhcpd: No subnet declaration for eth1 (0.0.0.0). > > >firewall dhcpd: Please write a subnet declaration in your dhcpd.conf >file > > >for the > > >firewall dhcpd: network segment to which interface eth1 is attached. > > >firewall dhcpd: exiting. > > > > > >Suggestions?? Thanks > > > > > >Regards, > > >Steve > > > > > > > > > > > > >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 > > > > > > > > > > _ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > ___ > > > > 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 > > _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: [leaf-user] dachstein question
At 11:33 AM 5/1/02 -0500, steve crowl wrote: >Yes, it appears the NICs are not initializing. As another thread observed, >there is no /proc/pci file, either. I am using rtl8139.o driver from >http://lrp.steinkuehler.net/files/kernels/Dachstein-normal/modules/net/rtl81 >39.o > >If I try manual install: insmod /lib/modules/rtl8139.o >the response is: insmod: unresolved symbol pci_drv_unregister >insmod: unresolved symbol pci_drv_register > >Next place to look? load pci_scan.o BEFORE you load rtl8139.o -- "Never tell me the odds!"--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED]
Re: [leaf-user] dachstein question
Doh...overlooked this change from eiger to dach. Works great now. Thanks for the help and patience. Regards, Steve - Original Message - From: "Simon Bolduc" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, May 01, 2002 11:46 AM Subject: Re: [leaf-user] dachstein question > Did you uncomment pci-scan and make sure its entry is above the nic module > entry in your modules file as mentioned in my previous post? That is > probably the problem. > > S > > > >From: "steve crowl" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Subject: Re: [leaf-user] dachstein question > >Date: Wed, 1 May 2002 11:33:58 -0500 > > > >Yes, it appears the NICs are not initializing. As another thread observed, > >there is no /proc/pci file, either. I am using rtl8139.o driver from > >http://lrp.steinkuehler.net/files/kernels/Dachstein-normal/modules/net/rtl8 1 > >39.o > > > >If I try manual install: insmod /lib/modules/rtl8139.o > >the response is: insmod: unresolved symbol pci_drv_unregister > >insmod: unresolved symbol pci_drv_register > > > >Next place to look? > > > >Thanks, > >Steve > > > > > >- Original Message - > >From: "Simon Bolduc" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > >Sent: Tuesday, April 30, 2002 4:16 PM > >Subject: Re: [leaf-user] dachstein question > > > > > > > This message may come up if your NICs aren't being initialized. Log in > >and > > > run ifconfig or ip addr - chances are your nic aren't there. Double > >check > > > your modules file, make sure the correct modules are uncommented, if > >they > > > are PCI nics make sure that pci-scan is loading before the NIC modules. > > > > > > S > > > > > > > > > >From: "steve crowl" <[EMAIL PROTECTED]> > > > >To: <[EMAIL PROTECTED]> > > > >Subject: [leaf-user] dachstein question > > > >Date: Tue, 30 Apr 2002 11:50:39 -0500 > > > > > > > >Hello. I received the following log message attempting to run dachstein > >(I > > > >have successfully run eigerstein on same configuration): > > > > > > > >firewall dhcpd: No subnet declaration for eth1 (0.0.0.0). > > > >firewall dhcpd: Please write a subnet declaration in your dhcpd.conf > >file > > > >for the > > > >firewall dhcpd: network segment to which interface eth1 is attached. > > > >firewall dhcpd: exiting. > > > > > > > >Suggestions?? Thanks > > > > > > > >Regards, > > > >Steve > > > > > > > > > > > > > > > > > >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 > > > > > > > > > > > > > > > _ > > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > > > > ___ > > > > > > 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 > > > > > > > > > _ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > >
[leaf-user] Compiling Bering Linux kernel
I have received many off-list requests about how to compile a Bering linux kernel. So here is a short how-to: 1/ Bering rc2 is built from linux kernel 2.4.18 2/ Bering can work without any patch. Especially none of the former LRP patches are required. 3/ Bering is compiled with patches to add extra functionnalities, namely - transparent bridging - htb QoS - iptables 1.2.6a patches and of course ipsec :-) For those who wants to replicates the "original" Bering rc2 kernel look at the README.txt in : http://leaf.sourceforge.net/devel/jnilo/bering/latest/patches/kernel/ it tells everything. You will also find some all the required patches in this directory (apart from freeswan 1.97 and iptables 1.2.6a related ones) 4/ Finally the .config file is there: http://leaf.sourceforge.net/devel/jnilo/bering/latest/Bering_1.0-rc2.config 5/ I am compiling the kernel on a Debian Potatoe machine. But any machine with a Gcc 2.95 or better should do (slink won't work :-)) That's all folks ! Jacques
Re: [Leaf-user] Packages (.lrp) list updated
At 21:31 12/04/2002, Mike Noyes wrote: Hi everyone, I just finished adding descriptions & versions & original webpage for all the packages on the html list. Its an excell sheet (I know I know) But this way I could do some of the stuff at work :-) Version were taken from the version file in the package or documentation in the package. Original webpage was taken from the .help file or through freshmeat/sourceforge/google. Descriptions were taken from .help file/ original download location/ freshmeat/sourceforge/google and if the packager was David http://www.securityfocus.com/tools :-) I can quite easily convert the excell sheet to a comma seperated value list and will probably send it in this way to mike so that he can add his glibc data. The information in the list is not really complete since their were quite some things I couldn't figure out what they were or how to describe them. Since I am just a linux newbie somethings might be easy to describe for some of you. If you are the packager of one of those empty lines don't hesitate to mail me the info or we might find another way to make the list more complete. Of course you don't have to be the packager to do this, If you happen to know what a certain package is just let us know. Final note : It is quite possible that I screwed up on occasion, it is even very likelijk ;-) Don't hesitate to send me any corrections you might have. Kim >Everyone, >I just updated our packages list, with help from Charles. I hope this >helps people find our packages easier. >http://leaf.sourceforge.net/pub/packages-list.txt > >-- >Mike Noyes <[EMAIL PROTECTED]> >http://sourceforge.net/users/mhnoyes/ >http://leaf-project.org/ > > >___ >Leaf-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/leaf-user ___ 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
