Article View: comp.protocols.ppp
Article #125Re: dp-2.2-beta problems
From: Larry R. Ader
Date: Mon, 12 Oct 1992 09:14
Date: Mon, 12 Oct 1992 09:14
145 lines
6627 bytes
6627 bytes
(replying to my own posting:) Since I haven't heard from anyone regarding my problems with dp-2.2, and I have made considerable headway in getting the thing to work, I thought I'd followup on these problems, just so others of you who are just starting to install dp-2.2, won't have the same problems that I had... > I have recently installed dp-2.2-beta on my Sun ELC (SunOS4.1.2) and > have read through the DialupPPP.doc several times. I reconfigured the > kernel and added the appropriate /etc/dp files. I am slightly at a > loss as to what to add to /etc/hostname.dp0, so I didn't use it. Instead, > I added the line: > > ifconfig dp0 129.212.49.100 129.212.49.101 netmask + -trailers up > > to /etc/rc.boot. > > My machine (hostname = echidna) is a standalone machine (at home) and > as such, doesn't have an ethernet connection. In /etc, I only have > one hostname.??0 file, and that is hostname.xx0 with the contents: > echidna. > > In my /etc/hosts file, I have the following lines: > 127.0.0.1 echidna localhost loghost > 129.212.49.100 echidna-dp0 > 129.212.49.101 pecan-dp0 > > "pecan" is a Solbourne machine that I administer at work, with the > 129.212.49.* IP addresses assigned to its subdomain. This is the > machine that I intend to connect to, but first things first. > > After adding the above "ifconfig..." line to /etc/rc.boot, and then > rebooting, I see the following error messages (interspersed with normal > messages): > > keyserv: unable to register service > rpc.statd: unable to register (SM_PROG, SM_VERS, udp) > Oct 10 01:53:31 echidna inetd [117]: Cannot register service: RPC: Unable to send; errno = Host is unreachable > > I have no idea what I'm doing wrong... Does anybody out there have a clue? What I ended up doing to avoid the above boot-time messages is to move the "ifconfig", "/usr/etc/dpd", and the "/usr/etc/route" statement to the very end of the /etc/rc file. That way all of the daemons that complain above have already started and don't complain when I now add the new statements. Does this seem like a reasonable thing to do? Am I missing anything by doing this? > Ignoring the above errors, I manually invoke dpd using the following > command: > > /usr/etc/dpd -d 3 > > "dpd" just core dumps (and does not run). There is nothing reported in > /var/adm/dp/. Any hints on this one?? I have heard that it (dpd) core > dumps (sometimes) when the dp-conf files aren't setup properly... > Is this true?? If so, where do I start looking for errors? I was right about dpd core dumping. I recompiled it with -g and used dbx to discover that it was getting a SIGSEGV in the readconfig portion of the code, while trying to print out an "unknown MODEM" message. I played around with my dp-conf file until I got it working. What I did to fix it is get rid of ALL blank lines in the file. Not a real friendly parser, but I'm very happy that it works now. Now, on to some NEW problems: Regarding routing: I have assigned my home machine's dp0 interface the address of 129.212.49.100, and my work machine's dp0 interface the address of 129.212.49.101 . The work machine (named pecan) has an IP address of 129.212.49.1 . The ethernet at work is also connected to the rest of the site thru a router (129.212.49.200). My ifconfig and routing commands on my home machine are: ifconfig dp0 129.212.49.100 129.212.49.101 netmask 0xffff0000 -trailers up and /usr/etc/route add default 129.212.49.101 1 My ifconfig and routing commands on my work machine (pecan) are: ifconfig dp0 129.212.49.101 129.212.49.100 netmask 0xffff0000 -trailers up and /usr/etc/route add 129.212.49.101 129.212.49.100 1 Now, it's easy to get from my home machine to my work machine and vice versa. I have another machine on the network at work (129.212.49.2) to which I've added "/usr/etc/route add 129.212.49.100 129.212.49.1 1". So, now I can get to both of these machines. My question is: Do I have to add a "route" statement to *every* host on my network in order to be able to get to them? And how do I get to machines on the "other side" of the router? The way I'm doing it now is to rlogin to pecan, and then rlogin to the "remote" machines, but that's not really elegant... Regarding FTP/rcp thoughput: I'm using WorldBlazer modems at both ends and have the following configuration in use: WorldBlazer - SA - Version LA5.01 - Active Configuration B1 E1 L1 M1 Q2 T V1 X0 Y0 &C1 &D3 &G0 &J0 &L0 &Q0 &R3 &S1 &T4 &X0 S000:1 S001=0 S002:128 S003=13 S004=10 S005=8 S006=2 S007=40 S008=2 S009=6 S010=14 S011=70 S012=50 S018=0 S025=5 S026=1 S038=0 S041=0 S045=0 S046=0 S047=4 S048=0 S050:254 S051:253 S056=17 S057=19 S058:2 S059=0 S060=0 S061:0 S062=15 S063=0 S064:1 S068=255 S069=0 S090=0 S092:1 S093=8 S094=1 S100=0 S104=0 S105=1 S111=255 S112=1 S151=4 S155=0 S180=2 S181=1 S183=25 S190=1 S191:6 S253=10 S254=1 S255=255 Does this seem like a reasonable configuration? [To Bob Sutterfield:] Bob, a couple of weeks ago you wrote to comp.protocols.ppp claiming FTP throughputs of 2.4-2.7 KB/s for /vmunix and 2.8-3.5 KB/s for /usr/dict/words. I'm getting apprx. 2.4-2.6 KB/s for /vmunix, but only 2.0 KB/s for large (~500K) text files. Incidentally, when I'm uploading to work from home, I often see the CTS (and thusly SD) LEDs go off. Should data be being held back this frequently? Bob, could I possilbly get a copy of your WorldBlazer configuration so that I can see what we're doing differently? Any help with these problems would be greatly appreciated, Larry Ader ------------------------------------------------------------------------- Larry Ader || Amdahl Corporation || ames \ 1250 E. Arques Ave. M/S 139 || apple > !amdahl!lra00 P.O. Box 3470 || att / Sunnyvale, CA 94088-3470 || uunet / ph. 408/992-2722 || or lra00@amdahl.com or 1-800-538-8460 x22722 || -------------------------------------------------------------------------
Technical Details
Message-ID:
<87Rw02E025vQ01@JUTS.ccc.amdahl.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!charon.amdahl.com!amdahl!JUTS!pecan.spa.amdahl.com!lra00Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!charon.amdahl.com!amdahl!JUTS!pecan.spa.amdahl.com!lra00 From: lra00@pecan.spa.amdahl.com (Larry R. Ader) Newsgroups: comp.protocols.ppp Subject: Re: dp-2.2-beta problems Message-ID: <87Rw02E025vQ01@JUTS.ccc.amdahl.com> Date: 12 Oct 92 09:14:46 GMT Sender: netnews@ccc.amdahl.com Organization: Amdahl Corporation Sunnyvale, CA Lines: 145