Do you have the iminfo command? This tests the validity of the transfered image. Try issue it after the tftpboot transfer
Yes, that passes just fine but it looks to be always checking the existing FW before booting anything.
Maybe try bootm 0x8f000000 to force the memory location of the transfered image
Already tried that, it always checks the existing FW which is stupid.
I mean, I can probably flash back stock FW using sf in U-boot
Or flash the one you just tftp-transferred ...
Not really, it has to be the stock FW, because its checking version of that.
At least, that is what it looks like to me
Maybe it is checking magic bytes that need to be in the image header?! Those would be defined here
Thats the thing, there is no custom magic defined for DGS series.
OpenWrt kind of currently relies on there being a stock FW on the second FW partition and then it passes the bootloader check.
It looks like they are using different endianess in stock FW and that is what the bootloader is most likely checking for because stock FW rootfs has sqsh while OpenWrt/mkfsquashfs produces hsqs as the magic.
So they gotta be using the old v3 Squashfs
1 Like
I actually thought I could just order one but it seems it won't be available any time soon. FS.com told me the earliest date for delivery will be around May/June 2022. That's why I cancelled my order. Still I hope one of those passively cooled 4x10G 24x1G Switches based on RTL9301 will someday be supported by OpenWrt. I would buy one right away.
Are there any known issues with switching or vlan configuration? I have been running up against an issue with the 21.02.2 (and earlier) where ports don't seem to forward ipv4 packets (ipv6 works). I seem to have a fairly vanilla configuration.
It appears that IPv6 packets pass flawlessly but that ipv4 is not being forwarded between ports (ARP lookup problem?).
1 Like
To debug this I've tried switching the switch back to the default configuration with a first_boot command. And I notice that, thankfully we no longer use the vlan 100 access system.
However I notice that the device, instead of appearing on 192.168.1.1 asks for a DHCP address.
Attaching it to a DHCP server will give it an address but then it doesn't accept web or ssh access on the issued address.
Short of reattaching a serial console, what's the right way to reconnect to a RTL838x (in this case a DLINK DGS 1210-28) switch?
For those interested I have started a device data page for the XGS1250-12. Feel free to amend/complete.
Currently discussing with the wiki moderators how to best accomodate the newer hardware with SFP/SFP+ and multigigabit RJ-45 ports, so people can filter on that stuff in the ToH.
2 Likes
Currently discussing with the wiki moderators how to best accomodate the newer hardware with SFP/SFP+ and multigigabit RJ-45 ports, so people can filter on that stuff in the ToH.
Rackmountable device would be nice also in ToH. There are some devices now in the list but it is very very hard to find.
2 Likes
I see that https://github.com/openwrt/openwrt/pull/4973 is merged. Yay!
I wonder whether using some backported kernel features which improve the random pool by using Blake3 there can help. Jason of Wireguard fame got that merged into 5.16 I think. Some quoted figures of a 2-300% output improvement.
I have experienced connections where one endpoint has jumbo configured, and the other, not, and the connection just craps out like this. Setting everything to ~1500 again got it working anew. (attention that both ends roughly agree on frame size)
I am curious how trivial it is to get some GS1900-24 and GS1910-24 devices I have running this firmware. I did not see these models explicitly mentioned, but implied. I would be happy to run the firmware, although some of my colleagues would be happier with a GUI. Does anyone here experience that there is typically enough flash space for luci things and trivial config of switch ports.. works?
My only concern is that there is no in-built serial console on the 1910-24 devices: I'd have to solder a header onto the board, I think. No shortage of irons or know-how in the office, though. The 1900-24 devices have a 9 pin dsub.
I had a support interaction with Zyxel recently, because their scheiße firmware failed to recognize an SFP which every other device in the office recognizes. "It's not an official SFP device...". GTFO.
With the above said: what kind of throughput could one expect on layer two? My use-case is mainly VLANs, with some (R)STP, and a few LACP - do we have those in owrt yet (I'm more acquainted with the WiFi side of things)?
The devices I am interested in are GS1910-24 and GS1900-24 of various hardware revisions.
I have on my desk a Zyxel GS1900-8HP v2, that runs the image I made from master 4ish days ago, just after merging #4973 (the big RTL-PR). POE works. but I haven't figured out, how to control power for individual ports. I bought that one, after finding the device mentioned in menuconfig.
As for serial port, the gs1900-8HPv2 has a "side-port", like some other zyxels, with 3.3V levels.
Since the merge of PR4973, I'm having trouble adding your commits for XGS1210-10 support. I suspect possible issues in my env, but just wanted to inquire, if things still apply cleanly for you?
Ah, thanks. Sorry, I forgot to mention that the devices I am interested in are the 24 port variants 1900-24 and 1910-24. None of them support PoE.
RE: LAG/LACP
Does the merge of 4973 change this picture somewhat?
It will need rebasing either way. You could check which commits are in the OpenWrt tree now but there's been changes and revisions before the PR got merged, so it will need careful inspection. Well, at some point git might just balk because the code doesn't apply anymore... Then you'll need to start digging either way.