Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]tlug: Debugging a PLIP connection
- To: TLUG <tlug@example.com>
- Subject: tlug: Debugging a PLIP connection
- From: Matt Gushee <mgushee@example.com>
- Date: Sat, 4 Sep 1999 11:51:09 -0400 (EDT)
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=iso-2022-jp
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
皆さん、元気でしょうか? Greetings from the piney rock-bound coast of Maine. Well ... all I can see out my window is a brick school building. But I'm sure there are still pine trees and rocks around somewhere :-) I've been having trouble setting up a PLIP connection (needed to transfer hundreds of Megs of cool custom-built software from my old notebook to my new desktop box). I floated this on the local LUG mailing list a few weeks ago, but nobody seemed to have a good idea what to do about it. Since there seem to be more genuine experts on TLUG (no, I'm not just trying to butter you up), I thought I'd try you folks. ------------------------------------------------------------------ ** This message is not for the faint of heart ** Well. I've been trying to set up a PLIP connection between my two Linux boxes. I struggled for a while, got it to work 2 or 3 times, now it doesn't work anymore. So I have 2 questions: 1) Can you suggest any programs or techniques to help figger out what's going on? Especially something that would give me very verbose messages about the signals being sent and received would be helpful. 2) Can you make any sense out of the info below? TIA for your helpful tips! Matt Gushee ****************************************************** The PLIP Mystery Machine #1 (hostname: 'lobstah' AKA 'bigbug') ============================================= IBM PC 750: Intel Pentium 133, PCI bus, 1 parallel port CMOS settings for port: IO=0x3bc, IRQ=7, Enhanced bi-directional mode Plug 'n' Pray enabled Linux distro: RedHat 5.2 w/ stock 2.0.36 kernel, glibc 2.0.7 ** Dual-booting w/ Windows NT 4.0 - [matt@example.com matt]$ hostname - lobstah - [matt@example.com matt]$ cat /etc/hosts - 127.0.0.1 localhost lobstah - 192.168.1.10 bigbug - 192.168.1.11 littlebug [BTW, I've been told I really should have a domain name for my local host -- but /etc/hosts wasn't any different when I had PLIP working, so I don't think that can be the cause -- at least not the sole cause] Machine #2 (hostname: 'crawdad' AKA 'littlebug') ================================================ Toshiba Satellite Pro 420 CDS (notebook): Intel Pentium 100, ISA bus, 1 parallel port CMOS settings for port: IO=0x378, IRQ=7, ECP mode (what is ECP?) PnP enabled, I guess Linux distro: RedHat 5.1, custom 2.0.34 kernel (see 'Anomalies'), glibc 2.0.7 - [matt@example.com matt]$ hostname - crawdad - [matt@example.com matt]$ cat /etc/hosts - 127.0.0.1 localhost crawdad - 192.168.1.11 littlebug - 192.168.1.10 bigbug Anomalies: ---------- * Kernel is customized, mainly for sound & APM support. To wit: CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_POWER_OFF=y # CONFIG_APM_IGNORE_MULTIPLE_SUSPEND is not set I've known various weird things to happen related to APM. E.g., sound doesn't work after an APM suspend, and sometimes the text-mode display is messed up. * Some months ago I replaced the original 800 MB hard disk with a 3rd-party 3.2 Gig disk. However, I couldn't find a hard drive specifically intended for this machine (none such exist, AFAICT). When I first installed the new hard drive, I ran the BIOS testing utility, or whatever it's called ... anyway, the hard drive FAILED the test (that's all the info I got -- guess it's not a very good test program). But it works fine under Linux, with no special configuration, and has never shown any weird behavior in 6-7 months of daily use. Still, I wonder: could the big HD somehow make the BIOS go psycho and mess up other parts of the system? PLIP Connection =============== (Some sample output. This is just after cold-booting both machines and logging in as root) Starting on the desktop machine: > [root@example.com /root]# rmmod lp > rmmod: module lp not loaded > [root@example.com /root]# insmod plip io=0x3bc To which the kernel responds: > Aug 15 22:48:04 localhost kernel: NET3 PLIP version 2.2 gniibe@example.com > Aug 15 22:48:04 localhost kernel: plip0: Parallel port at 0x3bc, using assigned IRQ 5. Note that this is different from the BIOS settings! I *think* that the times I got it to work, I forced the PLIP interface to IRQ 7 ... but I'm not really sure. Moving right along: > [root@example.com /root]# route add -net 192.168.0.0 netmask 255.255.0.0 dev plip0 > [root@example.com /root]# killall -HUP inetd Switching over to the notebook: > [root@example.com /root]# rmmod opl3 sb > [root@example.com /root]# rmmod uart401 > [root@example.com /root]# rmmod sound > [root@example.com /root]# rmmod lp > rmmod: module lp not loaded > [root@example.com /root]# insmod plip > [root@example.com /root]# route add -net 192.168.0.0 netmask 255.255.0.0 dev plip1 > [root@example.com /root]# killall -HUP inetd And back to the desktop: > [root@example.com /root]# ifconfig plip0 io_addr 0x3bc > [root@example.com /root]# ifconfig plip0 bigbug pointopoint littlebug up > [root@example.com /root]# route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.0.0 * 255.255.0.0 U 0 0 0 plip0 > 127.0.0.0 * 255.0.0.0 U 0 0 0 lo > [root@example.com /root]# ifconfig > lo Link encap:Local Loopback > inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 > UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 > plip0 Link encap:Ethernet HWaddr FC:FC:C0:A8:01:0A > inet addr:192.168.1.10 P-t-P:192.168.1.11 Mask:255.255.255.0 > UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 > Interrupt:5 Base address:0x3bc Notebook again: > [root@example.com /root]# ifconfig plip1 littlebug pointopoint bigbug up > [root@example.com /root]# route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.0.0 * 255.255.0.0 U 0 0 0 plip1 > 127.0.0.0 * 255.0.0.0 U 0 0 0 lo > [root@example.com /root]# ifconfig > lo Link encap:Local Loopback > inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 > UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 > TX packets:0 errors:0 dropped:0 overruns:0 > plip1 Link encap:Ethernet HWaddr FC:FC:C0:A8:01:0B > inet addr:192.168.1.11 P-t-P:192.168.1.10 Mask:255.255.255.0 > UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 > TX packets:0 errors:0 dropped:0 overruns:0 > Interrupt:7 Base address:0x378 Looks okay, I guess. Let's try some pinging. > [root@example.com /root]# ping 192.168.1.11 > PING 192.168.1.11 (192.168.1.11): 56 data bytes > --- 192.168.1.11 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss Oops. > [root@example.com /root]# ping 192.168.1.10 > PING 192.168.1.10 (192.168.1.10): 56 data bytes > --- 192.168.1.10 ping statistics --- > 7 packets transmitted, 0 packets received, 100% packet loss Arrggh! Hmm. It may be significant that when I ping *from the notebook*, the following message appears (once for each ping, I guess) *on the desktop*: transmit timeout: (1, 87) ... or something quite like that. If the solution depends on it, I could reproduce the exact message with a little effort. One other funny thing I noticed: yesterday I tried loading and unloading the plip module on the notebook several times, and according to the kernel messages, first it set up a plip1 interface, then plip0, then plip1 again. What's up with that?? More APM weirdness? As best I can remember, I loaded the module at the same IO address each time. Well, I hope you enjoyed reading this more than I enjoyed writing it. Please let me know if y'all have any insight. Matt Gushee Portland, Maine, USA ------------------------------------------------------------------- Next Nomikai: September 17 (Fri), 19:30 Tengu TokyoEkiMae 03-3275-3691 Next Technical Meeting: October 9 (Sat), 13:00 place: Temple Univ. ------------------------------------------------------------------- more info: http://www.tlug.gr.jp Sponsor: Global Online Japan
- Follow-Ups:
- Re: tlug: Debugging a PLIP connection
- From: Jonathan Q <jq@example.com>
- Re: tlug: Debugging a PLIP connection
- From: "Petersen Jens-Ulrik (NRC/Tokyo)" <jens-ulrik.petersen@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: tlug: Mutt and domain lookup when sending mail - help!
- Next by Date: Re: tlug: Debugging a PLIP connection
- Prev by thread: tlug: Big Brother in TOOS
- Next by thread: Re: tlug: Debugging a PLIP connection
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links