Solved

Packet Loss

Posted on 2000-02-21
14
393 Views
Last Modified: 2010-03-18
I have a small LAN--Two computers connected via a hub.  One computer is in Windows; I am trying to bring the other into Linux and have the network work as it did under Windows.

My card is an SMC EtherPower II, which is supposed to use the EPIC driver (http://cesdis.gsfc.nasa.gov/linux/drivers/epic100.html).

Now, after much difficulty, I am able to successfully insmod the EPIC module and bring up the eth0 interface.  However, when I try to ping my Windows machine from the Linux one (and vice-versa), I get severe packet loss--50%-90%.  

When both machines are in Windows, packet loss does not occur, and the machines are able to interact over TCP/IP flawlessly.  Therefore, it can not be a network equipment problem.

On my hub, the Windows light is always on, whereas the light on the connection from the Linux box flashes at 2-4 second intervals.  (This is strange--I am sure that this is the source of the problem, but I don't know where to begin fixing it).

I have tried monitoring the network traffic with tcpdump, and I have come to the conclusion that traffic from one box to the other gets through in small bursts at intervals about equal to the light-flashing intervals. (I am getting less and less scientific here :)

Is there a cause for this oddity?  Is it that my driver is faulty, or are there settings which I have overlooked that are responsible?  I am only barely-knowledgeable on physical networking and so, after two days of frustration, I am at loss.  Any help would be greatly appreciated.

Below is some information:
uname -a:
Linux duckytown.home 2.2.9-19mdk #1 Wed May 19 19:53:00 GMT 1999 i586 unknown

output of ifconfig:
eth0      Link encap:Ethernet  HWaddr 00:E0:29:22:5C:5E
          inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16577 errors:0 dropped:0 overruns:0 frame:5
          TX packets:37581 errors:0 dropped:0 overruns:0 carrier:0
          collisions:5 txqueuelen:100
          Interrupt:10 Base address:0xfc00      


/proc/ioports:
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03e8-03ef : serial(auto)
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0530-0533 : WSS config
0534-0537 : MSS audio codec
fc00-fcff : eth0                  

/proc/interrupts:
           CPU0
  0:    1176507          XT-PIC  timer
  1:      17246          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:     241064          XT-PIC  serial
  5:          1          XT-PIC  MSS audio codec
  8:          2          XT-PIC  rtc
 10:      18852          XT-PIC  SMC EPIC/100
 12:     139283          XT-PIC  PS/2 Mouse
 13:          1          XT-PIC  fpu
 14:      49154          XT-PIC  ide0
 15:        309          XT-PIC  ide1
NMI:          0                            

/proc/pci:
PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Intel 82437 (rev 2).
      Medium devsel.  Master Capable.  Latency=64.
  Bus  0, device   7, function  0:
    ISA bridge: Intel 82371FB PIIX ISA (rev 2).
      Medium devsel.  Fast back-to-back capable.  Master Capable.  No bursts.
  Bus  0, device  15, function  0:
    VGA compatible controller: Matrox Millennium (rev 1).
      Medium devsel.  Fast back-to-back capable.  IRQ 11.
      Non-prefetchable 32 bit memory at 0xffbec000 [0xffbec000].
      Prefetchable 32 bit memory at 0xff000000 [0xff000008].
  Bus  0, device  16, function  0:
    Ethernet controller: SMC 9432 TX (rev 8).
      Fast devsel.  Fast back-to-back capable.  IRQ 10.  Master Capable.  Latency=64.  Min Gnt=8.Max Lat=28.
      I/O at 0xfc00 [0xfc01].
      Non-prefetchable 32 bit memory at 0xfffbf000 [0xfffbf000].    
0
Comment
Question by:Ducky
  • 7
  • 7
14 Comments
 

Author Comment

by:Ducky
Comment Utility
Adjusted points to 180
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
That sounds like it might be a driver problem. Do you have the latest (1.06) version? Have you tried the diagnostic programs mentioned on the driver site?

Do you have any options set for the card? If it'a a 10baseT hub and you enabled full duplex, there's going to be problems.
0
 

Author Comment

by:Ducky
Comment Utility
Yes, I'm using version 1.06.  In fact, I tried the experimental (1.06).

The hub is 100base-tx; i tried forcing FD as well as running it in HD.  Same problem always.
0
 

Author Comment

by:Ducky
Comment Utility
I meant v1.07 for experimental -- typo :)
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
Is everything that's hooked to the hub 100baseT? Some 10/100 hubs won't do mixed speeds, so if there's even one thing on the hub that's running at 10Mbit, you have to let everything be 10Mbit. I've also seen 10/100 hubs that supposedly did allow mixed speeds not actually handle 100Mbit connections if you forced it. Have you tried to let the card and hub auto-negotiate? You might also try going straight between the systems with a crossover cable.
0
 

Author Comment

by:Ducky
Comment Utility
The hub is only 100baseT, and I only have two things plugged in -- the Linux box and a Windows box.  They both have the same card model--the EtherPower II.

I will try a crossover as a last result, but I don't think that will help too much, especially since I need the hub to add more PCs later.
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
It's not that I actually doubt the hub, I'm just thinking of simplifying the problem.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 40

Expert Comment

by:jlevie
Comment Utility
Oh yeah, it is actually using the right driver, right? "lsmod" should show it as installed.

It would be interesting (and possibly illuminating) to try the diagnostic programs from the driver site.
0
 

Author Comment

by:Ducky
Comment Utility
Yes, I have to insmod the driver.  I did not place the line in conf.modules yet.

I have ran diagnostic tests, but I do not know enough about Ethernet cards to make any sense of the results.  I will paste the output from the two diagnostic tests at the bottom of this comment.

However, I have made a new discovery which complicates things more, but might shed some light on this error to someone who knows more than me-- Originally, I had problems with even bringing up the eth0 interface, because when insmoding the module, and then when doing ifconfig eth0 up, I would get the following:

WARNING: ** NO MII TRANSCEIVER FOUND

This seemed to be ocurring erratically, because sometimes it happened, but after rebooting sometimes I would be able to insmod the module correctly.  However, I have made this observation:

If I boot into Windows, the hub light stabilizes and goes on permanently.  If I then do a warm restart into Linux, I get the transceiver error.  If I somehow cause the light to go off and randomly flash (described below)--I have not figured out how to do this yet ;)--possibly by rebooting a hundred times and hoping it happens, then I can bring eth0 up correctly, but then I experience packet loss.

