Linux-Networking Digest #110, Volume #12 Wed, 4 Aug 99 16:13:32 EDT
Contents:
Re: Networking with linux (Roy Grimm)
Cobalt Qube 2 Windows file sharing partial failure (updated, but still no solution)
(LONG) (Lucius Chiaraviglio)
Re: PPP Server Problem - no "outside" IP access (Clifford Kite)
IP Masquerading - Logging ("Roman Kellner")
Fun with mail ("netaxs")
Re: dhcpc files ("Robert Glover")
Re: Request-Route <zombie> ("Robert Glover")
Re: /usr/bin/smbclient -L ......command (WChan21438)
NMBD Daemon not starting up. (Red Hat 6.0 package) (The Roberts)
nwpasswd question (root)
PPP (Dial-out) connection requirements ([EMAIL PROTECTED])
Re: Changing nic settings (Brian J. Ackermann)
----------------------------------------------------------------------------
From: Roy Grimm <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,redhat.networking.general
Subject: Re: Networking with linux
Date: Wed, 04 Aug 1999 11:12:04 -0500
Dave Cotterill wrote:
>
> I'm currently managing a small 10mbps bus network and have recently been
> given the task of upgrading a section of it to 100mbps star network. All
> machines must still be able to communicate with each other and I am
> therefore looking for help on the subject. The best method I could come
> up with due to lack of hubs allowing a 10mbps BNC bus network to be
> connected to them is to use a linux machine with a 100mbps and a 10mbps
> card to forward all networking data to/from. While installing a 100mbps
> hub for the upgraded machines.
>
> a) would this work?
Yes it would work.
> a2) if so how would I setup the linux box?
Configure the two network cards (10 and 100 mbps) in the linux system,
and adjust the routing setup if needed. The two most helpfull documents
will be the Ethernet HOWTO and Networking Overview HOWTO. You can find
them online at http://www.linux.org/help/howto.html.
> b) Any better ideas of experiences would be greatly appreciated.
Since you say you already have a linux system set up for routing between
a dial on demand ISDN connection, adding another network card and
updating the routing would be the course I would take.
Alternatively, you could find a 10Mbps hub with a 10Base2 connector and
a 10/100 ethernet switch and connect them to each other via a 10BaseT
connection. But, that would load up the 10Mbps segment with all your
internet traffic from the 100Mbps side. But, since ISDN can only do
128Kbps or so max in dual channel mode, that shouldn't be too much of an
issue...
> Thanks for any information
>
> PS: The network is completely internal and the linux box currently is set
> up with IP Masqurading for internet access with an ISDN modem so that the
> windows boxes can access the net on demand.
Best of luck to you,
Roy
--
"If it ain't broke, you're not tryin!" - Red Green
------------------------------
From: [EMAIL PROTECTED] (Lucius Chiaraviglio)
Crossposted-To: comp.os.ms-windows.nt.admin.networking,comp.protocols.smb
Subject: Cobalt Qube 2 Windows file sharing partial failure (updated, but still no
solution) (LONG)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 04 Aug 1999 18:44:11 GMT
I am definitely a linux newbie and only sort of expert with
Windows NT, but I have run into a stumper that still has the Cobalt
Networks technical support people stumped (and they've been working on
this for several days, with over a week inserted in the middle for
both them and me to think about it). Previously determined
information is first in this message, followed by new information.
Previously determined information (mostly -- new items have a *)
================================================================
At the places I work -- San Luis Obispo, CA and
Emeryville, CA -- we have a Cobalt Qube 2 at each site acting as a
web/ftp/e-mail/file/DNS/DHCP/WINS server and network address
translator, with several Windows NT 4.0 clients (and in the case
of San Luis Obispo, also Windows 95 and Windows 98 clients). The
problem we are having is that when I try to do the following at our
San Luis Obispo site, it always gives the error message "incorrect
password or unknown username for:" / {Qube 2 network name}, even
though I just put in my correct user name and password. I can confirm
that my user name nd password are correct because I am able to use FTP
to get to my files. In contrast, if I log in as "admin" with the
appropriate password, I can get to "admin"-accessible files without a
hitch. Not only that, but at our Emeryville site, I have no such
problem with user files either. It makes no difference what my
Windows NT user name and password are. The same thing happens with
Windows NT 4.0 SP3, SP4, and SP5, and with Windows 95 SP1 (with the
difference that the Windows 95 user name has to be the same as the
Qube user name, because when attempting to access a shared volume, it
only asks for a password, and not a user name). I checked all of the
Qube 2 services in the web-based configuration interface to confirm
that nothing was left out of or set incorrectly set in the
configuration for Windows file sharing, FTP, DNS, and DHCP -- if
something is incorrectly set for one of these services, it must be set
in a part of a configuration file that does not show up in the
web-based interface. I also manually looked inside of /etc/smb.conf,
and although I am not familiar with what does what in this file, I
didn't notice anything obviously strange when comparing these files
from the two systems; however, I don't think it is anything in here,
because the only difference between the files (according to diff) is
the line which specifies the workgroup/domain for the Cobalt Qube 2).
I didn't experiment with manually editing any configuration files,
because this might void the Cobalt warranty, and I am not sufficiently
familiar with linux to know what is safe to edit and what isn't.
To summarize:
Case 1:
1. Log in on Windows NT 4.0 (SP3 -- I may have also tried this
on a machine with SP4, but I'm not sure) in our Emeryville
office.
2. Double-click Network Neighborhood.
3. Navigate until the Cobalt Qube 2 is shown; double-click on it.
4. Enter any valid Cobalt Qube 2 user name (except "root", which
is specifically forbidden) and password combination.
Result: It works -- the files for the user you selected are now
accessible just as if they were on a Windows NT file server.
Case 2:
1. Log in on Windows NT 4.0 (SP3, SP4, or SP5) or Windows 95 SP1
in our San Luis Obispo office. If logging in on Windows 95,
log in as "admin".
2. Double-click Network Neighborhood.
3. Navigate until the Cobalt Qube 2 is shown; double-click on it.
4. Enter "admin" and the Cobalt Qube 2 password for this account
(Windows 95 does not give the opportunity to enter the user
name).
Result: It works -- the files accessible to the "admin" account are
now accessible just as if they were on a Windows NT file
server.
Case 3:
1. Log in on Windows NT 4.0 (SP3, SP4, or SP5) or Windows 95 SP1
in our San Luis Obispo office. If logging in on Windows 95,
log in as a valid Cobalt Qube 2 user other than "admin".
2. Double-click Network Neighborhood.
3. Navigate until the Cobalt Qube 2 is shown; double-click on it.
4. Enter any valid Cobalt Qube 2 user name except "root" or
"admin", and the appropriate password (if using Windows 95,
enter only the password for the Cobalt Qube 2 user name you
used to log into Windows 95).
Result: It never works -- it always claims the user name and password
are incorrect.
Variations I have tried (under Windows NT 4.0 SP4 at our San
Luis Obispo office), with absolutely no effect:
A. Make a Windows NT account with the same name and password as
the Cobalt Qube 2 account.
B. Change the Windows NT machine's workgroup to be the same as
the workgroup/domain that the Cobalt Qube 2 is in.
C. Different Windows NT 4.0 service packs as noted above (not on
the same computer).
D. Different computers with the same Windows NT 4.0 service pack.
E. Change what (if any) accounts are permitted telnet access into
the Cobalt Qube 2.
*F. Change a San Luis Obispo office Windows NT machine's name to
be the same as the unix user name (except for the case -- it
won't let me make it lower case).
*G. Enable plain text password negotiation on a San Luis Obispo
office Windows NT machine -- not acceptable for long-term
use, but it didn't even help in the short run.
I also confirmed that every Windows 95/NT computer I used is
capable of correctly accessing files on a Windows NT 4.0 SP3 server.
On the subset of these computers that I also tried pinging the Cobalt
Qube 2 or accessing it via FTP, ping and FTP also work correctly.
Our networks are configured very similarly, with the following
differences:
1. The domain/workgroup names are different.
2. The outside IP addresses (on the secondary ethernet interfaces
of the Cobalt Qube 2's) are different.
3. The Emeryville office only has 1 Windows NT workgroup, whereas
the San Luis Obispo office has multiple Windows NT workgroups.
4. The Emeryville office has its connection to the outside world
(from the secondary ethernet port of the Cobalt Qube 2)
through an Alcatel DSL 1000 "modem" over DSL service provided
by Pacific Bell; the San Luis Obispo office has its connection
to the outside world (also from the secondary ethernet port of
the Cobalt Qube 2) via an ethernet cable to a hub and/or
router in the office of our local ISP next door.
5. Something unknown in the configuration of the Emeryville
office connection to the outside world causes a reverse DNS
lookup by a remote site to return a CNAME record instead of a
PTR record (according to the sysadmin of the remote site) --
see my accompanying post (about resulting problem) only in
comp.os.linux.networking.
*6. In the Emeryville office, the Windows NT machines have the
same name (except for case) as the unix user name of the
person who normally uses it. On the other hand, this doesn't
seem to make a difference (see F above).
7. The Cobalt Qube 2's differ very slightly as detailed below.
The Cobalt Qube 2 in our Emeryville office (on which things
seem to work properly) is configured with the following software:
Cobalt OS Release 4.0 (original install)
Cobalt Qube2 Update Release 1.0 (original install)
Shell History Patch Release 1.1 (original install)
"RUNNING MFG TESTS" minor bug (original install -- a patch is
available, but not installed here)
The Cobalt Qube 2 in our San Luis Obispo office (on which
Windows file sharing doesn't work right) is configured with the
following software:
Cobalt OS Release 4.0 (original install)
Cobalt Qube2 Update Release 1.0 (added as patch from manufacturer)
Shell History Patch Release 1.1 (added as patch from manufacturer)
Doesn't have "RUNNING MFG TESTS" bug
Note: Cobalt OS 4.0 on the Cobalt Qube 2 identifies itself (before it
gives the login prompt) as "Cobalt Linux release 4.0 (Fargo)" /
"Kernel 2.0.34 on a mips".
New information
===============
Our /etc/smb.conf as it came from the manufacturer (including
the incorrect server string) follows. Note that the Emeryville and
San Luis Obispo versions are identical except for the workgroup name.
[BEGIN /etc/smb.conf]
; Samba Configuration
; Revision 1.0 for the 2700RJ, [EMAIL PROTECTED] 17.oct.98
;
; DO NOT USE THE \ CONTINUATION! THE QUBE PARSING CODE WILL CHOKE ON
IT!
;
[global]
alternate permissions = no
case sensitive = no
dead time = 5
debug level = 0
default case = upper
delete readonly = yes
delete veto files = yes
dns proxy = no
domain logons = yes
domain master = no
encrypt passwords = yes
follow symlinks = yes
guest account = ftp
local master = yes
lock directory = /var/lock/samba
locking = yes
log file = /var/log/samba
mangle case = no
map hidden = yes
map system = yes
max log size = 5000
oplocks = yes
os level = 1
preferred master = yes
preserve case = yes
security = user
server string = Cobalt Qube 2800WG
share modes = yes
short preserve case = yes
socket options = TCP_NODELAY
strict locking = yes
veto files = /Network Trash Folder/
wide links = yes
wins support = yes
workgroup = acmppi
;
[homes]
comment = Home Directories
browseable = no
read only = no
create mask = 0755
;
;home BEGIN (do not delete this line)
[home]
path = /home/groups/home
public = no
browseable = yes
writable = yes
printable = no
create mask = 0775
valid users = admin @home
force create mode = 0664
force directory mode = 0775
hide dot files = yes
;home END (do not delete this line)
;allusers BEGIN (do not delete this line)
[allusers]
path = /home/groups/allusers
public = no
browseable = yes
writable = yes
printable = no
create mask = 0775
valid users = admin @allusers
force create mode = 0664
force directory mode = 0775
hide dot files = yes
;allusers END (do not delete this line)
[END /etc/smb.conf]
Note: The Samba version included in Cobalt OS 4.0 is a release of
1.9.18p10 (according to the included man pages and according to the
help information printed by smbd when called with incorrect command-
line parameters) that apparently does not come with smbfs (even
though the man pages mention it).
I have tried changing the security setting to SHARE and making
homes browseable (both with and without also making homes have user
only and user = %S). If I try it this way, the user "admin" is no
longer able to access any shares formerly accessible to "admin"; a
"homes" share shows up in the Windows NT Network Neighborhood, but
attempting to access it either fails with "incorrect password or
unknown username" (if user only and user = %S are set) or gives an
error message "The network name could not be found" without even
giving an opportunity to enter a user name or password. I have also
tried setting debug level to 3 or 10 (both with and without setting
password chat debug) and looking for error messages in /var/log/samba,
but this doesn't give me any information deeper than "NT password
incorrect" error messages (even with password chat debug set, it won't
show the value or encrypted value it thinks it got for the password --
note that encrypt passwords is set in /etc/smb.conf).
I did always perform a "kill -HUP" on all smbd processes after
saving changes to /etc/smb.conf (but for some reason, changing the
server string to "Cobalt Qube 2 %h" seems to have no effect).
I should note that even though "server appliances" such as the
Cobalt Qube 2 are supposed to just work when you plug them in with
minimal setup, this has not been the case (this problem isn't the only
problem that has driven me to call tech support, just the first one to
get them stumped too). It is driving me up the wall, because I am
completely out of ideas as to what could be wrong.
On a somewhat related note: something in Cobalt OS 4.0 leaves
around plain text password files (found by searching the entire hard
disk for a couple of passwords). All such files that I found seem to
be related to AppleTalk (even though this is not turned on on this
machine), and they are all set to have permissions 0600, but this is
still not good.
Lucius Chiaraviglio | [EMAIL PROTECTED]
========
To reply to this message, remove the "not at" characters from in front of the
abbreviation of the company name (Advanced CMP Products, Inc.). If you are
seeing this in an e-mail message, it is because I am posting it and e-mailing
it at the same time -- normal e-mail messages from me do not have this feature.
Note: I am trying a new news server -- it seems to work well, but it has a
very short expiration time (1 week for most groups), so I will likely miss your
reply unless you send it by e-mail in addition to posting it.
------------------------------
From: kite@NoSpam.%inetport.com (Clifford Kite)
Subject: Re: PPP Server Problem - no "outside" IP access
Date: 4 Aug 1999 10:32:28 -0500
root ([EMAIL PROTECTED]) wrote:
: I am trying to setup a PPP server on my Linux (2.2) machine to allow me
: to dial-in and use the internet.
: I am using mgetty to enable dial-in. I am using the AutoPPP option to
: start pppd when the modem connects. That all seems to work fine.
: However, I can only ping the PPP server, but NOTHING else.
: I have the proxyarp option set in /etc/ppp/options, so I think it should
: be proxying IP addresses for the ppp0 device.
You need to turn on proxy arp in teh 2.2.x kernel series with
echo -n 1 > /proc/sys/net/ipv4/conf/ppp0/proxy_arp
and turn on IP forwarding with
echo -n 1 > /proc/sys/net/ipv4/ip_forward
This needs to be done at every boot up.
You also need for the IP address that the dial-in uses to belong to the
LAN for the mgetty machine.
--
Clifford Kite <kite@inet%port.com> Not a guru. (tm)
/* To extract lines: View file with "vi -R". Move cursor to first line.
Press "v". Move cursor to mark lines (Esc unmarks). Write lines to
fubar with ":w fubar <Enter>". Exit with ":q <Enter>". */
------------------------------
From: "Roman Kellner" <[EMAIL PROTECTED]>
Subject: IP Masquerading - Logging
Date: Wed, 4 Aug 1999 19:07:24 +0200
We are running different PC's (Linux, Win??) using IP Masquerading to
connect over one gateway(diald and pppd) to the Internet.
Is there an easy way (script, tool) to log (graphics?) the Internet IP
traffic caused by the different stations?
I guess this should be quite simple thinking of the facilities of Linux, but
I'm not sure where to start.
Thanks in advance
Roman
------------------------------
From: "netaxs" <[EMAIL PROTECTED]>
Subject: Fun with mail
Date: Wed, 4 Aug 1999 14:59:35 -0400
I have a linux box set up with IP masquerading to serve an ADSL connection
to a local network. I have a dns set up to provide a cacheing nameserver to
the workstations on the internal network. I also DO NOT have a registered
domain name. There are a few things I was wondering how to do.
1. Set up mail accounts for all the local network users.(internal network
e-mail) (Do I have to use sendmail for this?)
2. Have the administrators of the linux box get the e-mail from the isp.
3. Possibly masquerade the network e-mail addresses into the isp mail
giving the network users their own internet e-mail addresses through one isp
connection.
Any help, comments or suggestions would be greatly appreciated.
--
Jason Schadel
home: [EMAIL PROTECTED]
work: [EMAIL PROTECTED]
------------------------------
From: "Robert Glover" <rglover@air(dot)ups(dot)com>
Subject: Re: dhcpc files
Date: Wed, 4 Aug 1999 18:04:24 -0000
I created the directory. dhcpcd created the cache and info files for
me.
Matt Menze wrote in message <[EMAIL PROTECTED]>...
I installed the dhcpcd package from the RH6.0 cd and to my surprise
the
files:
/etc/dhcpc/dhcpcd-eth0.info
/etc/dhcpc/dhcpcd-eth0.exe
/etc/dhcpc/dhcpcd-eth0.cache
were not there. Do I have to create these?
------------------------------
From: "Robert Glover" <rglover@air(dot)ups(dot)com>
Subject: Re: Request-Route <zombie>
Date: Wed, 4 Aug 1999 18:24:58 -0000
I believe the kernel calls a script named /sbin/request-route (if it
exists) whenever it tries to deliver a packet for which there is no
route. You might look there.
Roger Plant wrote in message <37a61ee9.798777@linuxXpc>...
Hi all,
I am running Slackware, with kernel 2.0.34
With a nameserver entry to my ISP in resolv.conf.
Normally (Shortly after rebooting the system), if I try to ping a host
that is not connected ( When PPP is down)
eg. ping ftp.microsoft.com
I get back immediately a message saying the host is unreachable,
without even bothering to attempt to send a DNS request.
However the System seems to always eventually get confused, and tries
to send DNS requests, even when PPP is down!
These cause problems, especially with sendmail.
And Telnet, (If the host isn't in its /etc/hosts database)
The problems seem to occur after an entry of "Request-Route <zombie>"
occurs in the process table. I am not sure where this comes from, and
I dont seem to be able to get rid of it, without restarting the
machine.
Does anyone have any suggestions as to why this is occuring, and how
to fix it after it has?
TIA
Roger
===========================================================
Roger Plant :-) Email: [EMAIL PROTECTED]
===========================================================
------------------------------
From: [EMAIL PROTECTED] (WChan21438)
Subject: Re: /usr/bin/smbclient -L ......command
Date: 04 Aug 1999 19:12:06 GMT
Yes, the hostname should be under the server and. However the Master column
maight be missing.
------------------------------
Date: Wed, 04 Aug 1999 12:45:40 -0700
From: The Roberts <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: NMBD Daemon not starting up. (Red Hat 6.0 package)
This is a multi-part message in MIME format.
==============6AFB01E385D249507BE6F2B3
Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
I have just installed Red Hat 6.0 on a 486 with 8 Mb ram and a 211Mb
hadrdrive. I obviously had to install the bare mininum, but I can't
seen to get the NMBd daemon up and running on startup. The Eth0 is
detected, and the SMB daemon comes up fine, but not NMBD. Can anyone
offer me a possible cause to this problem and point me to a solution?
==============6AFB01E385D249507BE6F2B3
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for The Roberts
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: The Roberts
n: Roberts;The
email;internet: [EMAIL PROTECTED]
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
end: vcard
==============6AFB01E385D249507BE6F2B3==
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: nwpasswd question
Date: Wed, 04 Aug 1999 15:53:59 -0400
Ok, Basically, I've got a Netware 4.11 server, and I'm playing around
with trying to change Netware passwords using NCPFS and the nwpasswd
command. According to all the man page and documentation and source
code I've examined, it should work. However, any time I try to change a
password using the NDS name (username and context) I get an error:
nwpasswd: NCP Request returned error code trying to change password
That's using just the -U option. If I also try to use the -O option I
get an additional error:
nwpasswd: NCP Request returned error code not own password
I've tried using my own account (with administrator equivalence) or the
admin account with no luck. Anyone have any ideas? I know NDS is
supposed to still be fairly new in NCPFS so am I just asking too much at
the moment?
Any comments are appreciated.
Jim
------------------------------
From: [EMAIL PROTECTED]
Subject: PPP (Dial-out) connection requirements
Date: Wed, 04 Aug 1999 19:45:56 GMT
Hi All,
I have to set up my PPP such that :
(i) It doesn't disconnect if the connection is Idle
(ii) It automatically reconnects if my ISP drops the connection. Even if
it means multiple reconnection attempts [maybe - with predefined breaks]
Or in other words I want my m/c to be connected to the internet all the
time 24x7.
What all PPP options do I use ?
will the 'persist' option lead to automatic execution of the chatscript
when the connection drops ?
Any Sample script ?
TIA
Rajeev
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Brian J. Ackermann <[EMAIL PROTECTED]>
Subject: Re: Changing nic settings
Date: Wed, 04 Aug 1999 19:49:58 GMT
In article <[EMAIL PROTECTED]>,
Oliver Nelson <[EMAIL PROTECTED]> wrote:
> To anyone who might respond <g>,
>
> How do I change the settings on my nic (such as half or full duplex,
etc.)? I'm having
> weird speed problems with my linux box sending data slow. It seems to
receive ok though.
> This is the case with both telnet and samba. I think maybe it has
something to do with
> the nic settings, but I don't know how to change them.
>
> Thanx,
>
> OLIVER
>
Oliver, some cards, such as 3Com's cards come with a DOS based program
that can modify these config settings...
Brian
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
