Thats's it... awkward 
Since both the router and the switch had 192.168.1.1, it was of course not accessible.
It is now running fantastically. :))
2 Likes
Does anyone have a clue about the difference between the ZyXEL XGS1210-12 revisions? There's the original ZZ0101F from 2019, and a newer ZZ0102F revision which seems to have hit the market this December. And you can still get both, it seems. Wikidevi has no info on revisions.
I have no experience with either. But the two revisions are mentioned in the most recent User’s Guide found on https://www.zyxel.com/global/en/support/download?model=xgs1210-12
There are some cosmetic differences on the front panel and this:
Note: XGS1210-12/XGS1250-12 rev.B1 only support firmware version V2.00 or later.
which I guess implies that there are technical differences affecting firmware support. I guess we must consider rev B1 unsupported for now.
1 Like
Thanks. I suppose ZyXEL won't be switching its switching SoCs, that would be more expensive than just another iteration.
I've just got a JG926A (HP 1920-24G-PoE-370W), which I'd like to add support for. Differences from the non-PoE version (J924A) are the cooling fans and PoE interface. My plan is to have a look at janh's tree for fan speed control, and at the 1920-8G-PoE support for the PoE components. Anything else I've missed?
There is nothing related to fan control in my tree, as the fan in the JG927A can't be controlled (which is unfortunate because it is quite annoying).
However, fan control is already supported for JG922A (see 03_gpio_switches), and it should work in the same way for JG926A.
1 Like
Thanks for the hints. I think I've got all functionality working now. Fan GPIO on the JG926A is identical to the JG922A, as you said...
I'm wondering about the fan support. The OEM firmware defaults to running the fan at full speed, and only turns it down after boot is complete. I don't know how the fan is controlled in the OEM software but I expect the fan controls are based on the values of internal temperature sensors and/or total PoE power draw.
The JG922A (hpe 1920-8G-PoE+ 180W) currently just leaves fan control up to the user, and defaults to low speed fan operation. I'm reluctant to replicate this for the 1920-24G-PoE+ 370W because I assume that there's at least the possibility that this could cause hardware damage, so until the OEM fan control behaviour is investigated and a more sophisticated solution is implemented in OpenWrt, I'm inclined to default the fan setting to full-speed - if the user wants to change the default config to run the fan at low speed, then they would do-so at their own risk. Thoughts?
I've created a suitable /etc/config/poe - the mappings from the lan port numbers to PoE ID numbers are a bit funky (1→8, 8→1, 9→16 etc.). What's the best way to get that file included in the OpenWrt image instead of the example file that the realtek-poe package ships?
I did the same for the T1600G-52PS.
That's the same as with the DGS-1210-28MP.
AFAIK, there is no method to get that in by default, but there was a recent discussion on github:
1 Like
Does anyone have a JG925A (HP / HPE 1920-24g-poe-180w) around they could test with? I may as well add support for that too (I have a JG924A non-poe, and a JG926A 370w version).
FYI, I've added a "Switches" view to the ToH - https://openwrt.org/toh/views/start
7 Likes
I thought I'd have a look at fan control on the HP / HPE 1920-24g-poe-370w (JG926A). The fan speed changes a few times during boot - uboot seems to set it high. With the stock firmware, when the kernel loads the fan speed briefly switches low speed, before going high again. With no (or light) PoE load in normal room temperature, the fan speed goes low again a few minutes after boot.
My working hypothesis is that fan speed is controlled by some combination of:
- Has a fan failed (low/zero rpm reading)? If-so command fan speed to max (confirmed by manually stopping one fan - this is consistent with my experience of the fan behaviour on other HP switches in the past).
- One or more temperature sensors (unconfirmed).
- PoE power load (because this would lead to the generation of more heat within the power supply - also unconfirmed).
Searching for Fan in snmp shows a signal:
hh3cDevMFanStatus.1 ... when all fans are running freely this returns active(1). When one or more has failed it returns deactive(2).
As it happens I already knew this hardware signal existed because I had spotted it in OpenWRT when mechanically disabling one of the fans and running a command to print GPIO values. I'd guess that there is a fan control IC (or maybe a microcontroller) in there, and it has a 'failed' gpio output. There is just one GPIO input which toggles when at least one of the three fans is stalled. I haven't opened the case on one of these to check what ICs are present.
With the stock firmware if there are no fan failures for some time period (half an hour or so) then the fan speed returns to low speed.
I thought I'd search for any temperature sensor onboard in the output of snmpwalk (from net-snmp package). The firmware returns multiple temperature SNMP data points, but they are all either 0 or 65536. I'd guess that these are all bogus and the same snmp server code is shared with higher end 3Com and 3Com-derived H3C/HP/HPE hardware which did have such sensors.
display diagnostic-information is more promising. The section debug poe port-power 1 includes per-port temperature values. On my hardware these look a bit weird. My best guess is that the PoE hardware is based on 3x blocks of 8 ports (based on power to logical port numbering - see previous post). I'd guess that each has an ADC, attached to a set of thermistors or similar. In a switch which has been on for a while (I measured the case temperature at 22 Celsius, room temperature 21 C), the port "Temp" column values are:
ports 01 to 08 -> 12, 12, 12, 12, 12, 12, 12, 12
ports 09 to 16 -> 19, 19, 19, 19, 18, 20, 20, 20
ports 17 to 24 -> 08, 08, 08, 08, 09, 08, 08, 08
No units are stated in the output. Could be uncalibrated absolute temperature values, or it could be headroom values or anything else.
I also noticed in the display diagnostic-information output (and also the snmp output) - there is an item in the process list FanT - which might be some sort of fan speed control daemon, but I haven't investigated that further, or checked to see if it's absent on switches without fans/PoE.
So some progress. I was hoping for some temperature sensor which I could easy create a devicetree entry for, and then get the kernel to control fan speed, but doesn't look like that's (easily) possible...
1 Like
I have a JG925A that isn't in active use, but would love to see OpenWRT on it. Let me know how I can help you out. Thanks for your work on the 1920 series.
1 Like
So. The seller - ZyXEL partner, it turns out - had both XGS1210-12 revisions available, but I took a bit of a gamble and asked them to ship the ZZ0102F. So I got that recently. From what I can tell, the main difference is ZyXEL switched to RTL8221B 2,5 GbE PHYs, which seem newer than the 8226 ones on the 1F revision. Have no time to test OpenWrt on it for now, but I hope to find some in the weeks to come.
1 Like
I don't see support for the XGS1210-12, only the XGS1250-12. Is there an un-merged patch somewhere for the XGS1210-12?
There's this draft PR, but it contains other stuff as well besides pure device support:
Hey,
I've seen there was some work done around getting the network on XGS1250-12 switches up and running without assistance of the vendor u-boot. Is there anything that has survived in terms of code from this effort?
I'd love to take a look at it (mostly to resolve the current state of the switch bridging all ports on bootup due to the u-boot based network init).
I will buy a JG925A too, since my current POE switch just got hit by lightning 
@dmascord @ljanzen I've pushed my WiP tree for the 24 port HP 1920 24+4 port PoE switches (JG925A and JG926A) to https://github.com/tim-seoss/openwrt/tree/hpe-1920-24g-poe-370w-jg926a
Known issues and/or TODO are:
- When the kernel resets the GPIOs, it sets the fan to run at low speed (this might be a bug), and the gpio-fan kernel module has the policy of not changing initial state (it should be set by firmware). This is bad since it can almost certainly lead to hardware damage under high load and/or temperature conditions. See: Support for RTL838x based managed switches - #2668 by TimSmall
- Switch the fan speed to high with:
echo 10000 > /sys/devices/platform/gpio-fan-chassis-a rray/hwmon/hwmon0/fan1_target(FIXME: this should be done by default at boot time). - Fan speed should switch to high based on whatever algorithm HP/H3C/HPE uses.
- Failure of an individual fan (indicated when
/sys/devices/platform/gpio-fan-chassis-array/hwmon/hwmon0/fan1_alarmreads1), should also trigger a switch to high fan speed (i.e. if one fan fails, then the others should switch to high speed and/or high speed selection might free a stalled fan).
The script below will create a poe config, needs integrating...
#!/bin/bash
NUMPORTS=24
TOTAL_POWER=370
# TOTAL_POWER=180
SCHEME=block-reversed
echo "config global"
echo " option budget '${TOTAL_POWER}'"
for p in `eval echo {1..${NUMPORTS}}`
do
BLOCK=$(( ( ( ( $p - 1 ) / 8 ) + 1 ) * 8 ))
ID=$(( $BLOCK - ( ( $p - 1 ) % 8) ))
echo
echo "config port"
echo " option name 'lan${p}'"
echo " option enable '1'"
echo " option id '${ID}'"
echo " option poe_plus '1'"
echo " option priority '2'"
done
1 Like
Hello all!
Exciting times! I see some stuff happening on the repo! Great. Its nice seeing others contribute.
Only sad thing to see was, that it seemed someone was taking commits and pushing them as their own. Or they just had the same idea.
But since we are now in a 'moving' state again, where we actually want to do things and actually merge stuff. I got a bit excited. Also the discussion about moving to 6.6 and skipping 6.1 was great. Plus sander found out why my 6.1 tree wasn't building.
So maybe I can find some energy and continue the mission 
4 Likes
Is there any preferred method to give LEDs a useful name, maybe by listing them in the dts?
On my Zyxel GS1900-24HPv1, the PoE LEDs for port 1..24 are accessible via /sys/kernel/debug/rtl838x/led/led_sw_p_ctrl.* where each port has led_sw_p_ctrl.$(portnum-1) . No idea about the meaning of led_sw_p_ctrl.24 to led_sw_p_ctrl.27, those seem not to have any visible effect on writing.