ONCE, by some magic interference, things worked beautifully-- I was in Linux, eth0 went up fine, the light went on permanently at some point, and there was no packet loss.  However, as soon as I turned off the Windows box on the other end, the light began flashing again.

There is a specific pattern to the hub light:  It goes on--for a duration of a split second or as long as 2 seconds--, the collision light flashes quickly, and the light goes off for 2-3 seconds.  Then the pattern repeats.  

I can make absolutely no sense of this.  My guess now is that Windows sends some command/setting (whatever it be called) to the card which causes the hub to perceive it as "connected ok", and that this setting flares the NO MII TRANSCEIVER ERROR in linux.  If this setting is somehow undone, Linux can find the transceiver (what is an MII transceiver, btw?), but then it does not know how to turn on this setting to make the card work.

I'm sorry if I'm being wordy and overly observational, but random guessing/trial-and-error are my only means while I don't know "a lot" about low-level networking.

Thanks!

Dominik

Here is the diagnostic output:
(I ran epic-diag three times, with three switches -ee, -aa, -mm, and mii-diag once, without any switches.  If I am able to insert the epic100 module w/o a transceiver error again, I can run any additional diagnostics anyone may need for more info).

../epic-diag -ee
epic-diag.c:v1.07 10/14/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a SMSC EPIC/100 83c170 adapter at 0xfc00.
The EPIC/100 chip appears to be active, so some registers will not be read.
To see all register values use the '-f' flag.
 No interrupt sources are pending.
   Tx chain done indication.
   Tx Queue empty indication.
 Rx state is 'Running', Tx state is 'Idle'.
  Transmitter: slot time 512 bits, half-duplex mode.
  Last transmit OK, 0 collisions.
  Receiver control is 000c, multicast mode.
  The last Rx frame was 0 bytes, status 0.
EEPROM contents (size: 64x16):
  e000 2229 5e5c 1b00 0001 1c08 10b8 a014
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0010 0000 1980 2100 0000 0000 0003 0000
  0701 0000 0000 0000 4d53 3943 3334 5432
  2058 2020 0000 0000 0280 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
 The word-wide EEPROM checksum is 0xdae2.
Parsing the EEPROM of a EPIC/100:
 Station Address 00:E0:29:22:5C:5E.
 Board name 'SMC9432TX   ', revision 0.
  Calculated checksum is 00, correct.
 Subsystem ID Vendor/Device 10b8/a014.


../epic-diag -aa
epic-diag.c:v1.07 10/14/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a SMSC EPIC/100 83c170 adapter at 0xfc00.
The EPIC/100 chip appears to be active, so some registers will not be read.
To see all register values use the '-f' flag.
EPIC chip registers at 0xfc00
 0x000: 00000009 002400c0 0000733f 00004200 00000031 00000071 00000000 00000000
 0x020: 00000000 00000000 00000000 0000ffff 0000ffff 00000000 00000016 00003c60
 0x040: 0000e000 00002229 00005e5c 00001b00 0000ffff 0000ffff 0000ffff 0000ffff
 0x060: 0000000c ******** ******** ******** 00003c79 00002003 ******** ********
 0x080: ******** 00dff820 ******** ******** ******** ******** ******** ********
 0x0A0: ******** ffff087f ******** ******** ffff0bff ******** ******** ********
 0x0C0: ******** 00dffaf0 ******** ******** ******** ******** ******** 00dff900
 0x0E0: ******** ******** ******** ******** ******** ******** ******** ********
 No interrupt sources are pending.
   Tx chain done indication.
   Tx Queue empty indication.
 Rx state is 'Running', Tx state is 'Idle'.
  Transmitter: slot time 512 bits, half-duplex mode.
  Last transmit OK, 0 collisions.
  Receiver control is 000c, multicast mode.
  The last Rx frame was 0 bytes, status 0.


