Linux-Networking Digest #919, Volume #9 Mon, 18 Jan 99 02:13:48 EST
Contents:
NetWare client problems ([EMAIL PROTECTED])
Newbie help with dynamic IP ethernet connection to ADSL server (Philip Edwards)
Which network driver for SMC 8216T and Red Hat 5.2? (Ed Finch)
dlink nics and linux (Jim Watters)
executing programs on nfs? (Ben Sandler)
Re: forwarding, masquerading, firewalling?????? (Michael Schwager)
Re: traceroute is using the wrong interface (Stephen Carville)
Apache access to netware volume ? ([EMAIL PROTECTED])
NIS/YP - ypcat error ("Brian Alliet")
Re: forwarding, masquerading, firewalling?????? (Luca Filipozzi)
Re: Newbie help with dynamic IP ethernet connection to ADSL server (Michael Schwager)
Re: SOCK_PACKET, etc. (Malware)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: NetWare client problems
Date: Mon, 18 Jan 1999 03:25:54 GMT
First, I should say that I've already tried to post a message similar to this
one. Unfortunately, I don't think that it ever actually got posted to the
system. If I'm wrong, I'm sorry, and you can ignore this post. Otherwise,
read on.
I'm having problems logging into my NetWare server. When I type in "slist,"
it gives me the name of my server, and the other info like it should. When I
type in "nwauth -S ecorp -U forty2," it prompts for the password and then
says:
ncp_reply_size: 0 < 8
ncp_reply_size: 0 < 54
nwauth: Permission denied when trying to open connection.
If I type in "nwauth -S ecorp -U forty2.ema," it gives a similar output,
omitting the second "ncp_reply_size" line, like this:
ncp_reply_size: 0 < 8
nwauth : Permission denied when trying to open connection.
Does anyone know what I'm doing wrong? I'd appreciate it if you could email
me, as I am able to read newsgroups only infrequently. Thanks in advance for
any helpe you can provide.
Zach Bean
[EMAIL PROTECTED]
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Philip Edwards <[EMAIL PROTECTED]>
Subject: Newbie help with dynamic IP ethernet connection to ADSL server
Date: Sun, 17 Jan 1999 19:42:43 -0800
I need help with setting up a dynamic IP ethernet connection to ADSL
server. I have read several HOWTO's without much success. I presently
have 3 other windows systems connceted through a 10baseT hub. They are
all working fine. The service providers claim that they do not support
linux connections. However, I have spoken to a couple of technicians who
claim that it has been done although they themselves do not kow how.
Any help you can provide is appreciated.
philip edwards
------------------------------
From: Ed Finch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Which network driver for SMC 8216T and Red Hat 5.2?
Date: Mon, 18 Jan 1999 00:21:59 -0500
Greetings!
I'm installing Red Hat 5.2 on some old Swan 486 systems with
SMC 8216T network cards. Red Hat 5.2 offers these choices for
network drivers:
SMC 9000 Series
SMC Ultra
SMC Ultra 32
Which of these should I select?
Best regards,
Ed
--
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.
------------------------------
Date: Sun, 17 Jan 1999 22:48:11 -0500
From: Jim Watters <[EMAIL PROTECTED]>
Subject: dlink nics and linux
Hello
I am new to linux and have just installed Calder OpenLinux base 1.1
During install linux doesn't detect my dlink 530CT+ or my dlinkT+. Dlink
doesn't seam to have any support for linux on the web. If you have any
idea where i can find some drivers so these cards will work in linux i
would appreciate it.
thanks
jim
------------------------------
From: Ben Sandler <[EMAIL PROTECTED]>
Subject: executing programs on nfs?
Date: Mon, 18 Jan 1999 05:41:59 +0000
I mounted an nfs share with rw permissions, and I am able to read and
write fine, but I get "permission denied" when I try to execute any
executables in that directory. This happens no matter who created the
file or on which computer it was created. ls lists the file as world
executable.
Anyone know what's wrong?
Both server and client are running RedHat 5.1 (with nfs 2.2beta29-5).
Thanks,
- Ben
--
Ben Sandler
email me: sandler at ymail dot yu dot edu
------------------------------
From: Michael Schwager <[EMAIL PROTECTED]>
Subject: Re: forwarding, masquerading, firewalling??????
Date: Sun, 17 Jan 1999 22:41:05 -0800
Luca Filipozzi wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > 1. How to verify the kernel is ok with forwarding and masquerading?
> Take a look at what's in /proc/net. If you see ip_masquerade, then you
> have masquerading built into the kernel. Same for ip_forward. I use
> debian linux and these files may be in a different directory under RH.
>
> > 2. How to check the forward and masq rules
> You can see what rules are in effect as follows:
> ipfwadm -I -l # for input rules
> ipfwadm -O -l # for output rules
> ipfwadm -F -l # for forwarding (and masquerading) rules
> ipfwadm -A -l # for accounting rules
>
> > 3. How to test the system.
> >
> > I tried testing it by pinging to an internet address from my LAN, to no
> > avail. I have NT on the LAN set up so my linux box is the default
> > gateway. Any suggestions?
> I don't know your level of knowledge so I'm sorry if this is a little
> pedantic.
>
> This is what I have and maybe you can see how your setup differs.
>
> #eth0 is on cable modem (24.xxx.yyy.zzz)
> #eth1 is on LAN (192.168.1.1)
> # deny everything
> ipfwadm -I -p deny
> ipfwadm -I -f
> ipfwadm -O -p deny
> ipfwadm -O -f
> ipfwadm -F -p deny
> ipfwadm -F -f
>
> # permit dhcp traffic so that I can get an IP address allocated by ISP
> # permit bootps (dhcp server) traffic into eth0
> ipfwadm -I -a accept -S 0.0.0.0/0 bootps -D 0.0.0.0/0 -W eth0 -P udp
> # permit bootpc (dhcp client) traffic out of eth0
> ipfwadm -O -a accept -S 0.0.0.0/0 bootpc -D 0.0.0.0/0 -W eth0 -P udp
>
> # permit localhost traffic (so ping localhost works)
> ipfwadm -I -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
> ipfwadm -O -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
>
> # permit LAN traffic into and out of the firewall
> ipfwadm -I -a accept -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth1
> ipfwadm -O -a accept -S 0.0.0.0/0 -D 192.168.1.0/24 -W eth1
>
> # permit cable modem traffic into and out of the firewall
> ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
> ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0
>
> # masquerade the LAN
> ipfwadm -F -a masquerade -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0
>
> I don't make use of the -b option, which would simplify my rules. I don't
> really have to use -I or -O rules but I may in the future lock things
> down more and want placeholders in my firewall script.
>
> Procedure to debug:
> From the firewall:
> 1 - you should be able to ping the localhost
> 2 - you should be able to ping a host on the internet
> 3 - you should be able to ping a host on your LAN
>
> From a host on your LAN:
> 4 - you should be able to ping the firewall
> 5 - you should be able to ping a host on the internet
>
> If you can't get one of the steps to work, then you need to see where the
> packets are getting blocked. To figure this out, you can use tcpdump as
> follows:
>
> Let's say that step 5 doesn't work and that the "host on your LAN" has IP
> address 192.l68.1.2. On the firewall, run this command:
>
> tcpdump -i eth1 ip proto icmp
> or
> tcpdump -i eth1 ip proto 1
>
> This will show you all packets received by the firewall on interface eth1
> (the LAN-side of the firewall) whose ip protocol type is ICMP (what ping
> uses). If you see echo-request packets from 192.168.1.2 then you know
> that your internal machine's packets are getting to the firewall. If you
> don't see echo-reply packets then you know the ping reply's aren't
> coming out of the firewall and getting to your internal machine. What you
> don't know is whether its the outgoing echo-request packets that aren't
> getting out of the firewall and onto the internet in the first place or
> its the returning echo-reply packets that aren't getting back through the
> firewall to your internal machine. To find the answer, you need to see
> what's happening on eth0 (the internet-side of the firewall). On the
> firewall, run this command:
>
> tcpdump -i eth0 ip proto icmp
> or
> tcpdump -i eth0 ip proto 1
>
> tcpdump has a *LOT* of options that you can specify to allow you to focus
> on only those packets which interest you. Check out its manpage.
>
> If you see no echo-request packets, then the firewall isn't allowing them
> out of your internal network.
>
> If you see echo-request packets (you will also so echo-reply packets),
> then the firewall isn't allowing the replies back into the internal LAN.
>
> There's another wrinkle to this that I haven't mentioned.
>
> Are your routing tables set up correctly? Your internal machines should
> have the firewall's eth1 IP address set as their default gateway. You
> mention above that this is already the case.
>
> The firewall should have your ISP's router set as its default gateway. If
> it doesn't, then your firewall won't know what to do with the echo-
> request packets it gets from the internal machine.
>
> I hope this helps.
> --
> Luca Filipozzi <[EMAIL PROTECTED]>
YESYESYESYES!!!! IT worked!! THANK YOU so much! I typed in exactly
what you have, except changing the numbers, and it worked --- for now.
That is, until dhcp assigns me a new ip address. How do I get the dhcp
server to reassign the values in the ipfwadm tables when I get a new ip?
Honestly, I think this explanation should go into the firewall howto, or
into a mini-howto or something.
ms
------------------------------
From: Stephen Carville <[EMAIL PROTECTED]>
Subject: Re: traceroute is using the wrong interface
Date: 18 Jan 1999 04:04:25 GMT
[EMAIL PROTECTED] wrote:
>
> I am running Redhat 5.2 as a SMB and DHCP server for some Win95 clients. I am
> now trying to connect to the internet using PPP.
>
> I have three network interfaces when ppp is connected: lo, eth0, ppp0.
>
> I have tested both ping and http to both ip addresses and domain names, and
> both appear to use the correct interface(ppp0).
>
> But now when I attempt a traceroute, it says it has found multiple interfaces
> and is going to use eth0 (which is the wrong one).
>
> How can I get it to choose the correct interface???
Use "traceroute -i ppp0 <destination>" Traceroute does not automatically
pickup on the default route. Being able to switch interfaces is useful in
a diagnostic tool.
> Some useful information may be that in order to get win95 to work I had to do
> the following command:
>
> route add -host 255.255.255.255 dev eth0
Are you usng DHCP? I have to do this to get DHCP to work with the NT95
clients.
--
Stephen Carville
[EMAIL PROTECTED]
====================================================
Management: The art of hiring intelligent, skilled individuals and then
ignoring their advice.
------------------------------
From: [EMAIL PROTECTED]
Subject: Apache access to netware volume ?
Date: Mon, 18 Jan 1999 04:51:03 GMT
Hi all,
I 'm pretty new to linux and just
using it for my Apache.
I would like to know, which might be
the best (the safest not fastest) way
to access the Netware volume where I have
all the Intranet files and databases. I
head of mars, ncpfs and the caldera client.
NDS support is not so important.
It is essential that I can run an indexer/searchengine
which does safely index the netware volume.
Thanks in advance for your help
Clemens
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Brian Alliet" <[EMAIL PROTECTED]>
Subject: NIS/YP - ypcat error
Date: Mon, 18 Jan 1999 01:27:29 -0500
I'm trying to setup NIS on a few linux boxes. Almost everything is working
ok now except one thing. ypcat. Yes ypcat, this made testing a real pain. I
screwed around for about 2 hours before I realized that everything was
working except ypcat, which I was using to test the setup. ypmatch, ypwhich,
yppoll, everything else works, I can login from the other systems with no
problems, just ypcat won't work. When I run ypcat passwd I get this after a
few seconds delay:
No such map passwd.byname. Reason: YP server error
yet ypmatch brian passwd will get me:
brian:x:100:100:Brian Alliet:/home/brian:/bin/bash
I am running ypserv 1.3.6, ypbind 3.3, and yptools 2.2. I tried to apply the
update patch to ypbind but I got tons of errors compiling after that. Could
this be the problem?
Thanks for any help
-Brian
------------------------------
From: [EMAIL PROTECTED] (Luca Filipozzi)
Subject: Re: forwarding, masquerading, firewalling??????
Date: Sun, 17 Jan 1999 22:31:12 -0800
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Luca Filipozzi wrote:
> >
> > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > > 1. How to verify the kernel is ok with forwarding and masquerading?
> > Take a look at what's in /proc/net. If you see ip_masquerade, then you
> > have masquerading built into the kernel. Same for ip_forward. I use
> > debian linux and these files may be in a different directory under RH.
> >
> > > 2. How to check the forward and masq rules
> > You can see what rules are in effect as follows:
> > ipfwadm -I -l # for input rules
> > ipfwadm -O -l # for output rules
> > ipfwadm -F -l # for forwarding (and masquerading) rules
> > ipfwadm -A -l # for accounting rules
> >
> > > 3. How to test the system.
> > >
> > > I tried testing it by pinging to an internet address from my LAN, to no
> > > avail. I have NT on the LAN set up so my linux box is the default
> > > gateway. Any suggestions?
> > I don't know your level of knowledge so I'm sorry if this is a little
> > pedantic.
> >
> > This is what I have and maybe you can see how your setup differs.
> >
> > #eth0 is on cable modem (24.xxx.yyy.zzz)
> > #eth1 is on LAN (192.168.1.1)
> > # deny everything
> > ipfwadm -I -p deny
> > ipfwadm -I -f
> > ipfwadm -O -p deny
> > ipfwadm -O -f
> > ipfwadm -F -p deny
> > ipfwadm -F -f
> >
> > # permit dhcp traffic so that I can get an IP address allocated by ISP
> > # permit bootps (dhcp server) traffic into eth0
> > ipfwadm -I -a accept -S 0.0.0.0/0 bootps -D 0.0.0.0/0 -W eth0 -P udp
> > # permit bootpc (dhcp client) traffic out of eth0
> > ipfwadm -O -a accept -S 0.0.0.0/0 bootpc -D 0.0.0.0/0 -W eth0 -P udp
> >
> > # permit localhost traffic (so ping localhost works)
> > ipfwadm -I -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
> > ipfwadm -O -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
> >
> > # permit LAN traffic into and out of the firewall
> > ipfwadm -I -a accept -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth1
> > ipfwadm -O -a accept -S 0.0.0.0/0 -D 192.168.1.0/24 -W eth1
> >
> > # permit cable modem traffic into and out of the firewall
> > ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
> > ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0
> >
> > # masquerade the LAN
> > ipfwadm -F -a masquerade -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0
> >
> > I don't make use of the -b option, which would simplify my rules. I don't
> > really have to use -I or -O rules but I may in the future lock things
> > down more and want placeholders in my firewall script.
> >
> > Procedure to debug:
> > From the firewall:
> > 1 - you should be able to ping the localhost
> > 2 - you should be able to ping a host on the internet
> > 3 - you should be able to ping a host on your LAN
> >
> > From a host on your LAN:
> > 4 - you should be able to ping the firewall
> > 5 - you should be able to ping a host on the internet
> >
> > If you can't get one of the steps to work, then you need to see where the
> > packets are getting blocked. To figure this out, you can use tcpdump as
> > follows:
> >
> > Let's say that step 5 doesn't work and that the "host on your LAN" has IP
> > address 192.l68.1.2. On the firewall, run this command:
> >
> > tcpdump -i eth1 ip proto icmp
> > or
> > tcpdump -i eth1 ip proto 1
> >
> > This will show you all packets received by the firewall on interface eth1
> > (the LAN-side of the firewall) whose ip protocol type is ICMP (what ping
> > uses). If you see echo-request packets from 192.168.1.2 then you know
> > that your internal machine's packets are getting to the firewall. If you
> > don't see echo-reply packets then you know the ping reply's aren't
> > coming out of the firewall and getting to your internal machine. What you
> > don't know is whether its the outgoing echo-request packets that aren't
> > getting out of the firewall and onto the internet in the first place or
> > its the returning echo-reply packets that aren't getting back through the
> > firewall to your internal machine. To find the answer, you need to see
> > what's happening on eth0 (the internet-side of the firewall). On the
> > firewall, run this command:
> >
> > tcpdump -i eth0 ip proto icmp
> > or
> > tcpdump -i eth0 ip proto 1
> >
> > tcpdump has a *LOT* of options that you can specify to allow you to focus
> > on only those packets which interest you. Check out its manpage.
> >
> > If you see no echo-request packets, then the firewall isn't allowing them
> > out of your internal network.
> >
> > If you see echo-request packets (you will also so echo-reply packets),
> > then the firewall isn't allowing the replies back into the internal LAN.
> >
> > There's another wrinkle to this that I haven't mentioned.
> >
> > Are your routing tables set up correctly? Your internal machines should
> > have the firewall's eth1 IP address set as their default gateway. You
> > mention above that this is already the case.
> >
> > The firewall should have your ISP's router set as its default gateway. If
> > it doesn't, then your firewall won't know what to do with the echo-
> > request packets it gets from the internal machine.
> >
> > I hope this helps.
> > --
> > Luca Filipozzi <[EMAIL PROTECTED]>
>
> YESYESYESYES!!!! IT worked!! THANK YOU so much! I typed in exactly
> what you have, except changing the numbers, and it worked --- for now.
> That is, until dhcp assigns me a new ip address. How do I get the dhcp
> server to reassign the values in the ipfwadm tables when I get a new ip?
>
> Honestly, I think this explanation should go into the firewall howto, or
> into a mini-howto or something.
>
> ms
>
That's great that you got it working. Maybe I'll contact the LDP and see
if they want another mini-HOWTO. Thanks.
You can configure your DHCP client (dhcpcd) to to run a shell script when
it successfully gets an IP address (dhcpcd has a command line option for
this: "-c filename").
The following environment variables (amongst others) are set and passed
to the shell script: HOSTNAME, ROUTER, IPADDR, NETMASK and BROADCAST.
So, if you have all the stuff for ipfwadm in a shell script file called
/etc/init.d/rc.firewall, say, then you can start the DHCP client daemon
as follows:
dhcpcd -c /etc/init.d/rc.firewall
You'll want to make this change in whatever startup script starts up
dhcpcd. Since I don't use RedHat, I don't know where that might be. Under
Debian Linux, it's /etc/init.d/dhcpc.
This shell script, rc.firewall, will have to be modified a little bit
from what we have already. You need to use $IPADDR and $NETMASK in place
of the values you have specified statically.
So, instead of this...
# permit cable modem traffic into and out of the firewall
ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0
do this
# permit cable modem traffic into and out of the firewall
ipfwadm -I -a accept -S 0.0.0.0/0 -D $IPADDR/32 -W eth0
ipfwadm -O -a accept -S $IPADDR/32 -D 0.0.0.0/0 -W eth0
The daemon, dhcpcd, takes care of setting up the routing table. You just
have to take care of the firewall (as above) and port forwarding rules
(not described).
By the way, you could just use the subnet instead of the assigned ip
address. Since you will always be assigned a number from within the same
subnet, if you know the subnet network and netmask numbers you can just
do this
ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.0/24 -W eth0
ipfwadm -O -a accept -S 24.xxx.yyy.0/25 -D 0.0.0.0/0 -W eth0
Note that the numbers I have used above assume a full class-C
subnet (i.e., with a netmask of 255.255.255.0) but that your subnet might
be have a different netmask (like 255.255.252.0 or something). This means
that you can't use /24 (8+8+8+0) but would need to use /22 (8+8+6+0).
That way, you wouldn't have to set up dhcpcd to run rc.firewall everytime
it got a new ip address. This is true for ipfwadm, at least. If you are
using port forwarding, like ipportfw or ipautofw, then you will have to
use the -c option of dhcpcd since you will want to use the IPADDR
environment variable to change the port forwarding commands.
Glad to have been of help.
--
Luca Filipozzi <[EMAIL PROTECTED]>
------------------------------
From: Michael Schwager <[EMAIL PROTECTED]>
Subject: Re: Newbie help with dynamic IP ethernet connection to ADSL server
Date: Sun, 17 Jan 1999 22:47:53 -0800
Philip Edwards wrote:
>
> I need help with setting up a dynamic IP ethernet connection to ADSL
> server. I have read several HOWTO's without much success. I presently
> have 3 other windows systems connceted through a 10baseT hub. They are
> all working fine. The service providers claim that they do not support
> linux connections. However, I have spoken to a couple of technicians who
> claim that it has been done although they themselves do not kow how.
>
> Any help you can provide is appreciated.
>
> philip edwards
I have the same setup with adsl. The only way I've been able to get it
to work is to use netcfg, which is an x-based configuration utility.
Basically you add your hostname and other hosts on your network in the
first panel, then add your ethernet cards in the interfaces panel. With
your dsl-connected ethernet you select dhcp as a configuration protocol
and leave the rest blank. For the LAN-connected ethernet you type in
all the information. After saving, this will write/configure a script
for you in /etc/sysconfic/network-scripts and leave a sort of
configuration file in /etc/sysconfig/network. Clicking on active is the
same as typing ifup ethx at the command line, and THAT is how _I_ get
dhcp to work. Frankly, I've tried typing the same thing that the script
types at the command line, and it just doesn't work. So use the script
that comes with the system. BTW, I'm using rh5.1.
Hope this helps
ms
------------------------------
From: Malware <[EMAIL PROTECTED]>
Subject: Re: SOCK_PACKET, etc.
Date: Mon, 18 Jan 1999 07:21:25 +0100
Hi Chas,
you wrote:
> like to send directly to the card, as well, and I presume this is possible
> with the same socket that one may recv on. Does anyone know how to fill out
> the address structure to pass to recv or recvfrom?
Yes it is possible using such a socket. You have to fill sa_data with
the name of interface to send out/receive from.
> More generally, are there other low-level, direct ways to do this (such as
> writing to an appropriate special file)? I have not yet found the source
Yes, e.g. there is the ethertap-Device.
> code for the driver (tulip) in my RH5.2 installation, if that is even
> available in the source somewhere, but I guess that would reveal how to do
> it at lowest level.
The source of the driver should be located in
/usr/src/linux/drivers/net/tulip.c. But it won't tell you the lot of how
to access it from user-space. The API's therefore are on higher levels.
Malware
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************
