RealTEK 8139a, SCO OSR 5.0.5 and Sony Vaio PCG-FXA63
ews
Over the last week or so I have been attempting to get OSR5.0.5 running
properly on a Sony Vaio PCG-FXA63.
The biggest hangup I am having now is with the built-in ethernet card.
Although the Vaio docs neglect to mention the chipset, The Windows install
reported using the RealTEK RTL8139 driver / chipset.
So, I downloaded the SCO driver from
http://www.realtek.com.tw/downloads/downloads1-3.aspx?keyword=sco+rtl8139a
and installed the software, added a new LAN controller, relinked and reboot.
Now, when I try to ping a machine on the LAN, I receive one of several reply
messages.
The first is
#ping 10.0.0.1
ping: sendto: No route to host
ping: wrote 10.0.0.1 64 chars, ret=-1
#netstat -rn
Destination Gateway Flags Refs Use Interface
10.0.8 10.0.8.2 UC 1 0 net1\
10.0.8.2 127.0.0.1 UGHS 0 0 lo0
127.0.0.1 127.0.0.1 UH 3 17 lo0
224 10.0.8.2 UCS 0 0 net1
Same message with the route to 10.0.8 removed
#ifconifg reports that net1 is up, with the ipaddress of 10.0.8.2 and mask
of ff000000
after #route flush
the routing table looks like (summarized output)
Dest. GW If
10 10.0.8.2 net1
127.0.0.1 127.0.0.1 lo0
224 10.0.8.2 net1
and no messages are displayed. IE
#ping 10.0.0.1 (10.0.0.1): 56 data bytes
--hangs until killed --
I have read some older usenet postings of similiar probs, but none of the
suggestions seem to fix the prob.
Any suggestions?
If you need more informations please ask!
Thanks,
ews
Jean-Pierre Radley
|
| Now, when I try to ping a machine on the LAN, I receive one of several reply
| messages.
|
| The first is
|
| #ping 10.0.0.1
| ping: sendto: No route to host
| ping: wrote 10.0.0.1 64 chars, ret=-1
|
| #netstat -rn
|
| Destination Gateway Flags Refs Use Interface
| 10.0.8 10.0.8.2 UC 1 0 net1\
| 10.0.8.2 127.0.0.1 UGHS 0 0 lo0
| 127.0.0.1 127.0.0.1 UH 3 17 lo0
| 224 10.0.8.2 UCS 0 0 net1
|
| Same message with the route to 10.0.8 removed
You haven't got any default route *out* of your machine, or put anoputher
o, as the error message said, you can't find a route to 10.0.0.
Add the number of your router as your default route.
--
JP
Thom Price
Hi, JP.
Pardon, but his subnet mask (255.0.0.0) makes all 10.x.y.z IPs
accessible without default route needed to access 10.0.0.1. Default
route is for IPs not accessible directly on the NIC's subnet.
However, because it's a RealTek (with what I now know about RealTek
chipsets) it *may* help by adding the default route.
ews, search here for other mentions of RealTek chipset, esp. recently.
I think Tony Lawrence mentioned the shortcomings of RealTek with
reminder from someone else (sorry, can't remember the name) who
bolstered his thoughts with some Linux man info and RealTek driver
comments. It *may* be a chipset that can't handle subnetting Class As
properly.
HTH.
Thom
Tony Lawrence
Subnetting is up the stack..
--
Tony Lawrence
Free SCO and Linux Skills Tests: http://aplawrence.com/skillstest.html
Bill Vermillion
Thom Price <whudd...@yahoo.com> wrote:
>Jean-Pierre Radley <j...@jpr.com> wrote in message news:<2003010301...@jpradley.jpr.com>...
>> ews typed (on Fri, Jan 03, 2003 at 12:51:43AM +0000):
>> |
>> | Now, when I try to ping a machine on the LAN, I receive one of several reply
>> | messages.
>> | The first is
>> |
>> | #ping 10.0.0.1
>> | ping: sendto: No route to host
>> | ping: wrote 10.0.0.1 64 chars, ret=-1
>> |
>> | #netstat -rn
>> |
>> | Destination Gateway Flags Refs Use Interface
>> | 10.0.8 10.0.8.2 UC 1 0 net1\
>> | 10.0.8.2 127.0.0.1 UGHS 0 0 lo0
>> | 127.0.0.1 127.0.0.1 UH 3 17 lo0
>> | 224 10.0.8.2 UCS 0 0 net1
>> | Same message with the route to 10.0.8 removed
>> You haven't got any default route *out* of your machine, or
>> put anoputher o, as the error message said, you can't find a
>> route to 10.0.0.
>> Add the number of your router as your default route.
>Pardon, but his subnet mask (255.0.0.0) makes all 10.x.y.z IPs
>accessible without default route needed to access 10.0.0.1. Default
>route is for IPs not accessible directly on the NIC's subnet.
>However, because it's a RealTek (with what I now know about RealTek
>chipsets) it *may* help by adding the default route.
A lot depends on the OS and implementation involved. I've come
across some that need their default in the same /24 as their
address. And on such things as Macs [I don't know if OS/X has
does it this way] But bringing up a Mac on a subnet required
that the gateway be within the subnet while the MS products just
needed a gateway within a /24 even if they were on a subnet.
Many people were led astray on how networks worked getting used the
the faulty MS approach.
>ews, search here for other mentions of RealTek chipset, esp. recently.
> I think Tony Lawrence mentioned the shortcomings of RealTek with
>reminder from someone else (sorry, can't remember the name) who
>bolstered his thoughts with some Linux man info and RealTek driver
>comments. It *may* be a chipset that can't handle subnetting Class As
>properly.
The hardware really has nothing to do with the software side when
it comes to the addessing. I posted the acerbic comments from the
RealTek driver author in BSD. Tony put up the man rl page.
If you note the output of the netstat you'll see the the only
network the system knows about is 10.0.8 and the way to reach
that is the 10.0.8.2
So if there is a 255.0.0.0 netmask somewhere it's not showing up
in the outputs of netstat.
--
Bill Vermillion - bv @ wjv . com
Thom Price
from?...
What I meant was that the RealTek is so poorly written it may not be
able to handle what would normally be routable IPs, those over 8 bits.
This is somewhat implied when I read here:
"I'm not sure exactly what causes these to sometimes be unable to pass
a
router, but I have seen them do this more than once. "
What may prevent them from passing routers may be an inability in the
chipset and/or driver to handle more than 8-bit masks. I don't know
what was intended by the aboe statement, only that RealTeks are a
problem NIC, at best.
So, ews, more specifically, try any PCMCIA card you can find on the
SCO list.
Better?
Tony Lawrence
From the chipset. From the driver. It's addressing, not hardware.
Thom Price
understand this mask OK.
> >ews, search here for other mentions of RealTek chipset, esp. recently.
> > I think Tony Lawrence mentioned the shortcomings of RealTek with
> >reminder from someone else (sorry, can't remember the name) who
> >bolstered his thoughts with some Linux man info and RealTek driver
> >comments. It *may* be a chipset that can't handle subnetting Class As
> >properly.
>
> The hardware really has nothing to do with the software side when
> it comes to the addessing. I posted the acerbic comments from the
> RealTek driver author in BSD. Tony put up the man rl page.
>
> If you note the output of the netstat you'll see the the only
> network the system knows about is 10.0.8 and the way to reach
> that is the 10.0.8.2
>
> So if there is a 255.0.0.0 netmask somewhere it's not showing up
> in the outputs of netstat.
Thanks for the info on who posted what. Hardware has to have
*something* to do with the problems that a chipset driver gives to an
OS, no?
I won't trust what's been posted 'cos he mentions that he's snipped
lots out. But, we *do* see:
"#ifconifg reports that net1 is up, with the ipaddress of 10.0.8.2 and
mask
of ff000000"
So ifconfig knows the mask, which must mean something to this OS.
And...
"after #route flush
the routing table looks like (summarized output)
Dest. GW If
10 10.0.8.2 net1"
2 things to note, IMHumbleO:
1- "summarized output"
2- Dest of 10 shows the OS understands the mask. Unknown why netstat
doesn't indicate this...
I'm a bit confused by:
"Same message with the route to 10.0.8 removed"
It may indicate that the *OS* understands the mask, but the NIC driver
doesn't...
I, too, have seen some cards that couldn't supernet or do other than
24-bit masks properly, which is why I indicated that this RealTek may
be one of those wonderful devices giving us more reason to buy
helmets... to alleviate some of the damage from some of the
headbangin'. (maybe I'll try the Packers' fans' cheese hats... 24-7
now...) My point was that 256 may just be a "magic number" with this
driver or chipset...
I'd still try a PC Card and disable the RT, maybe a 3Com (or fill in
your favorite brand - Xircom? other?) PC Card that's well-known to
work. Once working, *then* attack the RT issue, if desired. Work
from known good, then add the hinky parts...
Bill Vermillion
Thom Price <whudd...@yahoo.com> wrote:
>b...@wjv.comREMOVE (Bill Vermillion) wrote in message news:<H8766...@wjv.com>...
>> >> | Destination Gateway Flags Refs Use Interface
>> >> | 10.0.8 10.0.8.2 UC 1 0 net1\
>> >> | 10.0.8.2 127.0.0.1 UGHS 0 0 lo0
>> >> | 127.0.0.1 127.0.0.1 UH 3 17 lo0
>> >> | 224 10.0.8.2 UCS 0 0 net1
>> >> | Same message with the route to 10.0.8 removed
>> >> You haven't got any default route *out* of your machine, or
>> >> put anoputher o, as the error message said, you can't find a
>> >> route to 10.0.0.
>> >Pardon, but his subnet mask (255.0.0.0) makes all 10.x.y.z IPs
>> >accessible without default route needed to access 10.0.0.1.
I'd surely have liked if he'd posted the exact output just in
case he was missing something or not showing all. He said the
ifconfig showed the netmask as ff000000 - but I'd like to see
the exact output to be sure.
The netstat surely doesn't reflect that.
>> A lot depends on the OS and implementation involved. I've come
>> across some that need their default in the same /24 as their
>> address. And on such things as Macs [I don't know if OS/X has
>> does it this way] But bringing up a Mac on a subnet required
>> that the gateway be within the subnet while the MS products just
>> needed a gateway within a /24 even if they were on a subnet.
>> Many people were led astray on how networks worked getting used the
>> the faulty MS approach.
>Hey, Bill. Understood on the vagaries of OSs, but SCO should
>understand this mask OK.
As above - it should - but we only saw that he said what the
netmask was and did not post computer generated output. I tend
to trust direct output but not 'reported' or 'synopsized' output.
>> If you note the output of the netstat you'll see the the only
>> network the system knows about is 10.0.8 and the way to reach
>> that is the 10.0.8.2
>> So if there is a 255.0.0.0 netmask somewhere it's not showing up
>> in the outputs of netstat.
>Thanks for the info on who posted what. Hardware has to have
>*something* to do with the problems that a chipset driver gives to an
>OS, no?
>I won't trust what's been posted 'cos he mentions that he's snipped
>lots out. But, we *do* see:
>"#ifconifg reports that net1 is up, with the ipaddress of 10.0.8.2 and
>mask
>of ff000000"
Yes - but I'd feel better to see the output. It just doesn't seem
right does it.
>2 things to note, IMHumbleO:
>1- "summarized output"
Yup.
>2- Dest of 10 shows the OS understands the mask. Unknown why netstat
>doesn't indicate this...
I didn't see this. I saw a dest of 10.0.8 for the gw.
>I, too, have seen some cards that couldn't supernet or do other than
>24-bit masks properly, which is why I indicated that this RealTek may
>be one of those wonderful devices giving us more reason to buy
>helmets... to alleviate some of the damage from some of the
>headbangin'.
It really shouldn't be a hardware problem. I'd have thought that
might have been noted with all the negative comments from the
driver writer. If a card won't handle supernetting I really
suspect it's a bad driver - at least the way I understand things.
>(maybe I'll try the Packers' fans' cheese hats... 24-7
>now...) My point was that 256 may just be a "magic number" with this
>driver or chipset...
I can see that.
>I'd still try a PC Card and disable the RT, maybe a 3Com (or fill in
>your favorite brand - Xircom? other?) PC Card that's well-known to
>work. Once working, *then* attack the RT issue, if desired. Work
>from known good, then add the hinky parts...
Cheap parts are so expensive by the time you add in all the lost
time making them work.
Bill
Jeff Liebermann
>Over the last week or so I have been attempting to get OSR5.0.5 running
>properly on a Sony Vaio PCG-FXA63.
>The biggest hangup I am having now is with the built-in ethernet card.
>Although the Vaio docs neglect to mention the chipset, The Windows install
>reported using the RealTEK RTL8139 driver / chipset.
Correct. The FX series uses the RTL8139CL. See:
http://www.myplc.com/sony/vaio_compare.htm
for clues.
>So, I downloaded the SCO driver from
>http://www.realtek.com.tw/downloads/downloads1-3.aspx?keyword=sco+rtl8139a
>and installed the software, added a new LAN controller, relinked and reboot.
Methinks(not sure) that the 3.2v5.0.5 version I installed two weeks
ago, had the RTL-8139 driver on the distribution media. However,
autodetect didn't find the ethernet card and I had to install it
manually. I'm not sure if the "SCO Unix 5.0.x" version on the Realtek
web pile is the same. There are also some no so subtle differences
between the RTL-8139 and the RTL-8139C Plus. Sorry, I have no details
on how this affects driver issues.
>The first is
>
>#ping 10.0.0.1
>ping: sendto: No route to host
>ping: wrote 10.0.0.1 64 chars, ret=-1
>
>#netstat -rn
>
>Destination Gateway Flags Refs Use Interface
>10.0.8 10.0.8.2 UC 1 0 net1\
>10.0.8.2 127.0.0.1 UGHS 0 0 lo0
>127.0.0.1 127.0.0.1 UH 3 17 lo0
>224 10.0.8.2 UCS 0 0 net1
>
>Same message with the route to 10.0.8 removed
Why would you want to remove the only route that goes somewhere?
You have no default route. You need a default route. Run:
route add default 10.0.0.1
or whatever reflects your default route.
Note: You can live without a default route, but you will not be able
to ping anything outside of your netmask.
>#ifconifg reports that net1 is up, with the ipaddress of 10.0.8.2 and mask
>of ff000000
[Insert general gripe about paraphrasing error messages and trunc..ing
diagnostic output]. What duz:
ifconfig -a
really output? Mine looks like:
-> ifconfig wdn0
wdn0: flags=23<UP,BROADCAST,NOTRAILERS>
inet 192.168.111.1 netmask ffffff00 broadcast 192.168.111.255
There was a bug in an older version of ODT or OSR5 that prevented
ifconfig netmask from delivering anything larger than /24. I think it
was fixed long ago. It would therefore be interesting to see what the
ifconfig lines in /etc/tcp look like. Run:
grep ifconfig /etc/tcp
Mine (from 3.2v4.2) looks like (slightly edited):
ifconfig lo0 localhost
ifconfig wdn0 192.168.111.1 -trailers netmask 255.255.255.0
broadcast 192.168.111.255
>after #route flush
>
>the routing table looks like (summarized output)
>
>Dest. GW If
>10 10.0.8.2 net1
>127.0.0.1 127.0.0.1 lo0
>224 10.0.8.2 net1
Well, if the above is true, then you should be able to now ping
10.0.0.1 since the route from your machine at 10.0.8.2 to the
10.xxx.xxx.xxx network is up.
Incidentally, for 3.2v5.0.5, please kill the "routed" daemon (RIP).
Then edit /etc/tcp by inserting comment symbols in front of the
section that starts tcp/ip. That will prevent accidental changes to
the routes from being broacast all over the LAN and from misconfigured
NT4 servers and cheap routers from trashing the OSR5 machines routeing
table.
>and no messages are displayed. IE
>#ping 10.0.0.1 (10.0.0.1): 56 data bytes
OK. So the route is there, but nobody is home. Lots of possible
reasons for that which have nothing to do with OSR5 or the RLT-8139.
Start with the simple stuff like:
1. Are the ethernet lights on? At both ends of the cable?
2. Can you ping yourself? Try both localhost and 10.0.8.2
3. Can whatever device is at 10.0.0.1 ping the laptop at 10.0.8.2?
4. Can you ping *ANY* other machine on the 10.0.8.xxx network?
5. Is the ethernet device enabled in the Sony CMOS setup?
6. You mentioned Windoze on the Vaio. Did the ethernet port work
under Windoze?
>Any suggestions?
1. Check your assumptions.
2. Don't blame the obvious.
3. Test what's easiest first.
4. Offer sacrifice to the computah gods in the form of a burnt 386
motherboard.
5. Start with a *SIMPLE* network configuration. That means that your
laptop IP address is in the same /24 block as the default router. Use
a netmask of 255.255.255.0. Keep it VERY simple. When that works,
then configure it to whatever weird netmask and creative route suits
your fancy. If it suddenly stops working, the problem will be
obvious.
>If you need more informations please ask!
1. Exact version including patches:
customquery listpatches | head -1
2. Some clue as to your network topology. Methinks it's sorta
working but the TCP/IP configuration is wacko.
Incidentally, don't try the:
route flush
incantation when connected over a network link. It clears all the
routes including the default route. It disconnected me from my office
server (I'm at home now) until I get it rebooted. I should have known
better. Dumb...dumb...dumb...
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com