RE: [leaf-user] Bering floppy basics
I had the same problem, and found that changing the floppy (disk) solved the problem. I re-wrote the image to other floppies. I have noted that the OS is more sensitive to marginal floppies than might be expected. I now format all the disks before writing the image to them, and if there's the slightest problem with the format, trash the floppy. They're just not worth the fuss to save a floppy and lose the data or OS. I've noticed a failure rate of about 80% on some cheap no-name floppies I bought 10 years ago. On the other hand, the name-brand floppies bought at the same time are working nicely. And, on the gripping hand, I'll eventually move the project to a CD. -Original Message- From: Steve Wright [SMTP:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 15:40 To: LEAF-USER Subject:[leaf-user] Bering floppy basics http://prdownloads.sourceforge.net/leaf/Bering_1.2_img_bering-1680.bin With no modifications, this fails with ; Loading initrd.lrp... Boot Failed: please change disks... Just a dud floppy ? TIA, Steve --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 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] Question: Bering static DHCP configuration
sigh RTFM rides again I found everything I needed in the DHCP man pages. The deny unknown-hosts command was what I wanted. It's up to the rest of the packages to reject traffic from unknown hosts that are using a fixed IP that would otherwise be on the subnet. -Original Message- From: Greg Playle [SMTP:[EMAIL PROTECTED] Sent: Saturday, August 02, 2003 20:05 To: '[EMAIL PROTECTED]' Subject:[leaf-user] Question: Bering static DHCP configuration Thank you to all that have helped me learn a bit as I go. My question now is: I'd like to configure the internal network to ONLY assign IP addresses to certain machines. I don't seem to have it correctly configured. Could someone point me to something to read / learn about this? I've checked the FAQ, read the User Guide and the Installation Guide, and Googled, but don't seem to find what I'm after. ..snipped content. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 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] Question: Bering static DHCP configuration
Thank you to all that have helped me learn a bit as I go.
My question now is: I'd like to configure the internal network to ONLY
assign IP addresses to certain machines. I don't seem to have it correctly
configured. Could someone point me to something to read / learn about
this?
I've checked the FAQ, read the User Guide and the Installation Guide, and
Googled, but don't seem to find what I'm after.
I've got DHCP running, and assigning IPs quite nicely.
Unfortunately, it's also assigning IPs to what I think are other hosts.
I thought that, by only assigning particular IPs to particular MACs, the
others would not receive addresses.
That leaves me with some options:
- restrict the netmask to only those few addresses
- somehow change the subnet mask.
- something else that restricts which IPs get assigned to which MACs
What haven't I learned yet?
My dhcp.config is like this:
dynamic-bootp-lease-length 604800;
max-lease-time 1209600;
host FirstHost {
hardware ethernet 00:00:00:00:00:00; # where the MAC addr is
fixed-address 192.168.1.1;
}
host SecondHost {
hardware ethernet 00:00:00:00:00:00;
fixed-address 192.168.1.2;
}
host ThirdHost {
hardware ethernet 00:00:00:00:00:00;
fixed-address 192.168.1.3;
}
#host ExcludeHost {
# hardware ethernet 00:00:00:00:00:00;
# fixed-address 192.168.1.4;
#}
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
option domain-name name;
option domain-name-servers 192.168.1.254;
range 192.168.1.1 192.168.1.3;
}
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
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] followup to interfaces / shorewall assist
This is essentially what I ended up doing. As Mr. Sturdevant observed, card services do not come up in time. I added a script at the end of the boot sequence in rc2.d that restarts networking, dhcpd and shorewall, and suddenly Bob's your Uncle! I got the same clue from an article that appeared referenced at SlashDot, which discussed making a Linux-powered wireless access point from a single board computer that used CF cards for the main storage and PCMCIA cards for the wireless NIC and ethernet NIC. It acted primarily as a bridge. As I read the article, he had a sentence that mentioned card services not up yet, so eth0 not up yet, so restartand the blindingly obvious strikes. I said I'd pass on what I learned...maybe we could add this to the official howto, or some such? -Original Message- From: S Mohan [SMTP:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 03:30 To: Erich Titl; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject:RE: [leaf-user] followup to interfaces / shorewall assist If it is a question of interface not coming up, why not put the commands in if-up and in rmnologon in /etc/init.d, add the svi networking restart? Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erich Titl Sent: Monday, July 28, 2003 1:18 AM To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Subject: Re: [leaf-user] followup to interfaces / shorewall assist Greg At 18:14 27.07.2003, Greg Playle wrote: Tom, Steve and George: Thank you; the information you gave was helpful. I checked a bit more; in short, eth0 does not come up on boot, but seems to take a while--perhaps longer than Erich Titl's script allows. I've got to check more on the script, as I'm not sure it delays as long as needed. Restarting networking, esp eth0, brings it up fine, and then I can manually launch dhcpd, after which all responds as it should. I'm able to ping the eth0 address (192.168.1.254) both from itself and from another machine (which obtained its IP from the dhcp server). What I'd like to accomplish is having this all come up without having to manually restart eth0 and dhcpd. What I think is going on is that the version of Erich's script I'm using doesn't wait 60 seconds, but runs to completion in about one second, so eth0 is still not up before the boot process continues. Since eth0 isn't yet up, networking, therefore dhcpd, don't work either. By the time boot completes, eth0 is up, and manual restart of networking on eth0 and on dhcpd work. I guess you must have modified the assert script as it is written for 2 interfaces and would run at a wrong init level. I believe it does not run in your case for some reason difficult to diagnose unless you tell us more about the way you implemented it. I am pretty certain your problems stem from the interface not being up and the assert script failing for some reason. It does not have a backup routine, so it would be saved by etc I guess. So here is the stupid question, did you back it up? regards Erich THINK Puntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 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 sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 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] followup to interfaces / shorewall assist
Tom, Steve and George: Thank you; the information you gave was helpful. I checked a bit more; in short, eth0 does not come up on boot, but seems to take a while--perhaps longer than Erich Titl's script allows. I've got to check more on the script, as I'm not sure it delays as long as needed. Restarting networking, esp eth0, brings it up fine, and then I can manually launch dhcpd, after which all responds as it should. I'm able to ping the eth0 address (192.168.1.254) both from itself and from another machine (which obtained its IP from the dhcp server). What I'd like to accomplish is having this all come up without having to manually restart eth0 and dhcpd. What I think is going on is that the version of Erich's script I'm using doesn't wait 60 seconds, but runs to completion in about one second, so eth0 is still not up before the boot process continues. Since eth0 isn't yet up, networking, therefore dhcpd, don't work either. By the time boot completes, eth0 is up, and manual restart of networking on eth0 and on dhcpd work. I suppose one test would be to add those commands to the /etc/networking/interfaces file and see if they'll run there. I'll try that and see what happens. Meantime, I'd sure appreciate some more pointers. In answer to Tom's question: I ran the ip addr ls both before and after restarting networking, and captured the results below. I've used asterisks to set off the different results. * ip addr ls 1: lo: LOOPBACK,UP mtu 16436 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 host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: ppp0: POINTOPOINT,MULTICAST,NOARP,UP mtu 1500 qdisc pfifo_fast qlen 3 link/ppp inet 10.64.64.64 peer 10.112.112.112/32 scope global ppp0 4: eth0: BROADCAST,MULTICAST mtu 1500 qdisc noop qlen 100 link/ether 00:60:08:b1:ea:f5 brd ff:ff:ff:ff:ff:ff * /etc/init.d/networking restart should have been eth0 instead of restart Reconfiguring network interfaces: Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Stopping Shorewall...Processing /etc/shorewall/stop ... Processing /etc/shorewall/stopped ... done. Shutting down dnscache without daemontools... /usr/bin/poff: No pppd is running. None stopped. dnscache error: already stopped dnscache queries allowed from 192.168 Starting dnscache without daemontools ... done. .. goes on to reconfigure network interfaces .. .. launch dhcpd manually, and it works * ip addr ls 1: lo: LOOPBACK,UP mtu 16436 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 host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 4: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:60:08:b1:ea:f5 brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 5: ppp0: POINTOPOINT,MULTICAST,NOARP,UP mtu 1500 qdisc pfifo_fast qlen 3 link/ppp inet 10.64.64.64 peer 10.112.112.112/32 scope global ppp0 6: ppp1: POINTOPOINT,MULTICAST,NOARP,UP mtu 1500 qdisc pfifo_fast qlen 3 link/ppp inet 10.64.64.65 peer 10.112.112.113/32 scope global ppp1 PING 192.168.1.254 (192.168.1.254): 56 data bytes 64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=4.0 ms 64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=1.9 ms 64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=1.9 ms 64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=1.9 ms --- 192.168.1.254 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1.9/2.4/4.0 ms --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 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] followup to interfaces / shorewall assist
I tried building in a simple wait 60 seconds script, which ran at S29. That didn't help. I've got something out of order, but I'm still not sure what. What diagnostics would be useful here? -Original Message- From: Steve Wright [SMTP:[EMAIL PROTECTED] Sent: Sunday, July 27, 2003 14:39 To: [EMAIL PROTECTED] Subject:Re: [leaf-user] followup to interfaces / shorewall assist Greg Playle wrote: Thank you; the information you gave was helpful. I checked a bit more; in short, eth0 does not come up on boot, but seems to take a while interfaces that take ages to come up are usually waiting for some dhcp server to answer.. 8-) Your eth0 should configure nearly instantly, or else something is amiss. Here is your problem to solve, IMO. Perhaps post a bit more diagnostics of this phase of the bootup. Restarting networking, esp eth0, brings it up fine, and then I can manually launch dhcpd, after which all responds as it should. I'm able to ping the eth0 address (192.168.1.254) both from itself and from another machine (which obtained its IP from the dhcp server). Bering Gurus are needed here. Good luck. /steve --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 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 sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 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] DHCP on PCMCIA interface?
This is a followup to earlier traffic, shown below. My problem now seems to be the DHCP daemon wants to activate before the PCMCIA card is available, so it cannot find interface eth0. Running dhcpd at the command line promptly fires it up, and activates the interface, and begins serving IP addresses. I think I need to launch dhcpd later in the boot cycle, or the pcmcia earlier, but I haven't had any luck with this. I've read the FAQ, re-read the installation and user guide (somethin like 15th time) and they don't seem to say either. Could someone point me to a successful approach? -Original Message- From: Greg Playle [SMTP:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 8:14 PM To: '[EMAIL PROTECTED]' Subject:RE: [leaf-user] Errors--Route through eth0? Richard: I'll be glad to share what I learn as I go, and I planned on sending lessons-learned back to the list / primary producers of LEAF. You pointed me in the right track, but it turned out the 3c589_cs CANNOT be called from within the /etc/modules. Instead, the 3c589 driver needs moved to the /lib/modules/pcmcia, then the pcmcia package backed up. Upon load, the OS automatically loads these modules, in module-dependent order. That got eth0 working, at least from the firewall's view. I'm still checking the eth0 service to make sure I understand what's available / works there. Best wishes, -Original Message- From: Richard Doyle [SMTP:[EMAIL PROTECTED] Sent: Monday, 09 June, 2003 21:03 To: '[EMAIL PROTECTED]' Subject:Re: [leaf-user] Errors--Route through eth0? On Mon, 2003-06-09 at 19:19, Greg Playle wrote: My thanks to Tom Eastep and Ray Olszewski, who pointed out some information that would help. I'm working on LEAF Bering 1.2, using a PPP serial modem (as ppp0) and a PCMCIA NIC as eth0 for the internal network. The host is a Toshiba Satellite Pro 460CDX laptop (recycled). The NIC is an older 3Com Ethe rLink III 3C589D based card (recycled). At boot, the firewall gives an error message of: Masquerade: Error: Unable to determine the routes through eth0 snip # /etc/modules: kernel modules to load at boot time. # ISA ethernet cards # PCI ethernet cards # should the 3c589_cs.o be declared here? - Yes. You can insert the module on a running system with insmod 3c589_cs I'm very interested in your progress on this project, as I'm about to try something rather similar in the next few weeks. Good luck! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.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 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 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] Errors--Route through eth0?
Richard: I'll be glad to share what I learn as I go, and I planned on sending lessons-learned back to the list / primary producers of LEAF. You pointed me in the right track, but it turned out the 3c589_cs CANNOT be called from within the /etc/modules. Instead, the 3c589 driver needs moved to the /lib/modules/pcmcia, then the pcmcia package backed up. Upon load, the OS automatically loads these modules, in module-dependent order. That got eth0 working, at least from the firewall's view. I'm still checking the eth0 service to make sure I understand what's available / works there. Best wishes, -Original Message- From: Richard Doyle [SMTP:[EMAIL PROTECTED] Sent: Monday, 09 June, 2003 21:03 To: '[EMAIL PROTECTED]' Subject:Re: [leaf-user] Errors--Route through eth0? On Mon, 2003-06-09 at 19:19, Greg Playle wrote: My thanks to Tom Eastep and Ray Olszewski, who pointed out some information that would help. I'm working on LEAF Bering 1.2, using a PPP serial modem (as ppp0) and a PCMCIA NIC as eth0 for the internal network. The host is a Toshiba Satellite Pro 460CDX laptop (recycled). The NIC is an older 3Com EtherLink III 3C589D based card (recycled). At boot, the firewall gives an error message of: Masquerade: Error: Unable to determine the routes through eth0 snip # /etc/modules: kernel modules to load at boot time. # ISA ethernet cards # PCI ethernet cards # should the 3c589_cs.o be declared here? - Yes. You can insert the module on a running system with insmod 3c589_cs I'm very interested in your progress on this project, as I'm about to try something rather similar in the next few weeks. Good luck! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.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 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 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] Errors--Route through eth0?
My thanks to Tom Eastep and Ray Olszewski, who pointed out some information that would help. I'm working on LEAF Bering 1.2, using a PPP serial modem (as ppp0) and a PCMCIA NIC as eth0 for the internal network. The host is a Toshiba Satellite Pro 460CDX laptop (recycled). The NIC is an older 3Com EtherLink III 3C589D based card (recycled). At boot, the firewall gives an error message of: Masquerade: Error: Unable to determine the routes through eth0 Tom suggested the interface isn't up before Shorewall starts, and that seems reasonable. Ray suggested there was a configuration error, and that seems highly likely, as I'm still learning. Pinging the firewall from the internal network, to the default IP of 192.168.1.254 Destination Host Unreachable. I think I've failed to declare something associated with the PCMCIA cards--I'm not sure where the declaration of the 3c589 driver goes--the documentation isn't clear. I've read the FAQ, but didn't find something that pointed in this direction. I searched the archive, and googled, but also didn't find much. I've pulled the information for troubleshooting, per http://leaf-project.org/pub/doc/docmanager/docid_1891.html. The document at http://leaf.sourceforge.net/pub/doc/guide/install-dachstein/ds-laptop.html there may be a PCI-to-PCMCIA bridge problem (these are older machines). But far more likely is that I've left something out, and I've annotated where my suspicions like, below, in the /etc/modules file. I appreciate the help you're providing, as I'm still learning. uname -a yields Linux firewall 2.4.20 #1 Sun May 11 18:53:34 CEST 2003 i586 unknown ip addr show 1: lo: LOOPBACK,UP mtu 16436 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 host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: ppp0: POINTOPOINT,MULTICAST,NOARP,UP mtu 1500 qdisc pfifo_fast qlen 3 link/ppp inet 10.64.64.64 peer 10.112.112.112/32 scope global ppp0 ip route show 10.112.112.112 dev ppp0 proto kernel scope link src 10.64.64.64 default via 10.112.112.112 dev ppp0 lsmod Module PagesUsed by ds 6796 2 i82365 27044 2 pcmcia_core41088 0 [ds i82365] ip_nat_irc 2176 0 (unused) ip_nat_ftp 2784 0 (unused) ip_conntrack_irc2880 1 ip_conntrack_ftp3648 1 ppp_async 6284 0 (unused) ppp_generic16152 1 [ppp_async] slhc4352 0 [ppp_generic] /sbin/shorewall status Shorewall-1.4.2 Status at firewall - Mon Jun 9 20:07:24 UTC 2003 Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/00.0. 0.0/0 udp dpt:53 0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 Chain all2all (3 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 newnotsyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:!0x16/0x02 0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ULOG all -- * * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix `Shorewall:all2all:REJECT:' queue_threshold 1 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 Chain common (2 references) pkts bytes target prot opt in out source dest ination 0 0 icmpdeficmp -- *
[leaf-user] Errors--Route through eth0?
I'm working a simple, serial-modem / single network (ppp0 eth0) setup. At boot, one of the last messages before login is: Masquerade: Error: Unable to determine the routes through eth0 I've checked the zones defined, the interfaces defined, and the masquerade definitions, and all appear to agree with the PPP setup instructions in the LEAF User documentation. I've tried pinging the IP and the hostname; without a DNS, it's hard to get this to work. I've checked the archives, and googled, but find nothing that sheds light on this. Could someone point me at something to check, or tests to run, to determine the problem? Thank you --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.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] Errors with LEAF
I could use some directions to more information. I am learning a bit about LEAF, the Bering distribution, v1.2. I've pulled the package, followed the directions, and I think I've got an approach working. I'm working a simple, serial-modem / single network (ppp0 eth0) setup. I wanted to install ssh as I went about it. I've followed the directions, changed the installation to use two floppies, and added the libz, sshd, and sshkey modules to syslinux.cfg and the modules disk. When I boot, I get an error message on the libz load that says Invalid gzip magic. I did a google, but could find only one dead link to a sourceforge archive. I've obviously set something up incorrectly, but don't know what it is. Would this be an erroneous version number, or am I not providing something? Possibly a corrupt file? Additionally, I'm seeing sshkey returning a format violated error message when that modules is loaded. Would this be a corrupt file? Finally, I'm getting an error message as the firewall loads its rules that says: Masquerade: Error: unable to determine the routes through eth0 I've checked the zones defined, the interfaces defined, and the masquerade definitions, and all appear to agree with the PPP setup instructions in the LEAF User documentation. If you could point me to something that might help, I'd greatly appreciate it. Thank you --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.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] Errors with LEAF
I could use some directions to more information. I am learning a bit about LEAF, the Bering distribution, v1.2. I've pulled the package, followed the directions, and I think I've got an approach working. I'm working a simple, serial-modem / single network (ppp0 eth0) setup. I wanted to install ssh as I went about it. I've followed the directions, changed the installation to use two floppies, and added the libz, sshd, and sshkey modules to syslinux.cfg and the modules disk. When I boot, I get an error message on the libz load that says Invalid gzip magic. I did a google, but could find only one dead link to a sourceforge archive. I've obviously set something up incorrectly, but don't know what it is. Would this be an erroneous version number, or am I not providing something? Possibly a corrupt file? Additionally, I'm seeing sshkey returning a format violated error message when that modules is loaded. Would this be a corrupt file? Finally, I'm getting an error message as the firewall loads its rules that says: Masquerade: Error: unable to determine the routes through eth0 I've checked the zones defined, the interfaces defined, and the masquerade definitions, and all appear to agree with the PPP setup instructions in the LEAF User documentation. If you could point me to something that might help, I'd greatly appreciate it. Thank you --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.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] Testing dial-up modem
On 19 Feb 2003 13:11:07 -0800, Richard Doyle wrote in reply: --- snip --- Post a log segment showing a complete sequence of chat and pppd entries. In general it is helpful to post unedited logs (but replace passwords with x's). The summary you provided doesn't provide any evidence that your system is communicating with your modem. The unsummarized log may give us a clue. My home network has two internal subnets and a dial-up connection to the Internet (currently via an internal modem, but in the past an external one), so your intended configuration is quite feasible. Your problem is probably not LEAF-specific--you might get more help by looking in the ppp howto (https://secure.linuxports.com/howto/ppp/), which is a bit old, and the linux-ppp mailing list (http://vger.kernel.org/majordomo-info.html). -Richard - end snip -- Richard: I had no fear that what I wanted was achievable; I seem to have done something incorrectly in setting it up. I've pulled various logs and configuration files and will post them below. Advice and comment is quite welcome. The machine is an older P75, no hard drive, two 3C905B NICs, and an external Zoltrix 56k modem. What I am trying to set up is a dual-homed firewall, dial-up service, and an internal store and forward server in the DMZ, to capture, filter, and hold e-mail and such until I can join the net and pull them. Getting Bering working is the first step in this. On to the logs: each is identified by a line before and after. Some lines may wrap snip /var/log/messages Feb 26 19:56:48 firewall syslogd 1.3-3#31.slink1: restart. Feb 26 19:56:48 firewall kernel: klogd 1.3-3#31.slink1, log source = /proc/kmsg started. Feb 26 19:56:48 firewall kernel: Loaded 21 symbols from 8 modules. Feb 26 19:56:48 firewall kernel: BIOS-provided physical RAM map: Feb 26 19:56:48 firewall kernel: 32MB LOWMEM available. Feb 26 19:56:48 firewall kernel: Initializing CPU#0 Feb 26 19:56:48 firewall kernel: Memory: 30136k/32768k available (965k kernel code, 2244k reserved, 252k data, 64k init, 0k highmem) Feb 26 19:56:48 firewall kernel: Dentry cache hash table entries: 4096 (order: 3, 32768 bytes) Feb 26 19:56:48 firewall kernel: Inode cache hash table entries: 2048 (order: 2, 16384 bytes) Feb 26 19:56:48 firewall kernel: Intel Pentium with F0 0F bug - workaround enabled. Feb 26 19:56:48 firewall kernel: Checking 'hlt' instruction... OK. Feb 26 19:56:48 firewall kernel: PCI: PCI BIOS revision 2.10 entry at 0xfcb71, last bus=0 Feb 26 19:56:48 firewall kernel: PCI: Using configuration type 1 Feb 26 19:56:48 firewall kernel: PCI: Probing PCI hardware Feb 26 19:56:48 firewall kernel: Limiting direct PCI/PCI transfers. Feb 26 19:56:48 firewall kernel: Linux NET4.0 for Linux 2.4 Feb 26 19:56:48 firewall kernel: Based upon Swansea University Computer Society NET3.039 Feb 26 19:56:48 firewall kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ DETECT_IRQ SERIAL_PCI enabled Feb 26 19:56:48 firewall kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A Feb 26 19:56:48 firewall kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A Feb 26 19:56:48 firewall kernel: Real Time Clock Driver v1.10e Feb 26 19:56:48 firewall kernel: Software Watchdog Timer: 0.05, timer margin: 60 sec Feb 26 19:56:48 firewall kernel: Floppy drive(s): fd0 is 1.44M Feb 26 19:56:48 firewall kernel: FDC 0 is a National Semiconductor PC87306 Feb 26 19:56:48 firewall kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Feb 26 19:56:48 firewall kernel: IP Protocols: ICMP, UDP, TCP, IGMP Feb 26 19:56:48 firewall kernel: IP: routing cache hash table of 512 buckets, 4Kbytes Feb 26 19:56:48 firewall kernel: TCP: Hash tables configured (established 2048 bind 2048) Feb 26 19:56:48 firewall kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Feb 26 19:56:48 firewall kernel: RAMDISK: Compressed image found at block 0 Feb 26 19:56:48 firewall kernel: Freeing initrd memory: 401k freed Feb 26 19:56:48 firewall kernel: Freeing unused kernel memory: 64k freed Feb 26 19:56:48 firewall kernel: 3c509.c:1.19 16Oct2002 [EMAIL PROTECTED] Feb 26 19:56:48 firewall chat[9516]: abort on (BUSY) Feb 26 19:56:48 firewall chat[9516]: abort on (NO CARRIER) Feb 26 19:56:48 firewall chat[9516]: abort on (VOICE) Feb 26 19:56:48 firewall chat[9516]: abort on (NO DIALTONE) Feb 26 19:56:48 firewall chat[9516]: abort on (NO ANSWER) Feb 26 19:56:48 firewall chat[9516]: send (ATZ^M) Feb 26 19:56:48 firewall kernel: http://www.scyld.com/network/3c509.html Feb 26 19:56:48 firewall kernel: CSLIP: code copyright 1989 Regents of the University of California Feb 26 19:56:48 firewall kernel: PPP generic driver version 2.4.2 Feb 26 19:56:49 firewall chat[9516]: expect (OK) Feb 26 19:56:56 firewall root: Shorewall Started Feb 26 19:57:34 firewall chat[9516]: alarm Feb 26 19:57:34 firewall chat[9516]: Failed
RE: [leaf-user] Testing dial-up modem
Richard: Thank you for the reply. Yes, I followed those procedures. I've set the system-wide options for ppp to debug, which was helpful. The /var/log/messages now has the chat scripts results in it. The ABORT commands appear to be sent, and the ATZ^M, but the chat script gives an expect (OK), then an alarm and a failed, with no further indication of what failed. For some reason, the SAY messages didn't show up either, so I removed them. There does not appear to be anything in syslog or ppp.log that adds any information; ppp.log indicates the same process. I never hear any dialing, and I see no change in the status lights on the modem. ifup shows ppp0 present. Are there other things I should try for debug? Richard sent: Have you followed the procedures in http://leaf.sourceforge.net/devel/jnilo/bumodem.html? -Richard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge 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] Testing dial-up modem
I'm new to LEAF, using Bering 1.1, and attempting to set it up for a serial modem (exterior), with two ethernet interfaces. I've got a booting distro, but there seems to be problems talking to the modem. While I learn about PPP, can someone point me to a way to verify the serial interface is actually detected, and is in fact talking to the modem? Thank you --- 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
