[Leaf-user] OT: 3c5x9 nic on Redhat 7.2
First, my apologies for this off-topic post, but I know that this list is full of very knowledgable people, some of whom have wrestled with a 3com card and linux before. It's a tenuous link, but this box I'm talking about will actually be sitting behind a Dachstein box ;-)... does that almost drag it on-topic? It seems likely that this machine will end it's life (at some point) as a leaf box as well. But I digress... I have a Compaq Deskpro 2000 that I am trying to install RH7.2 onto. It has no CD drive, so I am attempting to do a network (http) install from my winME box running Apache (temporarily). I used the bootnet.img and I booted up the Deskpro. Unfortunately, when I'm asked to select the driver for my nic, no matter what I select, I get 'failed to insert 3c5x9 module' (where 3c5x9 is the choice I made on the previous screen). The nic actually is a 3com 3c509b combo ISA card and I know it works as I took it straight out of a win98 box (working). I then disabled pnp and set irq=10 io=0x300. The card passes all of its diagnostics. So what gives? Any clues from the linux gurus out there? Do I need to make a driver disk? If so, which driver to I need... the obvious one doesn't seem to work! all the best tim ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] tcp packets to dns port (was Re: Dachstein-pr3 available)
- Original Message - From: Charles Steinkuehler [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, September 27, 2001 7:38 PM Subject: Dachstein-pr3 available Dachstein pr3 is now available in the usual location: http://lrp.steinkuehler.net/files/diskimages/dachstein/ There are two main changes: A major bug with port-forwarded DMZ setups was fixed, and I have added the lrpStat application to weblet. Charles, that's great. All the dmz problems appear to have gone away, and everything seems to be working as it should. Thanks very much. I do have one niggle though. My logs have quickly filled up with this sort of thing... Sep 27 23:45:02 glenmore kernel: Packet log: input DENY eth0 PROTO=6 203.208.128.70:35587 213.105.191.213:53 L=44 S=0x00 I=0 F=0x T=242 (#47) Sep 27 23:45:02 glenmore kernel: Packet log: input DENY eth0 PROTO=6 202.139.133.129:56100 213.105.191.213:53 L=44 S=0x00 I=0 F=0x T=239 (#47) Sep 27 23:45:02 glenmore kernel: Packet log: input DENY eth0 PROTO=6 203.194.166.182:43201 213.105.191.213:53 L=44 S=0x00 I=0 F=0x T=232 (#47) Sep 27 23:45:02 glenmore kernel: Packet log: input DENY eth0 PROTO=6 203.208.128.70:35613 213.105.191.213:53 L=44 S=0x00 I=0 F=0x T=242 (#47) I realise that these are tcp packets inbound to my dns port (53), but they don't appear to be from the dns root-servers (which was the case last time something like this happened). I seem to remember a thread on either this, or the linux-router list that discussed something like this a little while ago. If I remember correctly, the conclusion was that it was down to some flakey sort of load-balancing system, but I could be wrong on that. I searched the lists on geocrawler, but I couldn't turn up what I was looking for. I just want to check if I'm better opening up tcp_port_53, or simply silently denying all these packets? If I deny them, isn't there a possibility of certain dns queries failing if the response is too large? If I open the port, do I leave myself in more insecure position, given that I (think I) have a program that is listening on this port i.e. dnscache. cheers tim ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-pr2 DMZ problems
- Original Message -
From: Charles Steinkuehler [EMAIL PROTECTED]
To: Tim Hicks [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, September 26, 2001 2:58 PM
Subject: Re: [Leaf-user] Dachstein-pr2 DMZ problems
The problem is, I don't seem to have have the dmz functionality. While
my
internal network can access the internet, it cannot access the dmz net
(i.e.
pings fail). However, pings from the dachstein box to both the internal
and
the dmz net are successful. Looking at the /var/log/messages file, I
cannot
see any log of any packets from the internal net getting denied on their
way
to the dmz.
What I have written above is still the case, even after the changes that you
suggested.
Comment out all the following...these variables are not used for a private
port-forwarded DMZ
DMZ_SRC=216.171.153.128/25
DMZ_EXT_ADDRS=$eth0_DEFAULT_GW $EXTERN_IP
DMZ_HIGH_TCP_CONNECT=NO
#DMZ_CLOSED_DEST=tcp_${DMZ_NET}_6000:6004 tcp_${DMZ_NET}_7100
DMZ_OPEN_DEST= udp_${DMZ_NET}_domain
tcp_${DMZ_NET}_domain
icmp_${DMZ_NET}_:
tcp_1.1.2.13_www
Right, I've commented out all of that.
I missed adding this section to network.conf. Uncomment and change as
appropriate for your desired services.
# Private DMZ switches
# Services port-forwarded to the DMZ network
#DMZ_SERVER0=udp 1.2.3.13 domain 192.168.2.1 domain
#DMZ_SERVER1=tcp 1.2.3.13 domain 192.168.2.1 domain
#DMZ_SERVER2=tcp 1.2.3.13 www 192.168.2.1 www
#DMZ_SERVER3=tcp 1.2.3.13 smtp 192.168.2.1 smtp
#DMZ_SERVER4=tcp 1.2.3.12 www 192.168.2.1 8080
And I've added:
#Private DMZ switches
#Services port-forwarded to the DMZ network
DMZ_SERVER0=tcp 1.2.3.12 22021 192.168.2.2 21
DMZ_SERVER1=tcp 1.2.3.12 22022 192.168.2.2 22
DMZ_SERVER2=tcp 1.2.3.12 22080 192.168.2.2 80
DMZ_SERVER3=tcp 1.2.3.12 22180 192.168.2.2 8080
DMZ_SERVER4=tcp 1.2.3.12 22443 192.168.2.2 443
I do have one question about this port-forwarding though. Would there be a
problem caused by the fact that the external/public ip address that is
listed (1.2.3.12) is not my actual ip address because it is dynamically
assigned by DHCP? Should it be changed to something like $EXTERN_IP, or
doesn't it matter? Either way, I'm pretty sure that isn't my only problem
as this shouldn't affect connections from internal net to dmz right?
If you continue to have problems, please include the output of svi
network
ipfilter list, as well as the information you provided this time...it
will
help me determine if there's a problem with your network.conf settings, or
the new firewall scripts.
I did have one more theory that may or may not be relevant. Unlike the
(probably) more usual setup, my dmz interface is actually eth1 and my
internal one eth2. This is because my dmz has network cards with bnc
connectors, where as everything else is 10baseT. It is a workaround for the
fact that I can't (don't have the right dos disks) change the irq/dma (or
whatever it's called) on the cards to get them to detect in a different
order. Could this have anything to do with my problems? I'm pretty sure I
swapped over all the eth1/2 references in network.conf to reflect this
change though.
Anyway, here's the output that you asked for.
Thanks for your help
tim
# svi network ipfilter list
Chain input (policy DENY: 2 packets, 656 bytes):
pkts bytes target prot opttosa tosx ifname mark outsize
sourcedestination ports
46 15088 DENY udp -- 0xFF 0x00 eth0
172.16.67.2540.0.0.0/0 * - 68
0 0 DENY icmp l- 0xFF 0x00 *
0.0.0.0/00.0.0.0/0 5 - *
0 0 DENY icmp l- 0xFF 0x00 *
0.0.0.0/00.0.0.0/0 13 - *
0 0 DENY icmp l- 0xFF 0x00 *
0.0.0.0/00.0.0.0/0 14 - *
0 0 DENY all l- 0xFF 0x00 eth0
0.0.0.0 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
255.255.255.255 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
127.0.0.0/8 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
224.0.0.0/4 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
10.0.0.0/8 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
172.16.0.0/120.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
192.168.0.0/16 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
0.0.0.0/80.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
128.0.0.0/16 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
191.255.0.0/16 0.0.0.0/0 n/a
0 0 DENY all l- 0xFF 0x00 eth0
192.0.0.0/24 0.0.0.0/0 n/a
0 0 DENY
Re: [Leaf-user] mnc and scripts
- Original Message - From: Mike Sensney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 03, 2001 6:36 AM Subject: Re: [Leaf-user] mnc and scripts However, there is another rather crude way that I think will work. code echo $data | mnc $address $port pid=$! sleep 5 kill $pid /code Thanks Mike, it works just how I want to, crude or not :-). What this does is 1)run mnc as a background task 2)saves the background task PID 3)sleeps 5 seconds 4)kills the background task (mnc) And thanks for the rundown on what's happening. tim ___ Leaf-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] mnc and scripts
Hello all, this is my first time over in this neck of the woods (having lurked on the linux-router list for a long time). I'm running EigerStein Beta2 with extended scripts v1.0, but I'm not really sure that any of that is relevant. My problem is that I have a cable modem connection that does not come with a static ip address. As I run a DMZ server that I need to have accessible, my plan is to run a script (daily with the log cleanups or each time dhcpclient receives a new lease? how would I do that) that uses mnc to transfer the output of 'ip route' to my DMZ server, where I have a basic python server waiting to do things with the information. So, here is the script that I have, begin very basic script #!/bin/sh data=$(ip route) address=192.168.2.2 port=5 echo $data | mnc $address $port exit 0 end script This does what I want it to do, except it just waits to do anything until I hit control+c. I can see this when looking at my server output. It's like the mnc transfer is not completed until I hit control+c. I've looked through Mike Sensney's mail script here (http://users.owt.com/msensney/lrp/mail), but I'm totally new to shell scripting, and don't really understand how it works. If someone could tell me how I can make this script not require user intervention, I'd really appreciate it. thanks tim ps If you happen to know how I can execute my script each time I get an ip lease, that would be great too :-) ___ Leaf-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-user
