<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
<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
<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?
<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 10.1.2.1 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
<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?
<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.
<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>
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
<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>
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>
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)