<russell-->
mrnuke: what does it take to activate the sfp ports on the engenius ews2910p? i stuck some fs.com optics into the port on the off chance it would work, no joy.
<dwfreed>
maybe if they weren't using 5.5 year old firmware...
clandmeter has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
danieli has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
clandmeter has joined #openwrt-devel
danieli has joined #openwrt-devel
<russell-->
mrnuke: adding kmod-sfp to the build .config and moving the sfp module to lan10 seems to have worked
<svanheule>
russell--: only port 10 is fully supported, see commit 4d1fc8916c50 "realtek: EnGenius EWS2910P: add support for SFP ports"
<russell-->
svanheule: i don't quite understand the commit message, why is sharing sda and scl a problem?
<svanheule>
russell--: i2c-gpio requires a dedicated set of scl/sda lines, but the SFP cages use the same line for scl
<svanheule>
so you can't create a unique scl/sda set for both cages, only for one
<svanheule>
it's a stupid cost cutting measure by Realtek, and it's not compatible with anything currently supported by the kernel :-/
<russell-->
i2c often have multiple devices on the bus, still confused
<svanheule>
SFP modules are always at address 0x50 (and 0x51), so you can't have two modules on the same bus
<russell-->
ah, okay
<russell-->
that seems dumb, but okay
<svanheule>
the fixed addresses, the shared scl, or both? :P
<russell-->
the fixed address
<russell-->
most i2c devices have mechanisms to avoid collisions like that
<svanheule>
true, but they often only have a few bits of address freedom, giving something like 8 options
<russell-->
8 > 1
<svanheule>
an SFP cage would also need extra pull-up/-down resistors to indicate that it's the N-th cage
<svanheule>
in any case, sensible designs just use an external I2C bus muxer, and then you also only need two (GPIO) pins on your SoC
<svanheule>
plus maybe a few to select the muxed bus
<russell-->
what does the vendor firmware do?
<svanheule>
custom implementation that performs synchronous operations using one of the SDA pins, IIRC
<svanheule>
vendor firmwares on realtek switches barely use any upstream drivers...
<svanheule>
the Panasonic switches that are currently supported are about the only ones using a sensible design, allowing for (almost) complete feature support
<russell-->
seems like the device maybe ought to have a DEVICE_PACKAGES += kmod-sfp ?
<svanheule>
the realtek sub-subtargets already have CONFIG_SFP=y, so it should be built-in
<svanheule>
sub-targets**
<russell-->
the build i did on aug 6 has: # CONFIG_PACKAGE_kmod-sfp is not set
<svanheule>
that's because kmod-sfp is not needed if sfp support is already built into the kernel, no?
<russell-->
oh, you are talking about the kernel config
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
<russell-->
svanheule: confirm it works without kmod-sfp
<russell-->
thanks for unconfusing me
<svanheule>
russell--: yw
Piraty_ has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tapper has joined #openwrt-devel
<mrnuke>
russell--: port9 or port 10? They're tested working on the v1. Check the system log.
<mrnuke>
russell--: on port9, you also have to change the sff-p9-tx-disable GPIO (see /sys/class/gpio)
<mrnuke>
I really need to create a proper openwrt wiki page for thie engenius
<mrnuke>
svanheule: Don't you tell me how to spell Texas, boy! :p
<svanheule>
mrnuke: I was going to add "... unless that's the current spelling in Texas", but I deleted that :P
<mrnuke>
svanheule: That would have been awesome!
<svanheule>
mrnuke: did we ever discuss why you can't use mtdconcat on the engenius?
<mrnuke>
svanheule: Besides the stuff we discussed on github, no
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
bluew_ has quit [Ping timeout: 480 seconds]
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
<mrnuke>
svanheule: I have two main reasons I'm resisting mtdconcat on engenius.
<mrnuke>
svanheule: I've already talked about the bootloader interaction and nastyness with the DUAL_IMAGE bootloader
stintel[m] has quit [Server closed connection]
stintel[m] has joined #openwrt-devel
<mrnuke>
svanheule: The second reason is subjective: I don't like mtdconcat. I don't like how it doesn't prevent you from accidentally erasing any of its parent parttitions, or how it's entirely unclear from '/proc/mtd' what the hierarchy looks like
<mrnuke>
svanheule: mtdconcat was a good choice for the tplink (opinion) because the bootloader is so idiotic, it's hard to do worse.
<mrnuke>
svanheule: back to engenius, I thought about concating "firmware1", then "jffs2-cfg", and just restricting the uimage size. But then a bootloader-initiated factory reset would wipe jffs2-cfg, and probably some of your rootfs
<svanheule>
mrnuke: thanks, I was thinking about jffs2-cfg being wiped too. Not so much a problem if it's only rootfs-data, but if it also contains part of the rootfs partition...
<svanheule>
mrnuke: the bootloader doesn't support lzma by any chance?
olmari has quit [Server closed connection]
olmari has joined #openwrt-devel
pavlix has quit [Server closed connection]
pavlix has joined #openwrt-devel
<mrnuke>
svanheule: I remember testing something about lzma, but I don't remember the result
SlimeyX has quit [Read error: Connection reset by peer]
SlimeyX has joined #openwrt-devel
<mrnuke>
svanheule: sorry, just checked my notes. Can't fund anything about lzma uImage on the engenius.
srslypascal is now known as Guest560
srslypascal has joined #openwrt-devel
Guest560 has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
seer has joined #openwrt-devel
srslypascal is now known as Guest563
srslypascal has joined #openwrt-devel
Guest563 has quit [Ping timeout: 480 seconds]
<svanheule>
mrnuke: what kind of interface does the SG2008's console give? realtek CLI or some busybox?
<mrnuke>
svanheule: Good'ole realtek CLI
<svanheule>
ok, not useful for anything them
<svanheule>
then**
<mrnuke>
svanheule: can't we just mount their CPIO+rootfs in openwrt, and use their libso to launch their binaries?
<svanheule>
mrnuke: maybe, but that would require bootloader prompt access to launch and initramfs in the first place
<svanheule>
I was mainly thinking about how the image signature check could be bypassed for the TP-Link switches
<svanheule>
so a user could install OpenWrt without having to open their device and short the flash's reset pin
<mrnuke>
svanheule: I too want to get a Web-ready image. I tried feeding the realtek CLI a decrypted image. It failed with "RSA verify fail"
rua has quit [Ping timeout: 480 seconds]
<svanheule>
mrnuke: I threw that "core" binary from the T1600/T2500 source archive in Ghidra, and found the function that performs the RSA signature check
<mrnuke>
svanheule: Oooh! Anything good there?
<svanheule>
hardcoded public key, no internal variable to disable the signature check, and every upgrade path goes through that function
<mrnuke>
svanheule: You don't suppose tplink are just going to hand over their private key
<svanheule>
maybe if we ask very kindly?
<mrnuke>
I don't have any contacts there.
indy has quit []
<svanheule>
on the EAP245v1/EAP225v1 it was possibly to get a root shell over telnet, by exploiting the user credentials page. That allowed me to run a patched binary, with signature checks disabled, to upgrade to OpenWrt without screwdrivers or soldering
<svanheule>
newer EAPs just have the `cliclientd stopcs` feature, which kindly disabled the signature checks :)
<mrnuke>
How hard would it be to fuzz the image such that its MD5 sum matches a pre-setermined value (i.e. one for which we already have a signature) ?
<mrnuke>
svanheule: yes, like that! Didn't realize it was called a "chosen prefix" -- show you how little I know about crypto
indy has joined #openwrt-devel
<svanheule>
mrnuke: if you go down that path, maybe an "unlock" image would be intesting to have. Flash the unlock image that allows flashing unsigned firmwares, then flash the image of your choice
<mrnuke>
svanheule: Maybe I'm misunderstanding the complexity and time this endeavour would take. It's not as simple as running https://github.com/cr-marcstevens/hashclash , is it?
<svanheule>
mrnuke: it might be, but it would probably be too slow to run on every built image
<mrnuke>
The idea of the "unlock image" makes sense to me
<PaulFertser>
mrnuke: svanheule: I'm not sure it's that simple. You can't make the vendor sign your their image + your computed appendage.
<f00b4r0>
stintel: I meant it's not arch-dependent code
<f00b4r0>
or at least it doesn't look like it
<stintel>
ah
<stintel>
thanks for clarifying :)
<stintel>
2 x86 devices also running strongSwan are still on 5.10
<stintel>
could be fe9f1d8779cb47046e76ea209b6eece7ec56d1b4
robimarko has quit [Quit: Leaving]
<mrnuke>
PaulFertser: It looks like they used RSA with MD5. The idea is that if we make our image have the same MD5 as an image with have the signature for... We can pass our image as the signed image
<PaulFertser>
mrnuke: yes, but that sounds like a preimage attack.
<mrnuke>
PaulFertser: Yes. Just shows you how little I know about cryptography :p.