<aparcar[m]>
No files were found with the provided path: bin/targets/ath79/generic/openwrt-ath79-*. No artifacts will be uploaded.
<mangix>
aparcar[m]: exfat is a kernel module, not really a package
<mangix>
yeah, I see it as kmod-fs-exfat_5.4.79+5.10.1-1_x86_64.ipk
<aparcar[m]>
curious what stopped the images...
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 265 seconds]
goliath has joined #openwrt-devel
black_ant has quit [Ping timeout: 264 seconds]
<ynezz>
aparcar[m]: I've noticed your previous openvpn question, FYI I've already started the "Review and cleanup of base packages" discussion, can't point you to the archive link, here is excerpt from my local archive http://sprunge.us/3sWpKc
<aparcar[m]>
excellent thank you
gch9812139 has joined #openwrt-devel
gch981213 has quit [Ping timeout: 240 seconds]
gch9812139 is now known as gch981213
<aparcar[m]>
mangix: images were built, problem was just a config option in the ci :)
<stintel>
damex: I should look into details again but iirc it was a different soc
<damex>
stintel: yeah, they use different soc on their servers and on consumer devices
<damex>
but platform itself is 'kinda supported' :)
opal has joined #openwrt-devel
<aparcar[m]>
mangix: tested your exfat patch and it worked fine, mounting etc, merged
<stintel>
damex: I'll force myself not to buy anything new to try play with openwrt on until I get one of the other devices I got for that working
<mangix>
aparcar[m]: nothing really to test
<damex>
stintel: haha, at this point i am trying to not get any network device that have no support for openwrt. burned by ubiquiti and their broadcom switches ;(
<rsalvaterra>
Good morning/evening/night! :)
<aparcar[m]>
rsalvaterra: 🦈
<rsalvaterra>
Shark? :P
<stintel>
damex: well I have 2 WatchGuard Firebox M300. I would really like to get them working, would be nice for a HA setup, but just the DTS alone is insane
<rsalvaterra>
… how about we enable airtime policy on hostapd for the -basic variants too? It's only a 4 kiB binary difference, and it's extremely useful for multiple BSS scenarios (most people nowadays have at least a private and guest network).
<aparcar[m]>
rsalvaterra: ping dangole
<damex>
stintel: could be worse. 1/3 of that is what it took to bring dts for cn71xx and actual cn7130 device :)
nast has joined #openwrt-devel
<rsalvaterra>
aparcar[m]: Yeah, I will, no worries. :)
<aparcar[m]>
rsalvaterra: also shark in german is *hai* == hi
<rsalvaterra>
aparcar[m]: Oh…! TIL.
<rsalvaterra>
My German is basically non-existent. :P
<Tapper>
https://t.co/FBcxhTGhew - A new WebAIM survey is open for anyone that implements accessibility. This is a follow-up to previous surveys. Please take a few minutes to complete the survey to provide valuable data and insight into the web accessibility field and practices.
<aparcar[m]>
mangix: btw WARNING: Makefile 'package/feeds/packages/whois/Makefile' has a build dependency on 'perl/host', which does not exist
<Tapper>
That is off topic I know, but It can be helpfull for blind people. Thanks and sorry for the noise.
<aparcar[m]>
Tapper: appreciate thanks
<aparcar[m]>
mangix: I can't reproduce the error message, how to?
<mangix>
make package/argp-standalone/compile V=s
<mangix>
should be there
<aparcar[m]>
nope not here...
gnslu2-lo has quit [Quit: Disconnecting from stoned server.]
nslu2-log has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
<aparcar[m]>
mangix: how do I set the buildroot to use clang?
<mangix>
don't
<mangix>
tools won't compile
<aparcar[m]>
so why is it then supported?
<aparcar[m]>
or semi supported
<karlp>
or, why submit patches for compiling with clang you mean? :)
<mangix>
karlp: because I have CC and CXX set to clang and clang++ locally :)
<karlp>
that's your problem :)
<mangix>
it just so happens that cmake.mk does not set HOSTCC and HOSTCXX for host builds
<karlp>
(I don't see that clang fix submitted upstream either)
<mangix>
both of those are ignored by cmake.mk basically
<mangix>
there's nothing to fix upstream honestly
<karlp>
doesn't sound like anything to fix here then either?
<karlp>
well, maybe a better commit message might be more palatable then :)
<karlp>
because at the moment it's " fix clang, here's some compiler spew"
<mangix>
the compiler spew is pretty clear. you can't redefine builtin functions
<mangix>
*redeclare :)
<karlp>
personally, I don't feel unaccompanied compiler spew is ever an appropriate commit message.
<mangix>
again, I have no idea why that patch is even there. probably a fix to some old glibc version
<aparcar[m]>
I agree with karlp
<mangix>
note that clang is aliased to gcc on at least macos. maybe even the BSDs
<aparcar[m]>
anyway I'm off, more merging tomorrow
<rsalvaterra>
mangix: On macOS gcc is aliased to clang…? O_o
* rsalvaterra
tests…
<rsalvaterra>
Sweet baby Jesus…
<rsalvaterra>
As if I didn't have enough reasons to hate macOS ($dayjob requirements)…
<mangix>
LOL
<mangix>
macos cannot use GCC because of licensing reasons
<rsalvaterra>
Sure, I know… but aliasing?
<nitroshift>
rsalvaterra, i feel you, got a macbook as a gift, gave it away 2 days later
<mangix>
well, do note that clang is compatible with GCC 4
<rsalvaterra>
brew install gcc, I guess…
<mangix>
in a way it makes sense
<rsalvaterra>
nitroshift: This is a 2012 Mac Mini, with the top i7 CPU, it's quite agile… but the OS *feels* slow, when compared to my beloved Debian Sid.
<nitroshift>
mine was an i7 too, still in love with my i7 acer nitro running kali linux
<rsalvaterra>
nitroshift: Yeah, but Linux is much faster, especially for these kinds of workloads (building and git workflow). :)
<nitroshift>
rsalvaterra, exactly! ;)
<rsalvaterra>
It was already the fastest, at the time RCU path name lookup was introduced. After that, it just blows everything out of the water.
adrianschmutzler has joined #openwrt-devel
<mangix>
huh. fedora uses chrony. wonder if I can use timedated
pgjermshus has quit [Ping timeout: 272 seconds]
<nitroshift>
nbd, ping
<rsalvaterra>
mangix: I use systemd-timesyncd… :P
<ynezz>
is it already possible to compile complete OpenWrt with clang?
<mangix>
nope
<ynezz>
so why to bother?
<mangix>
tools/m4 fails to compile
<ynezz>
kernel likely as well
<mangix>
it's not that
<mangix>
I have CC and CXX set to clang and clang++ for other reasons
<mangix>
cmake.mk does not respect HOSTCC and HOSTCXX
<ynezz>
but GCC is mandatory, clang is not supported
<ynezz>
look at readme at minimal requirements
<mangix>
sure, but it's using it
<ynezz>
those clang changes doesn't make much sense, maybe you should rather detect that clang aka gcc in prereq and error out?
<mangix>
or fix cmake.mk
<mangix>
what makes less sense is that math patch
<ynezz>
are we going to support visual c++ if they make it gcc in wsl3? :p
<mangix>
that's...not going to happen
<mangix>
MSVC is a completely different beast
<ynezz>
it was rather meant as a joke
<Namidairo>
all I wanted from them was the ability to mount ext4 but that's only in preview builds for now
<ynezz>
either we can build complete tree with that compiler and decide that we want to support it, update readme to reflect that or simply ignore the compiler
<ynezz>
simple as that for me
<adrianschmutzler>
Hi, what's neheb's name here on IRC?
<mangix>
pretty sure it's possible. macOS uses clang symlinked to gcc and it builds there
<rsalvaterra>
Well, I hope one day, in the far, far future, we'll be able to compile with clang (or any other standards-compliant compiler). That would be healthy for the project as a whole. :)
<mangix>
the m4 issue is some linker problem
<mangix>
adrianschmutzler: hi
<adrianschmutzler>
ah, you are that ... :-)
<adrianschmutzler>
just saw the libusb-compat removal patch, do you plan to synchronize removal and addition, or can I just merge it?
<mangix>
Go ahead
<mangix>
actually...if I merge on packages first it won't conflict
<adrianschmutzler>
technically, nbd is maintainer, but I doubt he will be too interested in moving that package?
<mangix>
I'm sure he's busy with more important stuff
<adrianschmutzler>
that's what I meant ;-)
<mangix>
anyway, merged to packages
<adrianschmutzler>
thanks. I've picked it into my local tree, so it will go to master in the next two hours
<mangix>
great
victhor has joined #openwrt-devel
<ynezz>
nice, thanks!
Borromini has quit [Ping timeout: 240 seconds]
voxadam has quit [Read error: Connection reset by peer]
jas4711 has quit [Ping timeout: 240 seconds]
voxadam has joined #openwrt-devel
Borromini has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
<zorun>
aparcar[m]: thanks! will do
<zorun>
aparcar[m]: can you also have a look at the other patches?
<adrianschmutzler>
just got aware of the musl 1.2.1 PR again
<adrianschmutzler>
since we probably won't branch anywhere really soon, can somebody give an estimate how long it would take to clean up if we added that one now?
<stintel>
it breaks libvirt and upstream refuses to accept the patches to fix it. not sure if many people use libvirt on openwrt, but it could be a problem
<Namidairo>
would probably be limited to some of the beefier x86 targets using it?
<adrianschmutzler>
and as I understand it, it wouldn't be different after the branch?
<adrianschmutzler>
so we just don't have to deal with it _now_?
al has quit [Ping timeout: 256 seconds]
<adrianschmutzler>
Just saw that the PR is from May ...
<karlp>
probably about when 1.2 came out?
<adrianschmutzler>
I just don't have that much experience how big the risk for stability would be if we added it now ...
al has joined #openwrt-devel
<stintel>
I'd say we skip it and try getting 20.* out asap, we're back to old OpenWrt release schedules atm so we're breaking our own "rules"
<zorun>
let's ask the question the other way around: what advantage would it bring to update to 1.2 now?
<stintel>
but at the same time I'm of not much help these days and probably won't be any time soon
<zorun>
if there is no clear advantage, it's not worth the risk (even if the risk is small)
<adrianschmutzler>
stintel: well, this is about building an opinion, so you are a help with that
<karlp>
swiutching to 1.2 now seems like a really bad idea
<stintel>
one question to ask is: will 1.1 still receive any updates?
<stintel>
as in (security) bugfixes
<karlp>
it's declared eol, but 1.2 only came out in feb, and I guarantee lots of people are sitll on 1.1 and it will get fixes
<Tapper>
karlp The thing is how close are we to branching? If we are branching soon then we should hold off on the update, but if it's going to be a long time untill branching then update it.
<Tapper>
To be clear I would like openwrt 20.xx insted of a update to
<Tapper>
1.2
<Borromini>
Tapper: any extra major change just pushes branching further forward.
dansan has joined #openwrt-devel
<adrianschmutzler>
and that discussion was mainly my point
<Tapper>
What do we get from updating to 1.2?
<adrianschmutzler>
nobody does seem to address the remaining DSA usability issues soon
<Borromini>
like stintel says, it's looking like old openwrt release schedules again, and that's one of the things people did not want (and one of the reaons we had the lede plit)
<Borromini>
*split
* Tapper
nods
mangix has quit [Read error: Connection reset by peer]
voxadam has quit [Read error: Connection reset by peer]
voxadam has joined #openwrt-devel
<Tapper>
there is some Security Advisories for it, but I don't know if any of them are bad for openwrt
<mangix>
adrianschmutzler: i don't care much for the actual bump as much as I do the other patches in that PR. The PR mixes musl and GCC10 fixes.
<adrianschmutzler>
I can help you much with package changes, but obviously nobody will merge those if they are _only_ in that PR
<mangix>
stintel: maybe alpine has a patch. they've bewn using musl 1.2 since it came out
<adrianschmutzler>
but you seem to have sent several GCC10 fixes separately IIRC
<stintel>
mangix: patches are sent to libvirt upstream, they don't care
<stintel>
everything is in that issue
<stintel>
redhat are asshats
<adrianschmutzler>
stintel: be careful, there are many submissions at our platforms where people could say the same ... :-(
<Borromini>
:P
<mangix>
adrianschmutzler: all tb
<mangix>
tbe patches in that PR are on patchwork
<mangix>
eh maybe except 1 or 2
linzst has quit [Ping timeout: 240 seconds]
linzst has joined #openwrt-devel
jas4711 has quit [Ping timeout: 260 seconds]
jas4711 has joined #openwrt-devel
<Strykar>
do ddns-scripts respect "ddns.global.upd_privateip='1'"?
AdrianFL has joined #openwrt-devel
al has quit [Ping timeout: 260 seconds]
al_ has joined #openwrt-devel
barhom_ has joined #openwrt-devel
<barhom_>
I've come across now several times that the dnsmasq config looses its "dhcp-range=set:lan,192.168...." until I run a restart of dnsmasq. Has anyoen come across this before and know what's going on?
<barhom_>
Before I spend hours trying to reproduce it
<AdrianFL>
Hi guys, I'm working on debugging something on Ubus and I'm planning to add ulog support (from libubox) to it, in a similar way as procd has a debug mode. I think this would be good to have upstream if you think its worth it. Do you have any coding standards I should follow for this?
barhom_ has quit [Read error: Connection reset by peer]
barhom_ has joined #openwrt-devel
<jow>
barhom: maybe the init script detects another active dhcp server in the segment
<jow>
barhom: see if setting option force 1 cures it
<barhom_>
jow, interesting. How does the init script try to detect this even? It sends a dhcp request to see if there is a dhcp server somewhere?
<PaulFertser>
barhom_: yes
<barhom_>
PaulFertser, thanks. For my use case, I do strongly believe force should be default to 1. But I guess there are other better use cases then
<jow>
the intention about not forcing is to avoid disrupting existing lans when plugging in an openwrt device for configuration
<PaulFertser>
barhom_: is running more than one DHCPv4 server on a single line segment a good idea ever?
<PaulFertser>
s/line/ethernet/
<barhom_>
PaulFertser, definentely not. But I am certain in my lab testing I've seen several instances on where the dhcpserver fails to start. And I do not have another dhcp server in my lan
pgjermshus has joined #openwrt-devel
<PaulFertser>
barhom_: then the startup failure is likely explained by other reasons
junland has quit [Remote host closed the connection]
<rsalvaterra>
adrianschmutzler: Hope you didn't fall. :)
<adrianschmutzler>
IMO this is about two completely separate things and should be split
<adrianschmutzler>
though both are tiny ...
junland has joined #openwrt-devel
Mister_X has quit [Quit: Bye]
junland has quit [Remote host closed the connection]
<rsalvaterra>
adrianschmutzler: Ah, you mean de rewording should be a patch and the default -z should be another, right?
junland has joined #openwrt-devel
Mister_X has joined #openwrt-devel
<adrianschmutzler>
yes
junland has quit [Client Quit]
junland has joined #openwrt-devel
<rsalvaterra>
adrianschmutzler: Actually, I'm thinking if it wouldn't be better just to resend everything as a series of three patches…
<adrianschmutzler>
and if you touch in anyway, please change prefix into tools/sstrip
<adrianschmutzler>
3rd is version bump?
<rsalvaterra>
First, version bump. Second, build patch, Third, default -z.
junland has quit [Client Quit]
junland has joined #openwrt-devel
<adrianschmutzler>
err, if you create that file in the version bump, why not give it a proper description right there?
junland has quit [Remote host closed the connection]
<adrianschmutzler>
and send a v2 with two patches, version bump and -z?
junland has joined #openwrt-devel
junland has quit [Remote host closed the connection]
junland has joined #openwrt-devel
<rsalvaterra>
Oh, shouldn't I also increment PKG_RELEASE?
<rsalvaterra>
(Just noticed it.)
<adrianschmutzler>
well, for the _version_ bump you would actually reset RELEASE to one, but it's already there. And for the -z, I'd say that's an external change and can be ignored ...
<rsalvaterra>
I need to read when and when not to change PKG_RELEASE, I still don't get the exact criteria. Is it documented somewhere?
junland has quit [Client Quit]
junland has joined #openwrt-devel
junland has quit [Client Quit]
<rsalvaterra>
Just to make sure we're in the same page: I'll squash the reword into the version update patch and send a the default -z as a second patch, in a series.
junland has joined #openwrt-devel
<adrianschmutzler>
yes. since I'm under the impression that you create the patch that you reword later in the version-bump patch
<adrianschmutzler>
so, make it right on the first patch instead of introducing a second ...
<rsalvaterra>
Yeah, it was basically it. :)
<adrianschmutzler>
Unless the -z is also a consequence of the version bump.
<adrianschmutzler>
then you can squash all of them together
<adrianschmutzler>
or rather "necessity" instead of "consequence"
<rsalvaterra>
It is, in the sense the -z is an argument that didn't exist. Adding it by default maintains the behaviour of the previous sstrip we had in our tree (remove trailing zeros).
<adrianschmutzler>
then squash it all together and expand the description in the remaining patch
<adrianschmutzler>
though I'm not sure whether PKG_NAME should be changed, but that's for somebody else to decide
<rsalvaterra>
Yeah, I had thought about PKG_NAME too, but I wasn't sure what to do about it, so I let it be.
<adrianschmutzler>
aparcar[m]: you commented initially on that patch. any opinion?
<adrianschmutzler>
I'd also be happy if Paul could then evaluate and merge the result, since he tested the initial version and requested the changes ...
<rsalvaterra>
adrianschmutzler: It's still early, aparcar[m] is probably asleep.
<adrianschmutzler>
I've marked the old patches with "Changes Requested".
<adrianschmutzler>
You are probably right.
<adrianschmutzler>
Maybe just send the new patch and add him to receivers
<adrianschmutzler>
You could add the question about the PKG_NAME to the commit message after the ---
<rsalvaterra>
Yeah, I'll send to the mailing list and copy both of you.
<rsalvaterra>
Thanks for the review! v2 coming up shortly. :)
rr123 has joined #openwrt-devel
<adrianschmutzler>
Well, it wasn't really a review ...
jas4711 has quit [Ping timeout: 246 seconds]
<rr123>
l=require('lsqlite3'); error loading module 'lsqlite3' from file './lsqlite3.so':Error relocating ./lsqlite3.so: sqlite3_enable_load_extension: symbol not found
junland has quit [Quit: %ZNC Disconnected%]
<rr123>
not sure about the different between luasql-sqlite3 vs lua-sqlite3 but the latter is the 'official' one from lua.org, however I can not load it, other so module under /usr/lib/lua ars loaded without problems
<rr123>
s/different/difference/
jas4711 has joined #openwrt-devel
junland has joined #openwrt-devel
gch9812138 has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch9812138 is now known as gch981213
junland has joined #openwrt-devel
<rsalvaterra>
adrianschmutzler: Patch sent.
<adrianschmutzler>
BTW don't feel discouraged by the little feedback on your patches, I think you touch the right spots, but there is just not many people able to review that stuff
AdrianFL has quit [Ping timeout: 240 seconds]
<rsalvaterra>
adrianschmutzler: Let me put it this way: I'm used to upstream kernel feedback. ;)
<aparcar[m]>
mangix: wondering if the [..] stuff should be above the SoB line
<jow>
aparcar[m]: feel free
f00b4r0 has quit [Ping timeout: 272 seconds]
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has joined #openwrt-devel
eduardas has joined #openwrt-devel
<rsalvaterra>
dangole: Speaking of airtime policy, I've been playing with it today. I defined a per-BSS limited configuration, but I somehow see all stations with an airtime weight of 256, when I do a iw dev station dump. Is this expected?
<eduardas>
hello, I am quite confused about SPI-NOR flash IC command sets... It seems to me that chips from different manufacturers like Microchip, Macronix and Gigadevice are compatible (like gd25q16c and SST25VF016B), but that particular command set is not really part of any JEDEC standard
<eduardas>
I would be very grateful if anyone could elaborate on this topic... is this a de-facto standard or is there a spec for this?
gch9812138 has joined #openwrt-devel
<mangix>
aparcar[m]: probably.
gch98121387 has quit [Read error: Connection reset by peer]
indy has quit [Ping timeout: 272 seconds]
goliath has quit [Quit: SIGSEGV]
<aparcar[m]>
mangix: please fix that
<mangix>
the PR is not mine
<mangix>
you can manually do it
<adrianschmutzler>
Those commit message could need some polishing anyway
<rsalvaterra>
Is it my impression, or is the hostapd release cycle *really* slow? I mean, the latest version is 2.9 and it was tagged early August last year… :/
ivanich has joined #openwrt-devel
<adrianschmutzler>
but it's up to aparcar whether he prefers fixing himself or pushing the author to do so
<adrianschmutzler>
depending on the author, one or the other might be the better choice ;-)
DonkeyHotei has joined #openwrt-devel
ivanich has quit [Client Quit]
<pkgadd>
rsalvaterra: there is no real release cycle for hostapd
<pkgadd>
it's basically just trunk/ master, it only gets bumped when Jouni notices that a long time has passed and that there really ought to be one soon; to be fair, he does a great job at maintaining security fixes for old(er) releases though
<dangole>
rsalvaterra: i meant the hostapd contained in wpad-mesh-*, and yes, there is no hostapd-mesh
<rsalvaterra>
pkgadd: Ah, I see our makefile points to a specific commit, that explains it.
<rsalvaterra>
dangole: Wait. The mesh variants are -full + mesh stuff. So they already have airtime policy enabled.
indy has joined #openwrt-devel
<stintel>
any reports of broken swconfig ? my DAP-2695-A1 doesn't configure its VLANs anymore after sysupgrade
f00b4r0 has joined #openwrt-devel
<rsalvaterra>
stintel: I had an issue one or two weeks ago, it was caused by a netifd change, but nbd fixed it really quickly.
<pkgadd>
stintel: seems to work with a slightly complex VLAN setup on my nbg6817 (ipq8065) on r15021-b0ecae504b (1.5 days old)
<stintel>
on DAP-2695-A1. similar works fine on EAP-245v3
<stintel>
great. how does one debug this?
<rsalvaterra>
stintel: That's similar to my Archer C6, on which I had the issue. Basically, the WAN VLAN wasn't configured at all, in my case.
<stintel>
wait. would it be caused by uci again, due to /etc/config/snmpd and /etc/config/snmpd-opkg conflicting somehow
<stintel>
I vaguely recall having this on another device
<stintel>
apparently not
<stintel>
apparently something was in my /etc/config/network that broke it
<stintel>
config device 'wl24-guest'
<stintel>
option isolate '1'
<aparcar[m]>
mangix are you up for a commit message fix-up and I do the testing and merge?
<stintel>
a bit annoying that this completely breaks stuff instead of ignoring it
<mangix>
well, do note I never made that commit. I just made the changes. I assumed Pepe would merge those into his commit.
<mangix>
Hmm don't see the issue with the commit, except for the last point being commented badly.
<mangix>
Maybe Removed TARGET_CLAFGS, it is not longer necessary.
<mangix>
whoops
<mangix>
Removed TARGET_CFLAGS. fPIC is default. gnu99 is as well. Defining USE_DOS increases the size by adding extra outdated conversions that are unused.
<adrianschmutzler>
mangix: there is a signed-off-by from you in the second commit
<adrianschmutzler>
if you didn't authorize that, you should tell him
<mangix>
well, I don't really mind.
DonkeyHotei has quit [Ping timeout: 264 seconds]
<stintel>
blocktrron: can you document the wifi options you added recently on the wiki?
dopje has quit [Ping timeout: 272 seconds]
black_ant has quit [Ping timeout: 256 seconds]
<mangix>
there's actually a different issue with libiconv-full that I haven't figured out
<mangix>
when building with BUILD_NLS, the host package becomes totally broken
<Tapper>
Hi am I write in thinking that dnsmasq does DHCP?
<mangix>
I would hope so
<Tapper>
If so why do we have dnsmasq odhcpd and odhcpdv6
<mangix>
because NIH
<Tapper>
NIH?
<mangix>
not invented here
<pkgadd>
dnsmasq-full could do IPv6 as well, but it's not too good with dynamic prefixes (that's where odhcpd is better).
<Tapper>
I don't know a thing about ip v6. why do we need odhcpd and odhcpv6 then if dnsmasq can handle ipv4 dhcp?
<Tapper>
can't dnsmasq do ipv4 and odhcpv6 do ipv6?
<stintel>
yes
<Tapper>
so would dropping odhcp save space
<mangix>
yes
<Tapper>
It sounds to me like we have 3 packages that can do the same thing.
<stintel>
seeing a load of `Thu Nov 26 01:36:55 2020 daemon.notice netifd: radio5 (3230): sh: out of range`
<stintel>
how can one figure out what is causing this ?
<Tapper>
mangix I am not just talking about me I am on about openwrt as a project.
<mangix>
Tapper: eh no. odhcpdv6 is just a package variant with disabled ipv4
<Tapper>
In a stock build of openwrt you have dnsmasq odhcp and odhcpv6
<mangix>
I've actually replaced dnsmasq with odhcpcd before. works well. but no DNS.
<Tapper>
lol I have to say I need me some DNS!
<mangix>
Tapper: one is a client the other is a server
<Tapper>
I am confused.
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<mangix>
odhcp6c is a client used for WAN. odhcpd is a server for the local network
<Tapper>
I did a build of openwrt with out odhcp and odhcpv6. I switched dnsmasq to dnsmasq-full and it all worked
<mangix>
right. But NIH.
<Tapper>
all devices on my net work got dns and dhcp ip-v4 and ip-v6