[leaf-user] kernel crash
Hi list, I'm using the Bering firewall for several years now. First standard Bering and now Bering-uClib. With both versions I have had a mysterious error when installing a new version now I have it with version 2.2.2. System: PII (I think) 90 Mhz 48 MB Ram, diskless. The error: After loading linuxrc etc. the system loads perfetctly until it has installed the modules for eth0 (3c905) and eth1 (ne2000) (found in kern.log) then the error appears: "Unable to handle kernel paging request at virtual address 000e0001" Then a long list of registers values etc. are given (which I don't write down as I think they are too specific. It also says kernel Oops 0002) At that moment insmod is the running program. Of course the system is then unusable and halts. Luckily my old version is still functional. However I'm working with version 2.0 and would like to use 2.2.2. Has anybody any clue what's the problem? Thanks a lot. Joep -- Joel Louis Blom <[EMAIL PROTECTED]> --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ 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] dropbear
I tried to contact my Bering -uClib_2.1 firewall from a winXP system with the ssh-client 'bitvise Tunnelier'. However, although the connection seems to be accepted (it says i the log 'password accepted') no connection is possible. With another Linux system (Fedora 2.6) connection is no problem. In the auth logfile the following is shown: Dec 27 11:31:40 renault dropbear[25897]: Child connection from 192.168.100.33:4102 Dec 27 11:31:43 renault dropbear[25897]: password auth succeeded for 'joep' Dec 27 11:31:43 renault dropbear[25897]: exit after auth (joep): bad buf_getbyte. What is ment by "bad buf_getbyte". Does anybody know how to solve this. Thanks in advance Joep --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Cant connect to external https site
lars, UI just tried it with Mozilla and got no problem. Firewall: Bering uclibc 2.1 on an 66 Mhz Winchip (memory only no disks) Joep On Fri, 2005-03-11 at 11:33, Lars wrote: > Came to my mind that anyone can test: > > Browse to http://www.elfa.se/en/ and press the button > "Order status" at the bottom of the page. For me > nothing comes up and the browser times out after a > while. (You dont need an account at Elfa to test this) > > /Lars > > > > > --- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > leaf-user mailing list: leaf-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-user > SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Shorewall problem
Hi, I am using Bering -uClibc now for more than a year (after > 2 year the earlier versions) and I think it is the best firewall there is especially as it can run on a memory only system. I now, however have a small problem with Shorewall. For some reasons I want to give ssh access to the firewall from another system. So I set in the Rules file the appropriate ACCEPT statements. However, Shorewall refuses to give TCP access to the system. Here is the result of my Rules file when Shorewall is restarting: [EMAIL PROTECTED] svi shorewall restart Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Restarting Shorewall... Initializing... Determining Zones... Zones: net loc Validating interfaces file... Validating hosts file... Validating Policy file... Determining Hosts in Zones... Net Zone: eth0:0.0.0.0/0 Local Zone: eth1:0.0.0.0/0 Processing /etc/shorewall/init ... Deleting user chains... Creating input Chains... Configuring Proxy ARP Setting up NAT... Adding Common Rules Adding rules for DHCP Enabling RFC1918 Filtering Setting up Kernel Route Filtering... IP Forwarding Enabled Processing /etc/shorewall/tunnels... Processing /etc/shorewall/rules... Rule "ACCEPT fw net tcp 53" added. Rule "ACCEPT fw net udp 53" added. Rule "ACCEPT fw net:nic.lth.se tcp" added. Rule "ACCEPT fw net udp 37,123" added. Rule "ACCEPT loc fw tcp 22,20,21" added. Rule "ACCEPT net:xxx.xxx.xxx.xxx fw tcp 22" added. (for security) Rule "ACCEPT fw net:xxx.xxx.xxx.xxx tcp" added. (idem) Rule "ACCEPT loc fw icmp 8" added. Rule "ACCEPT net fw icmp 8" added. Rule "ACCEPT fw loc icmp 8" added. Rule "ACCEPT fw net icmp 8" added. Rule "ACCEPT loc fw udp 53" added. Rule "ACCEPT loc fw tcp 80" added. Processing /etc/shorewall/policy... Policy REJECT for fw to net using chain all2all Policy ACCEPT for fw to loc using chain fw2loc Policy DROP for net to fw using chain net2all Policy ACCEPT for loc to fw using chain loc2fw Policy ACCEPT for loc to net using chain loc2net Masqueraded Subnets and Hosts: To 0.0.0.0/0 from 192.168.100.0/24 through eth0 Processing /etc/shorewall/tos... Rule "all all tcp - ssh 16" added. Rule "all all tcp ssh - 16" added. Rule "all all tcp - ftp 16" added. Rule "all all tcp ftp - 16" added. Rule "all all tcp ftp-data - 8" added. Rule "all all tcp - ftp-data 8" added. Processing /etc/shorewall/ecn... Activating Rules... Processing /etc/shorewall/start ... Shorewall Restarted I don't know what the problem is as the route to nic.lth.se (an ntp server) can well be established. I am running -uClib version 2.0 - as I have some problems with the newer versions - and Shorewall 1.4.5 on a 90 Mhz Winchip system memory only (no disks). I also want to know if dropbear looks at both channels (net & loc) or only at one? Can somebody point to my error of thinking with Shorewall? Thanks in advance Joep --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Provide DHCP address ONLY to predetermined MAC address?
Craig, There is a radius.lrp which works OK (but read the radius instructions carefully!) http://www.radius.cistron.nl/ www.gnu.org/software/radius/radius.html Joep On Thu, 2005-04-14 at 23:54, Craig Caughlin wrote: > Oh, I agree completely. It just seems like a "quick & dirty" method to keep > the auditors that I've personally met (who, IMHO, are not "the sharpest > knives in the drawer") happy. > > I like method number 2, but Bering doesn't support that..does it??? If it > does, well hey, tell me more! I'll be on that like white on rice. > > Thank you, > Craig > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Spakman > Sent: Thursday, April 14, 2005 2:38 PM > To: [EMAIL PROTECTED] > Cc: leaf-user@lists.sourceforge.net > Subject: RE: [leaf-user] Provide DHCP address ONLY to predetermined MAC > address? > > > Hello Craig, > > I understand what you are trying to do, but it goes beyond my > knowledge of the dnsmasq setup. > > It's also a weak security method, you only prevent someone getting an > ip address if the mac address is not listed in a dhcp pool. Someone > who wants to get access can easely spoof a mac address or take a > fixed ip address in the subnet. > > A better method for securing a network against unwanted access with a > laptop is by using 802.1x (Validated Network Access). Where the > laptop is authenticated against Radius via the switch and Active > Directory to give access on hardware level (network link). It does > this by checking the machine level name/password (not the user > name/password), which is stored in AD, and some other values and > (fully) opens the switch port when everything is allright. > > Eric > > > > > --- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > leaf-user mailing list: leaf-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-user > SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Shorewall problem
Tom, I followed your suggestion but no result. I am a little farther however. It seems that the entry is blocked via the RFC1918 rule list as the error is logdrop: Apr 15 15:54:15 renault Shorewall:logdrop:DROP: IN=eth0 OUT= MAC=00:01:02:0c:f0:b1:00:05:5f:eb:38:8d:08:00 SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=60 TOS=00 PREC=0x00 TTL=62 ID=38469 CE DF PROTO=TCP SPT=46244 DPT=22 SEQ=1930172565 ACK=0 WINDOW=5840 SYN URGP=0 My rules are: ## #ACTION SOURCE DESTPROTO DESTSOURCE ORIGINAL # PORTPORT(S)DEST # Accept DNS connections from the firewall to the network # ACCEPT fw net tcp 53 ACCEPT fw net udp 53 ACCEPT fw net:nic.lth.se tcp ACCEPT fw net udp 37,123 # # Accept SSH connections from the local network for administration # ACCEPT loc fw tcp 22,20,21 # Accept external SSH connection from xxx.xxx.xxx.xxx (Mark) ACCEPT net:xxx.xxx.xxx.xxx fw tcp 22 ACCEPT fw net:xxx.xxx.xxx.xxx tcp # # Allow Ping To And From Firewall # ACCEPT loc fw icmp8 ACCEPT net fw icmp8 ACCEPT fw loc icmp8 ACCEPT fw net icmp8 # # Bering specific rules: # allow loc to fw udp/53 for dnscache to work # allow loc to fw tcp/80 for weblet to work # ACCEPT loc fwudp 53 ACCEPT loc fwtcp 80 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE The strange thing is also that, although a ping from the net to the firewall is allowed, the firewall cannot be pinged (that rule was in the original RULES-file). The firewall works perfectly from all local systems, I can ping from the firewall and access the ntp-server but controlled access to the firewall is a problem. Can it be that the iptables is misconfigured and do you have any suggestions? I need this access as we want to setup a radius-server on both ends with equal certificates, etc. and my radius knowledge is very low. (I will make a backup as soon as the problem is solved as I work memory only and the firewall is already up for 60 days). Hope you can give some clues. Joep On Thu, 2005-04-14 at 16:33, Tom Eastep wrote: > Tom Eastep wrote: > > Joel Louis Blom wrote: > > > >>Can somebody point to my error of thinking with Shorewall? > > > > I'm guessing that it is not Shorwall that is blocking the SSH access but > > rather tcp wrappers -- check your /etc/hosts.allow file. > > > > And if you still believe that it is Shorewall blocking your access then > please submit the information requested at > http://shorewall.net/support.htm#Guidelines > > -Tom --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Shorewall problem
1. I'm running shorewall 1.4.5. 2. I've put xxx.xxx.xxx.xxx where an individual IP-address written for security reasons. I don't think that the real IP-adresses are relevant. I may be a little paranoid but I want to avoid the link of names with IP-adresses. 3. It's true that I'm working with an old RFC-file. 4. The IP-address is obtained from the DHCP-server of the provider and is of the 62.xxx.xxx.xxx range. 5. I don't understand what you mean with "To correct this problem". Joep On Fri, 2005-04-15 at 17:12, Tom Eastep wrote: > Joel Louis Blom wrote: > > Tom, > > I followed your suggestion but no result. > > I am a little farther however. It seems that the entry is blocked via > > the RFC1918 rule list as the error is logdrop: > > > > Apr 15 15:54:15 renault Shorewall:logdrop:DROP: IN=eth0 OUT= > > MAC=00:01:02:0c:f0:b1:00:05:5f:eb:38:8d:08:00 SRC=xxx.xxx.xxx.xxx > > DST=xxx.xxx.xxx.xxx LEN=60 TOS=00 PREC=0x00 TTL=62 ID=38469 CE DF > > PROTO=TCP SPT=46244 DPT=22 SEQ=1930172565 ACK=0 WINDOW=5840 SYN URGP=0 > > > > You don't tell us what version of Shorewall you are running. > You obfuscate the facts with this xxx.xxx... crap. > Yet you expect our help. > > The only thing that I can possibly guess is that: > > a) You are running an ancient version of Shorewall that doesn't support > the 'nobogons' option. This means that bogons are listed in the > 'rfc1918' file. > > b) You haven't updated your rfc1918 file in years > (http://shorewall.net/errata.htm). > > c) The xxx.xxx.xxx.xxx after SRC= matches a bogon entry in your rfc1918 > file. > > To correct this problem. > > 1) xtgyo spiteys 988674 flsiey8 http://xxx.xxx.xxx.xxx/yy.htm > 2) psyyt witii sopom dspslosy > 3) soppllmo soppoym splo > > -Tom --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Shorewall problem
Tom, I'm currently in the process of doing it. Have 3.0 installed and am now reinstalling the various parameter files. I assume that this also contains the current RCF1918 file. Excuse my paranoia. Joep On Fri, 2005-04-15 at 22:23, Tom Eastep wrote: > Joel Louis Blom wrote: > > 1. I'm running shorewall 1.4.5. > > Shorewall 1.4.5 is no longer supported. see http://www.shorewall.net/1.4 > > > 2. I've put xxx.xxx.xxx.xxx where an individual IP-address written for > > security reasons. I don't think that the real IP-adresses are relevant. > > THE REAL IP ADDRESSES ARE ALL THAT IS RELEVANT WHEN PACKET'S ARE > REJECTED BY 'norfc1918'! > > > I may be a little paranoid but I want to avoid the link of names with > > IP-adresses. > > 3. It's true that I'm working with an old RFC-file. > > > 4. The IP-address is obtained from the DHCP-server of the provider and > > is of the 62.xxx.xxx.xxx range. > > Is that YOUR IP address or the OTHER IP address. The OTHER IP address is > most likely the problem. > > > 5. I don't understand what you mean with "To correct this problem". > > Since you decided to disguise the problem, I felt that it was alright > for me to disguise the solution!! Actually, the solution to your problem > was in my post if you looked carefully... > > Since you aren't going to tell us what the IP addresses on each end are, > we don't know how to help you for sure. Download and install the latest > rfc1918 file from http://shorewall.net/errata.htm and restart Shorewall. > If that doesn't fix your problem, I can't help you further until you > upgrade to a support version of Shorewall. > > -Tom --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Daemon tools (daemontl) logging
The "weird" numbers are time signature in TAI64N notation. They can be made human readable by the program tai64nlocal which is part of the daemontools developed by J.D. Bernstein: http://cr.yp.to/daemontools/ You can find them in the URL here given, Succes Joep On Mon, 2005-04-18 at 20:51, Tibbs, Richard wrote: > > Dear list > Having looked at the cr.yp.to web site for several fruitless hours over > several weeks, I find no information on daemontl log file > interpretation. Googled and search the leaf-user archives but to no > avail. > > Can anyone tell me how to interpret the various weird numbers in the > snip of /var/log/dnscache/current below? > > TIA, Rick. > > # cd /var/log/dnscache > > firewall: -root- > # more current > @40004263eb893a9d6cac starting > @40004263ec8122779db4 query 1 c0a80a01:8001:c8ab 28 > download.fedora.redhat.com. > @40004263ec812277b524 tx 0 28 download.fedora.redhat.com. . 892d1a13 > @40004263ec81236b40cc nodata 892d1a13 600 28 > download.fedora.redhat.com. > @40004263ec81236b4c84 stats 1 50 1 0 > @40004263ec81236b506c sent 1 44 > @40004263ec812371bcf4 query 2 c0a80a01:8001:c8ac 28 > download.fedora.redhat.com.private.network. > @40004263ec812371c8ac tx 0 28 > download.fedora.redhat.com.private.network. . 892d1a13 > @40004263ec8127998514 nxdomain 892d1a13 3600 > download.fedora.redhat.com.private.network. > @40004263ec81279990cc sent 2 60 > @40004263ec81279f1eac query 3 c0a80a01:8001:c8ad 1 > download.fedora.redhat.com. > @40004263ec81279f2a64 tx 0 1 download.fedora.redhat.com. . 892d1a13 > @40004263ec8128aa06cc rr 892d1a13 600 1 ns1.redhat.com. 42bbe9d2 > @40004263ec8128aa1284 rr 892d1a13 600 1 ns2.redhat.com. 42bbe0d2 > @40004263ec8128aa1a54 rr 892d1a13 600 1 ns3.redhat.com. 42bbe50a > @40004263ec8128aa2224 rr 892d1a13 300 1 download.fedora.redhat.com. > 42bbe014 > @40004263ec8128aa29f4 rr 892d1a13 300 1 download.fedora.redhat.com. > d184b014 > @40004263ec8128aa31c4 rr 892d1a13 600 ns redhat.com. ns1.redhat.com. > @40004263ec8128aa3994 rr 892d1a13 600 ns redhat.com. ns2.redhat.com. > @40004263ec8128aa4d1c rr 892d1a13 600 ns redhat.com. ns3.redhat.com. > @40004263ec8128aa54ec stats 3 382 1 0 > @40004263ec8128aa58d4 sent 3 76 > @40004263ec812d8d089c query 4 c0a80a01:8001:c8ae 28 > download.fedora.redhat.com. > @40004263ec812d8d1454 cached 28 download.fedora.redhat.com. > @40004263ec812d8d1c24 sent 4 44 > @40004263ec812d92fc0c query 5 c0a80a01:8001:c8af 28 > download.fedora.redhat.com.private.network. > @40004263ec812d9307c4 cached nxdomain > download.fedora.redhat.com.private.network. > @40004263ec812d930f94 sent 5 60 > @40004263ec812d9837e4 query 6 c0a80a01:8001:c8b0 1 > download.fedora.redhat.com. > @40004263ec812d983fb4 cached 1 download.fedora.redhat.com. > @40004263ec812d984784 sent 6 76 > > > --- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&opk > > leaf-user mailing list: leaf-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-user > SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Daemon tools (daemontl) logging
Sorry, I was too hasty. This is the original link: http://cr.yp.to/ Here you find the link to all tools of D.J. Bernstein: D. J. Bernstein's home page; * the qmail home page; * the djbdns home page; * the daemontools home page; * the ucspi-tcp home page; * the cryptography page; * the Bernstein v. United Statespage. * Joep * On Tue, 2005-04-19 at 02:25, Tibbs, Richard wrote: > Errm, that link seems to be bad. > Rick. > > -Original Message----- > From: Joel Louis Blom [mailto:[EMAIL PROTECTED] > Sent: Monday, April 18, 2005 5:29 PM > To: Tibbs, Richard; Bering List > Subject: Re: [leaf-user] Daemon tools (daemontl) logging > > The "weird" numbers are time signature in TAI64N notation. > They can be made human readable by the program tai64nlocal which is part > of the daemontools developed by J.D. Bernstein: > http://cr.yp.to/daemontools/ > You can find them in the URL here given, > Succes > > Joep > > On Mon, 2005-04-18 at 20:51, Tibbs, Richard wrote: > > > > Dear list > > Having looked at the cr.yp.to web site for several fruitless hours > over > > several weeks, I find no information on daemontl log file > > interpretation. Googled and search the leaf-user archives but to no > > avail. > > > > Can anyone tell me how to interpret the various weird numbers in the > > snip of /var/log/dnscache/current below? > > > > TIA, Rick. > > > > # cd /var/log/dnscache > > > > firewall: -root- > > # more current > > @40004263eb893a9d6cac starting > > @40004263ec8122779db4 query 1 c0a80a01:8001:c8ab 28 > > download.fedora.redhat.com. > > @40004263ec812277b524 tx 0 28 download.fedora.redhat.com. . > 892d1a13 > > @40004263ec81236b40cc nodata 892d1a13 600 28 > > download.fedora.redhat.com. > > @40004263ec81236b4c84 stats 1 50 1 0 > > @40004263ec81236b506c sent 1 44 > > @40004263ec812371bcf4 query 2 c0a80a01:8001:c8ac 28 > > download.fedora.redhat.com.private.network. > > @40004263ec812371c8ac tx 0 28 > > download.fedora.redhat.com.private.network. . 892d1a13 > > @40004263ec8127998514 nxdomain 892d1a13 3600 > > download.fedora.redhat.com.private.network. > > @40004263ec81279990cc sent 2 60 > > @40004263ec81279f1eac query 3 c0a80a01:8001:c8ad 1 > > download.fedora.redhat.com. > > @40004263ec81279f2a64 tx 0 1 download.fedora.redhat.com. . > 892d1a13 > > @40004263ec8128aa06cc rr 892d1a13 600 1 ns1.redhat.com. 42bbe9d2 > > @40004263ec8128aa1284 rr 892d1a13 600 1 ns2.redhat.com. 42bbe0d2 > > @40004263ec8128aa1a54 rr 892d1a13 600 1 ns3.redhat.com. 42bbe50a > > @40004263ec8128aa2224 rr 892d1a13 300 1 > download.fedora.redhat.com. > > 42bbe014 > > @40004263ec8128aa29f4 rr 892d1a13 300 1 > download.fedora.redhat.com. > > d184b014 > > @40004263ec8128aa31c4 rr 892d1a13 600 ns redhat.com. > ns1.redhat.com. > > @40004263ec8128aa3994 rr 892d1a13 600 ns redhat.com. > ns2.redhat.com. > > @40004263ec8128aa4d1c rr 892d1a13 600 ns redhat.com. > ns3.redhat.com. > > @40004263ec8128aa54ec stats 3 382 1 0 > > @40004263ec8128aa58d4 sent 3 76 > > @40004263ec812d8d089c query 4 c0a80a01:8001:c8ae 28 > > download.fedora.redhat.com. > > @40004263ec812d8d1454 cached 28 download.fedora.redhat.com. > > @40004263ec812d8d1c24 sent 4 44 > > @40004263ec812d92fc0c query 5 c0a80a01:8001:c8af 28 > > download.fedora.redhat.com.private.network. > > @40004263ec812d9307c4 cached nxdomain > > download.fedora.redhat.com.private.network. > > @40004263ec812d930f94 sent 5 60 > > @40004263ec812d9837e4 query 6 c0a80a01:8001:c8b0 1 > > download.fedora.redhat.com. > > @40004263ec812d983fb4 cached 1 download.fedora.redhat.com. > > @40004263ec812d984784 sent 6 76 > > > > > > --- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real > users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_ide95&alloc_id396&opk > > > > > leaf-user mailing list: leaf-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/leaf-user > > SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html > > > --- > This SF.Net email is sponsored by: New Crystal Reports XI. > Version 11 ad
