guerby_ has quit [Read error: Connection reset by peer]
guerby_ has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
will[m] has joined #openwrt-devel
slh has quit [Remote host closed the connection]
slh has joined #openwrt-devel
<will[m]>
hiya, i got my first package to build with the sdk, but my next hurdle is that my second package needs to include the first as a library. i've messed around with DEPENDS and PKG_BUILD_DEPENDS and i'm getting nowhere quick, any suggestions?
slh64 has quit [Ping timeout: 480 seconds]
<will[m]>
if i wanted to be really evil i'd put something like this in my second project's (not the opkg but the project itself's) makefile:
<will[m]>
but that's probably the worst possible way of doing that
valku has quit [Remote host closed the connection]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
danitool has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
alex_const has joined #openwrt-devel
<alex_const>
Hi. I'm interested in adding device support. Does OpenWrt require me to assign my copyright to someone? If so, to what entity?
<Borromini>
alex_const: no copyright is yours
<Borromini>
you can't assign copyright to OpenWrt itself afaik
<Borromini>
no idea how that plays with GPL etc though
<alex_const>
Borromini: it's just that many GPL projects often assign copyright to a charity like the FSF so I was curious
<PaulFertser>
alex_const: not needed for OpenWrt
<PaulFertser>
alex_const: basically, same as with Linux.
<alex_const>
I see, thanks
Borromini has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
_lore_- has joined #openwrt-devel
_lore_ has quit [Ping timeout: 480 seconds]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
rejoicetreat has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
alex_const has quit [Quit: Page closed]
aleasto has quit [Ping timeout: 480 seconds]
Borromini has quit [Quit: Lost terminal]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
fda has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
alex_const has joined #openwrt-devel
<alex_const>
Another question regarding adding device support. I am not sure how long this will take. I see that 21.02 release uses kernel 5.4.132. Should I target this kernel when creating patches or some other revision? The device in question uses kernel based on 3.3.8.
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
snh has quit [Remote host closed the connection]
snh has joined #openwrt-devel
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
alex_const has left #openwrt-devel [#openwrt-devel]
alex_const has joined #openwrt-devel
Rentong has joined #openwrt-devel
anon__ has quit [Ping timeout: 480 seconds]
rejoicetreat has joined #openwrt-devel
<PaulFertser>
alex_const: you should target Linux upstream first of all. Then you can backport some of the patches to whatever version OpenWrt master happens to use at that moment.
<alex_const>
PaulFertser: Why? I thought the patches first go to OpenWrt and then get sent upstream.
<PaulFertser>
alex_const: some patches get into hack-*, those are not for upstream. Others should be sent upstream as OpenWrt is trying hard to be as close to upstream as possible, so you increase the chances of problem-free support if you sent something to upstream first. I do not mean they must be _accepted_ upstream before you can send to OpenWrt, no.
<PaulFertser>
alex_const: try to imagine you're an OpenWrt maintainer and you'd be willing to be bothered with different patches as little as at all possible. What would you ask from the contributors regarding upstream in this case?
<alex_const>
PaulFertser: Oh, I see. Then I'll try to port the code to mainline kernel, build that with OEM's kernel config and see if the rest of the OEM's system will be fine with the new kernel. Does this sound about right? Should I expect compatibility problems in userspace? Going from 3.3.8 to 5.14 sounds a bit scary :)
<PaulFertser>
alex_const: not sure if you need OEM's userspace for anything. You can make OpenWrt build any kernel with your patches for you, just specify a directory where your git repo is in the config. But to get OpenWrt booted you might need some patches from generic/ , that might complicate testing with linux-next and plain OpenWrt userspace I admit.
<alex_const>
PaulFertser: Do I need to solder the wires to get to the serial console except if I brick the device?
<PaulFertser>
alex_const: any kernel work without serial console is pain in the arse.
<alex_const>
PaulFertser: Haha, good to know. Thank you!
<PaulFertser>
alex_const: if connecting to serial is possible at all anyhow then what can be the reason not to do that?
<alex_const>
PaulFertser: the need to solder xD
<alex_const>
which is something I've never done
<PaulFertser>
alex_const: ask someone who has. Or get some scrap boards and train a little. It's a useful skill anyway.
<alex_const>
I will try :)
<PaulFertser>
alex_const: good luck!
<alex_const>
Thanks!
fda has quit [Remote host closed the connection]
fda has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<fda>
if there are hole for serial console, put nails in it and fix with tape
<fda>
if it does not work, put more tape on it
<fda>
worked for me with repeater1200 ;-)
<fda>
@alex_const
<PaulFertser>
nails or seewing needles or something like that yes. But soldering a header is much more reliable and thus comfortable to work with.
<fda>
sure, i neede only tp lnpw why openwrt21 did not start
<fda>
... only to know ...
<alex_const>
guess today is the day I open the device...
_lore_- is now known as _lore_
<will[m]>
This is a pretty good soldering tutorial. Most people make the mistake of not having a hot iron with conical tip, not cleaning the tip, or not applying the side of the tip where it's hottest https://youtu.be/f95i88OSWB4
valku has joined #openwrt-devel
minimal has joined #openwrt-devel
<fda>
btw, soldering is not the problem for me, but i want to do hardware-changes to some devices!
<alex_const>
will[m]: SparkFun! Thanks!
Rentong has joined #openwrt-devel
<alex_const>
btw, does this channel has a bot to record the messages so that they can be archived much like a mailing list?
Rentong has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
pmelange has joined #openwrt-devel
<alex_const>
Opened it up! There they are: 3.3V, ground, TX, RX ^_^
<nick[m]12>
would be awesome to know if it is working :D
<will[m]>
Also alex_const if you have trouble or need to borrow tools, consider looking up your local hackerspace at hackerspaces.org
<alex_const>
I only needed to unscrew the screws and open the top side of the router. No need to take the board out of the rest of the case, you can use it as usual in this state. Good job, ASUS!
Rentong has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<alex_const>
will[m]: wow, didn't think they'd have entries for my country, thanks!
<will[m]>
They're everywhere!
Rentong has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
aleasto has joined #openwrt-devel
alex_const has left #openwrt-devel [#openwrt-devel]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<pmelange>
Would anyone be able to help me with some luci js stuff?
<PaulFertser>
will[m]: everywhere except in russia, moscow :/
danitool has joined #openwrt-devel
<hurricos>
Hmm, is there any reason mesh / IBSS would not work in UNII-2A with iw reg set US?
<hurricos>
e.g. channel 60.
<PaulFertser>
hurricos: have you checked what "iw list" says?
<hurricos>
It's ath9k -- iw list agrees just radar detection.
<hurricos>
I tried first with an AP and IBSS vif, no luck. Then AP+mesh, no luck. Mind you if I only have a mesh or IBSS VIF, I don't see the standard CAC scan
<hurricos>
(in logread output)
<hurricos>
which I think is problematic -- does hostapd not know to perform a CAC scan upon mesh / IBSS VIF, or does hostapd just not want to put those types of VIFs on those channels at all?
<hurricos>
both would be bugs in hostapd, though the latter would be more understandable
<hurricos>
(for at least one reason why those VIFs aren't coming up anyhow)
<PaulFertser>
will[m]: what I do not like about that video is that it doesn't explain how flux is essential. They show how a very clean board and clean components are easily soldered with just the flux in the solder core. It's not always the case.
<hurricos>
OK, it is not a bug in hostapd because at this point hostapd does not bringup mesh VIFs, it's wpa_supplicant
<hurricos>
... So then the question is, is there a way to make a wifi-iface use hostapd to bring up an interface in mode mesh?
<hurricos>
Looks like they are much more interrelated than I thought
<hurricos>
wpa_supplicant exclusively manages mesh-mode; I found commit eefed841b0 which removes patch 016-tests-DFS-test-for-wpa_supplicant-mesh.patch.
<hurricos>
Many patches were dropped in that commit eefed841b0, it looks like!
Tapper has quit [Ping timeout: 480 seconds]
fda has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
fda has joined #openwrt-devel
<hurricos>
nbd: RE commit eefed841b0, it looks like some patches were dropped from wpa_supplicant. One of the patches looks like it enabled wpa_supplicant to do radar scans for mesh mode. Is this feature present in any current version of wpa_supplicant?
<hurricos>
My brain has backtracked fully -- we use the base hostapd-common package for wpa_supplicant. So I bet those features were just packed into e.g. wpa-supplicant-mesh-wolfssl
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
aleasto has quit [Remote host closed the connection]
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
<hurricos>
OK, wpad-mesh-wolfssl works. It takes an extra 2 minutes because there's a race to initiate the first scan, and the mesh VIF's scan seems to trample the hostapd's, but eh: https://paste.c-net.org/MoronsGregory
minimal has quit []
Acinonyx has joined #openwrt-devel
<grid>
hurricos: hey did you see my msg about P2041RDB above (on the 18th)?
Borromini has joined #openwrt-devel
<stintel>
ooh more people messing with PPC
<grid>
yeah i'm replacing my rspro with it
<stintel>
cool
<grid>
it's kind of big, even after being transplanted into a smaller case
<stintel>
but I got 2 WatchGuard Firebox M300, also PPC based, managed to boot OpenWrt but never managed to get the network to actually transfer anything
Rentong has joined #openwrt-devel
<grid>
using some odd phy?
<stintel>
the M300 are 1U not very deep
<stintel>
the dts is a total mess, I suspect I'm doing something wrong there
<stintel>
iirc it's like 1500 lines of code
<grid>
ah
<stintel>
it's based on T2081QDS
<stintel>
it might be that I need some proprietary tool to do something during boot
<stintel>
I vaguely remember something about that but it's been a while since I worked on it
<grid>
they've been removing a bunch of unmaintained ppc stuff. luckily p2041rdb made the cut
<stintel>
oh I haven't even looked into building u-boot for them
<grid>
it took a couple patches but mainline u-boot now works on p2041rdb
<stintel>
that's pretty cool
<stintel>
that removal commit doesn't seem too drastic, like 600 loc
<stintel>
I guess I can always build an old version and if it helps me at all with those m300's I can look into restoring and reworking it to whatever CONFIG_DM_MMC is
<grid>
just some new driver framework
<grid>
i think it is related to dts
Rentong has quit [Ping timeout: 480 seconds]
<stintel>
heh now I feel like giving it another shot :P
<grid>
ended up having to diff the dissassembly to figure out what changed
<stintel>
yikes, what a nasty commit
<grid>
yeah
<grid>
it turned out, a struct had a different number of members depending on the inclusion of that header
<grid>
so it was touching the wrong memory when trying to access uhm, a function pointer to somewhere IIRC
aleksander has quit [Quit: Leaving]
Borromini has quit [Quit: Lost terminal]
<hurricos>
grid: I did not!
<grid>
ah
<hurricos>
I dropped our P2041RDB into storage about a month ago
<hurricos>
I can pick it up again. I've just been being murdered at work.
<hurricos>
reading ...
<hurricos>
nice case transplant. Wow! Holy crap, that's cool.
<hurricos>
Well done, mainling u-boot!! But it wasn't that hard was it? It's NXP after all. It looks weird but they're never far from mainline :^)
<hurricos>
well, I trust it wasn't that hard anyways ...
<grid>
yeah, well it had support, but it was broken in a couple ways
<hurricos>
gotcha
<hurricos>
Did you ever get the CAM mapping fixed up so Linux sees all the memory?
<grid>
nope, didn't try. 2GB is plenty for me. it was the second pci-e slot and mmc boot i was after
<hurricos>
I know Adrian pinged me about the board and I never actually followed-up.
<grid>
i'm not actually sure it's possible
<hurricos>
do you happen to know what's going on there?
<grid>
with the > 2GB ?
<hurricos>
Yeah.
<hurricos>
Oh, ppc32
<hurricos>
(I'm assuming?)
<grid>
i didn't look too far into it. i can check the datasheet
<hurricos>
you have the datasheet! Do share :^)
<grid>
k, one sec
<hurricos>
thank you ...
<hurricos>
My only other thought was to ask if you'd looked into the XAUI riser card at all.
<hurricos>
The procesor was always supposed to be stuck onto a whitebox switch next to a switching fabric ... heh
<hurricos>
though those riser cards ain't cheap :\
<hurricos>
(not really a 'riser' when you have a PHY and all on there.)
<grid>
no, other than the mode the serdes lanes behave in is determined by the RCW
<grid>
and configuring the RCW requires an ancient eclipse plugin
<hurricos>
oh hahahaha
<grid>
i could tar up the local install dir if you want
<grid>
i think it acting as pci-e is a lot more useful than some one-off $$ unobtanium riser
<hurricos>
No, I don't have a XAUI card anyways, I was just curious. RCW = off-processor, on-die extra hardware queue stuff, yes?
<hurricos>
grid: true.
<grid>
rcw is kind of like the cpu bootstrap settings
<grid>
rather than a bunch of physical strap pins, it reads it from a location based on how jumpers are configured
<hurricos>
I remember seeing a copy of a .... powerpoint basically explaining how each of these parts interrelate
<grid>
it controls hw configuration, clocking, boot location, etc.
<hurricos>
aha
<grid>
there are some hard-coded rcw's in ram and also it can be external. for example, u-boot when built for sd boot prepends an RCW to the beginning of the image (u-boot.pbl)
<hurricos>
I guess I can call the u-boot replacement process a one-time-only thing? I remember seeing the same copy of u-boot on all three pieces of onboard flash
<hurricos>
which is what made me wonder if we could ignore the original u-boot.
<hurricos>
(specifically this came up as I was anxious about partitioning existing flash)
<grid>
if we're still talking about mmc boot, yeah it'd require changing some dip switches on the board
<hurricos>
(I wasn't aware the original u-boot could be so easily mainlined)
<hurricos>
yeah, as if I'm not mistaken you're saying a u-boot replacement is required for mmc boot
<grid>
u-boot actually resides on the mmc itself
<hurricos>
so, flipping a dip switch -> bootrom grabs u-boot from mmc?
<grid>
yes, well i think technically it grabs the RCW from mmc, and the RCW tells it the boot location is mmc
<grid>
'dd if=u-boot.pbl of=/dev/sdd bs=512 seek=8' where sdd is the sd card
<hurricos>
gotcha. OK, thank you, that makes way more sense
<hurricos>
OK, so the build process for sdcard.img will be kind of ugly
<hurricos>
not ugly, really, there's way worse out there, just custommade
<grid>
and then... 'dd if=fsl_fman_ucode_p2041_r2.0_106_1_18.bin of=/dev/sdd bs=512 seek=1680' for the fman microcode
<hurricos>
can we be putting the microcode in the OpenWrt tree? Is it redistributable?
<hurricos>
assuming yes but
<grid>
not sure
<stintel>
where did you guys find the info about that microcode and where to put it ?
<stintel>
is reliable internet not a common thing there then ?
Rentong has joined #openwrt-devel
<hurricos>
stintel: it is! It definitely is. But people are poor and Comcast charges $120/month
<hurricos>
stintel: > cool
<hurricos>
hahaha no. OLSRv1 baby :^)
<hurricos>
It's a giant kludge from the Metamesh days.
<hurricos>
I've been trying to upkeep the legacy stuff with Meraki MR16's which perform way better than the AR9331-based nodes Metamesh sold.
<stintel>
wtf 120 per month
<hurricos>
but we still haven't even gotten 5GHz meshing working. Well, I just did, and I'm publishing the new build
<stintel>
I pay 10% of that :/
<hurricos>
it's also 80 down 5 up
<stintel>
1000/600 :/
<stintel>
geeeez
<hurricos>
Welcome to Vermont, where, if you live far enough from a city, corporations mess with you
<hurricos>
I have Comcast and pay $70 for 100 down, 15 up
<stintel>
bloody hell
<hurricos>
Burlington Telecom spent $34 million from '06 to '15 deploying fiber to the door and you can get great speeds with them -- about 1000 symmetric -- for $100
<hurricos>
but the bank sued them for spending too much money and forced the city to sell it
<stintel>
ok, you do need to get out of Vermont ;)
<hurricos>
Lol. My probably-soon-to-be-wife is the kid of two doctors at UVM and is probably going to be going to UVM
<stintel>
I lied, I pay 35lv per month for 1000/600 ftth which is 17.9 EUR
<hurricos>
lol hahahaha
<stintel>
so thats ~21 USD per month
<stintel>
your prices remind me of Belgium
<hurricos>
why is Belgium so bad??
<hurricos>
oh expensive
<hurricos>
but not shit I imagine?
<stintel>
where they charge you >60 EUR and you still have a data limit
<hurricos>
haaa
<hurricos>
my dream is ... well, the state ran fiber on all their highways with federal money and you can get business class connection through one of the resellers for ....
<hurricos>
well, we pay a lot of money. $555 for 80Mbps
<stintel>
dafuq
<hurricos>
but it's dedicated -- there is never any other traffic
<hurricos>
I figure once we get some SXTsq 5 ac's on the granary in Newport we will be able to take the whole city
<stintel>
funny how these things go ..
Rentong has quit [Ping timeout: 480 seconds]
<hurricos>
Diane happens to work at pretty much every large business as a cleaner and she has connections, though we haven't tested how far those connections can go
<hurricos>
she does clean offices at the granary and knows the IT guy there who would be happy to help
* stintel
plays Therapy? - Diane
<fda>
i noticed a "restore" of settings by luci does not restore directory permissions as they are in the tar.gz.
<fda>
in flash.js is executed: /sbin/sysupgrade', [ '--restore-backup', '/tmp/backup.tar.gz'
<fda>
is it possible that luci/uhttpd hast no root permissions to restore permissions?
<hurricos>
fda: could be if it's jailed? ... but I think not, doesn't restore trigger a reboot?
<fda>
yes, reboots then
<hurricos>
so it'd just copy the file there and then hand off to sysupgrade
<fda>
i noticed this "procd" which seems to be a kind of selinux
<fda>
some dir-permissions are okay, maybe just the one existing also before restore
<fda>
in flash.js: return fs.exec('/sbin/reboot');
<fda>
another bug: after "restore" it redirect to another device, the ip is hardcoded: ui.awaitReconnect(window.location.host, '192.168.1.1', 'openwrt.lan');
<fda>
i had fear i destroyed the config of my mainrouter
<fda>
so, when i restore in terminal i get 755, by luci-webif i get 700 for new dirs
<fda>
can there be sat a suid bit or something for sysupgrade?
<fda>
or procd exception?
<stintel>
fda: I'd report that on bugs.openwrt.org
<fda>
hm, seems to to be very reliable. i requeste a "close" 1 week ago after posting link to the commited fix - no reaction
<fda>
a bug would need a long time to be fixed
<fda>
so im searching the reason for diffeen permissions
<stintel>
well afaik b.o.o is the still the official bugtracker so that's the place to report it
<stintel>
but sure, not everybody looks at it every day
<stintel>
it's still a hobby to most if not all of us
<stintel>
pinging about things in here usually helps
<fda>
PING: please close 3930, fixed and works for my device :)
<fda>
i want say: if i report there, i maybe get in a week an answer. and a fix could take very long
<fda>
so im seatching for the source
<stintel>
I closed 3930 already
<fda>
Thx!
Tapper has quit [Quit: Tapper]
<fda>
when backing up an 750 dir, luci still restores 700 and terminal 755. there is disabled CONFIG_BUSYBOX_CONFIG_FEATURE_TAR_UNAME_GNAME "Enable use of user and group names in tar. This affects contents listings (-t) and preserving permissions when unpacking (-p).". Maybe helpfull