pmelange1 has left #openwrt-devel [#openwrt-devel]
<rsalvaterra>
nbd: Hah! There had to be a logical explanation. Thanks for the insight! :)
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
Ironalchemy is now known as Guest5734
Ironalchemy has joined #openwrt-devel
Guest5734 has quit [Ping timeout: 480 seconds]
dangole has quit [Ping timeout: 480 seconds]
swalker has quit [Remote host closed the connection]
victhor has quit [Ping timeout: 480 seconds]
SamantazFox has quit [Ping timeout: 480 seconds]
SamantazFox has joined #openwrt-devel
madwoota has quit [Remote host closed the connection]
madwoota has joined #openwrt-devel
strobo_ has joined #openwrt-devel
strobo has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
swalker has joined #openwrt-devel
minimal has quit []
hanetzer has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
rua has quit [Quit: Leaving.]
Grommish has quit [Read error: Connection reset by peer]
Grommish has joined #openwrt-devel
valku has quit [Quit: valku]
madwoota has quit [Remote host closed the connection]
madwoota has joined #openwrt-devel
rua has joined #openwrt-devel
ecloud has quit [Remote host closed the connection]
ecloud has joined #openwrt-devel
floof58_ has joined #openwrt-devel
floof58 has quit [Ping timeout: 480 seconds]
<mangix>
Ansuel: only 8327
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<slh>
Ansuel: tl-wdr3600 and tl-wdr4300 here, so should be AR8327N, according to the wikidevi - but the photos (both FCC and OpenWrt) are a bit to blurry to be sure
<Grommish>
Becsause you didn't save on an upgrade, or shouldn't have
<Grommish>
and the theme is a luci package like anything else
<Grommish>
Unless it's baked into the image, yo uhave to add it again
<Ansuel>
or the theme is not installed by default and bootstrap is by default
<Lynx->
Well normally I upgrade using 'attended sysupgrade'
<Lynx->
this time I used 'auc'
<Grommish>
Ansuel: You did the ipq and 5.15 kernel update?
<Grommish>
the PR I mean?
<Ansuel>
Rosy was good but not maintained... jow should really think of putting luci theme outside the luci repo so they can be updated separately
<Lynx->
I thought auc and 'attended sysupgrade' are supposed to be the same
<Ansuel>
or detach them from luci... theme problem is really that the approval process is ""slow""
<Ansuel>
Grp,,osh yes?
<Lynx->
so I need to install package openwrt-theme-2020 ?
<Ansuel>
yes
<Ansuel>
it's not present by default on everyupdate
<Lynx->
auc is not the same as attended sysupgrade?
<Lynx->
or just coincidence that this happened when I used auc
<Lynx->
it's just never happened in months
<Grommish>
Ansuel: I've been using it to test Octeon target. There is a target/linux/generic patch that needs to be changed from 5.10 to 5.15. Who submitts those, asnd when?
<Lynx->
I just checked: luci-theme-openwrt-2020 is installed - so why is it not being displayed?
<Ansuel>
Grommish can you post a comment on the pr? You should submit them when a real 5.15 merge will be introduced but we are a bit far from that.
<Grommish>
Reload the page
<Grommish>
After you install, the LUCI website is just a frame
<Lynx->
I tried that, also with hard reload
<Lynx->
no dice :(
<Ansuel>
Lynx- AFAIK theme are installed by adding stuff to the luci file
<Ansuel>
check if you have luci-opkg in the config dir
<Lynx->
no opkg but maybe the luci file got changed in upgrade
<Lynx->
does that show diff theme?
<Ansuel>
mh the theme is there
<Ansuel>
/etc/init.d/rpcd restart try
<Lynx->
trying
<Lynx->
no dice
<Grommish>
Ansuel: Thanks! MIPS removed the "HAS_6k" "HAS_8K" flags and they gotta come out or it fails.. I'll throw a comment on after I trace it back down and then wait
<Grommish>
I figured as much since there isn't anything to PR against yet
<Ansuel>
Grommish the pr is really for the generic part, i didn't touch other target (aside from ipq806x)
<Lynx->
Ansuel I got it by changing system -> system language / design
<Lynx->
it was set to 'bootstrap'
<Lynx->
naughty router
<Grommish>
Ansuel: Yeah, I pulled all the kernel changes and left the ipq stuff since it didn't apply. Now if only I could figure out where this memleak is coming from, i'd be happy
<Ansuel>
did you tried the kernel memleak stuff ?
<Ansuel>
for simple task it should detect it quickly
<Grommish>
I did.. Then i wrote the upstream, who told me it wasn't the octeon-ethernet driver, but then, when i removed the drivers ethernet/usb) from the imges, no leak
<Grommish>
So.. it seems to be the driver is some form, but I dunno if it's something that ws update between 5.4 and .10 and wasn't accounted for n the driver, or, something else
<Grommish>
And then
<Ansuel>
mips doesn't support ksan so rip about it
<Grommish>
I saw this from my NAS firmware update: The memory usage of dnsmasq would keep increasing when users ran the "nslookup" command in Ubuntu
<Ansuel>
think the only way is bisecting
<Ansuel>
but are you sure is something kernel related and not from userspac?
<Grommish>
So I've heard, but I never heard of the term before yesterday
<Grommish>
Ansuel: KMEMLEAK doesn't show any issues when the ethernet driver is unloaded
<Grommish>
I get THOUSANDS with it. BUT, it was explained why
<Ansuel>
wait you have kmemleak report with the driver loaded?
<Grommish>
"The reason kmemleak thinks those are unreferenced is because those
<Grommish>
"
<Grommish>
memory buffers are given to FPA, and they are not visible to kmemleak
<Grommish>
I get thousands of swapper/0 and softirq entries
<Ansuel>
but why ? afaik there are some way to handle this kind of thing... like telling kmemleak TO NOT TRACK THEM...
<Ansuel>
so let's sum up
<Grommish>
There is programatically
<Grommish>
but i'm not a dev ;p
<Grommish>
I'm just persistent
<Ansuel>
you have a leak with the driver loaded and kmemleak reports leak
<Grommish>
Right.. uner 5.10 and 5.15
<Grommish>
but NOt under 5.4
<Ansuel>
you don't have leak with the driver unloaded and kmemleak clean correct?
<Grommish>
Correct. octeon-ethernet.ko wasn't on the device
<Ansuel>
did you said that 5.4 didn't suffer from this?
<Grommish>
No memleak
<Grommish>
correct, 5.4 is clean
<Ansuel>
that should be a magic word for devs to understand that there is probably a regression in the driver and it's not just some shit from user
<Grommish>
Stintel ran into the same issue with memleak on Octeon
<Grommish>
hasn't had the gear to deal with it.. octeon is a sparse branch
<Grommish>
I hsad attributed it to running large adblock lists, causing RAM to fill sand bootloop
<Grommish>
But that wasn't the case
<Ansuel>
i mean the first thing to do would be investigate the leak reported and flag the untrackabale one the correct way...
<Grommish>
Ansuel: This isnt' go thru a ML or anything.. I'm not brave or techie enough for that yet. this was direct email to the person listed as the Octeon maintainer
<Grommish>
Mostly because I don't know how to quantify what I'm seeing?
<Ansuel>
Grommish you need to reproduce a leak with the system not overloaded / report more data on the leak
<Ansuel>
the best thing would be find a detailed way to reproduce it
<Grommish>
Ansuel: Easy enough.. You just load it and let it sit
<Grommish>
it increases both on free and on luci status every 3 seconds
<Ansuel>
that's not a detailed way :(
<Grommish>
Well.. Can you give me a better way? :) That's been the issue.. i can see it, but I can't nail it down
<Grommish>
except I know that if the octeon-ethernet isn't there, it doesn't do it
<Ansuel>
a good way would be router with only one device connected THAT doesn't do any traffic... clean system. and produce some data and check how the memory bheave
<Grommish>
that's what I got
<Grommish>
this box has a WAN connection and that's it
<Grommish>
it doesn't process LAN at all
<Grommish>
and only have the LO interface withou tthe ehternet driver
<Ansuel>
mhhh can you try router as iperf server
<Ansuel>
client connected
<Ansuel>
iperf bench and report the results
<Grommish>
From the LAN side or from the router to an external
<Ansuel>
LAN side
<Grommish>
LAN to device? I'd have to put the driver back on.. but yeah
<Grommish>
Shouldn't be an issue
<Ansuel>
yes a pc connected to the router to a LAN port with static ip. Router as iperf server Device client and run a bench from the Device
<Ansuel>
does the mem increase ?
<Ansuel>
(and is never freed)
<Grommish>
I can tell you from daily limited use, yes. There is even a difference in what is reported by luci vs free
<Ansuel>
you need to provide all these data to better understand the leak and the cause
<Grommish>
Ansuel: Thanks :) I'll see what I can find
<Ansuel>
once you find a way to trigger the leak in a very bad way then devs can start checking it (if they want)
<Grommish>
Well
<Grommish>
service network stop
<Grommish>
Stops the leak :D
<Grommish>
In a very real way
<Grommish>
But yes, I need more data and now I have an idea on where/how to look
danitool has joined #openwrt-devel
<Grommish>
Do you mind if I hit you up from time to time for ideas on how to proceed?
<Ansuel>
sure feel free also to contact me on the forum
<Grommish>
Ansuel: if that's a better way for you, I'll certainly do it there then :) thanks!
<Ansuel>
back to the main question:
<Ansuel>
anyone that have some knowledge about the offload api in the kernel
<Ansuel>
'
robimarko has joined #openwrt-devel
<robimarko>
Ansuel, nbd is probably the one to ask regarding network offloading
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
dangole_ has quit [Ping timeout: 480 seconds]
<Grommish>
Ansuel: ping - those drivers are in Staging, and AFAIK, haven't been changed in a while. Someone was wondering if maybe the rest of the net stuff changed and octeon just didn't
<Grommish>
Something bad changed between 5.4 and 5.10 and people have been sayig kernel bisect on openwrt is.. not fun?
<Ansuel>
fun stuff
<Ansuel>
it.
<Ansuel>
This driver has been in the tree since 2009 with no real movement to get
<Ansuel>
people who want to fix coding style problems, but can not actually build
<Ansuel>
it out. Now it is starting to cause build issues and other problems for
<Ansuel>
As nothing is happening here, just delete the module entirely.
<Ansuel>
with what i can see things are looking bad for this driver... it looks like its using ancient thing and they are just fixing build problem o.O
<Grommish>
I mean, it builds fine.. Aside from the kernel memleak
<Grommish>
and runs fine, aside from the leak. If I reboot it every day, it's great. I hit max speeds without issue
<Grommish>
which, for me, is 920/240
<Grommish>
QNAP just fixed an issue on their NAS firmware where dnsmasq had a memleak in regards to userspace calling nslooip
<Grommish>
err lookup. this wouldn't be an issue for us right?
<Grommish>
even though nslookup is used for damn near everything :D
<Grommish>
I mean, it's not octeon (aarch64), but if the bug isn't arch specific? dunno..
<stintel>
the driver was nuked from linux.git because of its terrible state
<stintel>
it was later restored
<stintel>
I believe this happened between 5.4 and 5.10
<stintel>
maybe something changed between it being removed and restored and that was not taken into account
<Grommish>
I see 2 commits under 5.4 that asren't under 5.10
<Ansuel>
stintel i didn't check but it wasn't a 100% revert ?
<Ansuel>
never be re-enabled; the others are in drivers which can't currently be
<Ansuel>
I missed a few places. One is in some ifdeffed code which will probably
<Ansuel>
Build fixes for skb_frag_size conversion
<Ansuel>
compiled on x86.
<Grommish>
When i attempted the patch, it said it was already there, so, I had to have missed it in the list
<Grommish>
Ah well.. I'll keep looking D
Tapper has joined #openwrt-devel
<aparcar[m]>
why do we have two lua versions (5.1, 5.3) in tree?
giaco has joined #openwrt-devel
<giaco>
hello
<giaco>
I'm interested in approaching my first openwrt port on an unsupported device, but I'd like to ask you if this target is easy or not from your experience, as I don't want to start from the hardest level you know what I mean
<mangix>
aparcar[m]: because the former is smaller and a lot depends on it.
<mangix>
Ansuel: I only have 8327n
<aparcar[m]>
mangix: so we run both in device at times?
<mangix>
Not sure. It might just be two versions if liblua.
<Habbie>
giaco, the CPU certainly is well-supported in openwrt on various other devices
<Ansuel>
mangix: nice! so i add you to the list testing...
<Ansuel>
but currently i need nbd and do some question about the kernel API
<Ansuel>
the current state is offload support for simple nat
<giaco>
Habbie: good! Any good start point you'd suggest?
<Ansuel>
if you want i can prepare a patch but no idea if it work and how to make it work in openwrt... it does use the same mtk api so in theory should be supported by openwrt hw offload stuff
<Habbie>
giaco, i have one port on my TODO, so your question comes too early ;)
<Habbie>
giaco, do you have root access?
<giaco>
Habbie: yes, on the original firmware
<Habbie>
ok
<Habbie>
i recall people in here asking for flash dumps to help figure out what's what
<Habbie>
and the other first step is to boot over tftp without writing any flash
<Habbie>
again, based on what i read in here
<nbd>
Ansuel: hi
<giaco>
Habbie: makes sense. But isn't booting from ram loaded via tftp a "bootloader feature"? How do I know if I should expect to have it or not?
<Habbie>
giaco, good question, perhaps the other other first step then is to get a serial console?
<Habbie>
you'd want that in any case
<Habbie>
much easier to unbreak things
<Habbie>
(that's also what's holding up my port to a new device - have to solder on serial first)
<giaco>
sure. But uart or jtag?
<Habbie>
i suspect jtag is cooler?
<Ansuel>
nbd: Hi ! don't know if you notice my email
<Habbie>
but unless weird things happen, uart might very well be enough
<mangix>
Ansuel: IIRC the offload stuff uses nftables. OpenWrt carries a patchset to make it work with iptables
<Ansuel>
mangix: so in theory by adding api on the driver side openwrt should support them right away ?
<Ansuel>
anyway my concern were more on the driver part than on openwrt part. we are still at the driver part ahahah
<giaco>
Habbie: does openwrt imply overwriting bootloder, or generally the original booloader persists and openwrt stands in place of the kernel+os?
<Ansuel>
giaco: openwrt doesn't touch bl
<Ansuel>
the image is adapted to work with it
<Ansuel>
(unless bl lock any type of custom image)
<giaco>
got it, thanks. Is secure boot a thing for routers? I guess yes
<Ansuel>
only on recent one and on ipq SoC
<Ansuel>
but many time oem just lock serial access so not secure boot but still no way to install a custom image from the bl
<giaco>
is openwrt doomed to be killed by secure boot in the future?
<Habbie>
giaco, and the links under Firmware on the shoutwiki link you posted?
<Ansuel>
giaco: again depends on the oem if enforcing it or not...
<nbd>
Ansuel: yes, i noticed your email
robimarko has quit [Quit: Page closed]
<giaco>
Habbie: yes I've already considered padawan builds but it's old stuff and I'm not getting all the goodies of openwrt, that I want. Also, I'm here to learn about how to work with openwrt more than making this router a compatible platform. It's just a potential test case
<nbd>
Ansuel: what questions do you have for me?
<Habbie>
giaco, understood
<Habbie>
giaco, but the padawan builds might be very educational during the openwrt porting job
<giaco>
Habbie: yes, I'm already having a look at the AR-1200AC padawan build config
<Ansuel>
nbd: the napt entry have all the required data like sip dip sp dp but it does also require the public ip. Do we have a way to get that from the tc functions? or i'm missing something?