Date: Wed, 11 Dec 1996 08:07:53 +0100 (MET) From: Greg Lehey <grog@lemis.de> To: terry@lambert.org (Terry Lambert) Cc: FreeBSD-current@FreeBSD.ORG (FreeBSD current users) Subject: Re: It works! Solved my problem wih Etherlink III on AcerNote Light Message-ID: <199612110707.IAA02737@freebie.lemis.de> In-Reply-To: <199612101906.MAA04666@phaeton.artisoft.com> from Terry Lambert at "Dec 10, 96 12:06:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
(dropping -mobile from this list--it's not really a notebook issue)
Terry Lambert writes:
>> For those of you who've been following my tribulations installing
>> -current on an AcerNote Light, the good news: finally it works.
>
>> ... ]
>
>> So then I built a -current kernel without crd0 and pcic[01]. It
>> FOund the baord. And it was able to correctly configure zp0. But
>> I still couldn't get things to work. On closer examination, there
>> seems to be something wrong with the routing table entry: there
>> was no entry at all for zp0, and I couldn't find a way to put one
>> in. In /etc/sysconfig, I did effectively:
>>
>> ifconfig lp0 192.109.197.159 192.109.197.137
>> ifconfig zp0 192.109.197.159
>
> This is incorrect.
This is correct and valid.
> You have "named" both interfaces the same IP "name".
No. The first interface is lp0. The second interface is zp0. They
have different names, only the address is the same. That's a big
difference.
> You can't do this, it's not legal.
You can do this, it's legal.
> If it works at all, it has more to do with assignment order, and the
> resulting bogus data in your routing table, and which bogus route is
> found first during a linear traversal, than anything else.
You've touched on the truth, and passed it by.
> Consider: I am your kernel... I have a packet for 192.109.197.158; do
> I send it out your parallel port or your ethernet card?
In the above, it looks as if you're saying "you can't have two
interfaces with the same address", but I'm not sure that's what you
want to say. Maybe you want to say "you can't have two routing table
entries, one of which is a subset of the other.
Either way you're wrong. You look in the routing table. In the case
I was talking about, there was no entry for zp0, and that's what I was
complaining about. Compare page 39 of TCP/IP illustrated, volume 1.
Routing does:
1. Look for the complete destination IP address in the routing table.
If found, use it. In our case, this would be lp0.
2. Otherwise, look for the network ID in the routing table. If
found, use it. In our case, this would be zp0, if it were there.
3. Otherwise look for a default entry. If found, use it. Otherwise
'network is unreachable'.
This is done rather more elegantly than this description suggests in
the function rn_match in net/radix.c. It does a single linear
traversal and looks for the matching entry with the longest net mask.
Having said this, you might be amused by freebie's complete interface
settings:
lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.109.197.137 --> 192.109.197.159 netmask 0xffffff00
ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.109.197.137 netmask 0xffffff00 broadcast 192.109.197.255
ether 00:a0:24:37:0d:2b
ipi0: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.163.31.4 netmask 0xffffffc0
ipi1: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.64.112.1 netmask 0xffffff00
ipi2: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.163.31.129 netmask 0xffffffc0
ipi3: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.37 --> 192.109.197.38 netmask 0xffffff00
ipi4: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.148 --> 194.77.2.34 netmask 0xffffff00
ipi5: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.163.31.1 netmask 0xffffffc0
ipi6: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 192.129.52.242 netmask 0xffffff00
ipi9: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 194.97.201.66 --> 194.97.201.9 netmask 0xffffff00
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
The ipi<x> are ISDN interfaces.
BTW, as I mentioned yesterday, I thought something else had gone
wrong. It looks like it had. I can take both interfaces up and down,
and the routing table is updated correctly.
>> ftp'ing a 67 MB file gave me a throughput of about 220
>> kB/s when copying to disk, about 750 kB/s when copying to
>> /dev/null. By comparison, the same file ftp'd to (IDE) disk on
>> freebie at 860 kB/s, and to /dev/null at 940 kB/s. The error rate
>> might explain some of this: on freebie, netstat -in shows:
>
> I can't explain the error rate. Does it claim that the card is bogus
> at boot time?
No.
> There were some rent patches for (589?) which might
> be applicable.
This was with -current as of Tuesday. The latest cvs update was
cvs-cur.2791.gz. I haven't seen any relevant patches come in since
then.
> The 3COM stuff is notoriously variable in their detection interface
> design... moreso than almost any other devices (well, except ATAPI
> CDROMs).
Interesting. In the meantime I've spoken with 3com, and I'm gradually
left with the impression that the detection problem is with the
AcerNote PCMCIA interface, and not with the board. The other problems
remain. Anyway, maybe the problems were related to my startup
attempts. I've since rebooted the machine, and when I look now I see:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
zp0 1500 <Link> 00.60.97.40.fb.e1 39442 0 39038 10 0
zp0 1500 192.109.197 192.109.197.159 39442 0 39038 10 0
That looks a lot more healthy. I've noticed that the machine seems to
go into some kind of power-save mode when it's closed, and that causes
it to respond more slowly. Maybe the oerrs are related to that.
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612110707.IAA02737>