8

I am trying to connect two devices one of which is only capable of 10Mbps and does not support auto-negotiation. (The other is a black box, I am unsure how to tell whether it supports auto-negotiation, although it works when connected to my PC at both 10/100Mbps)

I can connect these devices using a switch, and they talk quite happily. However if I connect the devices directly to each other then no packets seem to traverse the link. I have tried four cables, a straight-through, a cross-over, a straight-through with TX+ and TX- wires swapped, and a cross-over with TX+ and TX- wires swapped. I have tried the latter two cables both ways around. (This is in case pins 3 and 6 are swapped in either device, I read that this can be a problem with 10M which uses polarized transmission).

I can connect to either device from my PC if I limit my NIC to 10M and ask it not to auto-negotiate.

Is there something else that the switch could be doing to make this connection work? Are there any other things I could try to get a cable between these devices?

Weir_Doe
  • 191
  • 5
  • I have tested with a dual speed hub in addition to the switch which I was using, this works perfectly. I have also tested all the cables in half and full duplex as per the excellent answer Hauke Laging gave (although sadly not correct). When I use direct cables the link and activity lights suggest traffic is being sent, but no packets arrive either side. – Weir_Doe May 31 '13 at 18:16

2 Answers2

3

Have a look at the Wikipedia article.

The switch may correct a duplex mismatch. Maybe you can switch the non-blackbox between half and full duplex?

Hauke Laging
  • 5,285
  • 2
  • 24
  • 40
  • Very good point, thank you. I have tried both full-duplex and half-duplex modes on the device I have control over. I will read the rest of that article you suggested, hopefully it will shed some light. – Weir_Doe May 31 '13 at 15:37
  • If I understand correctly, I should leave the device I have control over in half-duplex, and only try sending traffic in one direction, then this will rule out a duplex problem? At least until I can get a connection working without the switch that is. – Weir_Doe May 31 '13 at 16:40
  • 1
    @Weir_Doe It's obviously difficult to send traffic in one direction only. I have no experience with that case but I assume the problem is strongly related to the amount of traffic. It does not cause much traffic but it may help to make a static ARP assignment on the system you control. And if you do not have to send much data it may also help to use `tc` with HTB and rather extreme settings so that after each packet there is a pause. – Hauke Laging May 31 '13 at 17:48
  • I have complete control of one device, and the other sends a single test packet every few seconds, so in this case I do not need a pause to ensure low traffic in one direction. It is a good suggestion though, especially the tc-htb mention if other people have similar issues. – Weir_Doe May 31 '13 at 18:20
1

Finally solved it.

When using Auto-Negotiation, Parallel Detection is used to determine the link speed when the other device is not capable of Auto-Negotiation.

The concern raised by Hauke Laging is a valid one, especially in this case as a duplex mismatch can cause a link to be established but an extremely slow connection. When using Parallel Detection both devices should default to Half-Duplex though, since it would be impossible to tell if a device was capable of full / half duplex just from the LTP which is transmitted by a device which doesn't support Auto-Negotiation.

In my case the black box was failing to do Parallel Detection and was defaulting to 100M despite the spec claiming it supported Parallel Detection. A Firmware update fixed this.

The reason that the link worked to my PC was that even when I limited my NIC to 10M HD, it was still using Auto-Negotiation to communicate it's capabilities, and so the black box correctly detected the required rate. Likewise, this worked perfectly when connected to a switch as the switch detected both the LTP and AutoNegotiation pulses correctly.

Thanks for all the helpful comments and useful links. If anyone has a similar issue I would be happy to help debug.

Weir_Doe
  • 191
  • 5