<GraphicHealer>
Tusker: I think its soldered right...
<GraphicHealer>
Gonna test it...
<Tusker>
ok!
<GraphicHealer>
No chip found
<GraphicHealer>
Does it need power?
<GraphicHealer>
Or gnd?
<Tusker>
yeah, it would
<GraphicHealer>
Both?
<Tusker>
i would try to power on the board and see how it goes
<GraphicHealer>
Ok...
<Tusker>
rather than powering with the bluepill
<GraphicHealer>
gonna try to find my wire extenders
<GraphicHealer>
breadboard hookups
<GraphicHealer>
the power worked!
<GraphicHealer>
now to try SPI
<GraphicHealer>
STILL NOT FOUND
<GraphicHealer>
AUUUGGHHH
<Monkeh>
But as soon as you power it on the CPU on the board is busy using it.
silver has joined #openwrt-devel
<GraphicHealer>
ohhhh
<GraphicHealer>
shoot
<Monkeh>
So you need to hold that in reset or remove the flash chip to work with it.
<GraphicHealer>
how do I get around this?
<Tusker>
probably need to hold the reset pin to ground...
<GraphicHealer>
Ah.
<GraphicHealer>
Which reset?
<GraphicHealer>
the SPI or the SOC
<Tusker>
maybe if you hold the reset button upon power up might work on your board
<Monkeh>
The reset button isn't connected to actual reset.
<GraphicHealer>
idk. Maybe.
<GraphicHealer>
huh. It found it. Read error.
<GraphicHealer>
Could the lock pin be enabled?
<GraphicHealer>
*write protect
<GraphicHealer>
ahhhh it's pulled low.
<GraphicHealer>
the WP (Write Protect) pi
<GraphicHealer>
*pin
<Monkeh>
If you haven't got the CPU in reset you can't play with the flash.
<GraphicHealer>
its pulled low with a resistor
<GraphicHealer>
It finds it now though
<GraphicHealer>
it wouldn't even find it before
<GraphicHealer>
when I hold the reset, i can see the chip is there, but cant read, write, anything.
<Monkeh>
And you shouldn't try
<GraphicHealer>
why?
<GraphicHealer>
and how do I work around this?
<Monkeh>
Because the CPU isn't in reset, which means you're not in exclusive control of the bus
<GraphicHealer>
Do I need to power the SPI seperate from the board?
<Monkeh>
Removing the chip to do that is one option
<GraphicHealer>
As in put the Bluepill's 3.3v and gnd on the spi chip
<GraphicHealer>
not removing the chip
<Monkeh>
And where do you think that 3.3V will go from there?
<GraphicHealer>
idk
<Monkeh>
To everything else running off 3.3V, like the CPU..
<GraphicHealer>
shoot...
<GraphicHealer>
Would using the UBOOT login on uart help?
<Monkeh>
No
<GraphicHealer>
shoot...
<GraphicHealer>
how do I do this then?
<Monkeh>
Remove the chip or hold the CPU in reset. Which again, is not the reset button and may not be convenient.
<GraphicHealer>
Maybe bend the 3.3v of the spi up so its not touching the board and then connect to it and gnd
<Monkeh>
And hope you don't break it off trying
<slh>
chances to break off the pin, much higher than desoldering the whole chip
<GraphicHealer>
I really dont want to have to take anything off
<GraphicHealer>
:(
<GraphicHealer>
THis is so frustrating
<GraphicHealer>
WAIT
<GraphicHealer>
there is a switch that poweres off the device
<GraphicHealer>
oh wait
<GraphicHealer>
the spi uses that...
<GraphicHealer>
DUH
<slh>
soic-8 isn't that bad to desolder/ resolder
<GraphicHealer>
not when you have a crappy low-temp soldering iron
<GraphicHealer>
:(
<Monkeh>
Porting this thing may not be all that useful if there's no way to TFTP it and nobody has worked out their firmware format.
<Tusker>
btw... any idea what the standard process for overriding the mac address of wlan from uboot environment? I can't find any examples of another device doing that, all seem to try and use offsets inside the mtd
<Monkeh>
Tusker: If the MAC isn't stored there, there isn't one
<slh>
Tusker: e.g. nbg6817 and ea8500
<Tusker>
Monkeh: it is stored inside the uboot environment, it's visible in fw_printenv
<Tusker>
but it's not stored at some consistent offset
<Monkeh>
Tusker: But is it normally loaded from there?
<Tusker>
normally? ie, factory firmware ?
<GraphicHealer>
maaan i tried 3.3 and gnd hooked up and it still wont find the chip.
<GraphicHealer>
the board didnt power up though
<Monkeh>
Tusker: By OpenWRT.
<slh>
Tusker: nbg6817 and ea8500 do exactly that
<Tusker>
slh: can you point me to the file that does it ? i've looked in 02_network and in the DTS
<GraphicHealer>
ok, so where would the SoC reset line be?
<Monkeh>
Removing the chip will be easier and safer by the looks of it.
<GraphicHealer>
eeerrrrggg
<GraphicHealer>
dang it
<GraphicHealer>
rrrreeeaaalllyyy didnt want to.
<GraphicHealer>
but ok.
<GraphicHealer>
:(
<Tusker>
slh: yup, I know about the lan and wan set via uboot
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
<Tusker>
just forgot where the mac for the wlan is set, and Monkeh reminded me
<GraphicHealer>
got the chip off
<GraphicHealer>
pns are all stuck together with solder. Gotta clean it up
<GraphicHealer>
*pins
<GraphicHealer>
maaaan this is hard to solder to
linusw has quit [Quit: Connection closed for inactivity]
silver has joined #openwrt-devel
silver has quit []
silver has joined #openwrt-devel
<GraphicHealer>
whelp its dead
<GraphicHealer>
I killed it
<GraphicHealer>
:(
<GraphicHealer>
I have a second one, but IDK if I wanna try that.
<GraphicHealer>
oh wait i missed some solder...
<Tusker>
phew :)
Luke-Jr has quit [Remote host closed the connection]
Luke-Jr has joined #openwrt-devel
<GraphicHealer>
nope dead
<GraphicHealer>
its dead
<GraphicHealer>
beyond repair
<Tusker>
did you know what you did wrong accidentally?
<GraphicHealer>
t'was all for nought
<GraphicHealer>
I think I fried the SPI chip
<GraphicHealer>
Not trying that again anytime soon
<slh>
before throwing it away, desolder/ resolder again
<GraphicHealer>
did that
<GraphicHealer>
no luck
<GraphicHealer>
:(
<GraphicHealer>
Kinda want to see what voltage the power suply outputs tho. Might be usefull.
fda has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
<Monkeh>
12V about 300mA, at a guess
<Tusker>
OK, cool, I think my port is ready for PR, anyone want to review before I submit? :)
<mangix>
hmmm SPARC seems slow
<Tusker>
depends on what SPARC
<mangix>
v9
<mangix>
says SPARC T3-2
<Tusker>
yeah, I suppose... 296Mhz 9 bogomips ?
<Tusker>
oh, the T3-2 should be fast enough
<slh>
it's quite a bit faster than that
<mangix>
compiling openwrt currently on one
<mangix>
no idea why
<mangix>
maybe UltraSparc T5 is faster
<slh>
sadly oracle killed it off for good
<mangix>
compiling openwrt on non x86 seems like a bad idea. the main issue is go host requiring x86
<slh>
well, no big loss without go
<Tusker>
ah, one more question... the uboot has some kind of watchdog counter in uboot, which increments boot, and then switches to the secondary image... is there some standard way to address this in openwrt ?
<slh>
e.g. ea8500, asrock g10 /etc/init.d/bootcount
<Tusker>
cool, thanks
<Tusker>
you have a good memory
<slh>
I've been looking into getting a spare ipq806x device for a long time, so I've been looking into the details as much as possible to weed out the problematic ones
<slh>
(and I also had to go over the details to get dual-firmware working properly on my nbg6817)
<Tusker>
this is my first ipq806x device, so it's been interesting
<slh>
which device are you working on?
<Tusker>
extreme networks ws-ap3935i-row
<slh>
interesting device, I was quite interested in the indoor BT whole house wifi as well (only 2 ethernet ports and brexit shipping/ customs fun spoiled that idea)
<Tusker>
the device is really heavy... massive alumninium heatsink
<Monkeh>
slh: I thought last time I looked at those they were MTK
<Monkeh>
Did they pull a standard BT bait and switch again?
<slh>
well, I hope to receive a used ASRock G10 (ipq8064+qca9980) by saturday, fingers crossed
<Monkeh>
"Quite different in some ways to the Homehubs, which use uncommon chips."
<Monkeh>
Uncommon, he says about two of the most popular VDSL chipsets on the market..
<Monkeh>
I love the amount of heatsink, though, that's unusual
<Monkeh>
I've pondered some myself, but I'm not sure I'm ready for more mt76.
<slh>
would have still been an interesting device with mt7615, but I've promised myself to skip anything with less than 4 ports (and I really wanted to say 4+1 ports here, but my ax3600 only has 3+1)
<Monkeh>
afaik they're intended entirely as APs, but I could be wrong
<Monkeh>
Also I've just identified a critical design flaw.
<Monkeh>
No PoE.
<slh>
whole home, not whole office ;)
<Monkeh>
Homes can have PoE!
<slh>
you're right, but that would have been the least of my concerns (still haven't gotten a PoE switch)
<Monkeh>
Nor do I, but if I'm going to stick things on the ceiling..
<slh>
yep
<Monkeh>
They appear to have three different models now
<Monkeh>
So anything could be in them.
<Monkeh>
Shame it's BT or there'd be convenient photos available.
Slimey has quit [Remote host closed the connection]
rmilecki has joined #openwrt-devel
<mangix>
make[3] -C target/linux compile not done after an hour
<mangix>
oh boy
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
slh has quit [Quit: leaving]
slh64 has quit [Quit: gone]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
rmilecki has quit [Ping timeout: 480 seconds]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Tusker has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<russell-->
GraphicHealer: fwiw, it's typical (in my experience) for the programmer to power the chip, you don't typically power the board normally at the same time
<russell-->
it is also advisable to read the datasheets for the things you are connecting to
nitroshift has joined #openwrt-devel
<mangix>
make[2]: *** [package/Makefile:70: package/install] Bus error
<mangix>
that's a new one
<slh>
welcome to sparc ;)
<slh>
where bus errors are plenty
dedeckeh has joined #openwrt-devel
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
rmilecki has joined #openwrt-devel
<rmilecki>
rsalvaterra: sysupgrade soft bricked my R6220
<rmilecki>
so i won't test mt76 for now
<rmilecki>
it's stuck in a (re)boot loop
<rsalvaterra>
rmilecki: Ouch! What caused it, any idea?
<rmilecki>
no serial, no idea
<rsalvaterra>
Oh, well… there's always TFTP, I hope.
<rmilecki>
still, how is that possible :|
<rmilecki>
i don't recall having such problems in years with "my" targets
<rsalvaterra>
rmilecki: Actually, the target with which I had most issues (especially when making my own builds) was x86-64.
Tapper has quit [Ping timeout: 480 seconds]
<russell-->
would whatever is wrong on the r6220 also be wrong with a dlink dir860l?
Tapper has joined #openwrt-devel
<slh>
push-button tftp recovery tends to be very reliable on netgear devices, so there's a good chance of that succeeding
<nbd>
since it might just be picking up on low-rate mgmt packets when traffic stalls for other reasons
<nbd>
rmilecki: did you run the tests with reset_test that i asked for?
<nbd>
sorry if i missed any response related to that
<rmilecki>
nbd: not yet, I was giving big hopes to rate fixes and spent some time testing them and also recovering my soft bricked R6220
<rmilecki>
those seems very promising
<rmilecki>
ca64a36908b7 mt76: fix mt76_rates for the multiple devices
<rmilecki>
f517116bf14c mt76: add mt76_default_basic_rate more devices can rely on
<rmilecki>
but they don't fix problem after all
<rmilecki>
*seemed
aleksander has joined #openwrt-devel
<rmilecki>
nbd: did you try running iperf over any mt76 supported 2.4 GHz device? today i took me 5,5 minutes to get few slow down & lost connection
<PaulFertser>
rmilecki: there was another idea to try triggering mac resets manually, that wouldn't require any kernel mods, but if they provoke the slowdown you'd see.
Tapper has quit [Ping timeout: 480 seconds]
<rmilecki>
PaulFertser: oh, that reset_test is available with snapshot firmware
<rsalvaterra>
rmilecki: For testing, you're running iperf on two machines connected over Wi-Fi (on the MT7603 interface), right?
<rmilecki>
I thought I need to enable some debugging and recompile
<rmilecki>
rsalvaterra: iperf -s on R6220
<rmilecki>
rsalvaterra: but I tried iperf -s on another device too
<rsalvaterra>
Ok, the server is the router itself.
<rsalvaterra>
rmilecki: What's the wireless adapter on the client machine?
Tapper has joined #openwrt-devel
<rmilecki>
right now:
<rmilecki>
ThinkPad with 05:00.0 Network controller [0280]: Intel Corporation Dual Band Wireless-AC 3165 Plus Bluetooth [8086:3166] (rev 99)
<rmilecki>
i also had issues with:
<rmilecki>
HP EliteBook with 02:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
Rentong has joined #openwrt-devel
<rsalvaterra>
Ugh… Intel 3165. I had so many issues with that one, I replaced it with an RTL8821AE.
Rentong has quit [Remote host closed the connection]
<rsalvaterra>
rmilecki: Anyway, when I get to the RM2100 (playing with the Omnia, at the moment), I'll try to repro the problem you're seeing. I'll be using an ath9k 2x2:2 card on the client, though.
<rmilecki>
rsalvaterra: great, let me know please
<rsalvaterra>
rmilecki: Will do! :)
<rmilecki>
rsalvaterra: too bad you didn't manage to debug that 3165 and iwlwifi / rfkill issue
<rsalvaterra>
rmilecki: Yeah, I just gave up on it for the time being. It's my dad's laptop, it needs to *work*. :P
<rsalvaterra>
And it's an NGFF adapter, my other machines only have mini-PCIe slots, and I didn't bother to get an adapter.
<PaulFertser>
Another thing to rule out the intel gear would be to test one of those mt76 devices as a client to another.
<rsalvaterra>
PaulFertser: Like I said, I'll be using an ath9k card on the client.
<PaulFertser>
rsalvaterra: yes, but that's not what rmilecki has handy.
<PaulFertser>
btw, on mir3g (mt7621) iperf running on device itself is able to pump about 800 Mbit/s so testing right from a device shouldn't get cpu-bound really.
<nbd>
rmilecki: it's been a while since i've done iperf on mt7603, but it did work just fine for me
rsalvaterra_ has joined #openwrt-devel
<PaulFertser>
Might it be something "funny" about iwlwifi and their firmwares?
Tapper has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Ping timeout: 480 seconds]
<rmilecki>
i've found ancient ASUS 1215B with 01:00.0 Network controller [0280]: Qualcomm Atheros AR93xx Wireless Network Adapter [168c:0030] (rev 01)
<rmilecki>
i'm using it with MT7603 on R6220 now
<rmilecki>
big difference: bitrate is 144 Mb/s (MCS 15) instead of 72 Mb/s (MCS 7)
<rmilecki>
I don't see it going down to 6 Mb/s over and over
<rmilecki>
let me test it for few hours
<rsalvaterra_>
rmilecki: The probem is the Intel card? Say it ain't so! /s *facepalm*
<rmilecki>
rsalvaterra_: ask me in few hours
<PaulFertser>
Two different Intel cards.
<rmilecki>
rsalvaterra_: it may also be bitrate related
<rmilecki>
rsalvaterra_: or a mix of everything
<rsalvaterra_>
rmilecki: I don't need to ask, you'll tell us, for sure. :)
<rmilecki>
i will not hestitate ;)
Tapper has joined #openwrt-devel
<rsalvaterra_>
Minstrel >> everything else, I guess.
<rsalvaterra_>
(Note that with mt76 on the router and ath9k on the client, you're running minstrel rate control on both ends.)
<rmilecki>
can I make ath79 run a single stream only? so it stucks at MCS 7 instead of using MCS 15?
<PaulFertser>
minstrel-ht
<rsalvaterra_>
rmilecki: Good question, I have no idea… :/
<rmilecki>
nbd: can I make ath79 run a single stream only? so it stucks at MCS 7 instead of using MCS 15?
<PaulFertser>
You can set antenna mask with "iw"
<rmilecki>
ah
<rsalvaterra_>
PaulFertser: No difference, nowadays. It's just minstrel.
<PaulFertser>
set antenna tx 1 rx 1
<PaulFertser>
I guess
<PaulFertser>
rsalvaterra_: so was renamed, good to know, thanks :)
<rmilecki>
ok, that will be my next test, thanks PaulFertser
<rsalvaterra_>
I can't fscking believe I'm entertaining *again* the idea of moving back from Debian Sid to Ubuntu… because Debian is so horribly slow to update(!!).
<PaulFertser>
What can make Ubuntu update faster? Isn't it borrowing everything related from Debian anyway?
<rsalvaterra_>
PaulFertser: That's what I thought, but not really…
<PaulFertser>
rsalvaterra_: you'll be sorry. Slow is less annoying than surprising silly bugs out of nowhere ;)
<rsalvaterra_>
For example, the glibc is at 2.31 (Sid) vs 2.33 (21.04). Mesa is at 20.3.5 vs 21.x (don't remember the minor).
<rsalvaterra_>
I'd like to give Arch a spin, but it means I'll have to learn to use new admin tools, I guess…
rsalvaterra has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
rsalvaterra_ has quit [Ping timeout: 480 seconds]
<PaulFertser>
rsalvaterra_: do you really need bleeding edge mesa or glibc?
<PaulFertser>
rsalvaterra: re Arch, there you usually have to update the whole system all the time, the dependencies are not that fine-grained. Have you considered Gentoo? I think it's quite manageable if you follow few simple rules (used it for many years).
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
SamantazFox has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<PaulFertser>
For the reference, my gentoo "rules". 1. If you like latest versions, install ~ (testing) system right away (and if you stick to stable, try to minimise the amount of packages you install from testing); 2. Use dracut + genkernel to have trivial painless kernel upgrades; 3. Refrain as much as possible from adding per-package use flags, add them globally instead; 4. Run something like emerge -auDN
<PaulFertser>
@world at least monthly.
goliath has joined #openwrt-devel
<rsalvaterra>
PaulFertser: I like shiny toys. And yes, I *really* want to give crocus and i915g a spin. :)
<rsalvaterra>
PaulFertser: I've used Gentoo years ago (2003-2008, around that time), but only on a headless server. I remember a stage 1 install (with KDE 3) taking almost and entire day. I was young at the time… :P
<rsalvaterra>
cd
<rsalvaterra>
Oops, wrong terminal.
<fda>
$ god
<fda>
-sh: god: not found
SamantazFox is now known as Guest880
Guest880 has quit [Read error: Connection reset by peer]
SamantazFox has joined #openwrt-devel
SamantazFox is now known as Guest882
SamantazFox has joined #openwrt-devel
Guest882 has quit [Ping timeout: 480 seconds]
snh has quit [Remote host closed the connection]
SamantazFox is now known as Guest883
SamantazFox has joined #openwrt-devel
SamantazFox has quit [Read error: Connection reset by peer]
SamantazFox has joined #openwrt-devel
Guest883 has quit [Ping timeout: 480 seconds]
SamantazFox is now known as Guest884
SamantazFox has joined #openwrt-devel
Guest884 has quit [Ping timeout: 480 seconds]
<aiyion>
I just came across an onion omega; a small ar71xx device, which naturally is not supported anymore.
<aiyion>
Apparently there even was a dts file for it in ath79, which got removed in fc553c7e4c8eea898aaa2086574b7e8737f6d26c due to its incompleteness.
<aiyion>
May someone take a look at it and tell me how unlikely it is for met to complete its ath79 migration?
<aiyion>
*for me
<PaulFertser>
aiyion: what's your experience with embedded Linux?
<aiyion>
The commit message said something like "the device support is never added to ath79 target". Is that due to technical limits, or just because it was never added?
<PaulFertser>
aiyion: just because never added
<PaulFertser>
aiyion: you can take a look at commits some other ath79 devices for example.
<aiyion>
PaulFertser: using openwrt and gluon since 2013, got a rough overview over gluons development and structure, but lack openwrt internals. Not that I wouldn't like to learn about them, I just did not yet.
SamantazFox is now known as Guest885
<PaulFertser>
aiyion: please read e.g. 27eae6597e5f1570f2f0a8584907b077e724a0e1 and say if anything's unclear
SamantazFox has joined #openwrt-devel
<aiyion>
PaulFertser: that looks like a really nice starting point.
<aiyion>
It's unlcear to me, whether one can dropsections that do not apply, like the ones on lan ports.
Guest885 has quit [Read error: Connection reset by peer]
SamantazFox is now known as Guest886
SamantazFox has joined #openwrt-devel
<aiyion>
And how the modularity of boards like the omega should be reflected
<aiyion>
In its base configuration, it does not even have a usb port;
<aiyion>
with one of two extension boards it has;
<aiyion>
and with a third one (which I do not possess) it even has lan.
SamantazFox is now known as Guest888
SamantazFox has joined #openwrt-devel
<aiyion>
Other than that I'll try to build something that works for me and come back with proper questions. Thanks!
Guest886 has quit [Ping timeout: 480 seconds]
SamantazFox has quit [Read error: Connection reset by peer]
Guest888 has quit [Ping timeout: 480 seconds]
SamantazFox has joined #openwrt-devel
SamantazFox is now known as Guest890
SamantazFox has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
Guest890 has quit [Ping timeout: 480 seconds]
SamantazFox has quit [Read error: Connection reset by peer]
SamantazFox has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
snh has joined #openwrt-devel
Pasti has joined #openwrt-devel
<Pasti>
elo
Pasti has quit [Remote host closed the connection]
SamantazFox has quit [Ping timeout: 480 seconds]
nitroshift has quit [Remote host closed the connection]
aleasto has joined #openwrt-devel
rsalvaterra_ has quit []
rsalvaterra has joined #openwrt-devel
Tapper has quit [Ping timeout: 481 seconds]
<fda>
when i build an image with latest revision, the device shows then with "opkg list-upgradable", like "libuv1 - 1.41.0-1 - 1.41.0-3". Why is that? How could i build an image with all updates?
<Namidairo>
don't forget to 'scripts/feeds update'
<Namidairo>
or was it './scripts/feeds update -a' as the quickstart says
<fda>
i do it wiht "./scripts/feeds update -a" + "./scripts/feeds install -a"
Tapper has joined #openwrt-devel
<fda>
but it seems not be enough
<fda>
and even a complete new checkout shows upgradables
<rsalvaterra>
Guys, does anyone know what can cause hostapd AP-STA-POLL-OK messages in the logs?
rsalvaterra_ has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
rsalvaterra_ has quit []
rsalvaterra has joined #openwrt-devel
minimal has joined #openwrt-devel
slh has quit [Ping timeout: 480 seconds]
slh64 has quit [Ping timeout: 480 seconds]
slh64 has joined #openwrt-devel
slh has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Rentong has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
lynxis has quit [Remote host closed the connection]
fda has quit [Read error: Connection reset by peer]
fda has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
lynxis has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
<jow>
fda: that upgradable libuv might be an AUTORELEASE artifact
danitool has joined #openwrt-devel
<jow>
fda: problem is that by defualt package feeds are cloned shallow, which causes the pkg revision calculation to be off
<jow>
binary repos are built with full clones, so pkg release -3
<jow>
yours is built with a shallow clone only containing the latest change, so pkg release -1
<jow>
try this:
<jow>
sed -e 's/src-git/src-git-full/g' feeds.conf.default > feeds.conf && ./scripts/feeds update
<jow>
aparcar[m]: maybe you should look into AUTORELEASE / git-src shallow clone interaction again, seems to lead to confusion
<fda>
@jow thx, i never heard about this, i will check
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
silver has joined #openwrt-devel
jlsalvador has quit [Remote host closed the connection]
jlsalvador has joined #openwrt-devel
Rentong has joined #openwrt-devel
<fda>
@jow: tested, this works for all packages.
<fda>
additional question about kernel modules:
<fda>
" pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.46-1 ......." is still there. "uname" shows im running "5.10.46". this was before & after creating feeds.conf
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
<stintel>
hmmz, modifying existing firewall zones with uci is annoyingly complex, or I'm doing it wrong :P
<stintel>
zone_id=$(uci show firewall | grep -E "^firewall\.@zone\[.\]\.name='wan'" | sed -E 's/.*\[(.)\].*/\1/'); uci set firewall.@zone[$zone_id].input="ACCEPT"
<stintel>
if anyone knows a less ugly way, that'd be appreciated :P
<fda>
yes, this is uhly stintel
<fda>
you could modify this:
<fda>
fw_traffic_on() { uci del $(uci show firewall | sed -n "s/\.name='$1'$/.enabled/p") 2>/dev/null ; }
<fda>
fw_traffic_off() { uci set $(uci show firewall | sed -n "s/\.name='$1'$/.enabled=0/p") ; }
<fda>
fw_traffic_on 'Allow-DHCP-Renew'
<stintel>
fda: that's pretty neat, thanks!
dedeckeh has quit [Remote host closed the connection]