Linux-Networking Digest #144, Volume #10 Mon, 8 Feb 99 06:13:27 EST
Contents:
Re: PPP problems under 2.2.1 (J. Scott Berg)
cablemodem/ethernet woes (Mike Marsman)
Re: 10/100 Ethernet SWITCH (to be used for Fast Ethernet LAN, and (MikeF)
Re: will virus affect? (Todd Knarr)
Re: Netcom & Linux PPP ("Rob")
2.2.1 IPIP tunnel works differently? Documentation available? (Miguel Cruz)
Re: sendmail-config vs. sendmail RPMS? (Villy Kruse)
Linux - Null Modem - NT4.0. How? ([EMAIL PROTECTED])
Re: NFS Install help needed. (eckardt)
Re: Linux server on small network (Robin Bowes)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (J. Scott Berg)
Subject: Re: PPP problems under 2.2.1
Date: 8 Feb 1999 04:24:50 GMT
In article <79igsk$[EMAIL PROTECTED]>,
Clifford Kite <[EMAIL PROTECTED]> wrote:
>J. Scott Berg ([EMAIL PROTECTED]) wrote:
>
>: My problems all consist of seemingly random disconnects. Here are
>: some of the things I've run into:
>
>: 1) I couldn't send large files to my ISP's mail server. The problem
>: seems to be that their initial ppp negotiation allows a mtu of 1524;
>: if I just go with that (don't set the mtu in my config files) the
>: large packet would hang. Presumably a bad router between me and my
>: ISP's mail server (but one has to question the intelligence of having
>: the ppp connection ask for an mtu of 1524 and then not being able to
>: have that mtu get through to your own mail servers). Fix: use an mtu
>: of 1500. Somebody in this group suggested this might really be a
>: kernel problem. I don't know enough to say yea or nay.
>
>Hmm. The default mtu for pppd is 1500. I don't know why explicitly
>setting this to 1500 would fix the problem - perhaps there _is_ a bug.
>Even if the ISP requests an mru of 1524 pppd should not try to send
>more than the default.
The docs certainly seem to imply that there's that default. But it
doesn't seem to work that way. I've attached to the end of this the
results of not setting an mtu or an mru in my /etc/ppp/options (this
is kernel 2.2.1, ppp-2.3.5), and running with debug and kdebug 1.
Note the "ppp_ioctl: set mru to 5dc" (that's 1500) in the debug
output, but the mtu is clearly set to 1524. Note that my end never
sends an mru over. By the way, here's another mystery: my command
line (below) tells it to do dynamic addresses for both ends; this is
not changed in any of the option files. So why in the LCP negotiation
does it request the 192.168.1.2 address (which corresponds to a dummy
interface that I have whose sole purpose is to prevent emacs from
trying to do a dns lookup when there's no nameserver running; it's
what my hostname resolves to from /etc/hosts)?
/usr/sbin/pppd call Earthlink /dev/ttyS1 115200\
0.0.0.0:0.0.0.0 connect /usr/sbin/ppp-on-dialer
>The mru is a request to the peer not to send more than the specified
>number of bytes in data packets. There may be a problem here too since
>the default is 1500 bytes according to the man pages and ppp-2.3.5 won't
>request the default value, *even if the mru is explicitly set to 1500*.
>And it is always risky to make the assumption that the other side will
>use an mtu of 1500 or less. The 1500 byte default may be based on a
>buffer limit and so also be the maximum mru for linux ppp. In this
>case pppd *should* request mtu 1500, especially if it is explicitly set.
It will request it if you set the mru to something different than
1500, but yes, it doesn't seem to bother if the mru is explicitly set
to 1500.
>: 2) At one time I was having SEVERE problems with random disconnects.
>: I would try to ftp a large file, and at one point in the file, the
>: connection would be dropped. I would reconnect, and at roughly (but
>: not exactly) the same point, the connection would drop again. The
>: fix: set up a firewall to only allow out packets with my currently
>: assigned IP. Apparently the dead connections (even after I quit the
>: programs with the dead connections) were still trying to send out
>: packets to finally close out the connection. The disconnect wouldn't
>: consistently happen at the first packet with the wrong address, so I
>: can't attribute it to that problem directly. However, the firewall
>: eliminated the bulk of these random disconnects.
>
>I'd bet that the dropped connections are likely caused by something
>other than the Linux ppp - although this opinion is based mostly on
>the use of ppp-2.2.0 rather than 2.3.5.
It wouldn't surprise me, but what? If it were an intentional act of
my ISP, I would see an immediate drop of the connection when the first
packet tries to go through with the wrong address. But that doesn't
appear to be the case. So somewhere in the chain there's some flaky
software; the Linux end can't be ruled out as far as I can see.
> I *think* the attempts to close out a dropped connection are normal.
I think they are as well. It would be nice if the kernel said "gee,
the interface associated with that address is gone. Maybe I should
just skip all the closeout stuff, since it won't get anywhere anyhow."
I'm sure there's a reason why this wouldn't work, but I haven't the
foggiest what it is. While my firewall solution works (prevents the
connection drops), it's always a bit confusing looking at netstat and
trying to figure out which connections are from my current address and
which are from previously assigned addresses (from a long time ago!).
>: 3) If a program tries to send packets too early in the connection
>: process, the connection seems to get dropped. I'm not sure how to
>: define "too early," but if ifconfig isn't showing ppp0, then I believe
>: that is "too early." It seems like this one has to be the kernel or
>: pppd.
>
>That seems logical and normal, if the ppp interface is not up when the
>connection attempt is made then no ppp connection is possible.
Sorry for the confusion, I'm referring to the connection to the ISP,
not the TCP/IP connection. Yes, I would expect the TCP/IP connection
to time out or something, but I wouldn't expect this to cause the
ppp connection to get dropped completely. But that's what seems to
happen.
>: 5) I STILL get some random disconnects. I've even set my modem (or at
>: least I think I have: getting comprehensive documentation for modem
>: commands is also a never ending battle) NEVER to hang up on carrier
>: loss or go into command mode based on '+++'. They're not from
>: timeouts at my ISP's end: this happens in the middle of a file
>: transfer sometimes.
>
>I would be surprised at a ppp bug that caused problems in maintaining
>established ppp connections.
I assume this is referring to point 5. I would be naturally inclined
to say that as well. However, I seem to be getting behavior where
there is a direct connection to maintaining the ppp connection and the
precise TCP/IP traffic that I'm sending or attempting to send. How
this could happen I really don't know: I haven't dug into the
pppd/kernel sources, and it would probably take me a while to come up
to speed. I definitely don't have enought to say: "there's a bug."
Of course, there's a bug somewhere, but whether that is at the Linux
end or not is unclear.
It would be interesting to hear if anyone else experiences these same
kinds of problems.
-Scott Berg
ifconfig output:
ppp0 Link encap:Point-to-Point Protocol
inet addr:153.35.214.36 P-t-P:206.115.157.73 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
syslog messages (except debug level):
Feb 7 22:04:13 pppd: sent [LCP ConfReq id=0x1 <magic 0x9a468a46> <pcomp> <accomp>]
Feb 7 22:04:13 kernel: ppp: tossing frame (e0)
Feb 7 22:04:13 pppd: rcvd [LCP ConfReq id=0x1 < 00 04 00 00> <mru 1524> <asyncmap
0xa0000> <auth chap 05> <pcomp> <accomp> < 11 04 05 f4> < 13 09 03 00 c0 7b 72 d0 f5>]
Feb 7 22:04:13 pppd: sent [LCP ConfRej id=0x1 < 00 04 00 00> < 11 04 05 f4> < 13 09
03 00 c0 7b 72 d0 f5>]
Feb 7 22:04:13 pppd: rcvd [LCP ConfAck id=0x1 <magic 0x9a468a46> <pcomp> <accomp>]
Feb 7 22:04:13 pppd: rcvd [LCP ConfReq id=0x2 <mru 1524> <asyncmap 0xa0000> <auth
chap 05> <pcomp> <accomp>]
Feb 7 22:04:13 pppd: sent [LCP ConfAck id=0x2 <mru 1524> <asyncmap 0xa0000> <auth
chap 05> <pcomp> <accomp>]
Feb 7 22:04:13 pppd: rcvd [CHAP Challenge id=0x1 <xxx>, name = "xxx"]
Feb 7 22:04:13 pppd: sent [CHAP Response id=0x1 <xxx>, name = "xxx"]
Feb 7 22:04:14 pppd: rcvd [CHAP Success id=0x1 "\030Welcome to the EarthLink"]
Feb 7 22:04:14 kernel: ppp_proto_ccp rcvd=0 code=1 flags=f010043
Feb 7 22:04:14 pppd: sent [IPCP ConfReq id=0x1 <addr 192.168.1.2> <compress VJ 0f 01>]
Feb 7 22:04:14 pppd: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1
15>]
Feb 7 22:04:14 pppd: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr
206.115.157.73>]
Feb 7 22:04:14 pppd: sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr
206.115.157.73>]
Feb 7 22:04:14 pppd: rcvd [IPCP ConfNak id=0x1 <addr 153.35.214.36>]
Feb 7 22:04:14 pppd: sent [IPCP ConfReq id=0x2 <addr 153.35.214.36> <compress VJ 0f
01>]
Feb 7 22:04:14 pppd: rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a 04 78 00 18 04 78
00 15 03 2f]
Feb 7 22:04:14 kernel: ppp0: ccp closed
Feb 7 22:04:14 pppd: rcvd [IPCP ConfAck id=0x2 <addr 153.35.214.36> <compress VJ 0f
01>]
Feb 7 22:04:14 kernel: ppp: set np 0 to 0
syslog messages, debug level:
Feb 7 22:03:43 pppd: pppd 2.3.5 started
Feb 7 22:04:12 pppd: Serial connection established.
Feb 7 22:04:13 kernel: ppp_ioctl: set dbg flags to 10000
Feb 7 22:04:13 kernel: ppp_ioctl: set flags to 10000
Feb 7 22:04:13 kernel: ppp_tty_ioctl: set xasyncmap
Feb 7 22:04:13 kernel: ppp_tty_ioctl: set xmit asyncmap ffffffff
Feb 7 22:04:13 kernel: ppp_ioctl: set flags to 10000
Feb 7 22:04:13 kernel: ppp_ioctl: set mru to 5dc
Feb 7 22:04:13 kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff
Feb 7 22:04:13 kernel: ppp_ioctl: set flags to 10000
Feb 7 22:04:13 pppd: Using interface ppp0
Feb 7 22:04:13 pppd: Connect: ppp0 <--> /dev/ttyS1
Feb 7 22:04:13 kernel: ppp_tty_ioctl: set xmit asyncmap a0000
Feb 7 22:04:13 kernel: ppp_ioctl: set flags to f010003
Feb 7 22:04:13 kernel: ppp_ioctl: set mru to 5dc
Feb 7 22:04:13 kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff
Feb 7 22:04:13 kernel: ppp_ioctl: set flags to f010003
Feb 7 22:04:14 kernel: ppp_ioctl: set flags to f010043
Feb 7 22:04:14 pppd: Remote message: ^XWelcome to the EarthLink
Feb 7 22:04:14 kernel: ppp_ioctl: set flags to f010003
Feb 7 22:04:14 kernel: ppp_ioctl: set maxcid to 16
Feb 7 22:04:14 kernel: ppp_ioctl: set flags to f010007
Feb 7 22:04:14 pppd: local IP address 153.35.214.36
Feb 7 22:04:14 pppd: remote IP address 206.115.157.73
------------------------------
From: Mike Marsman <[EMAIL PROTECTED]>
Subject: cablemodem/ethernet woes
Date: Mon, 8 Feb 1999 01:29:04 -0500
Hi all .. I could use some help..
I'm running debian 2.0 on a mahcine at home (w/ kernel 2.0.34), mainly for
the purpose of having a *stable* windows alternative, but i'm having some
problems, really with splitting my rogers@home cable connection..
I've got the box recognizing both cards (SMC's) and compiled the kernel
for a lean-mean machine -- but when i run ifconfig it tells me that my
base addresses are 0x250 and 0x310 even though the cards are jumpered to
0x240 and 0x300 respectively. The irq's are reported fine.
I've made sure that the first line of my lilo.conf file is:
append="ether=10,0x240,eth0 ether=11,0x300,eth1"
but to no avail.. is there anything specific that i can do to fix this? ..
or is my ifconfig reporting false info?
Also, if anyone knows of any sites dedicated to setting up multihoming on
debian, that'd be great too (i can never get enough info) .. or even good
sites talking about cablemodems all together..
Thanks for the help..
..Mike
--
reply to: <[EMAIL PROTECTED]>
A computer without COBOL and Fortran is like a piece of
chocolate cake without ketchup and mustard. -Anonymous-
--
------------------------------
From: MikeF <[EMAIL PROTECTED]>
Crossposted-To:
comp.dcom.lans.ethernet,linux.redhat.misc,linux.samba,comp.os.linux.hardware
Subject: Re: 10/100 Ethernet SWITCH (to be used for Fast Ethernet LAN, and
Date: Mon, 08 Feb 1999 06:32:08 GMT
Christian Aasland wrote:
>
> As stated, the switches are really expensive... not really sure a full switch
> is better than a hub for small networks, as switches only prevent collisions
> on busy nets.
>
I've found that just two nodes communicating, each trying to send at the same
time will really slow down a transfer. I haven't used a switch, it may be my
cheap ethernet cards on 486s, which it itself is most probably the cause of the
slowness. Another example... both comps have dlink tulip based nics p133 <->
pII300 the collision light is almost steadily on, but transfer goes about
900KB/s. This is with nothing else happening on ether comp or the network.
--
Mike Fedyk - [EMAIL PROTECTED]
Webmaster for The Flag Day Festival.
http://www.flagday.com
Debian - Linux . . . The Ultimate Windows NT service pack. :)
http://www.debian.org
"People want to have the computing equivalents of truck or heavy equipment
operators without even bothering to learn how those machines work."
/ / (_)__ __ ____ __ * Powerful * Flexible * Compatible * Reliable *
/ /__/ / _ \/ // /\ \/ / *Well Supported * Thousands of New Users Every Day*
/____/_/_//_/\_,_/ /_/\_\ The Cost Effective Choice - Linux Means Business!
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Subject: Re: will virus affect?
Date: 8 Feb 1999 07:04:56 GMT
[EMAIL PROTECTED] wrote:
> nope....
> Think about viris that write directly to Harddisks like fdisk..!!
Virus is running in user mode. User mode code is not permitted to
access device I/O registers. The process containing the virus will
be terminated by the kernel. End of virus.
Exception: virus is attached to a program that has permission to access
I/O registers ( usually because it's suid-root ). OTOH the virus is
likely to assume it's dealing with a FAT filesystem or DOS boot sector
or MBR, so you're more likely to get a corrupted MBR/bootsector/filesystem
than anything useful to the virus.
--
If you'll excuse me - I have fifteen things fighting for my attention, all
of them annoying.
-- Susan Ivanova
------------------------------
From: "Rob" <[EMAIL PROTECTED]>
Subject: Re: Netcom & Linux PPP
Date: Mon, 8 Feb 1999 01:12:10 -0500
im a dummy, i was using linuxconf to enter the name and password, and it
wasnt working, but if i manually edit the script it does :)
Rob wrote in message <79lb26$k62$[EMAIL PROTECTED]>...
>WTF is up with Netcom and PPP with Linux?
>
>In W95/98 DUN the netcom username is "#netcom_username"
>or you can use "us,ppp,netcom_username"
>
>Well this is fine in DUN, but when I try to connect my linux box to netcom
>the chat script fails. Propbaly because the # makes the netcom_username
>into a comment. I have no idea why the "us,ppp,netcom_username" fails, the
>log is below. I have no problem with my other provider, its simple and
>works, but I want to have the ability to switch between my 2 ISP's
depending
>on who has better (less) lag...
>
>Feb 7 18:42:01 bushwood chat[794]: alarm
>Feb 7 18:42:01 bushwood chat[794]: Failed
>Feb 7 18:42:01 bushwood pppd[791]: Connect script failed
>Feb 7 18:42:02 bushwood pppd[791]: Exit.
>
>
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Miguel Cruz)
Crossposted-To: comp.os.linux.development.system
Subject: 2.2.1 IPIP tunnel works differently? Documentation available?
Date: 8 Feb 1999 08:05:10 GMT
Is there any documentation of how the IPIP encapsulation (tunl0 device) is
supposed to work in 2.2.1? I can't get it to do anything to save my life. I
would prefer the most technical documentation possible short of having to
reacquaint myself with the source after years of blissful severance. Thanks
muchly.
miguel
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Crossposted-To: comp.os.linux.admin,comp.os.linux.setup,comp.os.linux.questions
Subject: Re: sendmail-config vs. sendmail RPMS?
Date: 8 Feb 1999 09:37:19 +0100
In article <7gSu2.548$[EMAIL PROTECTED]>,
Mitchell Maltenfort <[EMAIL PROTECTED]> wrote:
>
>
>However, the files it contains (list follows) conflict with those installed
>by sendmail.
>
>Do I stick it all in, using the --force option in rpm? Do I leave out
>sendmail-config? Why is there a sendmail-config anyway?
>
>Thanks in advance.
>
The standard redhat config files goes into /etc mainly the following files.
/etc/aliases
/etc/sendmail.cf
/etc/sendmail.cw
It appears the new rpm will put all the config files in /etc/mail and that
won't conflict. However, if you don't uninstall the original sendmail packages
you might get confused as to whether the aliases file is in /etc/aliases or
/etc/mail/aliases, and the same for sendmail.cw.
Villy
------------------------------
From: [EMAIL PROTECTED]
Subject: Linux - Null Modem - NT4.0. How?
Date: Mon, 08 Feb 1999 08:50:31 GMT
1) Can I set up my NT to use null modem connection to see Linux
directories as NT shares?
2) What are there the simplest programs to transfer files from NT to
linux over
null modem?
3) Any FAQ:s out there on these subjects?
Please respond by email.
[EMAIL PROTECTED]
------------------------------
From: eckardt <[EMAIL PROTECTED]>
Subject: Re: NFS Install help needed.
Date: Sun, 07 Feb 1999 23:44:00 +0100
Bassman wrote:
> I have a small network partially up and running.
>
> 1 P2 333 dual boot Win95 and RedHat 5.2.
>
> 4 workstations. 486dx2 33MHz, various amounts of RAM, Slakware 3.5
> 2 have 202 Mb HDD and CDROM, 2 Have 2x202MB HDD.
>
> All have 3com 3c509 NICS with PNP turned off ( all tested and work ok).
>
> IDE Controller has only 1 port. Therefore, I can only put either the disks
> or 1 HDD +cdrom on the PCs.
>
> The 2 machines with only 1 HDD have been configured using the CDROM and work
> perfectly. I have tested the network out and they are able to ping and
> telnet each
> other and the P2 machine.
>
> I thought I would be able to install RH5.2 onto the dual HDD machines via
> NFS installation. but get "permission denied" message.
>
> I wondered if this was to do with RH5.2 ( or my setup) and so tried from one
> of the 486's
> with Slakware, same message.
>
> It is obviously my error, what am I doing wrong?
>
> Can anyone help?
>
> Regards.
>
> Bassman
check this out on the nfs-server-machine:
- is the cdrom mounted?
- do you have an entry in the /etc/exports for your /cdrom to make it available
for the clients?
if not: add one like
/cdrom * (ro)
(see man-page for details) and restart nfs.
- change-into nad read-permission set to the mount-point?
good luck, eckardt
------------------------------
Date: Fri, 05 Feb 1999 09:22:28 +0000
From: Robin Bowes <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: uk.comp.os.linux
Subject: Re: Linux server on small network
[EMAIL PROTECTED] wrote:
>
> >the linux
> > machine sits across the other side of the room without a keyboard or
> > monitor.
>
> I am about to set up an old 586 to run Linux and I would like to do it without
> a monitor. How does one go about doing this? Boot up and remove the monitor?
> Hot swapping stuff is not my idea of doing things right but I saw an ace Unix
> sytem admin do just that with monitors on Unix boxes without any problem. Is
> this the way it's done? Don't mind leaving a $9 keyboard and mouse on it but a
> monitor is somewhat more precious.
?? Once you've got the box configured, just boot up without the
monitor.
R.
--
Two rules to success in life:
1. Don't tell people everything you know.
-- Sassan Tat
------------------------------
** 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
******************************
