<grid>
no idea if it works but it compiles on gcc 11.2
<mangix>
grid: I updated the PR. tell me what you think.
<mangix>
grid: too many variables
<mangix>
to work around stupid issue
<mangix>
I removed the temporary variable. It better work now.
<mangix>
aparcar[m]: please recheck. I'm pretty much done with this garbage
<grid>
i think the use of memcpy() there prevents an unaligned access
<mangix>
how so?
<grid>
0xBEBFF377 isn't on a 4 byte boundary
<grid>
memcpy() handles that behind the scenes
<grid>
not sure if there's a way around a temporary variable. besides, it's almost cleaner to give 0xBEBFF377 a variable name, else it's just a magic number
<grid>
s/almost//
victhor has quit [Ping timeout: 480 seconds]
<mangix>
grid: it's apparently a memory address.
<mangix>
in any case, who cares about alignment. as long as it works.
<mangix>
well, let's see what the guy with the device says
<aparcar[m]>
mangix: how is it so complicated to get a variable from a pointer?
<mangix>
You tell me.
danitool has quit [Ping timeout: 480 seconds]
<digitalcircuit>
mrkiko: I've actually been out on a trip for the past 10 days or so, no update on the IPQ806x bug hunt so far. Thanks for checking in though! I hope to return to The Case of the Unexpected Reset in the near future (I just got home today).
<aparcar[m]>
mangix: not my expertise, sorry
guidosarducci has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
nitroshift has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
Tapper has joined #openwrt-devel
<mangix>
nitroshift: out of curiousity, when you were testing DSA, did you have only one commit?
<nitroshift>
hey mangix
<nitroshift>
i took only the generic patches out of PR
<mangix>
nitroshift: I know what you mean, but locally without that iproute patch, all even ports were not working for me.
<nitroshift>
mangix, same here
<mangix>
the wrong MAC thing can be worked around
<nitroshift>
let me check again what patches i applied
<mangix>
but the even ports not working indicates the iproute patch was missing
<mangix>
aparcar[m]: that patch is all sorts of insanity
<mangix>
then again, so are DTS less platforms
<nitroshift>
mangix, my bad: left the iproute patch out :|
<nitroshift>
mangix, so now all ports work ok for you?
<mangix>
nitroshift: I believe so. The thing is, they all initially worked and then they stopped. I think what happened was I removed the iproute patch while doing some cleaning on my branch.
<nitroshift>
mangix, i'll fire up a build with the iproute patch included and run-test it
<mangix>
aparcar[m]: migrated to that suggestion. compiles.
<mangix>
that looks like it avoids any unaligned read concerns
danitool has joined #openwrt-devel
<mangix>
danitool: welcome back
<danitool>
hi mangix
<nitroshift>
mangix, i will have the results tomorrow, device is remote, can only test this afternoon
<rsalvaterra>
Looks like people start noticing WireGuard is fast and now want a piece of the action too… but (even a small part of) OpenVPN in the kernel… I don't know.
<rsalvaterra>
*started
<rsalvaterra>
mangix: Yeah, that was my gut reaction too. :)
<mangix>
rsalvaterra: the negative aspect of wireguard. Everyone wants a piece of the pie
<rsalvaterra>
Well, too bad… WireGuard got there first, deal with it. B)
<rsalvaterra>
And it's *simple*.
<mangix>
right. The OpenVPN module should be judged based on lines of code honestly.
<mangix>
funny enough, the original was a reference to Apple
<rsalvaterra>
A reference to Apple…?
<rsalvaterra>
Tell me more.
<mangix>
It's an episode of Futurama. New iPhone came out. The genius was explaining it. Then he hit him with that.
<rsalvaterra>
Oh, you mean the meme! :)
<nitroshift>
mangix, what is eth2 connected to? one end is cpu, but the other end?
<rsalvaterra>
I thought you were talking about the Omnia. ;)
<mangix>
lol no
<mangix>
nitroshift: I think you're confused. All eth interfaces are CPU ports. eth0 and eth1 are connected to the switch. eth2 is just a standalone one.
<rsalvaterra>
mangix: Brazil is a big country, there are lots of different accents… Heck, Portugal is a small country and we also have lots of different accents, depending on the region. :)
<mangix>
I mostly now of the jui-jitsu guys like Rickson Gracie whose first name is pronounced Hickson
<mangix>
*know
pmelange has joined #openwrt-devel
<rsalvaterra>
mangix: Oh, yes, that 'r' at the beginning (as well as 'rr' in the middle of a word) might sound like 'h', depending on the pronouciation.
<danitool>
mangix: I get a kernel panic with your new patch, because the used address (0xbebff377) for ioremap isn't correct
<rsalvaterra>
mangix: It should actually sound more similar to the 'ch' in 'Bach' or 'achtung'. :)
<danitool>
we should use 0x1ebff377 instead
<mangix>
danitool: joy...
<mangix>
danitool: pushed
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
mangix: The LED situation is… interesting.
<mangix>
explain
<rsalvaterra>
Did you see Andew Lunn's email?
<mangix>
oh that
<mangix>
sounded bogus when I read it
MatrixTravelerbot[m] has quit []
MatMaul[m] has quit [Quit: Bridge terminating on SIGTERM]
stintel[m] has quit [Quit: Bridge terminating on SIGTERM]
gnustomp[m] has quit []
Q__ has quit [Quit: Bridge terminating on SIGTERM]
enick_130 has quit []
t4h4[m] has quit [Quit: Bridge terminating on SIGTERM]
pavlix has quit [Quit: Bridge terminating on SIGTERM]
bluse-blue[m] has quit [Quit: Bridge terminating on SIGTERM]
will[m] has quit [Quit: Bridge terminating on SIGTERM]
fieryeagle954[m] has quit [Quit: Bridge terminating on SIGTERM]
decke[m] has quit [Quit: Bridge terminating on SIGTERM]
fpsusername[m] has quit [Quit: Bridge terminating on SIGTERM]
agb[m] has quit [Quit: Bridge terminating on SIGTERM]
John[m]12345 has quit [Quit: Bridge terminating on SIGTERM]
nick[m]12 has quit [Quit: Bridge terminating on SIGTERM]
olmari has quit [Quit: Bridge terminating on SIGTERM]
JuniorJPDJ has quit [Quit: Bridge terminating on SIGTERM]
aparcar[m] has quit [Quit: Bridge terminating on SIGTERM]
ServerStatsDiscoverertraveler4 has quit []
hexagonwin[m] has quit [Quit: Bridge terminating on SIGTERM]
evils[m]1 has quit [Quit: Bridge terminating on SIGTERM]
lipnitsk has quit [Quit: Bridge terminating on SIGTERM]
<rsalvaterra>
I think the Omnia has part of the blame, since it can do hardware triggering offload… ;)
<mangix>
meh. it just means things will need to remain out of tree
<rsalvaterra>
mangix: No, it means no hacks, like it should be. That's how the kernel progresses, with solutions to satisfy all use cases.
<rsalvaterra>
Yes, they take more time.
<mangix>
call me skeptical. The whole 2 port DSA thing was just upstream being indecisive.
<rsalvaterra>
I those situations, we have to keep pressing. We have real use cases that need to be addressed.
<rsalvaterra>
*In
<rsalvaterra>
However, pressing != rushing.
<mangix>
these mass disconnects
<danitool>
mangix: BTW are you able to compile with gcc11 using the 0x1ebff377 address?
<mangix>
gotta love matrix
<mangix>
danitool: wow same error
<mangix>
error: '__builtin_memcpy' may read 6 bytes from a region of size 0 [-Werror=stringop-overread]
<aparcar[m]>
mrkiko: sure but there is no clean implementation right now. Ideally you could control it from buildroot but also imagebuileer
<mrkiko>
aparcar[m]: thanks! So the problem is coming up with an implementation which would allow both.
eduardasm has joined #openwrt-devel
<aparcar[m]>
mrkiko: I got some ideas but not sure what's the cleanest way. Biggest issues that eventually people come and want to see their special corner case covered which would be impossible to cover. So maybe not open this can of worms at all
<aparcar[m]>
you can always try asu.aparcar.org/ and add some custom uci commands
Acinonyx has joined #openwrt-devel
<mangix>
aparcar[m]: it'll succeed. you should look into layerscape again
<aparcar[m]>
i pulled your PR but it crashed at some point
<aparcar[m]>
what do you want me to look at?
<mangix>
merging or testing it. it works absolutely fine here
<mangix>
it's somewhat concerning the CI doesn't do make V=s on failure
<aparcar[m]>
Uhm k
<aparcar[m]>
mangix: it does run make target/install V=s
<mangix>
that's weird since on the layerscape run I never saw the actual failures, just that they failed.
Acinonyx_ has quit [Ping timeout: 480 seconds]
<aparcar[m]>
mangix: dd: failed to open '/home/runner/work/openwrt/openwrt/staging_dir/target-aarch64_generic_musl/image/fsl_ls1012a-frdm-bl2.pbl': No such file or directory
pmelange has left #openwrt-devel [#openwrt-devel]
Tapper has joined #openwrt-devel
victhor has joined #openwrt-devel
pmelange has joined #openwrt-devel
<mangix>
aparcar[m]: the reason is the restool failure. But nothing shows why it failed.
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<aparcar[m]>
mhh I'll look at that later
<Tusker>
stintel: i have been doing trial and error... randomly configuring it seems not very productive... it really could be any combination of phy, non-phy etc... how did you figure it out for the m300 ?
<stintel>
Tusker: I guess I got lucky
<stintel>
at some point I tried packaging a tool to scan mdio buses
<stintel>
but I failed
<stintel>
let me see if I can find the tool
victhor has quit [Remote host closed the connection]
<stintel>
maybe you have more luck trying to package it for OpenWrt
victhor has joined #openwrt-devel
<Tusker>
ha, I packaged it and it's in openwrt-packages already :)
<Tusker>
https://pastebin.com/me8k9JF7 <- definitely useful when I was working on another port... but running into a brick wall with this one
<Tusker>
factory seems to use wg_dsa.ko to init the switch - https://pastebin.com/kjiCfZz6 - I have requested the source code from WatchGuard... but so far no joy
<stintel>
wait what :D
<stintel>
lol
<stintel>
*facepalm*
<Tusker>
maybe worth bumping the version, the guy released 1.0.0 a few days ago
<champtar>
(I'm trying to have someone, anyone look at it :) )
<stintel>
not too familiar with opkg tbh :(
<champtar>
me neither, but it's a cherry-pick and only touch opkg_remove.c
rmilecki has quit [Quit: Konversation terminated!]
<stintel>
preferably acked by one of the people who know its internals though
<stintel>
I've never even looked at the code
<stintel>
pinged someone to look at it
<stintel>
but I have the feeling a lot of developers are MIA on IRC
<champtar>
A bit sad we have a hard fork of opkg because this fix is from 2014 :)
<stintel>
anyone knows if I can retrieve dhcp lease info via ubus?
<stintel>
more specifically, can I lookup the MAC of an IP ?
<stintel>
I guess not
<stintel>
UBUS_METHOD only shows few
Guest482 has joined #openwrt-devel
bluse-blue[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
evils[m]1 has joined #openwrt-devel
fieryeagle954[m] has joined #openwrt-devel
fpsusername[m] has joined #openwrt-devel
gnustomp[m] has joined #openwrt-devel
hexagonwin[m] has joined #openwrt-devel
John[m]12345678 has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
Q__ has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
MatMaul[m] has joined #openwrt-devel
nick[m]1234 has joined #openwrt-devel
olmari has joined #openwrt-devel
pavlix has joined #openwrt-devel
ServerStatsDiscoverertraveler4 has joined #openwrt-devel
stintel[m] has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
MatrixTravelerbot[m] has joined #openwrt-devel
will[m] has joined #openwrt-devel
<rsalvaterra>
stintel: I think aparcar[m] has a cunning plan to migrate to Alpine's apk… :)
<champtar>
stintel: mac is the oldest form of id for dhcp, but you can have id not linked to mac (I'm sure the terms are incorrect)
<stintel>
well if apk is equally small and could allows us to drop a fork we otherwise have to maintain .. why not
<stintel>
but again, I don't know anything about opkg or apk internals, so that's the last thing I'm saying about the subject
<stintel>
champtar: just need to get the MAC for $IP, programatically, current code is reading /proc/net/arp but in some cases this causes duplicates, and the code doesn't handle that so I end up with "$mac$mac" 😂
<mrkiko>
out of curiosity still - where does opkg originate from? And does someonw know why that hard fork actually happened?
<champtar>
ip neigh get ?
<champtar>
or netlink directly
nitroshift has quit [Quit: Gone that way --->]
<champtar>
mrkiko: yocto maintains it now but not sure it was maintained when the fork happened
minimal has joined #openwrt-devel
<mrkiko>
champtar: so maybe some investigation work could be needed to investigate how much the two versions diverged...
<stintel>
champtar: I'm leaning towards ip neigh, yes
felix has quit [Remote host closed the connection]
felix has joined #openwrt-devel
<karlp>
mrkiko: there was a ML thread a few years back that went over some of the differences,and was proposing what it would take to remerge with upstream, could maybe try and dig that up?
kenny has joined #openwrt-devel
jlsalvador has quit [Quit: jlsalvador]
jbowen has joined #openwrt-devel
Tapper has joined #openwrt-devel
jlsalvador has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
<mrkiko>
karlp: thanks for the hint!!
brpr has joined #openwrt-devel
<karlp>
hrm, I'm updating my dragino2 patch moving it from ar71xx back to ath79 modern world,
<karlp>
eth1 detects link up/down properly on cable pulls,
<karlp>
but eth0 jsut always reports as up?
<karlp>
there's no force_link in /etc/config/network, what else would cause that?
<karlp>
(I've no idea anymore if hte old ar71xx code supported link detection on both ports or not)
<karlp>
PaulFertser: that's also 2016, I think upstream went on a dieat as well, as yocto people were complaining, I thought there was a thread more recent than that one.
<PaulFertser>
In "ip l" it's called either NO-CARRIER or LOWER_UP
<PaulFertser>
And if this status is not right then it means MDIO communication regarding eth0 is not right.
<karlp>
carrier says true regardless.
<karlp>
ubuswas also looking at ubus call network.device status '{"name": "ethXX"}'
<karlp>
but yeah, LOWER_UP no matter what on eth0.
<PaulFertser>
With "ip" you get carrier status directly from the kernel. So if it's not correct the next step would be to check what phy eth0 is using and how it communicates with it (what mdio bus etc)
* karlp
digs in the ar71xx code again
Tusker has quit [Quit: Time wasted on IRC: 13 hours 49 minutes 10 seconds]
philipp64 has joined #openwrt-devel
eduardasm has quit [Quit: Konversation terminated!]
<mrkiko>
PaulFertser: thanks for the hint.
goliath has quit [Quit: SIGSEGV]
<karlp>
cute. sysupgrade -v -n results in a boot loop crashing ala https://paste.jvnv.net/view/cyCMS but if you just break into uboot, wait five seconds and reset, it happily boots up normally.
<mrkiko>
karlp: did you check the kernel partition is large enough in ath79?
<karlp>
how would that let it boot after a pause in uboot?
<karlp>
if it's not big enough i tiw ould just never work...
<mrkiko>
karlp: sorry, missed that part of the message
decke has quit [Quit: Leaving.]
<mrkiko>
karlp: wow, very very strange
kenny1 has joined #openwrt-devel
kenny has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Can anyone more experienced with NAND chips tell me if the EN27LN1G08 and F59L1G81MB are mutually compatible?