-
Big Test MFG says our Ethernet Chip violates the IEEE standard - are they right?
Posted by
metrologist
on 19 Oct, 2021 19:45
-
Edit: it is a test equipment manufacturer acting as a customer to evaluate one of our new products - they were simply trying to connect to the instrument through Ethernet using a cat3 cable probably wired with a modular 8P4C plug (1236), and there was no talking until they went to a cat5 8P8C. So would this be an implementation flaw?
=== fake news:
A big one you will all know and love says that because our Ethernet port (RJ45 plugs), has a design flaw because it does not support a cat3 cable (RJ11 plugs).
Does the IEEE standard actually state that the physically different plug must be supported?
-
#1 Reply
Posted by
joeqsmith
on 19 Oct, 2021 20:01
-
A big one you will all know and love says that because our Ethernet port (RJ45 plugs), has a design flaw because it does not support a cat3 cable (RJ11 plugs).
Does the IEEE standard actually state that the physically different plug must be supported?
I would like to see the actual report if its available.
-
#2 Reply
Posted by
wraper
on 19 Oct, 2021 20:21
-
Title says it's the chip but it's about the port. What IEEE standard in particular? There are many. Sounds like utter BS, even latching mechanism is not compatible between them.
-
#3 Reply
Posted by
ve7xen
on 19 Oct, 2021 20:23
-
Do they call out the clause and standard they think is being violated?
The only IEEE 802.3 PMA supporting Cat3 that would be relevant is 10base-T. Clause 14.5.1 of 802.3-2018 (in the 10base-T MDI section) says:
Eight-pin connectors meeting the requirements of Clause 3 and Figures 1 through 5 of IEC 60603-7:1990 shall be used as the mechanical interface to the twisted-pair link segment. The plug connector shall be used on the twisted-pair link segment and the jack on the MAU. These connectors are depicted (for informational use only) in Figure 14–21 and Figure 14–22. The following table shows the assignment of signals to connector contacts.
So I don't see anything requiring the RJ-11 (6P2C, or the RJ14/RJ25 variants with more conductors) be compatible with the jack, and they specifically require an 8-pin connector (RJ11 etc. are 6-position), however I don't have access to IEC 60603-7:1990, which perhaps does specify a mechanical backwards-compatibility. This requirement also doesn't make sense in context, since pin 1 is used in 10base-T, and this outer pin is missing in RJ11, so you would never achieve a functional link using those connectors with any 10base-T or any other -T PMA; they all use pin 1.
-
#4 Reply
Posted by
wraper
on 19 Oct, 2021 20:37
-
Also CAT3 does not mean 6 wires. It can easily have 8 wires or 200.
-
#5 Reply
Posted by
ejeffrey
on 19 Oct, 2021 21:55
-
Definitely they should cite which standard and the specific section they think you are violating. You should be able to look at the cited text to see if what they are claiming makes sense.
8P8C jacks are designed to (poorly) accommodate 6P/2C plugs and cables. In some cases this was used to allow a combined ethernet/phone jack with the phone on pins 4/5 which are not used on 10baseT or 100baseT. I guess somehow an 8P8C jack that can't physically fit a 6P2C cable plug might be in violation of the mechanical standard for the jacks. I'm not sure exactly how you would make such a jack, and if you did I would consider it a feature since 1G networks use all 4 pairs and so plugging a phone in can't work, and any actual ethernet standard needs pin 1.
Cat3 is the cable standard, not the plug/jack.
-
-
OK, then I did not know cat3 was/could be or is required to be 8-pin. I think the difference has something to do with the twisting rate and wiring.
Then why wouldn't a cat3 cable work? As far as I know there are two wiring standards, TIA/EIA 568A and TIA/EIA 568B, and does it matter if they were using a crossover cable?
They specifically said it was an older Cat3 cable, which often has fewer wires, or just 4 (1,2,3,6), whereas cat5 has all 8. I assume they were using two twisted pairs in that configuration (maybe as 8P4C), but then is that cable required to be supported in the Ethernet standard?
-
#7 Reply
Posted by
ve7xen
on 19 Oct, 2021 23:19
-
What does the report *actually say*. It seems like at least part of the problem here is that you don't have enough domain knowledge to properly interpret the report. Does the cable not mate with the connector? Not establish link? Not pass data? Have an excessive loss rate? What are the details of the test setup ... etc.
With the new information it sounds like they may be testing a cable with only 2 pairs, which is adequate for 100base-TX or 10base-T. It would still use the 8P8C connector. It should still work *for 10base-T or 100base-TX*, however 1000baseT+ equipment configured for autoneg would negotiate 1000base-T but due to the missing pairs, fail to work. This would be the expected outcome; there is no requirement for link segment testing, and most equipment doesn't do anything of the sort.
Crossover 'matters' if neither side supports AutoMDIX, but I'd expect a test house to be using the 'correct' type of cable for their test environment regardless of AutoMDIX. Which type they should use depends on what they are wiring the DUT to.
-
-
Why do you care what they say?
-
-
Guise, I just have an email. It's not a report. They are not testing a cable.
They want to interface with the equipment via SCPI commands using our Ethernet port. They grabbed an old cat3 cable and spent a while trying to resolve a no communication issue. They emailed us back saying they figured out the problem, they used a cat5 cable and it worked fine; therefore, they conclude we have a design flaw because the "Ethernet specification" says cat3 cables should be supported.
I'm trying to understand what the issue could be (if it's not just an old broken cable, and I'd expect they'd know better, or maybe not if they are using crusty old cat3 cables???). It was my mistake to assume they were using a 6p connector, and maybe they were, the email did not really say, but I now assume it's an 8P type of ethernet cable marked cat3.
So, is it likely we have a design flaw and what could it be? I'm sure we are using a COTS Ethernet chip, I could probably find out which one. Maybe it's the PCB layout and pin configuration?
-
-
Guise, I just have an email. It's not a report. They are not testing a cable.
They want to interface with the equipment via SCPI commands using our Ethernet port. They grabbed an old cat3 cable and spent a while trying to resolve a no communication issue. They emailed us back saying they figured out the problem, they used a cat5 cable and it worked fine; therefore, they conclude we have a design flaw because the "Ethernet specification" says cat3 cables should be supported.
I'm trying to understand what the issue could be (if it's not just an old broken cable, and I'd expect they'd know better, or maybe not if they are using crusty old cat3 cables???). It was my mistake to assume they were using a 6p connector, and maybe they were, the email did not really say, but I now assume it's an 8P type of ethernet cable marked cat3.
So, is it likely we have a design flaw and what could it be? I'm sure we are using a COTS Ethernet chip, I could probably find out which one. Maybe it's the PCB layout and pin configuration?
Sounds like a total non-issue - who hasn't got cat5 cables coming out of their ears?
How many people have even heard of cat3?
-
#11 Reply
Posted by
ve7xen
on 20 Oct, 2021 00:20
-
I think people (myself included!) have misinterpreted your post to mean that a test house failed you on compliance and provided a report saying so, not that they simply had trouble using your product with a Cat3 cable. I don't think it's really reasonable to expect a Cat3 cable to 'just work' with modern equipment, it won't meet spec for 100base-TX or better, and almost all Ethernet interfaces are 'or better' these days. So outside of curiosity, this seems like a don't care to me.
Does your product support 1000base-T (Gigabit Ethernet)? Pretty typical for a Cat3-era cable to only be two-pair, and if they were connecting it to 1000base-T equipment on both sides, a 1000mbps link will be negotiated, but fail to function at all with the missing pairs. It wouldn't meet the integrity requirements for > 10base-T anyway, even if it did link, so there would be no expectation of it working properly (though it likely would, at least for a short run), and most modern equipment is going to want to link up at 1000base-T.
If it's 100baseTX or 10baseT, it could be a crossover issue, depending on whether your/their side does AutoMDIX or not. Almost any PC these days will do it, but an old switch or whatnot that's been sitting in their equipment rack for 20 years they might be plugging it into may not.
You can mess up the PHY implementation, of course, but not really in a way where an improved cable spec would help (it mostly affects crosstalk and the like), at least that I can think of. This is typically all handled in the COTS PHY and you simply wire it to magnetics and the jack that are also purpose designed. I'd guess it's one of the above things (missing pairs, crossover, out-of-spec) or that the cable is simply bad.
-
-
Thanks - yes - sorry - my OP was poorly constructed. Trying to squeeze something in between doing other things. I did mean to state in the title, Big Test Equipment MFG...
I don't have access to the specification but it seems reasonable that it would state backward compatibility, so I'd expect the system to fall back to 10Base-T, and if our implementation does not do that then I'd be inclined to agree with the customer. The interface supports gigabit, but would only be used for sending settings, like for a function generator. We even supply PC software with a simple interface for remote operation - as simple as entering the IP address.
-
#13 Reply
Posted by
wraper
on 20 Oct, 2021 08:44
-
Thanks - yes - sorry - my OP was poorly constructed. Trying to squeeze something in between doing other things. I did mean to state in the title, Big Test Equipment MFG...
I don't have access to the specification but it seems reasonable that it would state backward compatibility, so I'd expect the system to fall back to 10Base-T, and if our implementation does not do that then I'd be inclined to agree with the customer. The interface supports gigabit, but would only be used for sending settings, like for a function generator. We even supply PC software with a simple interface for remote operation - as simple as entering the IP address.
If the device on the other end supports more that 10Base-T, it's not surprising that connection would fail. I guess in such case you would need to manually limit your device to 10Base-T for it to work over crappy cable. Or neither or devices supports Auto MDI-X and require crossover cable to work (and they had a straight-through one).
-
#14 Reply
Posted by
tszaboo
on 20 Oct, 2021 10:30
-
Maybe they told you that, because your specification for the test wasn't appropriate (technical sense).
Should it even support Cat 3 in the first place? Is there a sectional part of the standard that you should've asked for for the certification?
Some testing house will know if your product will fail some obscure, outdated, or rarely used part of a standard, and only test that, and charge you full price for the testing. Because they will know, that 95% of the DUTs will fail and it is less effort for more money.
-
#15 Reply
Posted by
tooki
on 20 Oct, 2021 12:24
-
A few thoughts/summaries in addition to what’s been said already:
- I don’t have access to standards to check, but I suspect that backwards-compatibility is customary, but not required, because I think I’ve seen uplink ports on (gigabit or lower) switches that don’t support all lower speeds.
- 10Gbps Ethernet ports seem to have dropped support for 10Mbps Ethernet. (I’m not sure about 2.5Gbps ports.)
- 10Mbps Ethernet requires Cat 3 cable (using two pairs), but requires the 8P connector. It cannot be used on a 6P4C connector.
- 100Mbps Ethernet requires Cat 5 cable, but still only uses two pairs.
- Gigabit requires Cat 5 cable, but requires 4 pairs.
- Typically if two gigabit devices are connected with a two-pair cable, it’ll drop down to 100Mbps. (There’s no fallback to 500Mbps or something.)
- Auto-MDIX is mandatory for gigabit ports, but optional on lower speed ports. I want to say that I’ve seen or heard of ports that will not do auto-MDIX at 10Mbps, even if they support it at higher speeds.
I agree with the suspicion that both devices support at least 100Mbps, and thus expected Cat 5 cable even when just two pairs are in use, so they tried running 100Mbps over Cat 3, which is unlikely to succeed, and indeed did not.
Given the fact that Cat 5 patch cables were the norm even back in the heyday of 10Mbps Ethernet, Cat 3 cable certainly isn’t a usage scenario I’d worry about. I can’t even remember if I ever saw Cat 3 patch cables in the wild other than as pack-in cables with things like DSL modems. It seems to me that most Cat 3 cable was the stuff installed in the walls.
-
-
So I see mention of MDI and MDIX and what I see are two twisted pairs 8P4C, pins 1236. I also see token ring configuration using pins 3456. I suppose the latter would not be compatible with modern 10/100/1000 networks.
-
#17 Reply
Posted by
T3sl4co1l
on 20 Oct, 2021 15:59
-
Ask them to test some PCs with the suspect cable and confirm your device is specifically failing.
Though if your interface is missing those nice features (AutoMDIX), the cable fault might be hidden because almost everything does support it. The question then would be, why doesn't yours? So, a possibility there, or have them try other cables, or more closely replicate your configuration in case it really is something.
Tim
-
#18 Reply
Posted by
PaulAm
on 20 Oct, 2021 17:11
-
And maybe, since they used a cable with an RJ11 connector, it was just an old phone cord.
Who would plug in an RJ11 into an RJ45 jack and expect it to work?
Even when I was running wires in the dim past, I only used Cat3 for phone lines and everything else was cat5. And that's gotta be at least 15 years ago.
And I hear you say "phone line? what's a phone line?"
-
-
If I can get access to an instrument, I'd probably make or find a cable straight wired pins 1236 and try it through the LAN or direct to NIC. If both connections work then we don't have an issue on our end.
-
#20 Reply
Posted by
ve7xen
on 20 Oct, 2021 19:30
-
I don't have access to the specification but it seems reasonable that it would state backward compatibility, so I'd expect the system to fall back to 10Base-T, and if our implementation does not do that then I'd be inclined to agree with the customer. The interface supports gigabit, but would only be used for sending settings, like for a function generator. We even supply PC software with a simple interface for remote operation - as simple as entering the IP address.
That's not the case. Autonegotiation is completely unaware of cabling limitations, and doesn't compensate for them. The two devices will negotiate their highest-common-denominator and attempt to establish link. If pairs are missing, and that HCD is 1000base-T (or 10GBASE-T), then link will simply fail to establish and the autoneg process will repeat ad infinitum. Some clever PHYs will retry autoneg without offering 1000base-T after repeated failed attempts, and succeed at 100base-TX link, but this isn't required (or even mentioned) by the spec, and I can confirm it is not implemented in many popular PHYs/drivers. Typically link will just fail if there are missing or broken pairs. If the cable is complete but out of spec (e.g. using Cat3 for 1000base-T), link may or may not come up, and may or may not work at an acceptable loss rate, it's simply operating out of spec, similar to going beyond 100m.
tl;dr you should not expect a 2-pair cable to work at all between two 1000base-T+ interfaces, unless you manually force them 100mbps.
And as tooki points out, the 10base-T PMA isn't required to be implemented, and modern equipment is starting to omit it, though plenty of 10GBASE-T stuff does.
Auto-MDIX, if implemented on one side, should work even if it's not supported by the link partner, on any PMA including 10base-T (it happens prior to autonegotiation). It's actually optional for 1000base-T PHYs, but is almost always implemented; it's required as of 10GBASE-T.
-
#21 Reply
Posted by
Ranayna
on 20 Oct, 2021 19:43
-
Huh, i don't think that that is correct about auto negotiation. At least not in any implementation i ever saw. It also does not really make sense. It should be trivial to detect that pairs are missing, so that gigabit negotiation would be pointless.
It has been a while, but a couple of years ago, one of our office buildings was still wired with what we in germany like to call "Sparverdrahtung". Essentially one CAT 5 cable for a double ethernet jack, so just 2 pairs on 12 and 36.
I do not remember that we ever had to set 100 Mbit/s on any of our networking gear. And it is not that the cable itself or the jacks did not support gigabit. In several instances where speed was required we re-wired the jacks on both ends to have one gigabit capable port, and those worked fine.
-
#22 Reply
Posted by
nctnico
on 20 Oct, 2021 20:51
-
- Gigabit requires Cat 5 cable, but requires 4 pairs.
AFAIK Cat 5E actually. I had to redo a lot of wiring to replace plain CAT5 because it didn't work for 1Gbit.
-
#23 Reply
Posted by
ve7xen
on 20 Oct, 2021 21:28
-
Huh, i don't think that that is correct about auto negotiation. At least not in any implementation i ever saw. It also does not really make sense. It should be trivial to detect that pairs are missing, so that gigabit negotiation would be pointless.
It's correct. 802.3 says to always try the highest-common-denominator. The only way out is for one side to lower its advertised capabilities based on the link failures (or the administrator's awareness of the cabling limitations), to change the resolved HCD. Many 1000base-T PHYs do implement this (often called 'automatic downshift' or 'speed fallback'), kind of like AutoMDIX (though somewhat less common), but it's not part of the spec. In theory I suppose you could even do it in the driver. Many ports explicitly don't do this, particularly in networking equipment, as down link is often a better situation than a downgraded link, with the assumption that if this is desirable end-stations may implement it (and commonly do).
Auto-Negotiation does not perform cable tests, such as detect number of conductor pairs (if more than two pairs are required) or cable performance measurements. Some PHYs that explicitly require use of high-performance cables, may require knowledge of the cable type, or additional robustness tests (such as monitoring CRC or framing errors) to determine if the link segment is adequate.
...
Provision has been made within Auto-Negotiation to limit the resulting link configuration in situations where the cabling may not support the highest common capability of the two end points. The system administrator/installer must take the cabling capability into consideration when configuring a repeater port’s advertised capability. That is, the advertised capability of a hub port should not result in an operational mode that is not compatible with the cabling.
-
#24 Reply
Posted by
ejeffrey
on 20 Oct, 2021 22:04
-
- Gigabit requires Cat 5 cable, but requires 4 pairs.
AFAIK Cat 5E actually. I had to redo a lot of wiring to replace plain CAT5 because it didn't work for 1Gbit.
Really? I've haven't looked a that extensively but I have never seen a cat5 cable fail at a gigabit speeds. The initial version of 1000Base-T specifically called for cat5 but with slightly modified specs -- I think only for NEXT which was not specified in the cat5 standard but which most existing cat5 cables supported. Cat5e was then published and cat5 withdrawn and the ethernet spec modified to call for cat5e.