danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
guidosarducci has quit []
guidosarducci has joined #openwrt-devel
guerby has joined #openwrt-devel
ktifhfl has quit [Read error: Connection reset by peer]
ktifhfl has joined #openwrt-devel
djfe_ has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
djfe has quit [Ping timeout: 480 seconds]
djfe has joined #openwrt-devel
djfe_ has quit [Ping timeout: 480 seconds]
djfe has quit [Ping timeout: 480 seconds]
djfe has joined #openwrt-devel
minimal has quit [Quit: Leaving]
djfe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
jenders has joined #openwrt-devel
djfe has joined #openwrt-devel
janvenekamp has quit [Remote host closed the connection]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
sshtunnel has quit [Remote host closed the connection]
romany04 has quit [Quit: Ping timeout (120 seconds)]
romany04 has joined #openwrt-devel
fda- has quit [Quit: ZNC - https://znc.in]
fda has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
romany046 has joined #openwrt-devel
romany04 has quit [Ping timeout: 480 seconds]
romany046 is now known as romany04
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
jenders has quit [Read error: Connection reset by peer]
hanetzer4 has joined #openwrt-devel
hanetzer3 has quit [Ping timeout: 480 seconds]
romany04 has quit [Quit: Ping timeout (120 seconds)]
romany04 has joined #openwrt-devel
bookworm_ has joined #openwrt-devel
bookworm has quit [Read error: Connection reset by peer]
bookworm_ has quit [Ping timeout: 480 seconds]
bookworm has joined #openwrt-devel
philipp64 is now known as Guest7012
philipp64 has joined #openwrt-devel
Guest7012 has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
goliath has joined #openwrt-devel
hanetzer4 has quit []
cbeznea has joined #openwrt-devel
<rmilecki> https://github.com/openwrt/libubox/issues/1 an outstanding quality of GitHub reports ;)
<dwfreed> they are right (also the check just above for EAGAIN is also wrong), they could just stand to be a bit less terse
hanetzer has joined #openwrt-devel
danitool has joined #openwrt-devel
Andy99 has joined #openwrt-devel
<karlp> code owner agreed and fixed it to, soundsd like a pretty perfect report :)
Borromini has joined #openwrt-devel
<stintel> but what would be the symptoms of this bug? :)
<karlp> ask nbd to write better commit messages for that issue then.
<stintel> coincidentally I read a post about atomic git commits last night
<stintel> claiming a commit should be as small that in can be described with a single simple sentence
<stintel> I call BS. some problems cannot be explained in 1 sentence
<Andy99> Hello everyone, should I ask you a question about partition problems?
<stintel> don't ask to ask, just ask
<Andy99> Has anyone an idea, what could be wrong with partitioning https://github.com/openwrt/openwrt/pull/11647#issuecomment-1384232644 ? I guess, I just the correct partitions sizes/offsets from original FW.
<stintel> probably lacks a pad-to or so in the image generation code
<Andy99> ok, so isn't it automatically padded?
robimarko has joined #openwrt-devel
<Borromini> Andy99: that's just the sysupgrade though. By default no factory image is set unless you specify it in the device recipe
<PaulFertser> stintel: need your hardware advice: I'm considering getting fibre (with throughput capped to e.g. 300 Mb/s) for residential Internet access in a multi-apartment building, and I wonder if I have any low-power reasonably cheap options with an SFP port to avoid ISP's CPE altogether.
<PaulFertser> (other than mikrotiks which are problematic in many regards)
<stintel> first thing would be to check with the ISP if they allow you doing that :)
<f00b4r0> ^
<Borromini> PaulFertser: isn't there an EdgeRouter X with SFP?
<stintel> then mikrotik: avoid
<f00b4r0> also define "reasonably cheap"
<stintel> and then someone else probably knows better because I haven't done SFP or SFP+ on OpenWrt
<f00b4r0> i tried, and failed ;P
<f00b4r0> i think robimarko has this type of setup working
<robimarko> f00b4r0: Yeah, I am using Zyxel PMG3000-D20B as the GPON SFP
<PaulFertser> I've seen SFP working nicely on an 8-port rtl818x-based switch, so probably that's a reasonable option. But I do not need that many ports...
* Borromini has a MikroTik RB5009UG+S+IN doing SFP+ on OpenWrt :^)
<f00b4r0> i wish I could understand what my ISP checks to have this working, but so far no dice, so ISP ONT it is.
<f00b4r0> PaulFertser: you haven't defined "reasonably cheap". The Mochabin may be an option for you
floof58 has joined #openwrt-devel
<Borromini> and that just touches the kernel not complete your firmware images.
<Andy99> Borromini: I know, but isn't the "define Device/Default" took like default?
<stintel> no
<stintel> see the $(call Device/...)
<stintel> Device/uimage-lzma-loader does no padding for the kernel afaics
<PaulFertser> f00b4r0: haven't, yes, I'm confused about most things lately, so that naturally includes buying options and priorities, sorry.
floof58_ has quit [Ping timeout: 480 seconds]
<stintel> so what I would try is copy that KERNEL line to the Asus device, and add pad-to $$$$(BLOCKSIZE) ?
<stintel> not sure how many $$$$ you need to put
<stintel> this is all voodoo to me
<f00b4r0> the more $ the merrier ;)
<stintel> but that's what I would try
<stintel> or wait until someone who knows this stuff comes up with a better answer ;)
<PaulFertser> mochabin looks interesting, thanks!
<Borromini> mvebu platforms *are* interesting for that stuff
Danct12 is now known as Guest7036
<Andy99> stintel: which kernel line?
<djfe> append-kernel and then padding
<djfe> though I'm not sure about whether ubi is correct for your device
<Andy99> no, I don't have ubi
<Andy99> and I don't have factory.bin
<Andy99> so I have to add the line into ysupgrade.bin
<Andy99> sysupgrade.bin
<stintel> Andy99: git grep is your friend ;)
<stintel> as djfe suggested, look at how it's done for other devices
<djfe> well yes, I don't think sysupgrade needs padding, does it
<djfe> 😅
<djfe> I'm not an expert either
<stintel> I'd pad the kernel, and expect the problem to go away for both partitions
<djfe> maybe someone else will chime in later that knows about this. I also haven't looked at how you flash your device, yet
<Andy99> then I have to modify the $(Device/uimage-lzma-loader) somehow
<PaulFertser> Andy99: I'm looking at https://github.com/openwrt/openwrt/pull/11647#issuecomment-1384232644 but I see no errors, what do you mean by "wrong"?
<Andy99> for example mtd: partition "kernel" doesn't end on an erase/write block
<Andy99> or... mtd: partition "rootfs" doesn't start on an erase/write block boundary
<PaulFertser> Andy99: that's true, and that's good, it means it doesn't waste space, can't see anything bad about it.
<PaulFertser> Aligning on erase blocks is needed when you're going to write to those partitions, but you're not.
<stintel> hmmm. if that's expected ... we should silence that warning if the partition is already marked ro in DTS
<Andy99> PaulFertser: really?
<PaulFertser> sysupgrade will write to "firmware" partition which includes both fully.
<stintel> because I too would think this needs fixing
<PaulFertser> stintel: usually those partitions are not present in DTS, and instead are created on the fly by the splitters.
<stintel> right
<stintel> oh well
<Andy99> why is then the error/message "OF: Bad cell count for /" ?
<stintel> the DTS is incorrect
<PaulFertser> Andy99: bad cell count is unrelated, it's something indeed wrong about DTS where "u-boot", "config", "factory", "firmware" are defined.
<stintel> ehr my wild guess would be: address-cells needs to be 2
<stintel> but I'd need to do some reading again to be sure
<Andy99> I have the output from original FW of /proc/mtd
<stintel> I don't do this often enough
<Andy99> So I guess the numbers (offset/sizes) are correct
<Andy99> stintel: [11:47], no other devices have such on option, so I don't think so
<stintel> yes, this is not related to the offset and sizes, but to #address-cells or #size-cells
<PaulFertser> Andy99: yes, the offsets are correct.
<Andy99> stintel: that's what I'm saying, all decices have <1> and <1>
<stintel> drivers/of/fdt_address.c
<PaulFertser> Andy99: I suggest you do not worry about that too much for now, should be harmless.
<stintel> like the "forcing read-only" message, this also suggests something is wrong, it will cause other people to report it, so we must silence those messages if they are harmless
<Andy99> ok, so I don't have worry about it
<stintel> how long are we talking about this, if they are harmless we have wasted 5 people's time at least
<PaulFertser> stintel: probably, but that forcing read-only was visible in dmesg for many years, probably more than 5 already.
<Andy99> I have an another problem, which is... really an error
<PaulFertser> And it's kinda making sense and is expected. Probably the firmware splitters need to somehow mark them read-only and the warning to be emitted only if they're not already.
<PaulFertser> Andy99: the mdio one?
<Andy99> "unknown chip num:0000 ver:0000, mode:0000" it's completely couldn't find the switch, I have no idea why... maybe it's still in reset?
<PaulFertser> Andy99: my first guess would be that pinmuxing is wrong.
<PaulFertser> Andy99: is that switch part of SoC or is it an external IC?
<stintel> PaulFertser: yes, that sounds like the reasonable thing to do (splitter mark read-only)
<Andy99> external
<Andy99> RTL8367RB
<Andy99> MDIO bus should be used for connection
<PaulFertser> Andy99: does this SoC have just one MDIO bus? Is it known to work on other targets?
<PaulFertser> Andy99: and what MDIO address is the vendor's firmware using, does it match what you're trying?
<Andy99> I guess, the address is 0x00
<djfe> about "of bad cell count" https://github.com/openwrt/openwrt/pull/11302
<PaulFertser> Andy99: there might be a switch reset line indeed
<djfe> it's missing reviews I think
<djfe> it will be merged at some point
<stintel> sooo ... lastpass hack because of an employee running Plex :D
<stintel> I've always said it: Plex is an accident waiting to happen if you UPnP the port open
<stintel> another argument to absolutely not enable UPnP by default ever
<djfe> I have no clue about realtek switches, can't help you with that. as the others said the two errors should be harmless. I have seen them so often 😅
<Andy99> What only I have is the "padavan FW", where exitf-1 is used and the mdio bus, notthing more
<djfe> stintel: in the past I was annoyed a telekom router gave me no way to enable upnp port opening. why? because some games required it to realize that the same game is open twice in the network. all in order to open another random port for the second gaming instance (all client no server)
<PaulFertser> Andy99: have you tried booting OpenWrt after u-boot talks to the Ethernet?
<f00b4r0> oh that's new. Now I can ping some remote from my LAN. Apparently some router on my ISP network. Cute. NOT.
<djfe> if I started a second gaming instance, the first instance would loose connection to the servers
<Andy99> PaulFertser: you mean, stay in u-boot, make a ping and then boot?
<stintel> djfe: yes, UPnP has its uses, but it should never be enabled by default
<djfe> good to know :)
<PaulFertser> Andy99: yeah
<PaulFertser> Just a wild guess.
<stintel> I have miniupnpd running, but the devices allowed to open ports via it are in a VLAN isolated from my workstation
<Andy99> PaulFertser: nope, does it help? I don't think so, but ...
<PaulFertser> Andy99: and is it defined there? Because apparently that driver can also bitbang instead.
<stintel> many people would call me crazy if they know my network setup, but things like this prove you absolutely should use VLANs
<stintel> it should be a requirement if employers allow their people to work from home, that their corp devices go in an isolated VLAN
<stintel> but yeah, good luck enforcing that ;)
<Andy99> I installed there a https://github.com/wkz/mdio-tools and no response from 0x00 - 0x1F addresses
<Andy99> that's my assuption, that switch is maybe in reset state
<PaulFertser> Andy99: can you get list of all gpio states and probably pinmux and dmesg from that padavan firmware if it works?
<djfe> I know of companies that did that. a fritzbox that connected to the company via VPN. printer and thin client behind that
<djfe> early on because they did dsl themselves, later to latch on to use their lan connection and avoid having to pay for a second internet connection to an ISP
<PaulFertser> 14:09 < PaulFertser> Andy99: and is it defined there? Because apparently that driver can also bitbang instead.
<Andy99> PaulFertser: gpiolib -> kernel gpio debug is not possible to enable...
dangole_ has joined #openwrt-devel
<stintel> djfe: you can't be cautious (paranoid) enough these days
<PaulFertser> Andy99: what about /sys/kernel/debug/gpio ? Is that guarded by that thing?
<stintel> security bugs happen, a lot, and most people don't have planned maintenance for their home infra, even less automated updates
<Andy99> PaulFertser: let me boot it again
<PaulFertser> Andy99: and my question about bitbanging is essential, you should be able to figure it out from padavan sources.
<Andy99> PaulFertser: bitbang means if the virtual bus is used, like MDIO/MDC controlled like pins and not from physical interface?
<PaulFertser> Andy99: yes
<Andy99> so yes, it's not bitbang
<PaulFertser> 14:09 < PaulFertser> Andy99: and is it defined there? Because apparently that driver can also bitbang instead.
<PaulFertser> Sorry
<PaulFertser> So CONFIG_RTL8367_CIF_MDIO=y in .config there?
<Andy99> yes
<PaulFertser> Cool
f00b4r0 has quit [Quit: brb]
<PaulFertser> Andy99: just for the kicks I'd try to use bitbanging like in ramips/dts/rt3883_belkin_f9k110x.dtsi
<PaulFertser> Or ramips/dts/rt3662_dlink_dir-645.dts
<Andy99> ramips/dts/rt3883_belkin_f9k110x.dtsi already tried, didn't work
<Andy99> same num:000 ...
f00b4r0 has joined #openwrt-devel
<PaulFertser> And ramips/dts/mt7620a_iodata_wn-ac733gr3.dts uses another pins
<Andy99> yes, these I didn't tried
<Andy99> while I don't have any DS it's very hard to get the clue
<PaulFertser> Andy99: schematics would be needed.
<PaulFertser> Andy99: have you checked if by any chance it's possible to probe the bus with a voltmeter?
<PaulFertser> Or oscilloscope would be better of course.
<Andy99> sure, there is an aluminium shield, but I didn't want to break it
<PaulFertser> OK, but you have working kernel with sources so probably can figure it out without opening. And it indeed suggests hardware mdio is used.
<PaulFertser> Sometimes it's just very nice when you can sanity-check things, e.g. in this case something obscure might be making mdio silent, and so it'd not be a reset problem but rather silent mdio problem. Or the other way round. In anyy case if you knew for sure if the signals are present on the bus that would allow to concentrate on the real issue.
<rmilecki> Andy99: i didn't follow all discussion
<rmilecki> Andy99: regarding partitions - they look ok
<rmilecki> Andy99: you have required partitions, "rootfs_data" is aligned (writeable) = all looks ok to me
<PaulFertser> Yeah, the real problem is why it can't communicate with the switch chip now.
<Andy99> I'm going to try the
<Andy99> ramips/dts/mt7620a_iodata_wn-ac733gr3.dts
<PaulFertser> That's unlikely to work.
<PaulFertser> Andy99: have you found the datasheet for the SoC? I'd take a look at what GPIOs the MDIO interface is pinmuxed with.
<PaulFertser> Andy99: also, dmesg and /sys/kernel/debug/gpio from padavan might give some lues.
<Andy99> I tried to find the DS, but without any success. And as I wrote kernel/debug is missing
<PaulFertser> Andy99: do you mean debugfs isn't in /proc/filesystems ?
<Andy99> nope, /sys/kernel/debug/ is missing, there is only notes, mm and fscaps
<PaulFertser> Andy99: but then you can manually mount debugfs whereever
<Andy99> mount -t debugs failed
<robimarko> Debugfs doesnt even have to be compiled in the kernel as its optional
<PaulFertser> Of course but if it's present in /proc/filesystems then it's compiled in and mountable.
<Andy99> ok, I can compile it, becase I was thinking, that DEBUG_KERNEL was enough
<PaulFertser> I just thought it'd be a reasonable quick check to compare GPIO states between that firmware and OpenWrt.
<Andy99> I know, but gpio is not possible to debug, because it's depending on gpiolib, wihch is not possible to enable
Tapper has quit [Ping timeout: 480 seconds]
danitool_ has joined #openwrt-devel
<PaulFertser> I see your point now, the padavan firmware is using some hacked-up ad-hoc solution instead of gpiolib, that's unfortunate.
danitool has quit [Remote host closed the connection]
<PaulFertser> Another idea would be to try to bring all GPIOs up, then if the board still works, unbind and rebind the ethernet driver so that it would retry MDIO probe.
<PaulFertser> Kinda similar to how one is looking for GPIOs controlling LEDs.
<PaulFertser> If reset pin is the suspect.
<PaulFertser> (I meant to try it on OpenWrt)
<PaulFertser> You had reference there. But sometimes people have to bisect all the GPIO space looking for LEDs and buttons.
<Andy99> I know
<Andy99> If I bring all GPIOs up, shouldn't brake something?
Borromini has quit [Ping timeout: 480 seconds]
danitool_ has quit [Remote host closed the connection]
danitool_ has joined #openwrt-devel
Borromini has joined #openwrt-devel
<Andy99> I tried the ramips/dts/mt7620a_iodata_wn-ac733gr3.dts, but now it failed on ACK timeout
<PaulFertser> Andy99: hm, so different behaviour? It's a good clue.
<PaulFertser> Andy99: in theory forcing GPIOs up can do hardware damage but in all the cases I know the worst that happens is the target fully hangs and then you power-cycle it.
<Andy99> ok, but how to bring all GPIOs on?
<PaulFertser> Andy99: I'd do via /sys/class/gpio/export and little shell scripting.
<PaulFertser> echo out > direction; echo 1 > value
<Andy99> ok, I know how to do it, but I was thinking, if there isn't better solution
srslypascal is now known as Guest7046
srslypascal has joined #openwrt-devel
Guest7046 has quit [Ping timeout: 480 seconds]
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
<nick[m]12> We have 62 patches for hostapd. can't we switch to a new git commit instead of maintaining so many patches?
<stintel> those aren't backports
<stintel> or at least not all of them
<stintel> feel free to try and upstream them if you have the time for it
<stintel> also the ubus support should really be upstreamed. most vendor SDKs out there are OpenWrt based, the amount of devices out there that use hostapd+ubus is an order of magnitude higher than devices using wpa_supplicant+dbus, it makes absolute sense to upstream the ubus support
<stintel> so if you have time for that, by all means, go for it
<Andy99> PaulFertser: ok, exported all GPIOs, then set 1 test bus, nothing... same for 0
<PaulFertser> Andy99: and if you set to 0 ? Probably it's not missing reset then...
<Andy99> I tried also the 0
<Andy99> nothing changes
<PaulFertser> Andy99: if you manually read from those registers, do you only ever get zero?
<PaulFertser> Because apparently it behaves as it's able to talk to it...
<Andy99> how I can read those registers, while the device hasn't been found?
<PaulFertser> Andy99: hm, the padavan source code seems to suggest it's rtl8367, not rtl8367b.
<PaulFertser> Other than that CONFIG_RTL8367_API_8367B=y hm
<Andy99> here is RB
goliath has quit [Quit: SIGSEGV]
<PaulFertser> Andy99: with those mdio tools should should be able to read any register.
<Andy99> I know
<PaulFertser> Andy99: you can also probably try "generic phy" driver on that mdio bus.
<Andy99> mdio tools scans the devices
<Andy99> and from 0x00 - 0x1f there is nothing
<Andy99> means no device has been found
<Andy99> ok, I have no other idea ...
<PaulFertser> But with wrong GPIO numbers you're getting no ACKs and the driver isn't able to read any register. With the right numbers or hardware MDIO the registers are read but they all read as zero.
dangole_ has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
<Andy99> PaulFertser: exactly
<Andy99> but only in driver, once I use the mdio-tools there is not device found
<PaulFertser> Does u-boot have "mii" command?
<Andy99> nope
<Andy99> also the network is not initializes there, only if I run the tftp load
<PaulFertser> I'd try using ethernet-phy-ieee802.3-c22 instead of the proper switch driver, just to gather more info and possibly ideas.
<Andy99> how to do that?
<Andy99> nope, because here is "unknown chip num:6367" other then 0000 as my
<djfe> ok but atleast according to wikidevi it's the same realtek switch, right?
<djfe> (I could be wrong though)
<djfe> you already mentioned it could be the none b variant
<djfe> or rb
<Andy99> I guess RB
Borromini has quit [Quit: Lost terminal]
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<PaulFertser> Andy99: I'd just try changing compatible string in the DT.
<Andy99> hmm, ok to "ethernet-phy-ieee802.3-c22" or something specific?
<PaulFertser> Andy99: just that
<Andy99> but I guess this is for ports, isn't it? So just change compatible = "realtek,rtl83...?
goliath has joined #openwrt-devel
Andy99 has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
Andy99 has joined #openwrt-devel
<Andy99> hello again, I checked, that my assumption about RTL8637RB reset was wrong. This switch doesn't have an external reset.
<PaulFertser> Andy99: hi. BTW, I want to highlight that I do not really know the answer that would guarantee to help you, sorry, I'm just sharing how I would be approaching this issue.
<PaulFertser> Andy99: and my current idea is to try basically fooling the kernel into working with the switch anyhow at all, so that you could check networking configuration etc.
<Andy99> no problem... any kind of help is welcomed
<Andy99> but I guess is not possible to set the compatible type with something, which is related to port, or am I wrong?
<PaulFertser> Andy99: but from the SoC point of view it's essentially the same as a regular PHY, so that should be possible to somehow use the generic driver. Probably just omitting that compatible string might give the right results.
<djfe> jow: What's your opinion on this patch https://patchwork.ozlabs.org/project/openwrt/list/?series=53700
<djfe> Could we get something like this into uhttpd - or even better: cache-control: no-store - to prevent browsers from caching the html and therefor the refresh
<djfe> It appears like http-equiv are only respected by browsers when there are no http tags at all (if you open an html file locally)
<djfe> long explanation of the whole topic, if anyone's interested: https://stackoverflow.com/a/2068407
<PaulFertser> Andy99: I suggest you just comment out whole rtl8367rb section but leave mdio0 enabled, and see what happens.
<PaulFertser> (disregard my ethernet-phy-ieee802.3-c22 idea, it was indeed silly)
<Andy99> like this https://pastebin.com/ZTY7WYLC ?
Andy99 has left #openwrt-devel [#openwrt-devel]
goliath has quit [Quit: SIGSEGV]
floof58 is now known as Guest7071
floof58 has joined #openwrt-devel
Guest7071 has quit [Ping timeout: 480 seconds]
guidosarducci_ has joined #openwrt-devel
guidosarducci has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
djfe_ has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
djfe has quit [Ping timeout: 480 seconds]
SlimeyX has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
Borromini has joined #openwrt-devel
minimal has quit [Quit: Leaving]
floof58 is now known as Guest7089
floof58 has joined #openwrt-devel
Guest7089 has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
<blocktrron1> nbd: your wed memory region commit breaks my mt7986 board
<nbd> i will look into it tomorrow
<nbd> thx for letting me know
<blocktrron1> nbd: thanks
cbeznea has quit [Quit: Leaving.]
goliath has joined #openwrt-devel
Borromini has quit [Quit: leaving]
robimarko has quit [Quit: Leaving]
tlj_ has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
[Pokey] has joined #openwrt-devel
mcbridematt has quit [Ping timeout: 480 seconds]
mcbridematt has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]