ethtool : How to Know your LAN Card Status from LINUX
Couple weeks ago, there were problems reported came in my desk related to weird things about LAN connection happened in some place on branch office computers. The fact that one of the LINUX server unable to ping to others LINUX client connected in a LAN and so did from the clients. But the odd things was, the ping connection is successfully from the Windows. Windows displayed normally LAN connection status with default speed of 100Mbps.So what is the problem with LINUX? First thing, I got checked out the interface with ethtool software from LINUX (standard package found on Redhat setup CDs). This tiny tool displayed the LAN interface more and more details. From the server terminal, I wrote the default command “ethtool eth0” (with assumption that the LAN card is linked to eth0 device file).
[root@server ~]# ethtool eth0Everything is normal, nothings to be wrong on the server. The switch and cables is OK, this is the report answer from last information in Link detected: yes. What about the clients? I also got checked 2 sample client with the same command here, and what the each display said?
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
[root@client1 ~]# ethtool eth0Yes, there are differences here. The server LAN adapter are working with default speed: 10Mbps (Half duplex), while the clients are in 100Mbps (Full duplex). From these, I tried to force the server to working in clients mode (100 Mbps – Full duplex) with command below:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
[root@server ~]# ethtool –s eth0 speed 100 duplex full autoneg offAnd voila! The server are working good and ping was successful also the interface status now are same as the client. So, what is the interesting point with the command above? Since I had to force the interface to the same mode as client and the server interface are fully negotiable (shake-hand), so I inserted the parameter autoneg with off value in the last command statement.
Another situation I had face when I tried to connecting the web server in a WAN on one of my experience project. The server LAN on-board interface are looking normal.
[root@webserver ~]# ifconfig eth0Without LAN-tester toolkit, I got checked the cables heading to switch. First, I run the command within the cables unplugged:
eth0 Link encap:Ethernet HWaddr 00:01:6C:C2:66:3F
inet addr:10.1.7.50 Bcast:10.1.7.255 Mask:255.255.255.0
inet6 addr: fe80::201:6cff:fec2:663f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:265668 errors:0 dropped:0 overruns:0 frame:0
TX packets:945883 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16602948 (15.8 MiB) TX bytes:1238752271 (1.1 GiB)
Interrupt:11 Base address:0xd100
[root@webserver ~]# ethtool eth0Second, run the same command with cable plugged in the LAN adapter:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: Unknown! (65536) Duplex: Unknown! (256)
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: no
[root@webserver ~]# ethtool eth0The Link detected: no status tell that there is something wrong with the cable heading to switch. Then I switch the new cable and once again run the same command:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: no
[root@webserver ~]# ethtool eth0Bingo! The problem has solved without LAN-tester kit exist. The connection are now seems to be working well.
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
For few days, I’ve been playing around with
The chat transaction are so fun and easy. No wonder, I guess the developer are already using AJAX concept for its interactivity. Behind the advantages, there is a small number of lack when you use Meebo. You have to always focused on the Meebo monitor since its using the browser screen capability (I’ve been tested it on Internet Explorer 7 and Mozilla FireFox 2). You will never know when your friend are getting touch you, except its blink on the main panel in the browser display (even that the panel and the child chat window are able to change its state to pop-up or pop-in).
In other chances, I also tried the desktop version. It was developed with Visual Basic (?) by someone else who fanatics with Meebo. I thought that the desktop version are more identically with the original IM application, but it doesn’t. The concept are just simply put the web version into a web component compiler (TWebBrowser in Delphi or WebBrowser in Visual Basic). It is still no notification when your friend are try communicating to you. One thing for sure, there is an added value for the desktop version, it can minimized to system tray. In other words, you don’t have to wasting time to back again to the browser window and your current work application anymore. But, I was so confused since it’s installer required the .NET framework to operate well. Is there any relation between the requirement with its capability to minimized?
What will you do if you have to create an auto email responder in a web application but it hosted on a web server with no local SMTP port opened? Try this tiny module called PHPMailer. With PHPMailer, there are no problem to make any interactive email responder over your web application but – in a condition - you need to provide access to any available SMTP server. Guess what? No big deal about the un-existing SMTP server since there are tons free of it spread over the internet. Just let the uncle
Once again, I was on my journey to Pekanbaru by my own self due to my existing ongoing project on last Saturday. There were several points have to be done on it. I have to completed some missing documents after got flooded last month, installing the main server & also checking the network status. The next target date will be on 2nd week of this month, so I have to working on it as fast as I can.




