Can you please send screenshots of how you did it ? Or maybe explain it ? Thank youI tried, it works
Keeplink KP-9000-9XHPML-X-AC / fw 100.9.4
Can you please send screenshots of how you did it ? Or maybe explain it ? Thank youI tried, it works
Keeplink KP-9000-9XHPML-X-AC / fw 100.9.4
It does work. I don’t understand how, but I’ve put the ip address I wanted and it’s working. I’m wondering if internally, it’s assigning the static ip to all the interfaces and hope for the best.Nothing special, i use a static ip (no vlan possibility there) and have the vlans and port memberships configured.
Te SFP+ ports is member of all vlans and connected to my uplink switch on a port that has also all vlans configured.
The GUI is reachable on the static ip address that has its subnet on one of the vlans (from my PC that is part of another vlan and connected to the main switch and router)
Reply deleted, I had wrong infoAlso the fact that we cant specify the VLAN for management is a bit annoying as I'm not using VLAN 1 on my network and I didn't want to add routing in my OPNsense for VLAN 1, so I ended up doing a port isolation on LAN 8, and assigned access VLAN 1 only on LAN 8. Then I connected this port to an access port on my other switch that was set to Access VLAN 10. I'm wasting a port, but at least all is well now as that switch's VLAN 1 is now flagged as VLAN 10 just like the rest of my network.
a trunk port that carries vlan 10 is also connected to the switch and cannot reach the specified IP through the trunk port. It seems like it is only on VLAN 1I expect they assign the IP address to the cpu port (do not know the exact naming) and any vlan, and not a single physical port or vlan. So you can reach the IP address on any port of the switch as long as the management vlan on the switch exist and your workstation is in the right ip range or your router is allowing the workstation access to the management vlan10 through routing
So in theory you should not have to sacrifice a port to "map" a vlan1 port to a PVID 10 port on another switch just to make it reachable on vlan10, any port on the switch carying vlan10 should make it reachable from the rest of your network
Hmmm, I am confused why mine is working now. I will modify my post to not make others try this as well.Hi!
I just got a couple of those switches with the idea of them floating in my workshop if I need a managed switch here and there, and have easy access to a couple of networks on my desk for random experiments.
When toying with the VLAN settings, I disabled the VLAN 1 on all ports - assuming the info here is correct and the switch listens on all VLANs. This seems to be false - I can no longer reach the switch and I'll be soldering serial console over the weekend it seems.
On a second switch, I tested this and I can confirm i listens for management only on VLAN 1. At least 1.9.0 and 1.9.1 do.
On the other hand, I might buy something different soon, since I have little confidence in these switches...
Firmware Version | V100.9.4 |
---|---|
Firmware Date | Aug 07 2024 |
Hardware Version | V1.1 |
I think I see where I went wrong;a trunk port that carries vlan 10 is also connected to the switch and cannot reach the specified IP through the trunk port. It seems like it is only on VLAN 1
Mine is hardware rev 1.1 and firmware 1.9.1 if that matters
Yeah, the reset button worked fine. It was a bit too late and i glanced right over it, figured out it's not there, and went to sleep. UART works fine, 3.3V, well labelled, there is a repo that documents some of the commands on github. They seem to work, no command to change the management vlan though.Do you not have a reset button on the switch?
Thank you for that at least the uart is working on that...I’ve dump the ROM of my KP-9000-9XHPML-X-AC switch. It is version 100.9.5. It’s a dump after a reset. The defaut IP is 192.168.1.168 and the password is admin / admin. The MAC Address of the switch is at position 1FC000, you should change it if you plan on using this dump. If you want to download it : KP-9000-9XHPML-X-AC_V100.9.5.bin .
hi if i flash your pathed version i don´t get any output from UART, SWTG115AS-V2.0 bougt as web managed, if i flash the firmware for the 8 port i at least get the bootloader but then errors out because of hardware missmatch ... flash installed 25Q16, can not use firmwar from git as it is 4MB oposed to 2MB available on that chipNot sure if there's another thread about the 5/6-port, but after some hacking I was able to successfully flash the unmanaged SWTG115AS-V2.0 (5x2.5G) board - mine is SODOLA brand - to the managed version. I guess the SFP+ cage would work too if it were fitted, but I don't need it and it's a bit of tricky soldering, so I didn't try it. All of this very likely applies to the SWTG118AS-V2.0 unmanaged boards as well, the firmware is nearly identical, though maybe slightly different patch locations.
Unfortunately I don't think this is going to be possible without hardware hacking, as at least on my PCB only 4mbit of flash was fitted - the managed image needs a minimum of 16mbit and the OEM managed boards seem to have 32mbit fitted. So I didn't spend too much effort trying to reverse engineer the unmanaged firmware.
You will need to acquire an appropriate flash chip (I used W25Q16JLSS but probably any 25Q16 or 25Q32 in SOIC8 would work - I had 16mbit on hand, but 32mbit is probably a better choice to match the OEM hardware), < $1, and have a means to program it (I used a TL866, but CH341A 'bios' programmers should do the job for cheap), then swap it with the chip on the PCB (U8).
There are two checks in the firmware that need to be bypassed to make this work. First is a check of the unique ID programmed in the flash itself - this is meant to be unique _per chip_, but it's used as an 'authentication' scheme here. It's not possible to change this in widely available flash chips, so the only way around it is to patch the check. The second is the firmware's embedded checksum, which the algorithm hasn't been found yet afaik so must be bypassed.
In the v1.9 bare images (from up-n-atom's github repo - ie. not the firmware update files), patch 0xdd406 and 0x651c from 0x60 to 0x80. You might want to also patch the MAC address at 0x1fc000, I used the vendor's base 1c:2a:a3 with a random suffix for mine. Or use the attached image (but has MAC aa:bb:cc:dd:ee:ff).
Thanks to this github thread from libc0607 who did the hard work, I just interpreted the thread to figure out exactly what needed to be patched. Their switch hardware seemed to get stuck in a reset loop after similar patching, but apparently my board doesn't have this problem as it works fine.
If you do attempt this, note that using the internal updater will probably brick your unit until you remove the flash and reflash your patched image, unless you patch the new binary similar to above (but presumably at different addresses).