* russell--
just discovered that ubiquiti's xw u-boot (v6.3+) request a dhcp lease, so their address becomes unpredictable (not 192.168.1.20, like usual) if on a network with a dhcp server
<russell-->
from the 6.3.0 release notes:
<russell-->
Major changes:
<russell-->
--------------
<russell-->
* TFTP recovery responds to discovery requests and takes address from DHCP.
<russell-->
apparently that applies to XM, XW, and TI
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Rentong has joined #openwrt-devel
tohojo has quit [Remote host closed the connection]
tohojo has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
JohnA has quit [Quit: Leaving]
<philipp64>
aparcar[m]: I'm around briefly but it's late here... what's up?
<aparcar[m]>
philipp64: x86 loses configs between sysuogrades, can you reproduce that?
<philipp64>
never happened to me since Daniel and Yousong fixed all of that up... what sort of losses? Everything? Partial?
<aparcar[m]>
all I guess, maybe dango can go into details
<aparcar[m]>
he reported that the other day, I'll get back to you
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit []
goliath has joined #openwrt-devel
rmilecki has quit [Remote host closed the connection]
rmilecki has joined #openwrt-devel
<jow>
aparcar[m]: what's the problem?
<aparcar[m]>
jow: I think the ACL method isn't supported for luci in 19.07 so the menu doesn't show the attendedsysupgrade entry
<aparcar[m]>
also my code takes only half advantage of LuCIs JS functions since I'm not familiar enough with the concepts, but that's more a optimization not a function thing
<jow>
unsupported acl shouldn't be a problem
<aparcar[m]>
strange...
<aparcar[m]>
jow: other ideas?
<jow>
tried flushing the menu cache?
<jow>
rm -r /tmp/luci-*
<jow>
and tried resloading or restarting rpcd after installing the pacakge?
<jow>
aparcar[m]: the acl dependedncy is wrong
<jow>
your acl group is called "attendedsysupgrade"
<jow>
the menu entry depends on "luci-app-attendedsysupgrade"
<mangix>
Probably could have been avoided by assigning CMAKE_GENERATOR in the main CMAKE_OPTIONS
<mangix>
with a ternary expression or something
<aparcar[m]>
na it's my bad
<aparcar[m]>
now it works thanks
Strykar has joined #openwrt-devel
<xback>
hauke: regarding the backport question for rb912 to 5.4. the exact target is: MikroTik RouterBOARD 912UAG-2HPnD patches are in my staging tree (21.02) and it has been tested
<xback>
if it's OK with you, i'll merge it
<xback>
this one also covers the 5GHz flavour of the board
<xback>
4 patches in total. (including the nand fix)
Tapper has quit [Read error: Connection reset by peer]
ecloud has quit [Ping timeout: 480 seconds]
feriman has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
Tapper has joined #openwrt-devel
feriman has joined #openwrt-devel
Dandel has joined #openwrt-devel
<Dandel>
rmilecki, I got the cferam.000 file for my router from the firmware update. Should I send this file to you for formal submission, or what is the needed steps to get the file into the cfe-bcm63xx tree?
<Dandel>
I know the file is used for two different routers the Linksys EA9500S, and Linksys EA9500 ( version 2 ).
digitalcircuit has quit [Read error: Connection reset by peer]
Rentong has joined #openwrt-devel
digitalcircuit has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<johnf>
I'm working my way through the rather brutal review adschm gave my updated code
<johnf>
quite honestly, I think it's related to the next comment, or at least, I thought that resolved it
<johnf>
I'd appreciate any guidance anyone can offer
<johnf>
I've always found the openwrt community to be very welcoming and supportive, with even really busy senior developpers offering positive guidance
<johnf>
this experience has not been like that :(
dangole has joined #openwrt-devel
<plntyk>
johnf, the 18hours ago comments seem to be polishing
<johnf>
some of them aren't though
<plntyk>
also the question with the flash being there / not there is important - as afaik only supported stuff should be included in dts
<johnf>
it is, I agree
<johnf>
and I'm working to confirm exactly how it works
<johnf>
there are three "strike" comments on resolved no change
<johnf>
but I believed I had resolved each of the issues identified, and asked questions about the ones that I couldn't
<johnf>
I'm going to dig through the previous 26 issues to see if I can figure out what exactly was needed on those points
<karlp>
some of them are cleanup that needs to be done, that you seem to have simply closed as resolved though
<johnf>
the one's I've just marked as resolved now, from the second review
<johnf>
are not yet pushed
<johnf>
the one's from the first review were, I thought, resolved, in my update
<karlp>
well, you've given no comment to say, "will be coming" you've just closed them, and there's no indication of any follow up work arriving.
<johnf>
ok, that's not good, hard though, resolving them like this before I push makes it easier to see where I am in addressing the issues
<karlp>
right, I understand that from your bookkeeping
<karlp>
but the step you missed was a comment, "ok, have worked through these locally and closed all the ones I've worked, will push a new update"
<karlp>
so from outside it just looks like you closed a bunch of questions.
<plntyk>
also the complaint about "not tested" because the format of the entry is wrong in 01-leds so the line / script is broken at that point and that should have shown up if you tested that
<plntyk>
line continuation "|" instead of ")"
<johnf>
I did test
<johnf>
and also noticed some issues with the leds
<johnf>
but didn't understand the cause
<johnf>
was planning to raise that and address it
<plntyk>
you could write a line or two with "issues"
<plntyk>
I did that for my trashy pull request for "crap-drivers"
<plntyk>
"broken" functionality is OK if its documented
<plntyk>
like several broadcom based routers with no support for wireless
<johnf>
ok, I've pushed the ones I marked as resovled
<johnf>
I'm going to test stock firmware to see what's up with the MAC address behaviour
<johnf>
there's something I don't understand in the github interface, some of these comments don't have a reply / resolve thing; other's do
<karlp>
doh, I've been susbcribed to this issue now :|
<johnf>
apparently you left comments but I don't see them
<karlp>
click more links :)
<johnf>
ok, the mystery of the unrepliable comments is resolved, this UI is kind of confusing
<jMcS>
I need that driver because I bought a wifi dongle with that chip
<Pepes>
Buy another one. Problem solved.
Rentong has quit [Remote host closed the connection]
Tapper has quit [Quit: Tapper]
Rentong has joined #openwrt-devel
<rmilecki>
jMcS: cool, you can actually test your package then :)
JohnA has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
decke has quit [Quit: Leaving.]
aiyion_ has quit [Remote host closed the connection]
aiyion_ has joined #openwrt-devel
<plntyk>
jMcS, realtek drivers are really messy and so far every single one of them has bugs - thats why there are currently 3 variants for 1 chipset open
<plntyk>
dunno if / which of these drivers will make it
Rentong has joined #openwrt-devel
<plntyk>
the code for all realtek drivers is from a common source but it just get configured to compile a single version from almost the same codebase
Rentong has quit [Remote host closed the connection]
h01ger has joined #openwrt-devel
<JohnA>
just tried RC3, had hoped that the PPPoE problem might be solved. Unfortunately NOT!
jMcS has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<stintel>
ugh, unifi 6lr availability still not great in Europe
* h01ger
waves to aparcar[m]
* h01ger
trades some cookies with lynxis
* h01ger
thanks everyone for openwrt, which has been my network backbone since >15y :))
<stintel>
<3
<rsalvaterra>
stintel: I'll need one too… but only after September, fortunately. ;)
Rentong has quit [Ping timeout: 480 seconds]
<minimal>
johnA: what PPPoE problem?
goliath has quit [Quit: SIGSEGV]
<stintel>
lucihttp
<stintel>
ninja: error: loading 'build.ninja': No such file or directory
<stintel>
anyone who knows the solution from the top of his/her head
dangole_ has joined #openwrt-devel
<JohnA>
minimal, If I try to set the WA to PPPoE I cannot connect to my ISP. I get a variety of errors. if you take a look at http://pastebin.klam.ca
<JohnA>
minimal, the stuff there is from June 2.
aleasto has quit [Quit: Konversation terminated!]
<stintel>
pffft, now even ath10k-ct is completely unusable for me
<minimal>
johnA: from the logs: pppd[4080]: PAP authentication failed
aleasto has joined #openwrt-devel
<stintel>
connect a mbp 2020 and a galaxy s9 and shit start crapping itself several times per minute
<minimal>
johnA: could there be a problem with the credentials (i.e. password entered wrong)?
<rsalvaterra>
stintel: What ath10k-ct driven hardware? QCA9880?
<JohnA>
minimal, if I switch back to 19.07 copy and past the credentials they work
<stintel>
and once I get my hands on Unifi 6LR, I'll decommission all QCA based HW
<stintel>
I'm done with them
<stintel>
enough is enough
<rsalvaterra>
With upstream ath10k, mine crap out and die with WPA3. With ath10k-ct, they crap out and recover.
<stintel>
upstream craps out and dies even with wpa2
<JohnA>
I can use the wrt by configuring an old netgear 6200 to connect and the hook the wrt up with dhcp. This allows me to do things like update the firmware using opkg.
<rsalvaterra>
Either way, they need nappies. :P
<stintel>
good thing I ordered this GL-MT1300 thing
<stintel>
but of course master doesn't build :)
ashkan has joined #openwrt-devel
<ashkan>
is it me or the wiki's down
<JohnA>
minimal, I can use the wrt by configuring an old netgear 6200 to connect and the hook the wrt up with dhcp. This allows me to do things like update the firmware using opkg.
aleasto has quit [Remote host closed the connection]
<Dandel>
rmilecki: it looks like the firmware image for my router is an invalid BCM4908 image ( at least according to your bcm4908img tool )
goliath has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
feriman has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
<rmilecki>
hauke: i've bcm4908 on my desk which will get broken by the "kernel: Backport patch to automatically bring up DSA master when opening user port"
<rmilecki>
hauke: so I'll keep debugging bcm4908 for half an hour today
<rmilecki>
hauke: i'll test your branch tomorrow on bcm53xx
<hauke>
rmilecki: ok thanks
<hauke>
did you test the bcm4908 with a recent kernel? This patch is upstream since 5.12
<rmilecki>
hauke: i didn't
Borromini has joined #openwrt-devel
<JohnA>
hauke, sorry for the delay, long call with grandkids in NZ.
<blocktrron>
nick[m]4: applied the wolfssl patch to 2102
<nick[m]4>
blocktrron: nice. did u test?
<blocktrron>
yup, works as intended
<nick[m]4>
so we can switch back to openwrt 21.02 :D
<nick[m]4>
I mean wolfssl
<nick[m]4>
thanks a lot!
<blocktrron>
tbh. I'd still prefer openssl by a landslide
<blocktrron>
this broke in 19.07 because of their changing ABI and I'd be very surprised if this would be the last time
<JohnA>
hauke, my PPPoE problem is only occuring on a WRT3200ACM. The device works quite "normally" under 19.07.7. The connection works when I use netgear r6200 (vintage unknown). however, when I switch to 21.02.0-RC3 (linux 5.4.124) it fails.
<JohnA>
hauke, I/ll be away for about an hour, When I get back what info do I need to collect?
<nick[m]4>
blocktrron: okay thanks. however, we have issues with flash memory. we hoped we could use wolfssl
<nick[m]4>
however, openssl works very good
ashkan has joined #openwrt-devel
<russell-->
is there a way to log ibss connections? i don't see anything in dmesg or logread
Borromini has quit [Quit: Lost terminal]
Borromini has joined #openwrt-devel
<mangix>
wonder if wolfssl works with transmission now
<mangix>
my guess is no
<rmilecki>
hauke: i've patched bcm4908enet and have normal boot & failsafe working with your branch
<hauke>
rmilecki: good, what was the problem?
<rmilecki>
hauke: i'll send & push bcm4908enet fix tomorrow morning, please wait few hours before pushing your changes t the master
<hauke>
ok no problem
<rmilecki>
hauke: dma reset and rings handling
<rmilecki>
hauke: after network interface down & up DMA doesn't work anymore
<rmilecki>
fix it trivial, takes rings reset during DMA reset
<rmilecki>
i'm going to sleep now, will take care of it tomorrow
<hauke>
ok, so the up, down, sequenece in the preinit broke it
<rmilecki>
yes
<hauke>
ok no problem, I will just send a v2 to the mailing list