../epic-diag -mm
epic-diag.c:v1.07 10/14/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a SMSC EPIC/100 83c170 adapter at 0xfc00.
The EPIC/100 chip appears to be active, so some registers will not be read.
To see all register values use the '-f' flag.
 No interrupt sources are pending.
   Tx chain done indication.
   Tx Queue empty indication.
 Rx state is 'Running', Tx state is 'Idle'.
  Transmitter: slot time 512 bits, half-duplex mode.
  Last transmit OK, 0 collisions.
  Receiver control is 000c, multicast mode.
  The last Rx frame was 0 bytes, status 0.
 MII PHY found at address 1.
 MII PHY found at address 3.
 MII PHY #1 transceiver registers:
   0000 0000 0000 0000 0000 0000 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000.
 MII PHY #3 transceiver registers:
   3000 7809 0181 4401 01e1 0001 0000 ffff
   ffff ffff ffff ffff ffff ffff ffff ffff
   0040 0018 ffff ffff ffff ffff ffff ffff
   ffff ffff ffff 003e ffff 0010 0000 0dc0.

../mii-diag
Basic registers of MII PHY #3:  0001 0001 0001 0000 0000 0000 0000 0000.
 Basic mode control register 0x0001: Auto-negotiation disabled, with
 Speed fixed at 10 mbps, half-duplex.
 Basic mode status register 0x0001 ... 0000.
   Link status: not established.
 Link partner information information is not exchanged when in fixed speed mode.



0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
I've read through your "book" and have a few thoughts...

The "NO MII TRANCEIVER" found is interesting. The chip set has the ability to drive an MII transceiver port, but it looks to me that SMC doesn't offer a card with that option. An MII transceiver is another way to connect media to the ethernet adapter (RJ45 or single or multi mode fiber for example). It's a device that connects to a minature multi-pin connector and has a place to attach the media. It doesn't seem to me that you ought to ever see that, but it could be okay for the general case of the chip.

You mentioned rebooting from windows to Linux. Have you tried a power on boot to Linux? It's possible that windows leaves the internal state of the card in some funky mode that a reset alone can't clear.

Something interesting did come out of the diagnostics. You said that you've got a 100Mbit hub, but according to the mii-diag outpiut the card is locked to 10Mbit half duplex. What "insmod" are you using? The doc page on the driver is less than crystal clear, but my reading of it suggests that you might should use:

insmod epic100.o debug=1 full_duplex=0

or perhaps:

insmod epic100.o debug=1 full_duplex=3

I doubt the hub can do 100Mbit full-duplex (most can't), but if it can you might try:

insmod epic100.o debug=1 full_duplex=5

The light on the hub (typically called a link light) indicates the presence of carrier on the port. The cycling on and off on a multi speed port frequently means that the hub/switch/card isn't sure what mode it's supposed to be using or doesn't like that mode and tries to re-negotiate the link speed/duplex.
0
 

Author Comment

by:Ducky
Comment Utility
Hmmm; full_duplex=0 seems to have done the trick, although I had to reboot before the hub detected a constant carrier (that's why I thought this setting had been unsuccessful in the past).

Thanks a lot for your help and patience; you just saved me a lot of time and agony!

Dominik

0
 
LVL 40

Accepted Solution

by:
jlevie earned 180 total points
Comment Utility
That option makes sense if I understand the driver page correctly. "full_duplex=0" should put the card into auto-negotiate mode so that it and the hub can agree. It would be interesting (to me) to see the output of mii-diag and see what speed it negotiated.

Since it appears this solved the problem, I'm marking this one as answered.
0
 

Author Comment

by:Ducky
Comment Utility
Output of mii-diag now:

Using the default interface 'eth0'.
Basic registers of MII PHY #3:  3000 782d 0181 4401 01e1 0081 0000 ffff.
 Basic mode control register 0x3000: Auto-negotiation enabled.
 You have link beat, and everything is working OK.
 Your link partner is generating 100baseTx link beat  (no autonegotiation).



Why does it say "no autonegotiation"?

Thanks again for everything.
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
I think that last line must mean that it's wasn't negotiating when the diag ran.
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now