I have a D-Link DGS-1210-10P (revision F3) running OpenWRT snapshot.
When I use realtek-poe to talk to the PoE controller on /dev/ttyS1, it does not seem to turn on PoE. I'm including the output from realtek-poe -d below.
Notice the complaints about an invalid port number in response to command 0x28 ("get all port status"). Going by the documentation here, my feeling is that 0x61 it is some kind of error code, and not a port number. It also pops up in response to command 0x1a earlier.
Interestingly, when I change the port ID in /etc/config/poe from 1 to 2...
config global
option budget '170'
config port
option enable '1'
option id '2'
option name 'lan1'
option poe_plus '1'
option priority '2'
... the PoE device on the other end of the line turns on! The error about port 97 remains, however:
Does anybody have a recommendation on how to proceed with debugging? I suppose I could go out and buy a logic analyzer to snoop the traffic between the stock firmware and the controller, although I'm a bit hesitant to do this as I have no experience with these kinds of things.
Before going to a logic analyzer, I would check what happens if you enable all the PoE ports. @svanheule, @hurricos, do you have handy a known working realtek-poe config for the DGS-1210-10P ?
I would also look at the output of ubus call poe info
Maybe instead of getting a logic analyzer, I could connect a Raspberry Pi to the UART header and snoop it that way? My impression is that it's the same kind of interface as the serial UART header I had to use to install OpenWRT in the first place.
Thanks! I'm going to be away for a bit, but I think I'll try this first when I get back.
While is it a UART like any other, you need two input lines if you want to snoop traffic. Otherwise you can only follow traffic in one direction using the Rx line of you RPi. Probably best to also add a series resistor to limit current flowing to/from you sniffer (although Rx should be high impedance input).
The "no response" message indicates there's no reply to our messages, which look to be valid from the trace. This branch defaults to 115200 baud, which could be the issue. I recently added a -s flag to my development branch to use 19200 baud. I would try that first.
OK, that does improve things: the responses come in, but the error about invalid port statuses is still there. This time, it's in response to command 0x50 rather than 0x28, but going by the source code on your branch I think that comes down to the same command. Here's the output of realtek-poe -s -d:
The invalid port status is a known issue. Command 0x50 works on EnGenius, and only on EnGenius. We had the same issue in the BCM dialect.
What I need at this point is a serial trace (Rx and Tx) of the vendor firmware. There are a few initialization commands that I am unsure of. The trace would also tell us what port status command is being used.
OK, so I gave this a go tonight. I do not have a logic analyzer, so I hooked up two Raspberry Pis to J9 on the switch (using the documentation here), and I read out /dev/ttyS0.
I did not have a good way of wiring the GND of both Pis directly to the GND of J9, so I connected GND on the first Pi to GND on the switch's J9, and GND on the second Pi to (another) GND on the first Pi. This is probably not a great idea, but without this the second Pi only recorded gibberish.
Here are two dumps (run through od -x -w12 --endian=big). I started recording these before plugging in the switch, so they show what I was able to observe from a cold boot.
They are a bit more messy than I would have liked, but this is my first time doing anything like this, so I do not have a good baseline of what to expect.
If I squint I can make out some 12-byte sequences that look like frames, especially when the system has booted. For instance, the SoC tends to send the following frames:
4b ss : get power management config 43 ss 00 : get 4port status starting with group 0 41 ss : get system power
Those are all query commands. The interesting ones are the 0x and 1x, which do the system configuration. the capture is a bit de-synchronized, but it's easy to figure out the commands.
I basically ran a sliding window and kept all of the non-overlapping chunks with a valid checksum.
On a somewhat related note, I had was able to try realtek-poe on a ZyXEL GS1900-8HP earlier this week, and it seems to work quite well. Hats off to you and the other developers .
.