On Mon, 3 Dec 2007, in the Usenet newsgroup comp.os.linux.networking, in article <slrnfl7367.ta3.BitTwister@wb.home.invalid>, Bit Twister wrote: >Phi wrote: >> eth0 Link encap:Ethernet HWaddr 00:1A:92:6B:ED:4B >Dang it, for some reason, the command > mii-tool -v eth0 >or ethtool eth > >did not run. No idea why. but may indicate module to drive nic >is not working and is the problem. Do try both commands to see if you >get any indication why they did not work. [compton ~]$ etherwhois 00:1A:92 00-1A-92 (hex) ASUSTek COMPUTER INC. 001A92 (base 16) ASUSTek COMPUTER INC. No.5 Shing Yeh Street,Kwei Shan Haiang,Tao Yuan Taipei 333 TAIWAN, REPUBLIC OF CHINA [compton ~]$ No indication of what type of card, but at least the kernel can talk to it. Two possibilities - card doesn't support Mii-tools, or the desired binaries aren't installed. >I do know, Micro$not did an update to my onboard Realtek Semiconductor >RTL-8139 nic and linux was no longer able to use the nic. How long ago? Early in the life of the 8139 driver, there was a problem with the power management. From a long forgotten post to c.o.l.n: --------------------------------- >So once again I booted up the machine in Windows (98 SE) and then >rebooted into Linux again and ... the hardware adress was once again 0. >Shutting down the power and the booting up in Linux again gives the card >the right address again. This can be solved by using the 'pci-scan' module and updated driver from http://www.scyld.com/network/updates.html You have a RTL8139B or RTL8139C with PCI power management. Windows leaves PCI power management capable devices in D3-warm power state. Neither the BIOS nor Linux knows about PCI power management. The 'pci-scan' module, combined with the updated driver set, knows how to restore the device to full power "D0" state before using it. becker@beta.scyld.com (Donald Becker) --------------------------------- Old guy

On Tue, 04 Dec 2007, in the Usenet newsgroup comp.os.linux.networking, in article <47556a3f$0$29252$ba620e4c@news.skynet.be>, goarilla wrote: >david wrote: >> Phi rearranged some electrons to say: >> route -v >> Kernel IP routing table >> Destination Gateway Genmask Flags Metric Ref Use Iface >> 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 >> link-local * 255.255.0.0 U 0 0 0 eth0 >> default 0.0.0.0 UG 0 0 0 eth0 >> > Something seems wrong with the gateway on your default route.. it > shouldn't be blank, should it? > >he's right do this (as root): >/sbin/route del default >/sbin/route add default gw 192.168.1.1 netmask 255.255.255.0 ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^ <eth_device( eg eth0,eth1,...)> Ummmm.... you realy need to re-read that man page, usless this is one hell of a typ0. The "default" route is defined in the terms of a programming choice. If the other choices don't work to get you where you are going, send it here _by default_ (which in the Linux tools sense really means this is the route to the entire world). Last time I checked, the world doesn't exist in a 255.255.255.0 mask, and the correct mask is the default for a default route - which is to say 0.0.0.0. Old guy

On Wed, 5 Dec 2007, in the Usenet newsgroup comp.os.linux.networking, in article <ffc2d0d7-aeb9-4832-ab5a-5a17d5aa1b14@e67g2000hsc.googlegroups.com>, Phi wrote: NOTE: Posting from groups.google.com (or some web-forums) dramatically reduces the chance of your post being seen. Find a real news server. >My understanding of route -v is that it responds using symbolic names >for the hosts it finds. Have you looked at the man page? It's fairly well explained there. [compton ~]$ whatis route route (8) - show / manipulate the IP routing table [compton ~]$ >So, it shows link-local as a host. Since the gateway has no symbolic >name, it shows as a blank. No on both counts. Let's recopy your display here: ]route -v ]Kernel IP routing table ]Destination Gateway Genmask Flags Metric Ref Use Iface ]192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 ]link-local * 255.255.0.0 U 0 0 0 eth0 ]default 0.0.0.0 UG 0 0 0 eth0 The names 'link-local' and 'default' translate to a network named 'link-local' (169.254.0.0/16), and a route to use when no other route will take your packets where they need to go. The 'link-local' is an Apple invention copied by windoze, and used when a computer can't find a DHCP server to get a "real" address. It gets included in some Linux distributions because of the abundance of mis-configured windoze systems often found on home networks. It's a "don't bother fixing the problem, just make it work and I don't care about security" solution from windoze. You can disable this "feature" by including a line in the file '/etc/sysconfig/network' that says "NOZEROCONF=yes". The 'default' route is that route used when no other listed route will take you where you want to go. This is _NORMALLY_ considered to be the route to "the world". The lack of a name or the '*' character indicates that '/sbin/route' is finding some name for that gateway device, but is unable to display the name - generally a screwed up nameserver, or bad entry in the /etc/hosts file. Note that none of the routes you show are routes to individual hosts. These would be identified by a 'Genmask' of '255.255.255.255' and an 'H' flag. I'm not exactly sure where you got this routing table, as it has several problems. This _should_ look like this: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 Finally, when the 'route' command is unable to determine a name for a host or network, it puts in the numeric address. You could use the -n option to get this behavior by default. >I also posted netstat -rn. That shows the IP addresses for the >connections. It shows 192.168.1.1 for the gateway address. [compton ~]$ whatis netstat netstat (8) - Display network connections, routing tables, interface statistics, masquerade connections and netlink messages [compton ~]$ If you looked at the man page for 'netstat' (actual syntax 'man netstat') you would find -r, --route With the -r, --route option, you get the kernel routing tables in the same format as route -e use. netstat -er will use the output format of route. Please see route(8) for details. -n, --numeric shows numerical addresses instead of trying to determine symbolic host, port or user names. so the data shown by '/bin/netstat -rn' should be essentially the same as shown by '/sbin/route -n' Old guy

On Wed, 5 Dec 2007, in the Usenet newsgroup comp.os.linux.networking, in article <02b637cb-ed2f-45a6-8968-1240ebef84ea@a35g2000prf.googlegroups.com>, Phi wrote: NOTE: Posting from groups.google.com (or some web-forums) dramatically reduces the chance of your post being seen. Find a real news server. >The gateway is 192.168.1.1 >It did not show in route -v, because there is no symbolic name for it. Not true, but you could fix that by entering the hostname and address in /etc/hosts. What does 'route -vn' show? >It does show correctly for netstat -rn. >DNS was entered as shown in resolv >======== grep -v '^#' /etc/resolv.conf ========== >nameserver 29.25.5.60 >nameserver 29.25.5.61 >Using nameserves outside the local network is normal. Generally, it's frowned upon to try to use nameservers other than your own, or those of your ISP. External users asking a name server to resolve names/addresses it's not authoratative for is considered abuse by some, and I've know people to configure their nameserver to respond with an NXDOMAIN rather than the more correct REFUSED result code. >I may set up the linux system to do dns for itself for nodes on the >local network. The addresses you show certainly won't work from here - my routers tell me that no one admits to knowing how to send packets to that military network. As you are posting from NNTP-Posting-Host: 70.60.226.186 maybe you'd have better luck using one of the name servers associated with Road Runner Commercial (24.30.200.19, 24.30.201.19, or 65.24.0.172), or one associated with the techtriad.com (there are five to choose from). Old guy