Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

tlug: Debugging a PLIP connection



皆さん、元気でしょうか?

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

Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links