dangole has quit [Remote host closed the connection]
rsalvaterra1 has quit [Ping timeout: 264 seconds]
luke-jr has joined #openwrt-devel
danitool has quit [Ping timeout: 272 seconds]
samantaz has quit [Read error: Connection reset by peer]
silverwhitefish has quit [Ping timeout: 260 seconds]
samantaz has joined #openwrt-devel
valku has quit [Quit: valku]
andi- has quit [Ping timeout: 240 seconds]
whyameye_ has joined #openwrt-devel
whyameye has quit [Ping timeout: 240 seconds]
whyameye_ is now known as whyameye
shalzz has quit [Ping timeout: 240 seconds]
shalzz1 has joined #openwrt-devel
andi- has joined #openwrt-devel
otto has quit [Ping timeout: 240 seconds]
otto has joined #openwrt-devel
<damex>
what could be my options if uboot does not have network available (it is a switch and its ports are not initialized during uboot) and there is no usb available either? want to try to boot a new target/soc with CONFIG_ARCH_BCM_HR2 (Broadcom Hurricane 2)
gch9812136 has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch9812136 is now known as gch981213
_whitelogger has joined #openwrt-devel
<pkgadd>
unless you have spi-nor flash (which can be re-flashed externally easily), you'd probably first look into your options regarding recompiling the OEM u-boot with those options enabled and/or checking for jtag access
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
black_ant has quit [Ping timeout: 260 seconds]
<stintel>
damex: unifi switch?
<damex>
stintel: edgeswitch 8 150w
<stintel>
:)
<stintel>
I have a unifi switch 8 that is also based on this platform, unfortunately I seem to have killed the serial console and haven't worked on it anymore
<stintel>
also the soc might be supported in mainline Linux, afaik there is no userspace stuff for configuring the switch. maybe that changed, dunno
<damex>
stintel: yeah, soc 'has' mainline support (for a while)
<damex>
althought userspace is a problem :(
<stintel>
might better of getting an rtl8something based switch instead :)
<damex>
stintel: there is edgeswitch 8xp that goes phased out recently (pretty fast) has ath79 and broadcom chipset that is supported by openwrt
<damex>
s/goes/gets/
<stintel>
I read the US-8 switch SPI NOR chip with a clamp, should be able to write it like that too
<stintel>
that's what I was planning to do but since the serial console is dead I haven't tried anymore
<damex>
edgeswitch 8xp (toughswitch at a time) had lots of design/heating issues before (casing 'melted' or switch prematurely 'die') and edgeswitch 8 150w was a huge upgrade from that. more ports, more features. faster and higher performant platform.
<damex>
and i just happen to have edgeswitch 8 150w for 3 years or so
<damex>
stintel: any idea if there is anything rtl8* based that has poe? actual 802.11 af/at :)
<stintel>
but without proper support for the switch fabric it's going to be not that useful
<stintel>
pkgadd: that GS728TPv2 is 24
<pkgadd>
yeah, but availability (for interesting prices) is a bit difficult
<stintel>
ah
<pkgadd>
teh D-Link and ZyXEL switches are consierably cheaper
<stintel>
hmmm, that 48p is using qsgmii on all ports
<stintel>
man if something 24p 10GbE comes out I might ditch my huawei 10GbE switch
<damex>
i am not so sure if i can 'demand' anything from openwrt-based switch beside properly supported poe and vlans (maybe even QinQ?) ;)
<damex>
i am all up for l3 switch to finally put ospf on my switch ;p
<stintel>
ah but it'd need to be 802.3bt PoE for my AP :(
<PaulFertser>
btw, talking about switches, I find it odd that OpenWrt doesn't seem to have integrated support for features like dhcp snooping for arp spoofing detection/prevention.
Ycarus has joined #openwrt-devel
<damex>
PaulFertser: can't you just do dhcp snooping using iptables?
<PaulFertser>
damex: yes, you can LOG certain packets (all dhcp and arp) but then you'll need something to process it.
<damex>
offload it to to that tiny mips cpu /s
<damex>
it might be doable on platforms like mt7621 due to hardware offload
goliath has quit [Quit: SIGSEGV]
<stintel>
PaulFertser: patches welcome :)
<PaulFertser>
I recently tried playing with an HPE switch and I was shocked by how super-slow it was to boot or to save config. And finding a reference for their commands was surprisingly complicated, and the command set was odd (e.g. "undo shutdown" to enable interface), and enabling telnet required some odd commands from support forum and ssh I couldn't enable at all, it just didn't let me in.
<stintel>
undo shut / no shut are the 2 most common options afaik, in enterprise switches
<damex>
stintel: any idea if anything from rtk-owlab is ever getting upstreamed?
<damex>
trying to find which switch from that list has better support
<stintel>
damex: I'm not following development closely, blogic might be able to tell
<stintel>
anyway, time to get ready for daily crisis meeting :(
<stintel>
fml
gch9812138 has joined #openwrt-devel
gch981213 has quit [Ping timeout: 246 seconds]
gch9812138 is now known as gch981213
<damex>
PaulFertser: i have progress with edgerouter 4. seems like after patching in E300 to octeon target like it is done for other edgerouters - interfaces 2 of 4 are still down after loading but i can do 'ip link set up' and it is detected
feriman has joined #openwrt-devel
<damex>
and i need to use microsemi module/subsystem for bringing that up
<damex>
otherwise it says that media not detected on ethtool and that's it
<damex>
i guess i need to find how to tell it to bring all four ports up
CrazyLemon has joined #openwrt-devel
<damex>
technically 'whole' board is working now ;)
<PaulFertser>
damex: cool! So basically you just need to add a suitable default UCI config for it to work as expected?
<PaulFertser>
I wonder why that patching in really changed anything.
<damex>
PaulFertser: how can i adjust default UCI config if all it does by default is provide lan on eth0 (sfp eth3 physical) and wan (rj45 eth0 physical) on eth1?
<PaulFertser>
damex: you can add other ethX devices to the lan bridge
<damex>
PaulFertser: system type : cavium,ubnt_e300 (CN7030p1.2-1000-AAP) that is the line
<svanheule[m]>
damex: PaulFertser stintel I'm involved a bit in the rtl83xx effort. Someone is in fact looking at mainline support, which currently mainly comes down to reworking the code in OpenWrt to use modern kernel facilities.
<PaulFertser>
damex: omit the last ), I pasted it by mistake
<damex>
PaulFertser: so cavium,ubnt_e300 (CN7030p1.2-1000-AAP) it is
<stintel>
that could potentially be faster than the APU2 (quad 1GHz but x86/64)
<stintel>
can you do some simple benchmarks? I'm interested in max routing speed with NAT and SQM layer cake
<PaulFertser>
damex: then you need to match against "cavium,ubnt_e300"* I guess
<PaulFertser>
damex: the case match is case-sensitive
gch9812130 has joined #openwrt-devel
<damex>
stintel: i think it is up to vendor to decide about clock speed due to its active/passive design. edgerouter 4 is completely passive and as far as i see from vendor specs - it runs @1Ghz
<stintel>
ah
<PaulFertser>
And needs to match the whole string
<stintel>
ok
<damex>
stintel: what tests are you looking for?
<svanheule[m]>
PaulFertser: I got a HPE 1920-48G on my desk. It really is slow to boot, compared to Netgear GS110TPP which is based on the same platform.
gch981213 has quit [Ping timeout: 272 seconds]
gch9812130 is now known as gch981213
<damex>
PaulFertser: use 01_sysinfo to remap cavium,ubnt_e300 match to ubnt,edgeroute4 and then match against it?
<PaulFertser>
svanheule[m]: the one I tried playing with was HPE A3100v2, and the company got it for like 5 EUR from some bankrupcy sale or something like that :)
<damex>
what could be the preffered name for the octeon board?
<damex>
i can name it er4, edgerouter4, 'ubnt,er4', 'ubnt,edgerouter4' and etc
<svanheule[m]>
PaulFertser: That thing is even older than my switch :P
<PaulFertser>
damex: that should work (just do not make a typo in edgeroute/edgerouter). The question about the preferred name is not something I can answer. I also find grep | sed pipeline in that file to be silly.
<PaulFertser>
damex: my personal opinion would be that using compatible property directly should be the way to go.
<PaulFertser>
(the very first entry in there)
<PaulFertser>
damex: ramips target just does "strings /proc/device-tree/compatible | head -1"
<damex>
hmmm...
<PaulFertser>
damex: see package/base-files/files/lib/preinit/02_sysinfo , it is supposed to do the right thing for any modern DT target.
<damex>
octeon does not seem to like like any other modern DT target :D
<damex>
s/seem to/seem to be/
<PaulFertser>
And I think it already does that, just silly octeon/base-files/lib/preinit/01_sysinfo overrides it
grift has quit [Remote host closed the connection]
<damex>
one more thing: should i try to patch a working version of vitesse module/subsystem for phy to be blobless or we do not mind patching microsemi since upstream just use microsemi target from now on?
<damex>
but microsemi seem to work well
<damex>
and later we could just drop patch as is if we ever bump kernel version
grift has joined #openwrt-devel
<damex>
stintel: i think it might be faster then apu2 since mips64 vs x86_64 risc vs cisc
<damex>
does someone here have apu2 to do some testing?
danitool has joined #openwrt-devel
<PaulFertser>
damex: the closer to upstream Linux, the better.
<damex>
so microsemi it is ;p
<damex>
PaulFertser: how about board_name in target/linux/octeon/base-files/lib/upgrade/platform.sh ?
<stintel>
damex: I have
<damex>
stintel: do we test by openssl benchmark or you better idea/
<damex>
s/you/you have/
<stintel>
but no time right now
<stintel>
still in meeting
<PaulFertser>
damex: if you need specific handling for sysupgrade then you'll need to use it there.
<PaulFertser>
damex: I think it would be nice to somehow make octeon/base-files/lib/preinit/01_sysinfo to not write anything by default and count on package/base-files/files/lib/preinit/02_sysinfo to do the right thing
<damex>
let's see... i need to figure the flash partitions now. there is like 4gb emmc and it is supposed to be split in two for two different partitions for firmwares
<damex>
PaulFertser: what if we just drop octeon/base-files/lib/preinit/01_sysinfo then ?
<damex>
and adjust the rest to use package/base-files/files/lib/preinit/02_sysinfo
<PaulFertser>
damex: that would be cool but I do not have any idea how to not break the support for the existing octeon targets.
<damex>
stock use that mtdparts (bootloader access?) and it is not relevant for board to function since everything is on emmc (4gb). should we try to make it accessible before bringing up the board to openwrt upstream?
<damex>
neither of octeon boards do that
<Grommish>
Hey all
<PaulFertser>
damex: then skip it
<Grommish>
Ooo.. Whose playing with Octeon
<PaulFertser>
damex: where's the radio calibration data?
<Grommish>
Only the ERLite uses MTD
<Grommish>
ER uses SDA1 Fat, as does my Shield
<damex>
PaulFertser: why would there be radio calibration data? i think it is something else ;p
<damex>
PaulFertser: there is no radio on this board
<damex>
it is a 'pure router'
<PaulFertser>
damex: I see, no good reason to bother with MTD then I'd say.
<damex>
just 4x phy and that's it
<damex>
let's see first what stock does to that mtd (if at'all)
<PaulFertser>
I guess it's reading some unique serial number from ther
<damex>
PaulFertser: it also will help with updating bootloader
<Grommish>
damex: Does your device even have mtd? Or is it using emmc?
<PaulFertser>
damex: with (ro) I can't see how it can help
<damex>
Grommish: whole system+kernel is on emmc. mtd have bootloader (uboot).
Guest40023 is now known as lep-delete
<Grommish>
Your system is like my shield then
lep-delete is now known as Guest40023
<Grommish>
You won't use MTD at all
Guest40023 is now known as lep-delete
<damex>
PaulFertser: ubiquiti unlock it from the system and update ;p
<PaulFertser>
damex: right, the mapping is in DTS already, why do you want to override it with cmdline?
<damex>
PaulFertser: i did the way stock suggests - there has to be two partitions with exact copy of uboot
<damex>
PaulFertser: or i am getting it wrong
aszeszo has quit [Quit: aszeszo]
<PaulFertser>
damex: CONFIG_MTD_CMDLINE_PARTS=y is what can handle kernel command line. But I find it odd to first define something in DT and then override it via the command line.
<damex>
let's try to reboot to stock
WiredLife has quit [Quit: Idle for 30+ days]
<damex>
PaulFertser: CONFIG_MTD_CMDLINE_PARTS is already there :(
graphine has joined #openwrt-devel
<PaulFertser>
damex: that's because phys_mapped_flash is not related to spi0.0
<PaulFertser>
damex: probably what you see in kernel cmdline is just bogus silliness leftover from some other device
<damex>
i extracted mtd partitions and they seem to be different
Borromini has joined #openwrt-devel
feriman has quit [Quit: WeeChat 2.9]
danitool has quit [Read error: Connection reset by peer]
feriman has joined #openwrt-devel
<damex>
PaulFertser: uboot reports same thing that dts has
SpaceRat has quit [Read error: Connection reset by peer]
blb4393 has joined #openwrt-devel
SpaceRat has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
<damex>
also seems like setting cmdline for octeon targets is kinda useless if one is passed by bootloader
<damex>
CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER because of this
<damex>
PaulFertser: any idea if i could remap eth{0..3} as it is detected by kernel to something that resembles actual physical order physically is like this 'detected by OS -> actual physical name' eth0 -> eth3, eth1 -> eth0, eth2 -> eth1, eth3 -> eth2
<damex>
without editing dts
graphine has joined #openwrt-devel
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<PaulFertser>
damex: I think there is no need for any remapping like that, but you can assign labels that are visible in LuCI.
<dottedmag>
a heads-up: I've got Ubiquity USG Pro4 (another octeon, ubnt_e220, 4 Ethernet ports), and was working on adding it — should I wait a bit before you finish redoing sysupgrade stuff for it?
<dottedmag>
s/it/octeons/
<PaulFertser>
Isn't E220 already supported since long?
<PaulFertser>
Hm, probably labeling is only supported for switch ports.
<dottedmag>
sysupgrade was barfing on it — e220 is detected as edgerouter pro, and it is not handled there.
<dottedmag>
However I'm confused — edgerouter pro Wiki page shows e200 in logs, not e220.
<damex>
can't we do it more gracefully then pipe to dd ?
<PaulFertser>
It's squashfs image, how else do you expect it to be put into place?
<dottedmag>
Anyway even if e220 worked somehow in past it does not work anymore and nobody noticed, as 5.4 kernel halts on boot since https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6c22545225cdcc6b635ff94ce00a07663b254dbf has removed CONFIG_CAVIUM_CN63XXP1
<damex>
PaulFertser: ext4?
<PaulFertser>
damex: regular OpenWrt support is using squashfs for rootfs + copy on write overlay.
<PaulFertser>
damex: to have goodies like generic failsafe and reset.
graphine1 has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
graphine has quit [Ping timeout: 260 seconds]
graphine1 has quit [Remote host closed the connection]
<Grommish>
That is everything I had to do, if that helps
<PaulFertser>
damex: Grommish is your best source, having digged deep in the sysupgrade procedure just a few weeks ago
<PaulFertser>
With all the debug tricks etc
<Grommish>
ext4 on your storage will lead to issues since it'll have to extract the full-sized ext4 img before writing. I had to stick with squashfs, which worked out fine
<damex>
Grommish: how is the $BACKUP_FILE should be named?
<Grommish>
damex: it's automatically named by the system
<damex>
i find that there is nothing on /boot after rebooting (after sysupgrade)
<Grommish>
it's probably in /dev/sda1
<Grommish>
if er4 is like the er
<Grommish>
(mine is /dev/mmcblk1p1)
<Grommish>
but it's the FAT partition
<damex>
Grommish: ah no, on line sda is just externally connected flash drive. (there is usb3.0 port)
<damex>
on mine*
<damex>
it should be /dev/mmcblk0p1
<Grommish>
Make sure its blk0 and not blk1
<Grommish>
Because mine switched from mmcblk0 to mmcblk1
<Grommish>
otherwise, it's the same
<damex>
Grommish: yeah, it is blk0
<Grommish>
So.. /dev/mccblk0p1 is your FAT partition?
<Grommish>
damex: you are building from master branch?
<damex>
Grommish: yeah
<Grommish>
After you upgrade and save config.. when you boot, check your /dev/mmcblk0p1 for the file
<Grommish>
see what it's called?
<grift>
question: i have to test an update to a package, so i added a local feed but how can i make it compile my package version instead of the one upstream?
<damex>
Grommish: there is no file after booting now but config is preserved
<damex>
since we move it i guess
<damex>
Grommish: so basically sysupgrade preserve config now
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<damex>
rebasing again since it is successful point ;p
<PaulFertser>
damex: even if sysinfo01 is not get rid off I'd suggest to just reuse what comes from DTS
<damex>
PaulFertser: uh... but it is not a reference e300 board :(
<Grommish>
and, Adrianschmutzler might have an issue with cavium, since thats not the vendor
<Grommish>
thats the chipset manu
<PaulFertser>
damex: I'd certainly recommend to use whatever comes from strings /proc/device-tree/compatible | head -1 for the name
<PaulFertser>
The first compatible property is the most specific one
<damex>
PaulFertser: cavium,ubnt_e300 comes from there
<Grommish>
PaulFertser: Your command returns cavium,rhino_itus7x@ on mine
<Grommish>
Which certainly isn't valid.. thats the chipset and board manu, but not the vendor
<PaulFertser>
damex: I'd say it should be reused everywhere as a board name then. If it's incorrect, then a DT fixup should be included in the kernel.
gch9812134 has joined #openwrt-devel
<damex>
PaulFertser: how about device definition in target/linux/octeon/image/Makefile ?
<PaulFertser>
Grommish: that's what upstream DT says... if you do not like it, you can patch it or probably you can offer Linux upstream to use your own DTS I guess.
<Grommish>
damex: They depreciated BOARD_NAME
<PaulFertser>
damex: for image/Makefile I'd follow the established trend
<Grommish>
PaulFertser: I don't use a DTS, because there isn't one available.. I'm just telling you that cavium isn't a vendor and will not match with the previous stuff
gch981213 has quit [Read error: Connection reset by peer]
gch9812134 is now known as gch981213
<Grommish>
PaulFertser: However it wants to be handled internally to OpenWrt *shrug*
<Grommish>
PaulFertser: Otherwise, all the devices would be Broadcom bcm,something_version
<PaulFertser>
Grommish: you say you do not use a DTS and yet you just said /proc/device-tree/compatible is present on your system. Those statements contradict each other.
<Grommish>
There is not a dts/dtb in the kernel or OpenWrt for the CN7020/CN70xx
<PaulFertser>
Grommish: but it doesn't mean you do not use it
<Grommish>
There might be a dts in uboot
<PaulFertser>
Grommish: yes, u-boot gets it from somewhere and passes to the kernel, and the kernel uses it.
<Grommish>
but I don't even define LEDs outside of calling GPIO directly
<PaulFertser>
That's actually the way it is supposed to work for normal targets.
<Grommish>
Anyway.. It's an internal issue and you all can device, but cavium is the chip vendor
<damex>
btw as far as i know there is few e300 boards
<damex>
from ubiquiti it is
<damex>
like edgerouter 12 i think
<damex>
but that is a modification of e300 and i think it is e310 or e320
<damex>
won't know for sure till see actual board
<damex>
PaulFertser: so which one to use? i can opt for e300 easily ;p
<damex>
we can call for adschm in that case if we can not decide
mwarning has joined #openwrt-devel
am0rphis_ has quit [Ping timeout: 240 seconds]
<damex>
PaulFertser: can't we just override dts partially?
<damex>
or it has to be a whole?
dangole has joined #openwrt-devel
<dangole>
grift: ping
mwarning has quit [Ping timeout: 240 seconds]
<grift>
dangole hi
am0rphis_ has joined #openwrt-devel
<grift>
i am working on verifying your patch, it doenst work in enforcing mode, so i have to replace the upstream policy with one that defaults to permissive, trying that now
<dangole>
grift: but i tried that in enforcing mode on x86/64 and it worked... (?) what doesn't work?
linzst has joined #openwrt-devel
<grift>
mountroot isnt allowed to relabel
<grift>
mountroot runs restorecon
<PaulFertser>
damex: yes, one can partially override DT.
<grift>
and the syscalls that restorecon needs arent allowed in policy yet
<damex>
PaulFertser: how could i do that?
<dangole>
grift: weird, i thought you had covered that already, i didn't see any related audit logs
<PaulFertser>
damex: and it's already happening in arch/mips/cavium-octeon/octeon-platform.c
<grift>
looking into it now
* dangole
boots up freshly built image in qemu
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<grift>
grr need to recompile ... made a mistake
Nick_Lowe has joined #openwrt-devel
<dangole>
grift: i've now fine-tuned it so restorecon really only runs that one time that '/overlay/upper' has successfully been mkdir'ed. on my build it works, i end up with everything labeled correctly after first boot in enforcing mode.
Nick_Lowe has quit [Client Quit]
<dangole>
grift: and use fork()->execl(...) _->waitpid() instead of system(...) to call restorecon
<grift>
it does not make sense to me. but i am investigating it
<damex>
Grommish: why did you need to patch cvmx-bootinfo.h and cvmx-helper-board.c ?
<Grommish>
damex: Because my board was a custom 1-off that uses the CVMX_BOARD_TYPE_CUST_DSR1000N slot in the enum. I had to change that to make it report correctly
<Grommish>
reports as the 20006
<damex>
Grommish: where did you get that id?
<Grommish>
They only made 400-500 of them
<Grommish>
It's what it reported after I booted.. for me, it's cosmetic I suspect
<grift>
blockmount requires libblkid-tiny in its make file
<grift>
so i was wondering , why isnt it using libblkid instead
<grift>
and now it seems its using libblkid for you
<dangole>
grift: space reasons. libblkid is to big for small flash devices
<grift>
but libblkid is always there?
<dangole>
grift: libblkid-tiny is just a minified version of libblkid
<grift>
anyway ill add those rules and once i did can you please bump the version in your staging tree so that ican verify whether my restorecon fix did you trick?
<dangole>
grift: sure, will do. once we verified that it works i can also push the fstools stuff into master
<stintel>
damex: I'd be interested in some iperf results. source on the wan side of the er4 and destination on the lan side, with NAT enabled, and with and without sqm
<grift>
dangole :what is gnu-sleep? what pulls that in?
<dangole>
yes. former polarssl, now called mbedtls
<stintel>
it's nothing exotic really
<grift>
well it doesnt get installed by default
<stintel>
in fact I would expect most people to use this as it supports wpa3 + is smaller than openssl
<blogic>
anyone here played with 6lowpan ?
<blogic>
trying to get a simple link up
<blogic>
following howtos, all looks good but I never get a bt0 device coming up
<dangole>
stintel: that'd be libwolfssl then. libmbedtls doesn't support wpa3 but it's even smaller than wolfssl.
<stintel>
dangole: oh sorry
<stintel>
I confused the two
<stintel>
either way, I think we should cover all 3 of openssl wolfssl and mbedtls
<dangole>
blogic: never had my hands on 6lowpan :(
<stintel>
for the simple reason that: mbedtls is the smallest hence of interest for devices with small flash, wolfssl is the smallest that supports wpa3, and openssl is supported by most applications while many applications don't have support for the alternatives. so I expect all 3 to be commonly used by our users
<dangole>
grift: i'll give that a shot on ipq4029 gl-inet b1300 real hardware in a few moments from now
<grift>
can you though update your selinux-policy in staging so that i can test the label fix as well
<grift>
also for now it might be best to not try too exotic configurations
<grift>
currently the policy is known to support: openwrt , luci ,luci-acme, sftp-server, block-mount
<grift>
everything else is still unexplored
<damex>
is it discouraged to supply your own dts if board already have one but it does things not the way you want?
<dangole>
grift: wifi would be nice :)
<damex>
name, ethernet ports and other stuff
<grift>
dangole what you do you mean?
<grift>
i have this policy running on my router
<grift>
and it has wifi and it works
<dangole>
grift: ah, ok, so was just me having standalone hostapd instead of wpad multicall
<grift>
standard openwrt comes with wpad
<grift>
yes youre not using the defaults
<grift>
no wonder you hit all these exotics
<grift>
like having autofs on your router
<dangole>
grift: that's just blockd. it should be installed for everyone having a device with hotplug storage, microSD, USB, eSATA and such
<grift>
blockd isnt supported yet, only block-mount
<grift>
block-mount does the job for me
<dangole>
grift: good enough for starters. looking forward to see it boot on that gl-inet device with slow nor-flash and jffs2
<grift>
it has a hotplugcall plugin
<dangole>
grift: problem is when you share the external storage with samba, then you'd have to restart samba (and nfsd and afpd and ...) every time you hotplug
<grift>
lol
<grift>
ok but not today
<grift>
maybe tomorrow
<grift>
... samba on your router
<stintel>
this is a very common scenario
<grift>
then why isnt it part of base openwrt?
<dangole>
grift: for that, having blockd making use of autofs is really nice. NAS devices are very common OpenWrt targets by now, some supported hardware platforms are mostly for that.
<stintel>
in fact this is one of the reason people want to run openwrt on their device, so they can make a nas of it
<grift>
base openwrt is a common scenario
<stintel>
grift: because base openwrt needs to go in 4MB flash
<grift>
anyhow contributions are welcome
<grift>
i dont see me setting up samba on my router
<dangole>
grift: talking about that: you received my patch via git-send-email as well?
<stintel>
me neither. doesn't mean it doesn't happen
* dangole
running OpenWrt on a NAS box next to my router for that
<grift>
dangole yes but like i said that needs some investigation as you were using setfiles and not busybox
<grift>
and thats not the default scenarion
<dangole>
grift: independently of that, wouldn't that patch not be needed in any case as restorecon can only work if it knows about /tmp/overlay /tmp/overlay/upper and /tmp/overlay/work as well
<grift>
btw way me poor mans nas is already supported (i added support for sftp-server)
<dangole>
grift: that is fairly standard :)
<grift>
yes and i will commit it once i confirmed that restorecon work
<grift>
ie once you bumped selinux-policy in your staging tree so that i can test it
<dangole>
grift: done
<damex>
stintel: [ 4] 0.0-30.0 sec 3.18 GBytes 910 Mbits/sec done by iperf -d -t 30 -c 192.168.110.20. raspberrypi on the other side. same switch. same vlan. same subnet. gonna try cake
<damex>
7% cpu load during load
<stintel>
how was the load on the pi? did you measure?
<stintel>
I've seen 940Mbps on the apu2 iirc
<stintel>
but the pi could be a limiting factor
<damex>
stintel: 85% cpu load
<damex>
on rpi
<damex>
now peaking around 100%
<stintel>
ok. curious to see the difference with cake :)
<damex>
i think i should pick better target for test
<stintel>
well Pi's are easy ;)
<damex>
since i have bottleneck running iperf on rpi4 with arm64 distro
<stintel>
I wonder what hardware we will need to make this happen: [ 5] 0.00-10.00 sec 10.8 GBytes 9.31 Gbits/sec 0 sender
<damex>
ah, not the same vlan
<damex>
lemme fix that
<damex>
made a mistake
Nick_Lowe has joined #openwrt-devel
<damex>
stintel: [ 3] 0.0-30.0 sec 3.29 GBytes 942 Mbits/sec iperf to j5005 nuc7pjyh nuc (65~67% cpu load). done from edgerouter4 running iperf -d -t 30 -c 192.168.110.23 to nuc.
<damex>
5% cpu load :)
<stintel>
ok that's the same as apu2
<damex>
let me try using some device behind edgerouter 4 now
<stintel>
ah
<stintel>
this was on same VLAN?
<damex>
stintel: yeah
<damex>
edgerouer
<damex>
edgerouter got ip on same subnet and i tested to other machine there
<stintel>
ok
<stintel>
well the fact that the edgerouter can do iperf at gigE wirespeed is nice already
<stintel>
the average ath79 device is not able to do that afaik
Nick_Lowe has quit [Read error: Connection reset by peer]
Nick_Lowe has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
Nick_Lowe has quit [Ping timeout: 240 seconds]
Darkmatter66_ has joined #openwrt-devel
damex has quit [Ping timeout: 240 seconds]
Darkmatter66 has quit [Ping timeout: 260 seconds]
damex has joined #openwrt-devel
damex has quit [Client Quit]
damex has joined #openwrt-devel
damex has joined #openwrt-devel
<damex>
edgerouter x with hardware offload crashed :(
<damex>
was running last stable openwrt build
<damex>
stintel: [ 4] 0.0-30.0 sec 2.75 GBytes 787 Mbits/sec running iperf from macbook pro using usb-c usb3.0 adapter (ax88179) to edgerouter4 which is doing NAT. test done by connecting to the same j5005 nuc
<damex>
had 25% taken by irq on edgerouter
<damex>
25% cpu load*
<damex>
stintel: if edgerouter 4 runs as iperf server - it has 22% cpu load and able to do [ 4] 0.0-30.0 sec 3.22 GBytes 922 Mbits/sec with same command iperf -d -t 30 -c 192.168.1.1
<damex>
let's see qos
<damex>
stintel: how am i supposed to test qos ? still single iperf ?
<grift>
but i confirm that your fstools patch works dangole
<grift>
and your file_contexts.subs_dist patch also works but its fragile
<damex>
stintel: [ 4] 0.0-30.0 sec 1.67 GBytes 477 Mbits/sec SQM 500000/500000, default cake + piece of cake. edgerouter 4 has 25% cpu load (same ksoftirq)
<dangole>
grift: /tmp/overlay/upper/bin is very certainly not existing at the time restorecon is being run
<dangole>
grift: (restorecon runs just after mkdir /tmp/overlay/upper, so that is empty for sure at that point)
Borromini has joined #openwrt-devel
<grift>
so it doesnt run on every boot?
<dangole>
grift: no, it runs only on the first boot, when the filesystem for overlayfs is newly created and mkdir is run
<dangole>
ie. i check the return value of mkdir and only if it succeeds i also run restorecon
<grift>
i see, ok then i will make an adjustment
<dangole>
grift: /tmp/overlay/work should be labeled as well, i don't see that in your change
<grift>
it doesnt have to afaik
<damex>
stintel: [ 4] 0.0-30.0 sec 1.84 GBytes 527 Mbits/sec and still cpu load is only ksoftirq 25%. SQM 900000/900000, default cake + layer_cake or piece of cake
<damex>
have bottleneck somewhere else
<grift>
if it needs to be then we'll sae but for now i dont have a indication that it has to be
<stintel>
ksoftirq 25% sounds like 1 core fully used
<damex>
stintel: hmm... shouldn't it do 100% per core?
<damex>
i have used default 'top' that openwrt bundled with
<damex>
maybe should balance irq?
<damex>
let's see what i can do :)
<grift>
dangole please see if just this works:
<grift>
/tmp/overlay/upper /
<dangole>
grift: and /tmp/overlay itself as well as /tmp/overlay/work are covered elsewhere...?
<grift>
we dont need to address /tmp/overlay dir, and /tmp/overlay/work seems to not be an issue either, if it turns out to be we can address /tmp/overlay/work then
<grift>
thats needed
<grift>
we need to ensure consistent labeling
<grift>
so if this " /tmp/overlay/upper /" works then that is prefered as that corresponds to /tmp/root/upper ass well
<dangole>
Hauke: no, i recently lost pretty much all devboards i ever had because all my stuff got stolen from our car.
<stintel>
still impressive
<Hauke>
dangole: oh, that is not good
gch981213 has quit [Quit: Ping timeout (120 seconds)]
gch981213 has joined #openwrt-devel
<dangole>
Hauke: no, that quite sucks, fortunately my laptop and my nas box wasn't in the car, but pretty much everything besides 1x gl-i b1300 is gone. bought one teltonika device after that so i'm online somehow...
<stintel>
damex: I recently played around a bit on my apu2, by default it uses 4 queues for all ethernet interfaces. each queue uses a different irq and they are all balanced, but I'm only using 2 of the 3 interfaces, so I used ethtool to configure only 2 queues per interface, so it is now spreading all those IRQs on a different core. this appears to perform better than using 4 queues/irqs per iface
<stintel>
you might want to check that (/proc/interrupts)
<stintel>
4 queues for each*
<dangole>
Hauke: actually the whole car was stolen and we are lucky to have the car itself back, but everything inside is gone, ranging from dirty underwear, classics like the car stereo down to tax-relevant personal documents...
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<dangole>
Hauke: and of course lots of nice dev gear i had accumulated, DSO Quad, Open Logic Bench, FTDI 2232H JTAG...
<dangole>
quite certainly all that ended up on some trash pile on the outskirts of rome because who ever stole all that wouldn't know what it is or what to do with it. none of it looks new.
<damex>
seems like the most going to the same core
<stintel>
damex: both ifaces use the same queue, that's not good
<stintel>
damex: hold on
<stintel>
config globals
<stintel>
option packet_steering '1'
<stintel>
in /etc/config/network
<damex>
stintel: do i need reboot or just network restart is fine?
<stintel>
hmmm, it's handled via hotplug, not sure tbh
<stintel>
you could call the hotplug script probably
<stintel>
actually, do you have /etc/hotplug.d/net/20-smp-packet-steering ?
<stintel>
seems to be part of netifd so probably
<damex>
stintel: now 25% iperf and 17% irq
<damex>
iperf ate all cpu and couldn't produce more :)
<damex>
stintel: yeah, it is there
<stintel>
ACTION=add sh /etc/hotplug.d/net/20-smp-packet-steering
<damex>
stintel: i will try with machine behind router again
<dangole>
Hauke: I assume you want to replace swconfig by b53 dsa...?
<stintel>
damex: what does `uci get "network.@globals[0].packet_steering"` return ?
<stintel>
not sure if changing it in the config file actually activates it immediately in uci
lnslbrty has quit [Quit: ~-AmIsraelChai-~]
<damex>
stintel: return 1. i restarted network
<stintel>
ok
<damex>
i can flash image with irqbalance in there
<damex>
special package that will balance interrupts between cores
<stintel>
that might work too
Nick_Lowe has quit [Read error: Connection reset by peer]
Nick_Lowe has joined #openwrt-devel
<stintel>
hmmm, maybe it's driver related. I'm seeing f in all 4 /sys/class/net/eth{0,2}/queues/tx-0/xps_cpus and /sys/class/net/eth{0,2}/queues/rx-0/rps_cpus
<stintel>
maybe I just misunderstood the packet_steering option
<stintel>
or maybe it doesn't work
<stintel>
wiki describes it as "Use every cpu to handle packet traffic"
<stintel>
clearly not doing that on your device :)
<stintel>
I see the same behavior on my ERL
<damex>
stintel: [ 4] 0.0-30.0 sec 2.92 GBytes 836 Mbits/sec two of four cores 100% load. SQM 900000/900000 cake + piece of cake or layer of cake.
<stintel>
o_O
<stintel>
I might just need to order an ER4, or 2
<stintel>
or 4
<stintel>
lol
<damex>
haha :D
<stintel>
then I can finally upgrade to 1000/1000
<damex>
wait till it gets supported :)
<stintel>
200/120 is slow
<damex>
i think i just realize that we do not have LEDs supported
<damex>
there is a single led on board that could be controller (i guess)
Nick_Lowe has quit [Read error: Connection reset by peer]
<stintel>
strange, both interfaces still use cpu0 for irq
<damex>
i think it is not enabled since in config it said 0
Nick_Lowe has joined #openwrt-devel
<stintel>
so why did it improve
<damex>
no clue :(
<damex>
all i did is reboot with steeing enabled
<stintel>
well, if it can do 800+ with both interfaces using CPU0 for IRQ ... it could be even faster when they use a different IRQ
<stintel>
impressive device then
<stintel>
I kind of need to retest the apu2
<stintel>
because iirc it struggled even to get 200Mbps with sqm/cake
<stintel>
if only this thing would be 802.3af/at/bt powered
* stintel
continues dreaming
<damex>
edgerouter 4 does 500-600megabit with qos on edgeOS (full software) and edgeOS is poor old software. pretty sure it can do the same -atleast- 500 on openwrt
<damex>
now you have seen that it can do 520 or so
<damex>
and that is single core :)
<stintel>
not necessarily as edgeos uses offloading that afaik is not supported in openwrt
<damex>
stintel: edgeOS have 0 offload for QOS
<damex>
only vlans/forwarding/bonding and ipsec
<damex>
and gre ;)
<stintel>
yeah but even that offloading is not supported on openwrt afaik
<grift>
hmm dangole thinking some more about it , you might be right ...
<stintel>
maybe ipsec is
<damex>
> edgerouter 4 does 500-600megabit with qos on edgeOS (full software)
<damex>
this means that no offloading used since using QOS effectively disables it
<stintel>
ahj
<stintel>
ok
<damex>
there is some stuff available in kernel to use sha functions and some others using special OCTEON instructions :)
<damex>
upstream kernel
<stintel>
auch. that device is not cheap
<damex>
200$?
<stintel>
BGN390 so ~EUR200
<damex>
oh
<stintel>
but I could have it by wednesday
<stintel>
only 1 in stock tho
<stintel>
maybe I should first try to get this Firebox M300 working
mwarning has joined #openwrt-devel
Xesxen_ has joined #openwrt-devel
<stintel>
I'm really curious how that thing will benchmark
<damex>
if i ever have a chance to pick that edgerouter 4 after owning it for a while - i would go for edgerouter 12 or something like that since they have extra ports (integrated switch) and can be powered by PoE
<stintel>
freescale (iirc) T2081, also quadcore, don't recall the clock
<damex>
but if you just need a powerful router (great thing - power supply is integrated) - it is great ;)
<stintel>
ah yes, I remember this device now
<stintel>
24V PoE
<stintel>
no thanks
<stintel>
they should name it poo instead
<damex>
oh, okay. edgerouter 4 has no poe and just internal PSU :)
<damex>
maybe it will suit better ;p
<grift>
dangole: the current git head on git.defensec.nl should address /tmp/overlay
aparcar[m] has quit [*.net *.split]
sielicki has quit [*.net *.split]
aparcar[m] has joined #openwrt-devel
sielicki has joined #openwrt-devel
<grift>
dangole your patch was fragile in that it would cause labeling issues
Xesxen has quit [*.net *.split]
svanheule[m] has quit [*.net *.split]
tchar has quit [*.net *.split]
zaolin has quit [*.net *.split]
distemper has quit [*.net *.split]
christiandr_ has quit [*.net *.split]
Snowbl1nd has quit [*.net *.split]
russell-- has quit [*.net *.split]
christiandr_ has joined #openwrt-devel
Snowbl1nd has joined #openwrt-devel
zaolin has joined #openwrt-devel
svanheule[m] has joined #openwrt-devel
tchar has joined #openwrt-devel
distemper has joined #openwrt-devel
russell-- has joined #openwrt-devel
<grift>
dangole regardless though your fstools patch works and should be fine, if after that there are still issues then those can probably be resolved with policy
shalzz1 has quit [Ping timeout: 246 seconds]
pavlix has quit [Ping timeout: 244 seconds]
svanheule[m] has quit [Ping timeout: 244 seconds]
Huntereb has quit [Ping timeout: 246 seconds]
<dangole>
grift: cool, so i'll push that after test-running on ipq4029 (still building...)
<grift>
ive my policy running on linksys mr 8300 and linksys wrt1900acs
<grift>
so those two "should" work provided that one sticks to the basics
svanheule[m] has joined #openwrt-devel
<grift>
but yes the thing with labeling is that labels get associated with entities in various ways, so just adding a entry to file_contexts.subs_dist is only half of it
<grift>
we want to make sure that if you do a rmdir /tmp/overlay && mkdir /tmp/overlay that it will be labeled the same
<grift>
ie concistent labeling
pavlix has joined #openwrt-devel
<grift>
i went to great lengths to ensure that labels are always correct
<damex>
stintel: [ 4] 0.0-60.0 sec 4.66 GBytes 667 Mbits/sec consistently using 1.5 cores with irq balance enabled
shalzz1 has joined #openwrt-devel
<grift>
because mislabeled stuff is one of the most common selinux issues
<damex>
even like 1 core and 30% of other one
<stintel>
damex: makes sense because the cake stuff is only on one of the interfaces
<stintel>
so I suspect this one to be more heavily loaded
<damex>
stintel: could fq_codel be multithreaded?
<damex>
i am not so sure though
<damex>
sqm presets depend on cake though
<dangole>
grift: does that mean i should rather just do `restorecon /tmp/overlay` before the `mkdir` and then the labels for `/tmp/overlay/upper` and `/tmp/overlay/work` will still automagically be correctly set?
<grift>
yes
<dangole>
grift: that would make it a little more complex because then i can't use mkdir as stat to know if it is the first run after formatting the filesystem...
<grift>
err no sorry misread
<grift>
obvously a restorecon before the mkdir doesnt make sense
<grift>
/tmp/overlay /tmp/overlay/upper and /tmp/overlay/work will be created with the right contexts
<grift>
let me get this straight:
<grift>
the filesystem that eventually ends up on /overlay , gets prepped on /tmp/overlay right?
<dangole>
grift: exactly
<grift>
so we just needs to make sure that the / on that filesystem is labeled properly
<grift>
ie file.overlayfile
<grift>
if that is true then from that point on the work and upper dirs should get created automatically with proper contexts
<grift>
because there a rule that say:
<damex>
stintel: so basically packet steering screw things around so irqs are not balanced. iperf -P 4 -d -t 60 -c 192.168.110.23 i get 520M/s but irqs are balanced and cpu is not 100% at all times
<damex>
trying to find how to improve situation
<grift>
if a process with type sys.subj creates a dir with name "upper" in a dir with type "file.overlay" , then transition from "file.overlay" to "sys.rootfile"
<grift>
similarly:
<grift>
if a process with type sys.subj creates a dir with name "work" in a dir with type "file.overlay" , then inherited the "file.overlay" type from the parent "overlay" directory (file.overlay)
<dangole>
grift: so currently it works nice now on x86/64, now i dare flash it to ipq4029 as well...
<grift>
in other words as long as the / of the file system is labeled according to the spec, everything below it should be taken care of automatically
<grift>
just set bootparam and develop=y and set SELINUX=permissive
<grift>
and when all works , switch to SELINUX=enforcing
<dangole>
grift: i can't set anything there, bootloader is locked.
<dangole>
grift: if it fails, i'll connect serial cable...
<stintel>
damex: looks like I got you into something :P
<grift>
just build the kernel with those options ...
<grift>
i dont understand why those options arent enabled by default in kernel config
<grift>
and the selinux mode from config can just be edited in ./files/selinux-config
<dangole>
grift: because we don't have the single red 'enable SELinux' button in menuconfig yet. once somebody makes it, it should enable those options
<grift>
ok
<damex>
stintel: i think that i probably need to finish with device first so it works perfectly fine under openwrt
<damex>
then do testing ;p
<damex>
i will immediatelly migrate to it as a main device
<damex>
stintel: i am thinking if we should include irqbalance out of box on multicore devices ...
<dangole>
grift: still got complains about wpad and uhttpd wanting to link against openssl (or wolfssl)
Nick_Lowe has quit [Ping timeout: 240 seconds]
<stintel>
damex: I think we should rather look into why packet steering does not work on octeon
<damex>
stintel: it probably work but not as expected ?
<stintel>
sh: write error: No such file or directory
<dangole>
grift: uhttpd also got a built-in Lua interpreter, no need to fork&exec.
<grift>
ok dev fop level looks good , thanks
valku has joined #openwrt-devel
<grift>
yes but that shouldnt explain why /etc/init.d/uhttpd needs it
<grift>
thats why i would like to see a ps auxZ
<damex>
stintel: i think about making device tree for that octeons. since it is frustrating to have different port mapping inside system and physically and lots of redundant devices (they does not exist)
<grift>
something thats called directly from /etc/init.d/uhttpd wants access to liblui
<grift>
lua
<damex>
PaulFertser: is there any objections about making a device tree for octeons? it might be time consuming but i want to make things right
<grift>
doesnt return anything here, so not sure why its trying to traverse /usr/lib/lau
<PaulFertser>
damex: I think mapping between ethX devices and port numbers on the case is not a convincing enough reason to consider fully ignoring DT that's passed by the bootloader.
<damex>
PaulFertser: is there a way to use that dts and just include your own overrides? i get it that you can do so with local dts but it is not
<damex>
but it is not local*
<PaulFertser>
damex: platform startup code in octeon is already overriding some details
<damex>
PaulFertser: well, how about making local dts that will do that?
<PaulFertser>
damex: if you just want to rename ethX devices then it's not the right way afaik.
<damex>
PaulFertser: i want to rename ethX, device, exclude not-used-nodes
<PaulFertser>
damex: and I think Linux doesn't support "dtb overlays", it's the work done by the bootloader (e.g. u-boot does that on raspberrypi)
<PaulFertser>
damex: upstream doesn't consider ethX numbers to be stable or meaningful in any case
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
Nick_Low_ has quit [Ping timeout: 258 seconds]
<PaulFertser>
damex: for switch ports OpenWrt already has the notion of port number and port index and LuCI uses that to show sensible picture.
<PaulFertser>
Probably it should be extended to allow some kind of labeling for normal network devices.
<damex>
PaulFertser: but it is not switch... well, definition of 'wan' port does not make sense with that router either since any port is wan port
<damex>
i just follow trend and make first port as wan port
<PaulFertser>
damex: there's an analogy there: switch ports often have "wrong numbers" too.
mwarning has quit [Ping timeout: 240 seconds]
Nick_Lowe has joined #openwrt-devel
<PaulFertser>
damex: what devices are specified in DT and have corresponding drivers enabled but not working?
Borromini has joined #openwrt-devel
<damex>
PaulFertser: hmm.. like specified, should work but not working? lets see... sfp cage seem to work but i can't get info about its status (on stock ethtool shows details that it is a cage), leds maybe?
<damex>
PaulFertser: that is more like 'it does not work and i have no idea how to make it work' but otherwise all i know of and that we loaded corresponding drivers for - work.
<PaulFertser>
damex: so there's no reason to remove those additional specifications from DT then, since they do not harm at all anyhow?
<damex>
PaulFertser: well, kernel complains but that's it
<PaulFertser>
svanheule[m]: on OpenWrt , procd takes care of processing /etc/hotplug.json , but I can't tell if interface renaming is implemented.
Nick_Lowe has quit [Ping timeout: 240 seconds]
Nick_Low_ has quit [Ping timeout: 244 seconds]
movrax has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
MichaelOF has joined #openwrt-devel
mwarning has joined #openwrt-devel
Nick_Lowe has quit [Read error: Connection reset by peer]
<damex>
PaulFertser: i found that dts depend on vitesse,vsc8504 or generic phy variant and does not work properly with microsemi vsc8504 due to dts bindings
<damex>
anyway it does not really matter now at 5.4 kernel :)
Borromini has quit [Ping timeout: 260 seconds]
samantaz__ has joined #openwrt-devel
samantaz_ has quit [Ping timeout: 260 seconds]
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
Nick_Lowe has joined #openwrt-devel
Nick_Low_ has joined #openwrt-devel
Nick_Low_ has quit [Read error: Connection reset by peer]
Nick_Low_ has joined #openwrt-devel
Nick_Lowe has quit [Ping timeout: 240 seconds]
Nick_Lowe has joined #openwrt-devel
Nick_Low_ has quit [Ping timeout: 272 seconds]
<PaulFertser>
damex: I checked how udev does it and I think you just can call "ip link set eth0 name lan1" from /etc/hotplug.json
<damex>
PaulFertser: but it won't be an automated openwrt-like way ? :(
<PaulFertser>
Or rather from /etc/hotplug.d/iface/
<PaulFertser>
damex: if you create a file that'll be installed there then it'll be automated enough
<PaulFertser>
busybox ip applet is included by default
<damex>
PaulFertser: let me think about it, i am not so sure it is good idea to remap them to lan* ...
<damex>
PaulFertser: could point where i should look about adding gpio leds?
<PaulFertser>
damex: you can align that with how the upcoming DSA support is going to name the ports.
<damex>
there is only one led on boards you can control i guess... it is 'ubiquiti status led' which is either blue, either white.
<damex>
i don't see its configuration in dts
<damex>
although i can control it throught gpio pin 15
<damex>
and probably 16
<PaulFertser>
damex: I see one led defined in DTS
<damex>
PaulFertser: yeah, but i don't see anything in /sys/class/leds
<aparcar[m]>
ynezz I think als Firmware selector issues were addressed. Deploy?
<PaulFertser>
damex: to handle it you need CONFIG_LEDS_GPIO=y
<PaulFertser>
damex: or kmod-leds-gpio
<PaulFertser>
damex: ftr, I've checked and targrets with DSA support really have their network interfaces named lan1 etc.
<PaulFertser>
damex: did you manage to figure out the internal topology of all the network components on that unit?
<damex>
PaulFertser: yeah, i think so
<PaulFertser>
damex: it would be kinda interesting to learn, as all those uctl and pip ports and two mdio buses are confusing. If you draw a diagram it can be added to the wiki and used to help the other developers doing new ports for similar hardware.
<PaulFertser>
damex: ls -l /sys/bus/platform/drivers/leds-gpio/
<damex>
PaulFertser: no such dir
<PaulFertser>
damex: it means the drivers wasn't loaded for whatever reason.
<PaulFertser>
damex: probably a typo
<PaulFertser>
But if it's either =y or you installed the right kmod, it should appear there.
<damex>
PaulFertser: oh yeah, i checked config and it is not there - enabled manually from menuconfig and building again
<damex>
PaulFertser: it is loaded now and that singe 'Yellow' led appeared
<damex>
not sure what exactly that one doing but it is not gpio15 that controls blue led on front
<PaulFertser>
damex: you can check /sys/kernel/debug/gpio
<PaulFertser>
damex: and you can try manipulating gpios manually via /sys/class/gpio/ interface
<damex>
PaulFertser: i did manipulate manually and found right gpio
<damex>
no clue what to do with it next
MichaelOF has quit [Quit: Konversation terminated!]
<PaulFertser>
damex: I'd probably add DT led patching to that octeon platfrom .c file.
<damex>
uh
<damex>
PaulFertser: i think it is a bad idea to patch in cosmetics
<damex>
device that does not function and crucial? yes. cosmetical part? uh...
graphine1 has quit [Quit: Leaving]
<PaulFertser>
damex: I'd probably ask the developers who decided to use vendor's DT in the first place. Probably there's a rationale in the commit message, probably there was a mailing list discussion etc.
<damex>
PaulFertser: no device in octeon target have led support
<damex>
PaulFertser: it would be nicer if there is a dts though ;(
<damex>
i see the only problem with adding dts - where to get mac addresses? they're 'hardcoded' in dts
<PaulFertser>
damex: see 05f5507f59d6d3eab1c2172c6266b664b61599b5 and then 86bee12f88ac466af718eb26739f5671fdc7cf18 :)
<damex>
PaulFertser: are they in the tree? git can't find commits
<PaulFertser>
damex: linux
<damex>
> "Built-in DTB booting is deprecated on %s. Please switch to use appended DTB.",
<damex>
oh really
<damex>
how? ;p
<PaulFertser>
damex: same as most ath79 devices do it
<PaulFertser>
damex: but first commit I mentioned is a good example of how to patch/enhance the existing DT.
danitool has joined #openwrt-devel
Ycarus has quit [Quit: Ycarus]
<damex>
PaulFertser: KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | uImage lzma and just supply dts in the tree?
<grift>
any idea as to why it fell back to ram overlay?
<grift>
it was in permissive mode so its not selinux blocking
<damex>
PaulFertser: but i don't need to supply whole dts? i can provide just a part of it, right?
<grift>
also theres no issue reported with setting up labeling for your fs
<PaulFertser>
damex: if you use append dtb then I think it needs to be the whole dts. Not sure if the kernel does any merging or not, but I'd guess not.
<damex>
well... then it is not useful since we can not get a mac address from flash (i think) ;(
<damex>
like mtd or something
<grift>
dangole: please do a ls -alZ /mnt/overlay
<dangole>
grift: when frist-booting device with (slow) NOR flash, it always comes up with ramoverlay while jffs2 is still formatting.
<dangole>
grift: stuff is then copied over to jffs2 once it's ready
<dangole>
grift: and that now doesn't seem to include labels
<dangole>
grift: ls: /mnt/overlay: No such file or directory
<grift>
err /tmp/overlay i meant
<grift>
dangole: 960375f2c3adc2ad2e9cf1f396bdfcc5bc5b58c7 but it doesnt address the unlabeled issue
linzst has quit [Quit: Leaving]
<grift>
need to identify that first
<grift>
now we just need to figure out why some stuff ends up unlabeled, i suspect it has to do with /tmp/overlay
<dangole>
grift: ouf, that's busybox 'cp' which would need an additional parameter '-c' to preserve the selinux context of the files copied. always specifying this parameter breaks on normal (ie. non-selinux) busybox :(
<grift>
-a
<grift>
doesnt make sense
<grift>
also that lua stuff with uhttpd bothers me
<grift>
does that mean that all the code in /www/cgi-bin/luci gets interpretted by uhttpd instead?
linzst has joined #openwrt-devel
<grift>
i need some information
<grift>
also that cp -a stuff doesnt add up
linzst has quit [Remote host closed the connection]
<grift>
if the / of the file system is labeled properly then you dont need cp -a
<grift>
can you just show me the output of ls -alZ /tmp/overlay?
<grift>
without information i cannot identify the issue
<dangole>
grift: if cp 2>&1 | grep -q "\-c\t"; then cp -a -c ... ; else cp -a ... ; fi
<grift>
it was just a simple request to use the defaults for now, and by default uhttpd uses /www/cgi-bin/luci and not that interpretted stuff
<dangole>
grift: or we call restorecon from switch2jffs as well
<grift>
please dont jump the gun
<dangole>
grift: sorry, i'm testing many things at once in one build system, i couldn't work otherwise due to performance and space constraints. i don't expect any of that exceptional non-standard stuff to work with selinux for now, but that ipq4029 is as much of a standard build as it can be.
<grift>
when the filesystem gets mounted restorecon needs to run on it so that the / of the filesystem is labeled file.overlay
<grift>
i though that was addressed
<grift>
i tested it and it worked here
<grift>
i didnt say that it wasnt
<grift>
i was just saying that that lua httpd stuff isnt not the default
<grift>
and it distracts
<grift>
we first need to deal with the basics before looking into the non -basics like that lua interpreted stuff
<grift>
i am not adding any policy that i cannot vouch for
<PaulFertser>
damex: yes, parsing dtb from mtd doesn't sound cool/easy/desired. So probably just patching in leds by platform code is the way.
<dangole>
grift: you are on ubifs, jffs2 is a different codepath because it's much much slower
<grift>
anyway cp -a will copy the extended attributes over, so if a file is unlabeled somewhere and it gets copied with cp -a then the unlabeled label will be copied over with it
<dangole>
grift: i'm adding that now
<grift>
yes so we need to figure out what the difference is
<grift>
dangole can you tell me what exactly is it copying?
<grift>
wheres that code that does the copying?
<dangole>
grift: it's copying the content of the /tmp/overlay (tmpfs) to the future jffs2 overlay now that jffs2 is formatted
<dangole>
user may not want to wait 10 minutes (!) until 32MiB of slow NOR flash got formatted
<grift>
right
<grift>
ouch, theres probably another oversight ...
<grift>
switch2jffs is probably file.execfile
<dangole>
fixed it in fstools, updated staging tree
<grift>
can you please: ls -alZ `which switch2jffs`
<grift>
because mountroot probably runs that , but it should run that with a transition
<dangole>
that's part of mount_root, it happens in there
<grift>
where is it and what label does it have currently (i dont have it on my router)
<grift>
o ok
<dangole>
just a different codepath than for all the other (fast) filesystems
<grift>
alright but eventually i should target that switch2jffs command as well
shibboleth has joined #openwrt-devel
<dangole>
grift: you mean jffs2reset? because switch2jffs is really just a function in C code by now, it used to be shell 10+ years ago
<shibboleth>
i'm trying to add device support for the tp-link talon ad7200, unfortunately the emails don't seem to go through. can i simply paste the patches somewhere and ask someelse to commit them? stintel?
<grift>
dangole: o ok yes i might be confused
<grift>
actually i am confused pretty sure
<grift>
i am still kind of shook from the possible lua/uhttpd prospect. that really got me off guard
<dangole>
grift: sorry for that, that's really a minor detail not to worry about right now.
<grift>
if that luci lua code gets interpretted by uhttpd then that means that uhttpd will might need all the permissions that luci-cgi has
<grift>
you end up with a web server that can manage manage many aspects of the router
<grift>
might be faster but also a lot less secure ...
<grift>
by running that luci code out of uhttpd you dont have to associate the permission needed with uhttpd which is network bound
<grift>
mod_php made that mistake 10 years ago
<damex>
would it be acceptable to add a target for 'octeon3' since its devices benefit performance wise from compilation with march=octeon3 and specific kernel flags?
<Grommish>
damex: if you get it done, I'll move my device to it
<damex>
Grommish: oh
<Grommish>
damex: There wasn't another octeon3 device when i sent mine in, so it's using the octeonplus er/erlite uses
<dangole>
grift: i probably didn't even think about it much when i enabled it, it's just for demo the webui in this case
<Grommish>
damex: but its an octeon3. I couldn't justify the increased buildbot load for a single device, but maybe with two or more it'll be worth it
<damex>
Grommish: yeah, it is just backward compatible
black_ant has quit [Ping timeout: 256 seconds]
<dangole>
grift: just test-run with my current staging tree and apart from some weird mknod failing it looks all good now, even when booting in enforcing mode from the beginning
<damex>
Grommish: there is er4 and i guess soon to be er12
<Grommish>
damex: that would probably be a jow question
<grift>
glad to hear dangole
<grift>
i dont know why mountroot needs that cap_mknod ...
<grift>
might be due to a bug
<grift>
its "c"
<grift>
cp
<grift>
so its probably copying over a char file (i suspect /dev/console)
<grift>
which probably shouldnt be there in the first place
<shibboleth>
anyone feel like submitting a patch/device support? we're talking a few line changes and a new dts, emails to the lists are not going through
<ynezz>
shibboleth: create PR on GitHub
<shibboleth>
don't have a git account
<damex>
Grommish: i am not so sure that 2 devices will be worth extra target
<ynezz>
certainly not
<PaulFertser>
shibboleth: probably your mail server doesn't accept the confirmation/registration email from the openwrt devel mailing list server? That probably should be investigated.
<Grommish>
damex: that's the problem I ran into.
<shibboleth>
pretty sure it's the other way around
<PaulFertser>
shibboleth: do you mean you're trying to subscribe by sending it a mail?
<shibboleth>
no, i subscribed via the web form
<shibboleth>
never received confirmation, outgoing email was never listed on patchwork
<PaulFertser>
And their server should have tried sending yours a confirmation email.
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<dangole>
grift: most likely... this has probably last been touched more than a decade ago...
mwarning has quit [Quit: Leaving.]
<lemmi>
damex: there is er-4, er-6p, er-12 , er-12p and what grommish worked on that use octeon3
<lemmi>
so that's 5
<damex>
hmm... okay, 5 probably will be worth it
<damex>
how is it done? you make target in one MR , migrate device there on another one or does not matter and can start target with a single device?
<shibboleth>
tftp recovery, flash from webui, sysupgrade all tested
<shibboleth>
and the device itself has been stresstested for about 20 hours now
<PaulFertser>
shibboleth: you're supposed to create a commit locally in your repository. Then export it with format-patch.
<shibboleth>
i did?
<PaulFertser>
The working device is very nice!
<PaulFertser>
Your last paste is certainly not something created by "git format-patch".
<shibboleth>
sure it is. minus the header
<PaulFertser>
The DTS file is missing license information.
<PaulFertser>
The header is essential
<PaulFertser>
The commit message too. It shouldn't contain "not staged for commit" and other unrelated info.
<shibboleth>
the header would have to be changed by whoever forwarded the patch
<PaulFertser>
No
<PaulFertser>
The header contains author, date, commit message.
<shibboleth>
<shibboleth> the header would have to be changed by whoever forwarded the patch
<shibboleth>
since it would have to match the source address
<PaulFertser>
shibboleth: it wouldn't be forwarding then
<PaulFertser>
shibboleth: no, it doesn't have to match any address.
<PaulFertser>
Author address is one thing. Sending it is another.
<PaulFertser>
One can send patches From: anybody.
<shibboleth>
i dunno. never used git for other than clone and pull. format-patch only registers the added files for some reason, git diff lists the changed files
<PaulFertser>
If you ever plan to contribute code to free software projects you just have to master some git basics...
dedeckeh has quit [Remote host closed the connection]
<shibboleth>
and the dts is the c2600 dts with a few changed vars. no license
<lemmi>
damex: so. finally have my er-12 unpacked again and could run a couple of things if you want me to
<PaulFertser>
shibboleth: whoever wrote the original dts owns a copyright on it.
<damex>
lemmi: mii device and mdio list from uboot please ;p
<lemmi>
sure
<damex>
also ls -1 /sys/bus/mdio_bus/drivers/ on running system
<damex>
no idea how are we supposed to differentiate between them
am0rphis_ has joined #openwrt-devel
<lemmi>
damex: gist updated
<lemmi>
:O they are using macvlans over the switch device?
<lemmi>
seems like it
<lemmi>
in vepa mode
<damex>
lemmi: how does the disk layout look like?
<damex>
cat /proc/partitions or fdisk -l
<damex>
lemmi: i see that it is the same case as with er4. 4 ports are separate PHYs. it seems to need the same procedure to flash as edgerouter 4.
<damex>
everything seems to be the same or very lose except that switch
<lemmi>
i wouldn't be surprised
<lemmi>
gist updated
llewellyn87 has quit [Remote host closed the connection]
<shibboleth>
PaulFertser, still there?
<damex>
lemmi: so same thing. everything done for er4 could be applied to edgerouter12. is your regular 12 or poe variant?
<lemmi>
damex: without poe
<PaulFertser>
shibboleth: yes
<shibboleth>
here, i rebased the diff commit stages into one, hopefully valid patchfile. i also added the ceremonial license notification: https://paste.debian.net/hidden/09cc9698/
<shibboleth>
shucks, subject is wrong. should be: ipq806x: add support for TP-Link Talon AD7200
<PaulFertser>
shibboleth: there's also a rule that commit message should contain brief overview of the hardware features and flashing instructions
<PaulFertser>
That's an interesting device indeed.
<PaulFertser>
shibboleth: please see git log for other commits that are adding support for new devices.
<PaulFertser>
You'll likely be asked to split 802.11ad parts into a separate commit.
<shibboleth>
it's seven lines across two files to properly populate default config/wireless
<shibboleth>
not like we won't have to add .ax soon
<damex>
lemmi: please also add boot log and /proc/cpuinfo
<damex>
trying to find out how can we find a difference between er4 and er12 (beside ports)
<lemmi>
damex: bootlog into stock or openwrt or both?
<shibboleth>
i'll be adding support for the ax3600/ipq807x next weekend unless i accidentally cut off my own head while combing my hair while trying to commit a patch for the ad7200
<damex>
lemmi: stock should be enough
<lemmi>
k
<damex>
also /proc/cpuinfo on openwrt might be different due to dts/model/etc so maybe both?
<damex>
i haven't seem its sources yet
<PaulFertser>
shibboleth: sorry, I'm not one of the maintainers but I have a feeling they'll be asking you to do that. Because of the way the development works with git the commits need to be reasonably fine-grained.
<lemmi>
damex: done
<shibboleth>
it's copy+paste of the logic already in those files. and the config won't be populated unless there is an .ad radio
<shibboleth>
just like how some devices aren't dual-band, few devices are tri-band
<shibboleth>
this is one, the ax3600 is next
linzst has quit [Quit: Leaving]
<PaulFertser>
shibboleth: just tried sending the patch to myself (and you're in Cc). Did you receive it?
<shibboleth>
if only one .ad device could be added to mainline other ppl would have an easier time adding even more of them since there'd be a basis. luckily the ad7200 is basically a c2600 and the patches are exactly like c2600 support with a few changed vars
<shibboleth>
they can't complain about patches they've already accepted
<damex>
lemmi: thanks, i see that i can not just publish edgerouter 4 changes to be merged, it needs some work to make compatible with adding er4/6p/12/12p/etc devices later :)
<PaulFertser>
shibboleth: got complains of "git am" regarding trailing whitespaces
<damex>
i will think about more tomorrow, now it is time to get some sleep ;p
<shibboleth>
?
<PaulFertser>
shibboleth: in line $(eval $(call BuildPackage,wil6210-firmware)) and then endef, you add trailing whitespaces.
<lemmi>
damex: don't let this hold you back. just having something is a win in my book. worst case is that the er-12 is just an expensive er-4 with 2 sfp cages :>
<lemmi>
er-6p will be interesting. i don't think this one has a switch like the 12
<shibboleth>
confirmed, one whitespace on line 51
<lemmi>
this might be less of an issue to get going
<PaulFertser>
And the patch doesn't seem to apply on current master
<shibboleth>
cloned from commit 9604e216bf7b1445e5ddf66ea12446b65d7f2a69
dangole has quit [Remote host closed the connection]
<PaulFertser>
Well, no wonder you got no mail from the mailing list server then.
<PaulFertser>
There's nothing special about my e-mail configuration, and you were in Cc.
<shibboleth>
lemme check, had not gotten it the last time
<shibboleth>
confirmed
<shibboleth>
PaulFertser, also, the ad-stuff is specific to target/ipq806x (there are a few ipq40xx-devices, how about we give them a basis instead of grandstanding on ceremony). just like the upcoming ax-stuff will be be ipq807x-specific. these are the only device
<shibboleth>
s on the market with this hw and the only three targets
<PaulFertser>
shibboleth: you'll certainly be told to change commit message to include short specs, installation instructions and S-o-b.
<shibboleth>
can you change the commit message for me? add a link to deviwiki, say it's the same device as the c2600 with a third pcie-lane and a third radio?
am0rphis_ has quit [Ping timeout: 240 seconds]
<shibboleth>
install instructions: flash through webui works without a hitch, sysupgrade works fine, same tftp recovery instructions as the c2600 only filename AD7200_1.0_tp_recovery.bin
am0rphis has joined #openwrt-devel
<PaulFertser>
shibboleth: I can mail patch for you if I have a feeling it has any chance to be accepted, and that you'll be receiving review replies. But sorry, I'm not feeling like trying to write a proper commit message, at least not right now.
<shibboleth>
alright. lemme
<PaulFertser>
The last version still adds whitespace errors
<PaulFertser>
Line 1133 endef
<shibboleth>
shait
<shibboleth>
indeed
<PaulFertser>
shibboleth: there's no need to add dts for 4.19, it's going to be dropped anyway soon.
<shibboleth>
yeah, lemme drop it
<PaulFertser>
shibboleth: your patch seems to be breaking network config for netgear,r7800
<shibboleth>
why?
<PaulFertser>
shibboleth: you added new add_switch command and r7800 will be using it
<PaulFertser>
off to sleep, see you tomorrow. I suggest you try to figure out why you aren't getting subscription confirmation for the mailing list, you'll still want it working to send the follow ups.
<PaulFertser>
Ok, last check
<shibboleth>
whitespaces removed, bells and whistles added, switch config rearranged
<PaulFertser>
damn, missing [PATCH]
<PaulFertser>
wtf, format-patch adds it automatically.