Ethernet silly question time...

[peteb2]

I have multiple pieces of 'vintaged' PCBs with a couple of RJ45 style Ethernet sockets that appear to be connected to a couple of Broadtech B50610 series (obsolete) 10/100/1000Base-T Gigabit Ethernet transceivers. I need to know if the things are viable which i guess would be possible by attaching the unit to a Switch & so my Win7 PC & running up some sort of basic as hector Network interrogation SW that will in the least reveal these chips are viable by whatever standards data packet the chips put on the Network at power on.... I'm no IT tech. All this stuff always just worked so i have never really studied it. Am i simply flogging a dead horse or is there a free (cheap) SW that can do something? I have the Nirsoft options but nothing appears to happen other than light up the Send receive LEDs on my Switch. I've played with Wireshark also without any obvious stuff happening... Cheers & thanks for reading my most silly question ever....

[westfw]

Any transceiver that handles gigabit rates should have pretty standard operation at the physical layer, assuming that they're not specifically configured to do something weird.

That doesn't help at all if your problem is trying to figure out what SW protocols they're running on top of the ethernet.  They could be doing anything from bare ethernet to CLNS/TP4 (or Novell Netware, Banyan Vines, etc, etc...)

[Nominal Animal]

is there a free (cheap) SW that can do something?

Wireshark in promiscuous mode (in the capture options dialog) is a good start, I believe.  I don't use Windows myself, so can't help much there.

In Linux, I just use a dedicated Ethernet port, bring it up (using ifconfig), and use tcpdump to examine all traffic going through that port.  Despite its name, tcpdump can do link-level (Ethernet protocol) stuff, and does promiscuous mode automatically, but requires superuser privileges to do so.

Next step is to fire up nmap and do a portscan on the device.  Because port scanning is frowned upon, it is important (to me, at least) to do this on an otherwise unconnected network.  Typically, I'll also have to set up a DHCP server on my machine, to respond to "please give me an IP address" requests by the target device.  For that, I typically use dnsmasq.  For some single-board computers and appliances, BOOTP and TFTP servers are also useful.

This is such a common scenario, that the aforementioned utilities are either installed by default, or available via the package manager, in all Linux distributions.  (Careful organizations run nmap portscanners on their own machines, to detect suspicious network activity, for example.)

So, the free tools definitely do exist; it's just that most people who do this kind of stuff tend to eventually migrate to the Unixy side (Linux, mac OS, FreeBSD, OpenBSD) where these tools are widely used and developed; most servers on the net do not run Windows.  Some of the software like Wireshark, have been ported to Windows and given a nice user interface, too; but not all.

(Note: I am not saying "X is better than Windows for this".  I am only describing why I believe it is somewhat harder to find these tools on Windows than on the other systems, and that it is not that they don't exist, it is that most of the users wanting these kinds of tools tend to drift to other OSes.  Even though Tux the penguin is my mascot, I'm no zealot; there is nothing wrong in using Windows – or any other OS – if it works for you.)

[pcprogrammer]

... Broadtech B50610 series (obsolete) 10/100/1000Base-T Gigabit Ethernet transceivers.

You mean Broadcom I guess. Datasheet: https://raw.githubusercontent.com/q3k/chubby75/master/5a-75b/datasheets/B50610-DS07-RDS.pdf

Quick scan shows it as just a transceiver and needs a processor to deal with protocols.

So what more is on the PCB to which this transceiver is connected?

Post some pictures of the boards and maybe you get some good answers as to whether the boards are usable or not.

[peteb2]

OMG, classic getting the name wrong for Broadcom! I guess my brain was locked into my previously dealing minutes before my post  with a business called Broadtech & well typo!

Here’s a top & bottom image of the board concerned as best I can achieve with a dated iPhone camera.  The FPGA Altéra Cyclone series EP4CE6F17C8N, the Broadcom B50610s have some goop coating them so they didn’t photograph well on the underside where there’s a STM32F051C8T6 microcontroller. This module’s task is to drive a coloured LED panel for a signage/video wall. There’s another crate tasked with converting the animation/still image to individual panel sections. That data travels over what I assume is Ethernet network via Cat5 cables but I cannot access that actual crate.

These LED panels have featured in my previous posts as there’s simply zero service info the “video wall” consists of 1000s of them. I’m tasked with doing an audit upon what spares are remaining which previously have been ruled U/S but all that’s wrong as the fail is simply bad supply volts connections.

Making sure the Ethernet style double connection on this module is viable while at the repair bench would be a massive asset.

[pcprogrammer]

Interesting boards

My guess is that they made switch functionality in the FPGA and created a third port in there to supply the STM32 MCU with the data to display on its section of the wall.

A simple test can be to connect the board in between a network switch and your computer and see if you can connect to the internet just as without the board in between. If you get connection you know it is set up as a switch and at least the routing through it works.

To figure if the rest of the board is working you would need to know the protocol used to address the STM32 MCU.

[ajb]

ahh yeah those are a pretty standard interface module for LED walls.  The interface is Ethernet (hence the Ethernet PHY), but not IP AFAIK.  I've heard of some projects to reverse engineer the protocols, but the easiest way to test those is probably to plug them into a suitable sender card and see if they're detected.  I'm not sure how feasible it would even be to send/receive raw (non-IP) Ethernet from a modern PC/OS.

Here's an example of a common sender card: https://www.amazon.com/LCCL-NovaStar-Control-Sending-MSD300/dp/B00W66M51S  

Note that the PCI interface is typically not used for data, it just allows the card to be installed in a PC chassis for convenience, with a jumper cable from a video card output back into the sender card.  You can use those cards on the bench just by applying power and USB/video connections.

[ajb]

My guess is that they made switch functionality in the FPGA and created a third port in there to supply the STM32 MCU with the data to display on its section of the wall.

They won't've gone to the trouble to implement an actual switch.  These video walls just need to handle a firehose of pixel data in one direction and then a small amount of control data bidirectionally, and they don't need to use IP.  So the simplest and most performant way to implement that is to shovel any data that comes in on one PHY right back out to the other PHY as it comes in (while throwing any shovelfuls of pixel data with the right ID at the pixel driver).  These walls can be hundreds of tiles, so store-and-forward latency would add up.  This also consume fewer resources than a switch implementation, leaving more resources available for the panel driving/control (which will also be implemented in the FPGA--the small micro is likely only there for housekeeping).