Re: [leaf-user] How to define time zone in bering rc3
On Wed, Nov 13, 2002 at 11:47:42AM +0700, Thitiporn Pornpirunrak wrote: > Hi all > I am using bering rc3 and try to define time zone in my bering box. I am living >in thailand and my time zone is "GMT+7". How do i define them in my bering box? When >I use command "date" it returns "Wed Nov 13 11:42:22 UTC 2002" But I should be "Wed >Nov 13 11:42:22" at GMT+7. And when i use command "rdate -s time.nuri.net" it turn my >bering box into "Wed Nov 13 04:42:22 GMT 2002". Anyone who know please tell me.. Have a look at: http://leaf.sourceforge.net/devel/jnilo/butime.html - pretty comprehensive walkthrough of exactly that ;) HTH Jon Clausen --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] How to define time zone in bering rc3
Hi all I am using bering rc3 and try to define time zone in my bering box. I am living in thailand and my time zone is "GMT+7". How do i define them in my bering box? When I use command "date" it returns "Wed Nov 13 11:42:22 UTC 2002" But I should be "Wed Nov 13 11:42:22" at GMT+7. And when i use command "rdate -s time.nuri.net" it turn my bering box into "Wed Nov 13 04:42:22 GMT 2002". Anyone who know please tell me.. Thank in advanced, Thitiporn+,~wzf¢+,¦ì¢·o$èæ«Ø^m«"rÊ ±ç.®)àÊ«Áæì×°ØRH·%É!z·¢hTD4H º i8ZÂ×z»Þ¬'«¶'âq«^Ûiÿü0 - ¬-yÊ&þ·yÛhmY^iû¬z¹X§X¬¶W~ë ®X¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣù^iû¬z´!¶ÚþW~èç-¢¸?¦æÿv?v&jv z¿Ý¡È×ÏuÙ¥
[leaf-user] Müzik ve aradýklarýnýz nybh
Mp3sa yine bir ilki gerçekleþtiriyor: Klip arþivi!
Full albüm ve single parçalar mp3 halinde!
Arayýpta bulamadýðýnýz bütün parçalar için birde sitemize bakýn: http://www.mp3sa.com
Full Turkçe Album
Full Yabancý Album
A-Z Yerli Mp3
A-Z Yabancý Mp3
En Iyý 20
Yerli Výdeo Klýp
Yabancý Výdeo Klýp
Yerli ve Yab. Arsýv
Hepsine birden ulaþabileceðiz tek bir adres var
http://www.mp3sa.com
áË ë^¨¥Ë)¢{(ç[É:%yªç¶jȲìyË«x2¢êðy»"µì"¶-ÉbrH^ëhëZM .ÚN°µä®÷«
êíøjס¶Úÿ
0ak ^r¿ÞvÚfW~ë ®f¢)à+-æºÇ«+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþW~ë $Em¶ÿ榺#yËh®é¹¿Ý¡Ïݡɨ ¯÷hr'uóÝa¶i
Re: [leaf-user] nat between gateways ???
Charles Steinkuehler wrote: > > Michael D. Schleif wrote: > > Charles Steinkuehler wrote: > >> You don't give enough information to correctly diagnose martian errors, > >> which are based pretty much entirely on the status of the route tables. > >> Also, while I have not done a lot of host-host or host-subnet VPNs > >> (you also don't include your IPSec configuration), you will run into > >> problems with these VPN flavors if you don't have rpfiltering turned off > >> (you'll get a warning when starting IPSec about this if it's enabled). For futher information, please, let me know and I will be as verbose as necessary on a separate webpage. Let's hope that I remember to publish the final solution exhaustively to the list ;> [1] Indeed, that pesky martian problem appears to be directly related to the values of: /proc/sys/net/ipv4/conf/ipsec0/rp_filter /proc/sys/net/ipv4/conf/wan1/rp_filter Changing them from `1` to `0' resolves that issue. [2] The current setup is to mimic the intended vpn between DCD at pinktrout and that pesky dicom cisco vpn, for which we are substituting another of our DCD's: bluetrout. [3] Now, with that 1 -> 0 conversion and following ipsec configuration, SA is established on both sides. [4] Neither side can ping anything on the other side. [5] routes: root@bluetrout:/root # ip route 64.4.222.158 dev wan1 proto kernel scope link src 64.4.222.157 64.4.222.158 dev ipsec0 proto kernel scope link src 64.4.222.157 144.228.51.210 via 64.4.222.158 dev ipsec0 src 192.168.1.254 64.4.197.64/26 dev eth1 scope link 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 default via 64.4.222.158 dev wan1 root@pinktrout:/root # ip route 144.228.51.209 dev wan1 proto kernel scope link src 144.228.51.210 144.228.51.209 dev ipsec0 proto kernel scope link src 144.228.51.210 192.168.1.0/24 via 144.228.51.209 dev ipsec0 src 192.168.11.254 192.168.14.0/24 dev eth1 proto kernel scope link src 192.168.14.254 192.168.13.0/24 dev eth0 scope link 192.168.12.0/24 dev eth0 scope link 192.168.11.0/24 dev eth0 proto kernel scope link src 192.168.11.254 192.168.10.0/24 dev eth0 scope link default via 144.228.51.209 dev wan1 [6] udp port 500 & protocols 50 & 51: root@bluetrout:/root # ipchains -nvL --line-numbers | grep '\( 5[01] \|500$\)' 1 0 0ACCEPT 51 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 2 0 0ACCEPT 50 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 3 0 0ACCEPT 51 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 4 0 0ACCEPT 50 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 5 0 0ACCEPT 51 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 6 0 0ACCEPT 50 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 7 0 0ACCEPT 51 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 8 0 0ACCEPT 50 -- 0xFF 0x00 * 144.228.51.210 64.4.222.157 n/a 53 62 9756 ACCEPT udp -- 0xFF 0x00 wan1 0.0.0.0/0 64.4.222.157 * -> 500 root@pinktrout:/root # ipchains -nvL --line-numbers | grep '\( 5[01] \|500$\)' 50 26 6156 ACCEPT udp -- 0xFF 0x00 wan1 0.0.0.0/0 144.228.51.210 * -> 500 [7] kern.log: root@pinktrout:/root # tail -f /var/log/kern.log Nov 12 20:41:18 pinktrout kernel: Packet log: input DENY wan1 PROTO=50 64.4.222.157:65535 144.228.51.210:65535 L=136 S=0x00 I=62911 F=0x T=54 (#56) Nov 12 20:41:19 pinktrout kernel: Packet log: input DENY wan1 PROTO=50 64.4.222.157:65535 144.228.51.210:65535 L=136 S=0x00 I=62913 F=0x T=54 (#56) Nov 12 20:41:20 pinktrout kernel: Packet log: input DENY wan1 PROTO=50 64.4.222.157:65535 144.228.51.210:65535 L=136 S=0x00 I=62915 F=0x T=54 (#56) [8] ipsec.conf bluetrout = config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes conn %default authby=rsasig auto=start keyingtries=0 left=%defaultroute leftfirewall=yes [EMAIL PROTECTED] leftrsasigkey=_super_dooper_secret_L_ leftsubnet=192.168.1.0/24 include ipsec/pinktrout.conf ipsec/pinktrout.conf conn pinktrout right=144.228.51.210 [EMAIL PROTECTED] rightrsasigkey=_super_dooper_secret_R_ pinktrout = config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes conn %default authby=rsasig auto=start keyingtries=0 left=%defaultroute
Re: [leaf-user] Problem getting PPTP client to work behindLEAF/Bering firewall
--On Tuesday, November 12, 2002 10:04:20 AM -0600 "David A. Bright" <[EMAIL PROTECTED]> wrote: I've been trying to set up a LEAF/Bering firewall at home to allow a connection to my employer's VPN (PPTP). Here is a rough picture of my connection: Win98 client ---> Bering ---> Router ---> ISP ---> Internet ---> Company My internal network (Win98 -> Bering) uses a private IP space (192.168.1.0/24). I'm connected to my ISP via a DSL connection in bridge mode, so my router also has a private IP (192.168.x.y, x != 1). The ISP then does NAT on that, so my packets are NAT'ed twice, once at the Bering firewall and again by my ISP. I've got a fairly straightforward Shorewall configuration on the Bering box, defining just two zones (net and loc). Outgoing traffic from loc to net is allowed, related traffic is allowed back in. RFC1918 addresses are not allowed to flow from net -> loc, except for those on my bridge connection (192.168.x.y) to the ISP. What I see happening is that packets coming back from the company are getting rejected by the "norfc1918" rule, as shown by the trace below (just two messages are shown, I get a bunch more but they are all pretty much the same): Nov 9 02:29:15 firewall kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT=eth0 SRC=192.168.p.q DST=192.168.1.1 LEN=56 TOS=0x00 PREC=0x00 TTL=253 ID=20062 PROTO=ICMP TYPE=3 CODE=1 [SRC=192.168.x.y DST=a.b.c.d LEN=50 TOS=0x00 PREC=0x00 TTL=125 ID=28417 PROTO=47 ] This is an ICMP type 3, code 1 packet (Port Unreachable) packet being returned by 192.168.p.q. I suspect that box is behing a NAT gateway (or is the interal IP of a NAT gateway) and that gateway isn't handling NAT of ICMP properly so that the RFC 1918 address isn't being translated back into the external address of the gateway. The packet is being trapped in your Shorewall rfc1918 chain because it has a source IP reserved by RFC 1918. The packet has already had its destination IP rewritten to 192.168.1.1 so it is that box who sent the original packet which we can see in square brackets (a GRE packet from 192.168.x.y to a.b.c.d). Check the firewall configuration at the other end to be sure that it is accepting protocol 47. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://shorewall.sf.net ICQ: #60745924 \ [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Cant route to local IP address on eth2
Look at the differences in the routing tables of the Linux host on eth2 and ISDN router #2. I bet you will find that the Linux host knows that the LEAF router's eth2 IP address is its route to 192.168.1.0/24, but that the ISDN router #2 does not know this. (I am assuming here that the LEAF router is NOT set to NAT traffic from the eth1 network to the eth2 network.) The ISDN router may not even know that the LEAF router's eth2 IP address is its default gateway. If I'm wrong ... and if no one else chimes in with an "obvious" answer ... then we need a more complete characterization of the LEAF router's configuration then you have provided. Consult the SR FAQ (listed below) for how to provide this. Also, try putting the Linux host on the eth2 LAN with a different IP address this time, and using it to sniff traffic. See if the pings get *to* the ISDN #2 router, but the ping *replies* do not get back to the LEAF router. At 06:17 PM 11/12/02 -0500, Robert Szabo wrote: I have Leaf Bering installed. My setup is: 3 network cards eth0 - net - internet address to ISDN Router #1 (has internet address in and out) eth1 - lan - 192.168.1.x eth2 - dmz - 192.168.2.x to ISDN Router #2 with local address on the inside and internet address on the outside (setup to allow communication only to and from a single IP address) I used the designation dmz for this adapter even though I know its not really a dmz since I have no route between it and the net. I am able to see the internet through eth0 from the lan and fw. Everything is fine between lan and net. I can ping ISDN Router #2 hooked to eth2 from the fw. I can NOT ping ISDN Router #2 from the lan. HOWEVER, I have hooked a linux box to eth2 it is fine. I can ping it from the lan. For testing I set it to the same IP address that I have the #2 ISDN router set to. I am starting to think it may be the setup in ISDN Router #2. OR.. am I missing something in my rules. BUT if thats the case why does the linux box work fine on eth2?? Any help would be greatly appreciated. -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Mounting / formatting an IDE drive in Bering was Samba, Ide, Mount ???'s
OK so I answered my own question. mount -t ext2 /dev/hdc1 /mnt did the trick. I now have a usable IDE disk drive with an ext2 ext2 partition. Now I can go back to getting Samba working. Thanks for all the guidance. KK Kory Krofft wrote: > > Erich and all... > > I have loaded ext2.0 but not until after the tmpfs.o. > Will it matter where it is in the order as long as it > is after ide-disk.o? Since I could not mount /dev/hdc1 > due to errors that looked like a bad format I was > trying to use the mkfs.minix not realizing that it was > for virtual disks. At this point I can use a msdos > format but I believed it would be more secure as a > Linux partition. True? Or will the Samba share proved > all the security I need or can get? I do not want to > boot from this device I simply want to use it as a > file repository. > Is it likely that I need to reformat it on the RedHat > machine or more likely that the ext2.o driver is in > the wrong order. My original error was : > > # mount /dev/hdc1 /mnt results in the following: > > VFS: Can't find a Minix or Minix V2 filesystem on > device 16:01. > FAT: Did not find valid FSINFO signature. > Found signature1 0x0 signature2 0x0 sector=1. > Directory 1: bad FAT > Filesystem panic (dev 16:01). > FAT error > File system has been set read-only > > Maybe I should try to specify the fstype with the -t > switch in the mount command like so: > # mount -t ext2 /dev/hdc1 /mnt > > I will try a couple of things when I get home. Boy is > it frustrating to be at work with no access to the > problem. ;-) > > Thanks again, > > Kory > > > <>Big Snip<> > > I believe syslinux only supports M$DOS formattet > > filesystems. So in order > > to boot from that medium and using syslinux I > > believe you have to stick > > with M$DOS format. If all you want to do is to store > > information > > persistently then you are free to use whatever you > > decide to load a driver for. > > > > HTH > > Erich > > > > THINK > > Püntenstrasse 39 > > 8143 Stallikon > > mailto:erich.titl@;think.ch > > PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 > > FF9D 05B8 0A16 > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > > > > 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 > > > > > > __ > Do you Yahoo!? > U2 on LAUNCH - Exclusive greatest hits videos > http://launch.yahoo.com/u2 > > --- > This sf.net email is sponsored by: > To learn the basics of securing your web site with SSL, > click here to get a FREE TRIAL of a Thawte Server Certificate: > http://www.gothawte.com/rd522.html > > 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 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Cant route to local IP address on eth2
I have Leaf Bering installed. My setup is: 3 network cards eth0 - net - internet address to ISDN Router #1 (has internet address in and out) eth1 - lan - 192.168.1.x eth2 - dmz - 192.168.2.x to ISDN Router #2 with local address on the inside and internet address on the outside (setup to allow communication only to and from a single IP address) I used the designation dmz for this adapter even though I know its not really a dmz since I have no route between it and the net. I am able to see the internet through eth0 from the lan and fw. Everything is fine between lan and net. I can ping ISDN Router #2 hooked to eth2 from the fw. I can NOT ping ISDN Router #2 from the lan. HOWEVER, I have hooked a linux box to eth2 it is fine. I can ping it from the lan. For testing I set it to the same IP address that I have the #2 ISDN router set to. I am starting to think it may be the setup in ISDN Router #2. OR.. am I missing something in my rules. BUT if thats the case why does the linux box work fine on eth2?? Any help would be greatly appreciated. Robert Szabo --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Dachstein DNS Config - HELP!
Good catch, Ray. As usual, you were spot on. Details below... On Tue, 12 Nov 2002 12:30:19 PST Ray Olszewski wrote: > At 02:44 PM 11/12/02 -0500, Brad Fritz wrote: > > >A small addition to Ray's already comprehensive analysis... > [...] > >3. You have dnscache listening on port 193.37.83.1:53 and traffic > >is allowed to it through the packet filter, but > >/etc/dnscache/env/IPQUERY does not include a line that allows > >queries from pingu-serv.farside.net's address or network. > > This would certainly cause the query to fail, Brad ... but would it fail > with the particular icmp message he is getting? (This is a real question, > not a disagreement phrased as a question.) No, it would not send the icmp message. I actually thought about that before sending my post and then forgot to verify in my haste. Here is what testing revealed: While running: tcpdump -n -i eth0 port 53 or icmp Testing with IPQUERY=11.11.11 : [EMAIL PROTECTED]:~$ dig +short www.google.com @192.168.1.254 ;; connection timed out; no servers could be reached 15:52:58.571963 192.168.21.10.34619 > 192.168.1.254.53: 23740+ A? \ www.google.com. (32) (DF) 15:53:27.528375 192.168.21.10.34619 > 192.168.1.254.53: 7106+ A? \ www.google.com. (32) (DF) [no response, no ICMP traffic] Testing with IPQUERY=192.168 : [EMAIL PROTECTED]:~$ dig +short www.google.com @192.168.1.254 216.239.53.101 15:53:27.879319 192.168.1.254.53 > 192.168.21.10.34619: 7106 1/0/0 A \ 216.239.53.101 (48) (DF) [expected response, no ICMP traffic] Testing with dnscache stopped: [EMAIL PROTECTED]:~$ dig +short www.google.com @192.168.1.254 ;; connection timed out; no servers could be reached 16:01:54.009667 192.168.21.10.34619 > 192.168.1.254.53: 46045+ A? \ www.google.com. (32) (DF) 16:01:54.012534 192.168.1.254 > 192.168.21.10: icmp: 192.168.1.254 udp \ port 53 unreachable [tos 0xc0] 16:01:59.012618 192.168.21.10.34619 > 192.168.1.254.53: 46045+ A? \ www.google.com. (32) (DF) 16:01:59.015371 192.168.1.254 > 192.168.21.10: icmp: 192.168.1.254 udp \ port 53 unreachable [tos 0xc0] [no response, ICMP port unreachable message] Thanks for keeping me honest, Ray. :-) --Brad --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Dachstein DNS Config - HELP!
At 02:44 PM 11/12/02 -0500, Brad Fritz wrote: A small addition to Ray's already comprehensive analysis... [...] 3. You have dnscache listening on port 193.37.83.1:53 and traffic is allowed to it through the packet filter, but /etc/dnscache/env/IPQUERY does not include a line that allows queries from pingu-serv.farside.net's address or network. This would certainly cause the query to fail, Brad ... but would it fail with the particular icmp message he is getting? (This is a real question, not a disagreement phrased as a question.) -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Dachstein DNS Config - HELP!
A small addition to Ray's already comprehensive analysis... On Tue, 12 Nov 2002 10:53:38 PST Ray O. wrote: > Now, the tcpdump traffic you report is -- > > 17:07:30.870333 pingu-serv.farside.net.vfo > > 193.37.83.1.domain: 58405+ > PTR? 81.83.37.193.in-addr.arpa. (43) (DF) > 17:07:30.870892 193.37.83.1 > pingu-serv.farside.net: icmp: > 193.37.83.1 udp > port domain unreachable [tos 0xc0] [..] > the router's reply is that the DNS port cannot be reached on the router. Bad. > > So ... why not? Two candidate reasons -- > > 1. The firewall blocks access to that port. [..] > 2, Nothing is listening on port 53 on the router. 3. You have dnscache listening on port 193.37.83.1:53 and traffic is allowed to it through the packet filter, but /etc/dnscache/env/IPQUERY does not include a line that allows queries from pingu-serv.farside.net's address or network. --Brad --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] restoring vlan's after reboot: /proc/net/vlan not there
Le Mardi 12 Novembre 2002 08:27, Scott a écrit : Scott: Have you gone through: http://sourceforge.net/mailarchive/message.php?msg_id=2304008 Also it seems that you have a problem with backup. Suggestion by Luis to check available disk space of the quality of the floppy seems reasonable Jacques > using Intel Pro/100 82559 chipset > using eepro100 Revision 1.36 > using bering rc4 > > On boot I'm getting the error: >SIOCGIFFLAGS: Operation not supported by device > > I load the 802.1q driver (8021q.o). I configure my vlan with the > following command lines: > > vconfig add eth1 11 > vconfig add eth2 12 > vconfig add eth3 13 > etc... > > I backup the vlan. When I reboot, it is not finding the devices > eth1.11, eth1.12, and eth1.13. I check /proc/net/vlan and it's empty > where there used to be entries for each virtual device. > > /var/lib/lrpkg/vlan.list: > > sbin/vconfig > etc/network/if-pre-up.d/vlan > etc/network/ip-up.d/ip > etc/network/if-post-down.d/vlan > var/lib/lrpkg/vlan.* > > By default there is no entry in vlan.list for /proc/net/vlan. I tried > adding it, but it bombs when I try "lrpkg -i vlan" later with a tar > error. Any suggestions how to have those vlans active when I boot? > Otherwise shorewall doesn't have anything to configure. > > -Scott > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > > 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 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] orinoco wireless firmware versions -- any difference in performance/reliablity?
something i forgot to mention -- the newer drivers that i recieved i tried but i could not get them to work due to failed dependencies. should i persue this further? thanks again -Original Message- From: [EMAIL PROTECTED] [mailto:leaf-user-admin@;lists.sourceforge.net]On Behalf Of Matt Russell Sent: Tuesday, November 12, 2002 11:58 AM To: [EMAIL PROTECTED] Subject: [leaf-user] orinoco wireless firmware versions -- any difference in performance/reliablity? Hey all, I had the opportunity to do a checkup on the LRP, and found that my wireless card which serves as the interface to the internet has quite a few TX errors - 4916 to be precise. the following is reported by /proc/net/wireless: under quality link - 30; level - 199; noise - 169 discarded packets nwid - 0; crypt - 0; frag - 53217; retry - 4917 my question is, is there a great discrepency in the different firmwares with reguard to reliablity and link quality? are my figures (esp under the quality category) pretty bad? i had a fellow leaf-user send me some new drivers (orinoco 13b1) that he compiled based on the new drivers. i am using bering rc-2 and uptime is 19 days, 21hrs. thanks for any help. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] orinoco wireless firmware versions -- any difference in performance/reliablity?
Hey all, I had the opportunity to do a checkup on the LRP, and found that my wireless card which serves as the interface to the internet has quite a few TX errors - 4916 to be precise. the following is reported by /proc/net/wireless: under quality link - 30; level - 199; noise - 169 discarded packets nwid - 0; crypt - 0; frag - 53217; retry - 4917 my question is, is there a great discrepency in the different firmwares with reguard to reliablity and link quality? are my figures (esp under the quality category) pretty bad? i had a fellow leaf-user send me some new drivers (orinoco 13b1) that he compiled based on the new drivers. i am using bering rc-2 and uptime is 19 days, 21hrs. thanks for any help. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Dachstein DNS Config - HELP!
A preliminary comment -- please be more careful about use of upper and lower case in your reporting. I'm inclined to believe that your interface variables really are eth0 and eth1, not (as you report them) Eth0 and Eth1, and I doubt your LAN-side SuSE server is named both pingu-serv and Pingu-serv. And the app is named tcpdump, not Tcpdump. I spotted all of these mistakes easily, but the number of them leaves me a bit concerned that there is some other error (either in your reporting or in your actual setup) caused by misuse of case. Now, the tcpdump traffic you report is -- 17:07:30.870333 pingu-serv.farside.net.vfo > 193.37.83.1.domain: 58405+ PTR? 81.83.37.193.in-addr.arpa. (43) (DF) 17:07:30.870892 193.37.83.1 > pingu-serv.farside.net: icmp: 193.37.83.1 udp port domain unreachable [tos 0xc0] The second line replies to a packet *from* pingu-serv to the DNS port on the router *itself* (193.37.83.1.domain), one that attempts a reverse lookup on your NT host. (No indication of why the SuSE host is doing this recverse lookup, but such requests are commonplace.) So far so good. But the router's reply is that the DNS port cannot be reached on the router. Bad. So ... why not? Two candidate reasons -- 1. The firewall blocks access to that port. Improbable if the rest of your reporting is correct (but given my opening comment, worth considering). Check your firewall log for any report of REJECTed traffic to port 53 (domain). 2, Nothing is listening on port 53 on the router. The more likely answer, a consequence of some error in your (undescribed by you, beyond the uninformative "Made what I considered to be appropriate settings") configuration of dnscache (or conceivably one of the other 2 packages). Report what you did and someone may be able to help. In addition to rounding up the usual suspects (consult the SR FAQ) and describing your setup of dnscache and tinydns, see what, if anything, "netstat -ln" says is actually listening on port 53. At 06:01 PM 11/12/02 +, Wrigglesworth, Colin wrote: Help needed setting up DNS on Dachstein-CD V1.02. Have installed the packages djbutils, dnscache and tinydns. Made what I considered to be appropriate settings using the lrcfg menus, saved and rebooted. Host names for machines on the private side have been entered in NETWORK.CONF and DNS set to YES. The LRP box is configured thus: Eth0=89.10.1.1 Eth1=193.37.83.1 The Eth0 side is connected to the main company network which has a proliferation of windoze boxen one of which is a DNS server on 89.2.7.6 On the Eth1 side I have a SuSe8.0 box (Pingu-serv) 193.37.83.2 and a couple of WinNT3.51 boxes one of which is 193.37.83.81 Running Tcpdump on pingu-serv I get the following 17:07:30.870333 pingu-serv.farside.net.vfo > 193.37.83.1.domain: 58405+ PTR? 81.83.37.193.in-addr.arpa. (43) (DF) 17:07:30.870892 193.37.83.1 > pingu-serv.farside.net: icmp: 193.37.83.1 udp port domain unreachable [tos 0xc0] Pingu-serv is set to get DNS info for both the private network (farside.net) and the company network from 193.37.83.1, the private side of the LRP box. All ipchains rules have been flushed and the default policies set to ACCEPT so I shouldn't be blocking any requests. What is this tcpdump output telling me? I'm a relative newbie so pointing me at some relevant, but easily comprehensible reading matter might assist. To me it just looks like the port which serves the dns requests isn't open. -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] nat between gateways ???
Michael D. Schleif wrote: Charles Steinkuehler wrote: You don't give enough information to correctly diagnose martian errors, which are based pretty much entirely on the status of the route tables. Also, while I have not done a lot of host-host or host-subnet VPNs (you also don't include your IPSec configuration), you will run into problems with these VPN flavors if you don't have rpfiltering turned off (you'll get a warning when starting IPSec about this if it's enabled). Yes, I know that I did not include ipsec info; but, I fail to see any relevancy. Isn't martian-ness independent of anything ipsec? I don't think it is entirely. Martin-ness is related to the routing tables and the interface a particular packet arrives on. IPSec plays with this at a very low level, which is why some types of tunnels will not work with the kernel's rp_filter (spoofing) protection enabled. Fundamentally, IPSec can setup what looks to the kernel like asymetric routing tables, which can cause martians and (in the case of rp_filter) dropped packets. A good example is a host-host VPN. Your routing rules specify ipsec0 for the remote IP, but you will be recieving encrypted traffic from that system on your external interface (in violation of your routing tables as far as the martian and rp_filter logic are concerned). What I see here is a valid public address trying to come in the publicly addressed external interface of a router. My question, I feel, remains valid: How can this be considered martian? I can't tell without your routing table information. Clearly, in order for me to understand this, I need a better grasp of martian-ness. Pointers? Docs? A packet is considered a "martian" if it arrives on an interface *OTHER* than the interface the kernel would route a packet out of, when trying to reply to the source IP of the packet. For docs, your best bet is the kernel source-tree. In addiiton to the source itself, some info is in the Documentation directory: linux/Documentation/networking/ip-sysctl.txt linux/Documentation/proc.txt -- Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] updated dhcp_2_dns.sh
I have made some updates to Michael Schleif's dhcp_2_dns.sh script. For those who aren't familiar with it, this script takes data from the dhcp server's lease file and adds it to tinydns's data file so you can do DNS lookups on computers that are given addresses by the DHCP server. Here are the changes I made: - fixed "out of range" problem when comparing lease dates - fixed problem where dns entries were never replaced when a host's address changed - new feature: fixed-address entries (from dhcpd.conf) are now added to the dns server The file is in sourceforge's patches area: https://sourceforge.net/tracker/index.php?func=detail&aid=628812&group_id=13751&atid=313751 Enjoy... -Mark Ivey- --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Dachstein DNS Config - HELP!
Help needed setting up DNS on Dachstein-CD V1.02. Have installed the packages djbutils, dnscache and tinydns. Made what I considered to be appropriate settings using the lrcfg menus, saved and rebooted. Host names for machines on the private side have been entered in NETWORK.CONF and DNS set to YES. The LRP box is configured thus: Eth0=89.10.1.1 Eth1=193.37.83.1 The Eth0 side is connected to the main company network which has a proliferation of windoze boxen one of which is a DNS server on 89.2.7.6 On the Eth1 side I have a SuSe8.0 box (Pingu-serv) 193.37.83.2 and a couple of WinNT3.51 boxes one of which is 193.37.83.81 Running Tcpdump on pingu-serv I get the following 17:07:30.870333 pingu-serv.farside.net.vfo > 193.37.83.1.domain: 58405+ PTR? 81.83.37.193.in-addr.arpa. (43) (DF) 17:07:30.870892 193.37.83.1 > pingu-serv.farside.net: icmp: 193.37.83.1 udp port domain unreachable [tos 0xc0] Pingu-serv is set to get DNS info for both the private network (farside.net) and the company network from 193.37.83.1, the private side of the LRP box. All ipchains rules have been flushed and the default policies set to ACCEPT so I shouldn't be blocking any requests. What is this tcpdump output telling me? I'm a relative newbie so pointing me at some relevant, but easily comprehensible reading matter might assist. To me it just looks like the port which serves the dns requests isn't open. Regards, Colin *** The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform RACAL INSTRUMENTS LTD. immediately by phoning +44 (0)1628 604455 (ask for the I.T. dept) and delete it and all copies from your system. *** --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Mounting / formatting an IDE drive in Bering was Samba, Ide, Mount ???'s
Erich and all... I have loaded ext2.0 but not until after the tmpfs.o. Will it matter where it is in the order as long as it is after ide-disk.o? Since I could not mount /dev/hdc1 due to errors that looked like a bad format I was trying to use the mkfs.minix not realizing that it was for virtual disks. At this point I can use a msdos format but I believed it would be more secure as a Linux partition. True? Or will the Samba share proved all the security I need or can get? I do not want to boot from this device I simply want to use it as a file repository. Is it likely that I need to reformat it on the RedHat machine or more likely that the ext2.o driver is in the wrong order. My original error was : # mount /dev/hdc1 /mnt results in the following: VFS: Can't find a Minix or Minix V2 filesystem on device 16:01. FAT: Did not find valid FSINFO signature. Found signature1 0x0 signature2 0x0 sector=1. Directory 1: bad FAT Filesystem panic (dev 16:01). FAT error File system has been set read-only Maybe I should try to specify the fstype with the -t switch in the mount command like so: # mount -t ext2 /dev/hdc1 /mnt I will try a couple of things when I get home. Boy is it frustrating to be at work with no access to the problem. ;-) Thanks again, Kory <>Big Snip<> > I believe syslinux only supports M$DOS formattet > filesystems. So in order > to boot from that medium and using syslinux I > believe you have to stick > with M$DOS format. If all you want to do is to store > information > persistently then you are free to use whatever you > decide to load a driver for. > > HTH > Erich > > THINK > Püntenstrasse 39 > 8143 Stallikon > mailto:erich.titl@;think.ch > PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 > FF9D 05B8 0A16 > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > > 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 > > __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] kernel mode pppd problems
On Tue, 2002-11-12 at 04:32, Matthew Pozzi wrote: > Could someone please help me here, I have upgraded to Dachstein v1.02 and > would like to run pppd for a dialin service. > > However I have the following message coming back at me when I try to run > > # /usr/sbin/pppd > ioctl(TIOCSETD(PPP)): Invalid argument(22) > /usr/sbin/pppd: This system lacks kernel support for PPP. This could be > because > the PPP kernel module could not be loaded, or because PPP was not > included in the kernel configuration. If PPP was included as a > module, try `/sbin/modprobe -v ppp'. If that fails, check t > > I have the ppp.lrp module that came with Dachstein, so just what is > happening here? I must admit to being a bit tired of recent and hence a bit > muddled. Do: lsmod ls -al /lib/modules/ Report your system's responses. > > Many thanks, > Matt > > My apology for posting to the list admin, slip of the finger! > > -Richard --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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] Problem getting PPTP client to work behind LEAF/Bering firewall
I've been trying to set up a LEAF/Bering firewall at home to allow a connection to my employer's VPN (PPTP). Here is a rough picture of my connection: Win98 client ---> Bering ---> Router ---> ISP ---> Internet ---> Company My internal network (Win98 -> Bering) uses a private IP space (192.168.1.0/24). I'm connected to my ISP via a DSL connection in bridge mode, so my router also has a private IP (192.168.x.y, x != 1). The ISP then does NAT on that, so my packets are NAT'ed twice, once at the Bering firewall and again by my ISP. I've got a fairly straightforward Shorewall configuration on the Bering box, defining just two zones (net and loc). Outgoing traffic from loc to net is allowed, related traffic is allowed back in. RFC1918 addresses are not allowed to flow from net -> loc, except for those on my bridge connection (192.168.x.y) to the ISP. What I see happening is that packets coming back from the company are getting rejected by the "norfc1918" rule, as shown by the trace below (just two messages are shown, I get a bunch more but they are all pretty much the same): Nov 9 02:29:15 firewall kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT=eth0 SRC=192.168.p.q DST=192.168.1.1 LEN=56 TOS=0x00 PREC=0x00 TTL=253 ID=20062 PROTO=ICMP TYPE=3 CODE=1 [SRC=192.168.x.y DST=a.b.c.d LEN=50 TOS=0x00 PREC=0x00 TTL=125 ID=28417 PROTO=47 ] Nov 9 02:29:18 firewall kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT=eth0 SRC=192.168.p.q DST=192.168.1.1 LEN=56 TOS=0x00 PREC=0x00 TTL=253 ID=20068 PROTO=ICMP TYPE=3 CODE=1 [SRC=192.168.x.y DST=a.b.c.d LEN=50 TOS=0x00 PREC=0x00 TTL=125 ID=28929 PROTO=47 ] In these traces, "a.b.c.d" is the IP for my company's PPTP server, "192.168.1.1" is the (internal) IP for my Win98 client, "192.168.x.y" is the IP of my firewall (ISP side), and "192.168.p.q" is (I think; p != x != 1) the private IP being used inside my company's LAN (i.e., on the other side of the PPTP server). I'm not sure how to read the log message, but it appears to me that the part in the brackets is either an indicator of the GRE wrapper for the packet or the original packet that is "related" to the incoming packet. In any case, it appears that the filtering rules are keying on the private IP from inside my company and rejecting the packet. What I don't understand is why the packet isn't marked as coming from the PPTP server. I should note that I have the ip_conntrack_pptp and ip_nat_pptp modules loaded. Also, I've been told that I can't do this successfully due to the fact that my "external" (i.e., the router) address is a private, non-routable IP and that I have to get (and pay for) a "real" static IP in order to get this to work. What I want to know, though, is why. If it were really the case that my non-routable IP were the problem, I would have expected the packets to never even reach me. Any light that can be shed on this situation would be greatly appreciated. If I really need to buy an external IP, I will, but right now I'm not convinced that even that would work. Thanks. -- David A. Bright [EMAIL PROTECTED] [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html 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 on Port 67 68 rejects
--On Tuesday, November 12, 2002 05:28:51 AM + Bob D <[EMAIL PROTECTED]> wrote: Do I have to put a rule in shorewall to quiet this down? If so what is the rule. I am very green with tables. Simply specify the 'dhcp' option for eth1 in /etc/shorewall/interfaces -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://shorewall.sf.net ICQ: #60745924 \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] NIS/YP Packages for LEAF?
Does anyone know of or use a package for running an NIS server on LEAF? Thanks, Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] Write permission for weblet in bering
Hi everybody This refers to Bering 1.0rc3 I wou like to get a general feeling about allowing write to the file system for cgi-scripts in weblet. Is is reasonable to do that opening grsecurity for the various scripts or rather implementing a sudo like binary which is allowed to write. Is grsecurity a problem at all for this? Thanks Erich THINK Püntenstrasse 39 8143 Stallikon mailto:erich.titl@;think.ch PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] nat between gateways ???
Michael just a thought, is Martian-ness check done at the end of the tunnel then maybe you see the private address on the other side of the tunnel. $00.2 Erich At 14:25 12.11.2002, you wrote: "Michael D. Schleif" wrote: > > Charles Steinkuehler wrote: > > > > Michael D. Schleif wrote: > > > Every time that I think that I understand what constitutes martian-ness, > > > I am tossed a new wrinkle ;> > > > > > > What do you think? THINK Püntenstrasse 39 8143 Stallikon mailto:erich.titl@;think.ch PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] nat between gateways ???
"Michael D. Schleif" wrote: > > Charles Steinkuehler wrote: > > > > Michael D. Schleif wrote: > > > Every time that I think that I understand what constitutes martian-ness, > > > I am tossed a new wrinkle ;> > > > > > > What do you think? > > > > You don't give enough information to correctly diagnose martian errors, > > which are based pretty much entirely on the status of the route tables. > > Also, while I have not done a lot of host-host or host-subnet VPNs > > (you also don't include your IPSec configuration), you will run into > > problems with these VPN flavors if you don't have rpfiltering turned off > > (you'll get a warning when starting IPSec about this if it's enabled). Or, are you saying that, due to the ipsec stuff compiled into the kernel, martian-ness can manifest in many ways, including ipsec-specific ways? -- 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 . . . --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] pppd issues - user issues really
Sorry for lowering the signal to noise ratio, some thought on my part pointed to the wrong modules being loaded, and sure enough they were. So if you get messages about your kernel not having support for kernel mode ppp, then believe it and try the other ppp.o module that gives you non kernel ppp. Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] nat between gateways ???
Charles Steinkuehler wrote: > > Michael D. Schleif wrote: > > I am confused ;< > > > > In order to address the original vpn problem, we have setup a pilot vpn > > between two (2) of our DCD's. > > > > How does this scenario qualify as ``martian'' ??? > > > > root@bluetrout:/root > > # tail -f /var/log/kern.log > > Nov 11 22:08:09 bluetrout kernel: martian source d233e490 for 9dde0440, > > dev wan1 > > Nov 11 22:09:29 bluetrout last message repeated 2 times > > Nov 11 22:09:59 bluetrout last message repeated 2 times > > Nov 11 22:11:19 bluetrout last message repeated 2 times > > Nov 11 22:13:19 bluetrout kernel: martian source d233e490 for 9dde0440, > > dev wan1 > > Nov 11 22:14:29 bluetrout last message repeated 10 times > > Nov 11 22:15:19 bluetrout last message repeated 6 times > > Nov 11 22:16:37 bluetrout last message repeated 7 times > > Nov 11 22:17:19 bluetrout last message repeated 5 times > > Nov 11 22:18:37 bluetrout last message repeated 7 times > > Nov 11 22:19:19 bluetrout last message repeated 5 times > > Nov 11 22:20:37 bluetrout last message repeated 7 times > > Nov 11 22:21:19 bluetrout last message repeated 5 times > > > > NOTE: > > 9dde0440 == 64.4.222.157 > > d233e490 == 144.228.51.210 > > (wan1 on other side of vpn) > > > > > > # ip addr > > 1: lo: mtu 3924 qdisc noqueue > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > inet 127.0.0.1/8 brd 127.255.255.255 scope global lo > > 2: ipsec0: mtu 16260 qdisc pfifo_fast qlen 10 > > link/ipip > > inet 64.4.222.157 peer 64.4.222.158/32 scope global ipsec0 > > . . . > > 7: eth0: mtu 1500 qdisc pfifo_fast qlen 100 > > link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff > > inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 > > 8: eth1: mtu 1500 qdisc pfifo_fast qlen 100 > > link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff > > inet 64.4.197.65/26 brd 64.4.197.127 scope global eth1 > > 14: wan1: mtu 1500 qdisc pfifo_fast qlen 100 > > link/ppp > > inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1 > > inet 64.4.197.99/32 scope global wan1 > > inet 64.4.197.100/32 scope global wan1 > > inet 64.4.197.101/32 scope global wan1 > > > > > > Every time that I think that I understand what constitutes martian-ness, > > I am tossed a new wrinkle ;> > > > > What do you think? > > You don't give enough information to correctly diagnose martian errors, > which are based pretty much entirely on the status of the route tables. > Also, while I have not done a lot of host-host or host-subnet VPNs > (you also don't include your IPSec configuration), you will run into > problems with these VPN flavors if you don't have rpfiltering turned off > (you'll get a warning when starting IPSec about this if it's enabled). Yes, I know that I did not include ipsec info; but, I fail to see any relevancy. Isn't martian-ness independent of anything ipsec? What I see here is a valid public address trying to come in the publicly addressed external interface of a router. My question, I feel, remains valid: How can this be considered martian? Clearly, in order for me to understand this, I need a better grasp of martian-ness. Pointers? Docs? -- 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 . . . --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] nat between gateways ???
Michael D. Schleif wrote: I am confused ;< In order to address the original vpn problem, we have setup a pilot vpn between two (2) of our DCD's. How does this scenario qualify as ``martian'' ??? root@bluetrout:/root # tail -f /var/log/kern.log Nov 11 22:08:09 bluetrout kernel: martian source d233e490 for 9dde0440, dev wan1 Nov 11 22:09:29 bluetrout last message repeated 2 times Nov 11 22:09:59 bluetrout last message repeated 2 times Nov 11 22:11:19 bluetrout last message repeated 2 times Nov 11 22:13:19 bluetrout kernel: martian source d233e490 for 9dde0440, dev wan1 Nov 11 22:14:29 bluetrout last message repeated 10 times Nov 11 22:15:19 bluetrout last message repeated 6 times Nov 11 22:16:37 bluetrout last message repeated 7 times Nov 11 22:17:19 bluetrout last message repeated 5 times Nov 11 22:18:37 bluetrout last message repeated 7 times Nov 11 22:19:19 bluetrout last message repeated 5 times Nov 11 22:20:37 bluetrout last message repeated 7 times Nov 11 22:21:19 bluetrout last message repeated 5 times NOTE: 9dde0440 == 64.4.222.157 d233e490 == 144.228.51.210 (wan1 on other side of vpn) # ip addr 1: lo: mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope global lo 2: ipsec0: mtu 16260 qdisc pfifo_fast qlen 10 link/ipip inet 64.4.222.157 peer 64.4.222.158/32 scope global ipsec0 . . . 7: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 8: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff inet 64.4.197.65/26 brd 64.4.197.127 scope global eth1 14: wan1: mtu 1500 qdisc pfifo_fast qlen 100 link/ppp inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1 inet 64.4.197.99/32 scope global wan1 inet 64.4.197.100/32 scope global wan1 inet 64.4.197.101/32 scope global wan1 Every time that I think that I understand what constitutes martian-ness, I am tossed a new wrinkle ;> What do you think? You don't give enough information to correctly diagnose martian errors, which are based pretty much entirely on the status of the route tables. Also, while I have not done a lot of host-host or host-subnet VPNs (you also don't include your IPSec configuration), you will run into problems with these VPN flavors if you don't have rpfiltering turned off (you'll get a warning when starting IPSec about this if it's enabled). -- Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] kernel mode pppd problems
Could someone please help me here, I have upgraded to Dachstein v1.02 and would like to run pppd for a dialin service. However I have the following message coming back at me when I try to run # /usr/sbin/pppd ioctl(TIOCSETD(PPP)): Invalid argument(22) /usr/sbin/pppd: This system lacks kernel support for PPP. This could be because the PPP kernel module could not be loaded, or because PPP was not included in the kernel configuration. If PPP was included as a module, try `/sbin/modprobe -v ppp'. If that fails, check t I have the ppp.lrp module that came with Dachstein, so just what is happening here? I must admit to being a bit tired of recent and hence a bit muddled. Many thanks, Matt My apology for posting to the list admin, slip of the finger! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] Mounting / formatting an IDE drive in Bering was Samba, Ide, Mount ???'s
Hi At 11:47 12.11.2002, you wrote: >> This leads me to believe that the filesystem I created on Redhat is >> not Bering compatible so I tried # ./mkfs.minix -c /dev/hdc which >> gives me >> >> # ./mkfs.minix -c /dev/hdc1 >> BusyBox v0.60.3 (2002.06.08-17:56+) multi-call binary >> >> Usage: mkfs.minix [-c | -l filename] [-nXX] [-iXX] /dev/name [blocks] >> >> The man page for mkfs.minix is no help at this point. What am I >> missing? > >Umm Minix is a "virtual filesystem" not possible to partition an actual HD with. ie. RamDrive >(if I remember correctly). You originally formatted the drive ext2 as I remember correctly, which Bering Minix is a true filesystem. Due to its small footprint it is normally used for ramdrives. And I also think that originally you could boot from it. I believe syslinux only supports M$DOS formattet filesystems. So in order to boot from that medium and using syslinux I believe you have to stick with M$DOS format. If all you want to do is to store information persistently then you are free to use whatever you decide to load a driver for. HTH Erich THINK Püntenstrasse 39 8143 Stallikon mailto:erich.titl@;think.ch PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] restoring vlan's after reboot: /proc/net/vlan not there
It seems that your floppy must have been almost full when you ran the backup, ending up with a corrupted vlan.lrp... I guess you must redo the config again. -Original Message- From: Scott [mailto:leaf@;troutpocket.org] Sent: Tuesday, November 12, 2002 7:27 AM To: [EMAIL PROTECTED] Subject: [leaf-user] restoring vlan's after reboot: /proc/net/vlan not there using Intel Pro/100 82559 chipset using eepro100 Revision 1.36 using bering rc4 On boot I'm getting the error: SIOCGIFFLAGS: Operation not supported by device I load the 802.1q driver (8021q.o). I configure my vlan with the following command lines: vconfig add eth1 11 vconfig add eth2 12 vconfig add eth3 13 etc... I backup the vlan. When I reboot, it is not finding the devices eth1.11, eth1.12, and eth1.13. I check /proc/net/vlan and it's empty where there used to be entries for each virtual device. /var/lib/lrpkg/vlan.list: sbin/vconfig etc/network/if-pre-up.d/vlan etc/network/ip-up.d/ip etc/network/if-post-down.d/vlan var/lib/lrpkg/vlan.* By default there is no entry in vlan.list for /proc/net/vlan. I tried adding it, but it bombs when I try "lrpkg -i vlan" later with a tar error. Any suggestions how to have those vlans active when I boot? Otherwise shorewall doesn't have anything to configure. -Scott --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] Mounting / formatting an IDE drive in Bering was Samba, Ide, Mount ???'s
>> This leads me to believe that the filesystem I created on Redhat is >> not Bering compatible so I tried # ./mkfs.minix -c /dev/hdc which >> gives me >> >> # ./mkfs.minix -c /dev/hdc1 >> BusyBox v0.60.3 (2002.06.08-17:56+) multi-call binary >> >> Usage: mkfs.minix [-c | -l filename] [-nXX] [-iXX] /dev/name [blocks] >> >> The man page for mkfs.minix is no help at this point. What am I >> missing? > >Umm Minix is a "virtual filesystem" not possible to partition an actual HD with. ie. RamDrive >(if I remember correctly). You originally formatted the drive ext2 as I remember correctly, which Bering Minix is a true filesystem. Due to its small footprint it is normally used for ramdrives. And I also think that originally you could boot from it. Anyway if your harddisk was formatted as ext2, all you need to do is load the ext2.o module right after the ide-disk.o . You can get the mentioned module from here: http://leaf.sourceforge.net/devel/jnilo/bering/latest/modules/2.4.18/kernel/ fs/ext2/ext2.o --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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] restoring vlan's after reboot: /proc/net/vlan not there
On Mon, 11 Nov 2002 23:27:14 PST Scott wrote: > using Intel Pro/100 82559 chipset > using eepro100 Revision 1.36 > using bering rc4 > > On boot I'm getting the error: >SIOCGIFFLAGS: Operation not supported by device Interesting. It's hard to say exactly what's causing it without a bit more context. I doubt that error message directly affects the vlan configuration though. If you're really curious, set VERBOSE=1 and DEBUG=1 in /linuxrc, backup initrd, and reboot. You should get more verbose startup messages that will probably include the command that causes the SIOCGIFFLAGS error. > I load the 802.1q driver (8021q.o). I configure my vlan with the > following command lines: > > vconfig add eth1 11 > vconfig add eth2 12 > vconfig add eth3 13 > etc... > > I backup the vlan. When I reboot, it is not finding the devices > eth1.11, eth1.12, and eth1.13. I check /proc/net/vlan and it's empty > where there used to be entries for each virtual device. > > /var/lib/lrpkg/vlan.list: > > sbin/vconfig > etc/network/if-pre-up.d/vlan > etc/network/ip-up.d/ip > etc/network/if-post-down.d/vlan > var/lib/lrpkg/vlan.* > > By default there is no entry in vlan.list for /proc/net/vlan. There shouldn't be since /proc isn't a real filesystem. The trick is to make the vconfig commands persistent across reboots... > I tried > adding it, but it bombs when I try "lrpkg -i vlan" later with a tar > error. Any suggestions how to have those vlans active when I boot? > Otherwise shorewall doesn't have anything to configure. The approach I would probably use is: 1) Copy 8021q.o into /lib/modules . 2) Add 8021q to /etc/modules . 3) Backup the "modules" package. 4) Use the "up" option in /etc/network/interfaces to run the vconfig commands. As an example: auto eth0 iface eth0 inet static address 11.22.33.44 masklen 29 [..] up vconfig add eth1 11 5) Test with: svi network restart; svi shorewall restart (After insmoding 8021q.o manually if necessary.) 6) Backup the "etc" package if everything works as expected. There are also "pre-up", "down" and "post-down" options. Gory details at http://leaf-project.org/devel/jnilo/manpages/interfaces_man.html Hope that helps. --Brad --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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
