ekathva has quit [Remote host closed the connection]
bluew has quit [Quit: Leaving]
ekathva has joined #openwrt-devel
castiel652 has joined #openwrt-devel
castiel652 has quit []
castiel652 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
castiel652 has quit [Quit: Leaving]
Grommish_ has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
Grommish has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit []
rua has joined #openwrt-devel
ekathva has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
rua has quit []
ekathva has joined #openwrt-devel
rua has joined #openwrt-devel
valku has joined #openwrt-devel
ekathva has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
ekathva has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
rua1 has joined #openwrt-devel
Borromini has quit [Quit: Changing server]
rua has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Who around here is the top dan in netifd-fu? I'd like to know the right way to set an interface MTU with netifd. :)
rua1 has quit [Quit: Leaving.]
<rsalvaterra>
Case in point, defining option mtu '1400' in an OpenConnect interface does absolutely nothing. And the mtu option is supposed to be honored by all types of interfaces.
rua has joined #openwrt-devel
rua has quit []
rua has joined #openwrt-devel
ekathva has quit [Ping timeout: 480 seconds]
Gaspare has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
srslypascal is now known as Guest1170
srslypascal has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
Guest1170 has quit [Ping timeout: 480 seconds]
Gaspare has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit []
rua has joined #openwrt-devel
<mrnuke>
How come "poemgr" was accepted as a package, whereas "realtek-poe" was given the boot?
<mrnuke>
It seems to me that the solution in realtek-poe, with an event loop and ubus support is superior to the synchronous nature of poemgr. I get that poemgr claims to have "profile" support, but that plainly doesn't work as written. The profile selection loop is broken. There are also some issues with how a profile hides global context data, and some other separation of code and data issues that I've noticed
<mrnuke>
Point is, none of the two solutions are perfect, and none of the two offer workable "profile" support. So why can't the realtek folk have some decent way to do PoE ?
minimal has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
aiyion_ has joined #openwrt-devel
aiyion has quit [Ping timeout: 480 seconds]
swalker has quit [Remote host closed the connection]
<blocktrron>
mrnuke: poemgr predates the last realtek-poe patch which was lua prior
rua has joined #openwrt-devel
<blocktrron>
both solutions are not considered proper from the POV "proper" PoE support should be done by a kernel subsystem
<robimarko>
blocktrron: I personally dont see a proper PoE subsystem coming along anytime soon
<blocktrron>
Same
<blocktrron>
Thing is someone has to pour time & effort into a proper solution.
<robimarko>
Corporate backing is seriously lacking as everybody just rolled their userspace solution
<robimarko>
And nobody else has the time or money to pour into it, not to mention getting it accepted without some medium term guarantees about maintaining
<blocktrron>
Given the fact nobody even brought up the effort to push realtek-poe into the packages feed, i wouldn't hold my hopes up.
<blocktrron>
For everyone else, see the last message as an invitation ;)
<blocktrron>
robimarko: last time this topic came up, we've left the discussion at the conclusion every PSE chip has it's own take on managing power budget priority
<robimarko>
Oh yeah
<blocktrron>
Once you finished "Enable Port X" and "Read Power Draw", thats where the common ground ends
<robimarko>
Yeah, not to mention LLDP etc
<robimarko>
I tried to squeeze MicroSemi PD69200 into the current hwmon
<robimarko>
After port enable/disable, read voltage and power I gave up
<blocktrron>
:)
<blocktrron>
Honestly, the existing solutions work "fine enough"
<robimarko>
Well yeah
<blocktrron>
And next step should be kernel instead of userspace
<robimarko>
Especially with them all being I2C, SPI etc you can just write whatever daemon in userspace
<robimarko>
And just avoid the kernel
<mrnuke>
blocktrron: nick sounds familiar. You wrote poemgr on githug, right?
fda has joined #openwrt-devel
<blocktrron>
yup
<blocktrron>
someone lend me the board for a weekend, wrote a little simulator and then threw poemgr together
<mrnuke>
blocktrron: Cool stuff. I sent you a PR on github. I am trying to see how well the realtek stuff can integrate -- realtek stuff not part of the PR
<mrnuke>
Speaking of kernel vs luserspace driver for PoE, I think userspace is a perfectly valid solution. With a kernel driver, you have to be extra careful about error recovery and proper shutdown. WIth userspace, you just reload the daemon. I personally would much rather have UART comms in userspace than try to teach the kernel about yet another one-time-use-only binary protocol
<robimarko>
mrnuke: The point is not that, but rather having a standardized API
<robimarko>
To interact with it from other subsystems, ethtool integration etc
<mrnuke>
robimarko: Agree. You can try to design an API beforehand. You might get it right. Or you might allow a few divergent solutions which then converge to a common API
<robimarko>
The thing is that if everybody just keeps on rolling their custom solutions there will never be any APi
<blocktrron>
^ this
<blocktrron>
see swconfig
<blocktrron>
mrnuke: i can check later, currently on the go
<mrnuke>
robimarko: Then you risk getting stuck with the first-come first-served API. I think (this is opinion) that there needs to be some breathing room until a clear image can form about what that API should look like
<mrnuke>
blocktrron: no worries. That PR isn't going anywhere
<robimarko>
mrnuke: There has been a lot of time since 802.3 PoE was first standardized to now
<robimarko>
There will never be a perfect API, but this way there will never be any
<mrnuke>
how much time since openwrt has supported it?
<robimarko>
Well, thats the thing, OpenWrt does not support it
ptudor has quit [Ping timeout: 480 seconds]
<robimarko>
At least not the programable kind
ptudor has joined #openwrt-devel
<mrnuke>
I'm going to try and see if I can get the realtek stuf working with poemgr. I don't care which one wins, I have some coding to do anyway. I liked the asynchronous nature of realtek-poe, but it can work without it too in poemgr
<robimarko>
Why not just submit realtek-poe for inclusion in the packages feed?
blogic has quit [Remote host closed the connection]
blogic has joined #openwrt-devel
hexa- has quit [Ping timeout: 480 seconds]
digitalcircuit has quit [Ping timeout: 480 seconds]
owrt-2102-builds has quit [Ping timeout: 480 seconds]
<mrnuke>
robimarko: Somebody tried it and I believe it was rejected for not being generic
matoro has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
<robimarko>
mrnuke: No, John tried adding it to the core repo and including it by default on RTL target
<robimarko>
Bar for doing something like that is much higher
<robimarko>
Packages repo is just optional community maintained packages
<robimarko>
poemgr is just one of those
<mrnuke>
If it doesn't start up by default, it's not that useful, is it? Most users can go in the web gui, flash an image, done. Much fewer can ssh in and install a package with opkg.
fda has joined #openwrt-devel
<robimarko>
Well, you can install the package using LuCI
owrt-2102-builds has joined #openwrt-devel
<robimarko>
So, its not really hard
hexa- has joined #openwrt-devel
<mrnuke>
Well, no, but you flash openwrt, and all of a sudden, your PoE ports stop working. My view is that things just work. It's fun to tinker with stuff at first. Second time, they better just work.
<mrnuke>
I wouldn't want to go reinstall a package after every upgrade. Especially since I do it over an AP which is powered from PoE!
digitalcircuit has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
<robimarko>
mrnuke: Or you just include the package by using ASU or online image builder?
<blocktrron>
robimarko mrnuke: there is no realtek-poe vs. poemgr, they just happened to be written at the same time.
<blocktrron>
Honestly i would move forward with the first one, but i dont have the board anymore and only talk about this topic as we already did a year ago (which is dejavu in itself)
<blocktrron>
fwiw, realtek-poe to packages would be logical first step
<hurricos>
mrnuke: realtek-poe in the packages feed is actually a good idea, I somehow missed that realtek-poe was blocked because it was trying to be merged in core realtek
<hurricos>
mrnuke: auc is definitely the way to go when it comes to maintaining an installation of non-core packages
<hurricos>
auc is a C program in the OpenWrt packages feed which asks an attendedsysupgrade server to produce a sysupgrade which includes additional packages
<mrnuke>
hurricos: would you be interested in overseeing the getting realtek-poe in a package?
Grommish_ has quit [Read error: Network is unreachable]
Grommish has joined #openwrt-devel
Grommish_ has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
<robimarko>
blocktrron: I know, I never suggested that it was one or the other, they each target different stuff
<Lechu>
Folks, any good way to scan a MDIO bus from userspace? Working on Ruckus ZF7372 with no GPL sources, and I can't locate AR8035 connected to GMAC0 on the bus.
<robimarko>
mdio-tools
<hurricos>
mrnuke: I'd sign my name into the maintainer field, sure. I still don't have a working realtek-poe for my switch, though
<Lechu>
robimarko: thanks. For now I got GMAC1 (through switch only), both wi-fis and reset button working, not flashed yet.
<robimarko>
Lechu: For anything using MDIO, mdio-tools along with the required kmod are the best thing ever
<Lechu>
Trying it now ;-)
<Lechu>
Getting root shell on the device didn't help much at all, all debugging facilities are stripped out of stock kernel.
<robimarko>
Ughh, I hate when they do that
<robimarko>
Gives me MikroTik flashbacks instantly
<robimarko>
They go to the lengths to filter what symbols are exported by the kernel so you cant even build a kernel module to debug
Grommish_ is now known as Grommish
<Lechu>
is the kmod named kmod-mdio-netlink?
<robimarko>
That should be it
<robimarko>
mdio-tools now depend on it
<robimarko>
As they should
<Lechu>
Ok, building now.
<Lechu>
I laughed a bit, when I found that 5GHz Wi-Fi chip has its own EEPROM in that device.
<Lechu>
I'll temporarily set up a switch on GMAC1 so I can figure out what's going on with 100M port as well. It works, but of course, no port status reported.
<Lechu>
Got the address of the phy, I wonder if it'll probe now, because I remember trying it already.
<Lechu>
...nope :|
<robimarko>
Whats the PHY model?
<Lechu>
Atheros AR8035. Duh. I had a typo in compatible string ;_;
<mrnuke>
hurricos: same here. realtek-poe doesn't work on my switch. But that should be fixable in time
Grommish_ has joined #openwrt-devel
<Lechu>
robimarko: finally it probed. Thanks for pointing me on mdio-tools
<robimarko>
Glad to help
Grommish_ has quit []
Grommish has quit [Ping timeout: 480 seconds]
robimarko has quit [Quit: Leaving]
<Lechu>
Regarding GMAC1, show link up on mdio.1:1f:00, so to get link status reporting, I could bind a phy-handle for eth1 to swphy0?