<digitalcircuit>
Still working on tracking down the ipq806x CPU governor -adjacent crash/panic, and what "21.02" is missing that "master" has which makes it work. I think I've gotten a handle on how to properly handle git bisect - I overlooked that package dependencies may change over time, so I may need to adjust the "make menuconfig" results instead of just copy-pasting it.
Rentong has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tusker has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
Tapper has joined #openwrt-devel
Rentong has joined #openwrt-devel
indy has quit []
indy has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<digitalcircuit>
And, nope. Or I've happened to pick a series of commits (across openwrt, luci, and packages) that result in failure to build. I'll have to keep digging...
<digitalcircuit>
git bisecting isn't quite straightforward it seems.
<digitalcircuit>
(I'm currently just trying to see if "master" branch from February when "21.02" was split off triggers the kernel panic or not)
bluew has quit [Quit: Leaving]
decke has joined #openwrt-devel
goliath has joined #openwrt-devel
<jow>
ldir: was there any recent dnsmasq change wrt. lease time handling?
philipp64|work has quit [Ping timeout: 480 seconds]
philipp64|work_ is now known as philipp64|work
nitroshift has joined #openwrt-devel
<ldir>
jow: no changes to leasetime - HAVE_BROKEN_RTC build option will change what is stored, basically a remaining duration as opposed to an actual time.
<ldir>
ldir: I've some questions for you in my seeming role of 'dnsmasq liason'
<ldir>
jow: I've some questions for you in my seeming role of 'dnsmasq liason'
<jow>
ldir: right, but that option hasn't been made default, in genral or on some targets?
<ldir>
but perhaps after I have actually got some caffeine in me
<jow>
I was thinking about fixing this issue in LuCI anyway, by impleemnting some heuristic like
<ldir>
no it's an 'advanced' build option - I'm not sure who/why it was added
<jow>
so basically if its smaller than whatever the maximum protocol level dhcp lease value is, then assume its relative, otherwise treat it as unix timestamp
<jow>
just need to figure out what the maximum allowable dshcpv4 leasetime actually is
<jow>
*dhcp
<hexa->
2**32 - 2 secs
<ldir>
fair enough... I think :-)
danitool has joined #openwrt-devel
<jow>
then it won't work
nlowe has joined #openwrt-devel
<jow>
I hoped its way less than 32bit max
<jow>
in the 16bit ball park
<jow>
hexa-: thanks
<ldir>
how about 1 day of seconds ?
Rentong has joined #openwrt-devel
<ldir>
86400
<jow>
but that would yield totally bogus values for long lease times
<jow>
maybe anything smaller than a specific cutoff date
<jow>
like 2020-01-01
<ldir>
ok, so if you have the configure leasetime from uci use that * no. seconds
<jow>
$ date --date="2020-01-01 00:00:00" +%s
<jow>
1577833200
<jow>
so if < 1577833200 then relative
<ldir>
yes that looks like a magic number to me :-)
<rsalvaterra>
ldir: Mostly. Not completely, before the caffeine kicks in. :P
<ldir>
rsalvaterra: the tweak is in my tree https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=e2df11e742d928460ec85bf0296d94ded28ee18b
<rsalvaterra>
ldir: Oh, Simon says (hah!) he's happy. :)
<ldir>
you sound like how I feel - I can't keep both eyes pointing the same way - urrrgghhh
<rmilecki>
ldir: wow, thanks for dealing with that regression properly! nice work
<rsalvaterra>
rmilecki: I complained because it broke my onions. :P
<ldir>
rmilecki: All I did was flag rsalvaterra discovery on the dnsmasq list - Simon did the fixing
* ldir
just handed the broken onions on whilst trying not to cry
<rsalvaterra>
xD
<rmilecki>
nice, guys
Borromini has joined #openwrt-devel
<rmilecki>
fixing is one thing, but debugging issues, describing them & reporting it what we often miss
<rsalvaterra>
ldir: I still argue that RFC6761 handling in dnsmasq should only apply to upstream public (IP) DNS servers, never servers in 127.0.0.1/8 (or maybe even private networks).
<ldir>
jow: I have a favour to ask.
<ldir>
It's a request for help from Simon@dnsmasq
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
* ldir
observes the tumbleweed and hears the crickets - joins in, chirp chirp chirp chirp
SamantazFox has quit [Ping timeout: 480 seconds]
nlowe has joined #openwrt-devel
nlowe has quit [Read error: Connection reset by peer]
aleasto has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
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]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
kpoman has joined #openwrt-devel
<kpoman>
Hello everyone, I am trying too report problems on a router based on ath79, but I dont see "Issues" on github, was it removed ?
<kpoman>
Tapper: do you know which partition, on a dts file, specifies the writable free space for usage ?
<kpoman>
is it label = "config"; ?
<kpoman>
maybe you can give me a tip, basically I installed openwrt snapshot on a RE450, which has 8MB of flash memory, however after installing I get less than 500kB free space, even with a simple basic firmware with almost nothing on it. On a similar device I do get >2MB of free space
<kpoman>
then the next one starts here: art: partition@7f0000
<kpoman>
however, if starting there, the "config" one could be much larger, like (0x7f0000 - 0x630000) size, basically 1792kB of available space
<Tusker>
kpoman: have you looked at that location ? is it full of 0x00 ?
<kpoman>
Tusker: how can I look, check if it is really available ?
<kpoman>
I just see that non-used space before 0x7f0000
<kpoman>
which seems nonsense
<kpoman>
maybe a copy-paste from another device but with wrong config partition size
<Tusker>
agreed, but label = "firmware" is where it is usually written to, and the rest is left alone
<kpoman>
Tusker: sorry I am really noob here, what "is usually written to" ? firmware is a read-only fs with the overlayfs lower (read-only stuff), and config is the empty, writable, upper part ?
aleasto has quit [Remote host closed the connection]
<Tusker>
kpoman: Look at the bootlog on that https://openwrt.org/toh/tp-link/re450 and compare the mtd layout for v1 and v2. they are different oddly enough
<Tusker>
kpoman: 0x0000003e0000-0x000000600000 : "rootfs_data" should be where the data is stored, not config
<kpoman>
Tusker: these bootlogs are from the original firmware ?
<Tusker>
first one is from original
<Tusker>
the v1 v2 ones are from openwrt
<kpoman>
there are hardware diffs between those 2, v1 has another qc chip and more ram
<kpoman>
Tusker: the most important thing to preserve is uboot (to not brick the device and need some extra cable to revive it) ?
<kpoman>
I mean if I expand something much higher in mtd offsets I dont risk killing it, right ?
aleksander has joined #openwrt-devel
<Tusker>
i suppose you can risk overwriting some factory firmware part that is used, such as wifi firmware blobs etc
<Tusker>
but, if you don't write anything in the uboot mtd, you should be able to recover
Rentong has joined #openwrt-devel
<Tusker>
always best to take backups of the device before playing with the mtds :)
nlowe has joined #openwrt-devel
<kpoman>
Tusker: I dont have jtag or whatever, nor can I find here in Brasilia. I would just do stuff which doesnt require those !
Rentong has quit [Ping timeout: 480 seconds]
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
<kpoman>
Tusker: Ok lets try ! hehehe
<kpoman>
hope I wont be crying in 5 minutes from now
nlowe has quit []
kpoman has quit [Remote host closed the connection]
kpoman has joined #openwrt-devel
nlowe has joined #openwrt-devel
kpoman__ has joined #openwrt-devel
<kpoman__>
Tusker: ok, it seems to boot correctly. Is there a way to check the size of that partition ?
<kpoman__>
I tried with df and it reports not a lot of space
nlowe has quit []
kpoman has quit [Remote host closed the connection]
greearb_ has quit [Remote host closed the connection]
Rentong has quit [Remote host closed the connection]
greearb_ has joined #openwrt-devel
Rentong has joined #openwrt-devel
greearb_ has quit [Remote host closed the connection]
greearb_ has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<Borromini>
Tusker i suppose you can risk overwriting some factory firmware part that is used, such as wifi firmware blobs etc < no you cannot. You might be overwriting calibration data.
aleksander has quit [Remote host closed the connection]
<Borromini>
OpenWrt only replaces a small part of the flash and usually sticks to what the OEM uses for kernel/firmware partitions. Not just to maintain compatibility to the extent that you can revert back to OEM firmware, but also not to cripple functionality (e.g. overwriting calibration data would render your wireless unusable)
<ldir>
does anyone know of anything that actually talks to dnsmasq over ubus ?
<ldir>
ie. uses the (limited) dnsmasq ubus interface
<ldir>
or is the ubus support in dnsmasq basically abandonware ?
<jow>
ldir: I'd say it is abandonware
<rsalvaterra>
ldir: Well, another chunk of code to drop. :)
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 481 seconds]
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Tapper has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<ldir>
rsalvaterra: or it needs to be rationalised 'cos there are 3rd parties coming along looking to enhance dnsmasq's ubus capabilities
<rsalvaterra>
ldir: Aw… how about making it optional, then? (Don't know if a new config knob would fly, though.)
lynxis_ has quit []
lynxis has joined #openwrt-devel
<ldir>
in the dnsmasq codebase it is - you don't have to build with 'HAVE_UBUS'
<rsalvaterra>
ldir: So there's a knob already…! Hm… jow, shall we disable ubus support altogether in the dnsmasq makefile?
goliath has joined #openwrt-devel
<ldir>
except Etan has some new functionality in upstream dnsmasq that also has ubus support. Simon has another patch with some more ubus support enhancements.
<ldir>
Etan's dnsmasq support has a pending patch with openwrt to use this functionality (dns source filtering)
<ldir>
so we're in this interesting position of 'somehow ubus support got added to dnsmasq, ubus is a product of openwrt, but openwrt doesn't knowingly use the support nor does it particularly want to'
kpoman__ has quit [Remote host closed the connection]
kpoman has joined #openwrt-devel
kpoman__ has joined #openwrt-devel
kpoman has quit [Remote host closed the connection]
<kpoman__>
is there anything alse than the dts file in order to make the space available for userland ?
<kpoman__>
else
<kpoman__>
I modified the dts of my re450-v2, flashed the new firmware, still see very low space on overlayfs
<kpoman__>
I mean, I downloaded the sdk, edited the dts of my device for a specific partition (label = "config"; reg = <0x630000 0x020000>;) from size 0x20000 to size 0x1c0000, make menuconfig, make, flashed the firmware, but still see almost no free space for extra packages.
<jow>
ldir: if dnsmasq ubus would gain support for managing ipv6 prefixes then this would be interesting
<jow>
ldir: it could enable dnsmasq to become a 1st class drop in replacement for odhcpd
Rentong has joined #openwrt-devel
<ldir>
jow: right - are you willing to chat directly (seen my email) or shall I act as intermediary? Basically from an owrt perspective 'ipv6 prefix over ubus' = ubus alive, else 'owrt' not really interested, do what you will?
<kpoman__>
something am I missing ?
<kpoman__>
any way to test the size of the partitions created from a dts file ?
Rentong has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<ldir>
it's certainly an approach to the situation
Luke-Jr has quit [Ping timeout: 480 seconds]
<rsalvaterra>
ldir: Only in my tree, of course. :)
<rsalvaterra>
The executable gets smaller, but not by much, about 5 kB.
<ldir>
Some of an unkind disposition would say that's 5kB worth of fewer bugs
<rsalvaterra>
Ok, let's smoke-test this…
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
rsalvaterra_ has joined #openwrt-devel
* ldir
waits for rsalvaterra running away from the flames shouting "hot! hot!"
<rsalvaterra_>
ldir: Well, seems to run Fine™. No dnsmasq entries in ubus list, both service instances up and running.
<rsalvaterra_>
ldir: You're not going to see the world burn today, put the lyre down, Nero. :P
<ldir>
you've gained an underscore - should we be worried? These side-effects of disabling ubus are very subtle ;-)
rsalvaterra has quit [Ping timeout: 480 seconds]
<ldir>
jow: if it is a case that nobody wants to write the code..and I can understand why that might be.. I'll say here and now that I'm willing to contribute £250 toward Simon doing it for us - we would need a behaviour specification.
zatwai has joined #openwrt-devel
rsalvaterra_ has quit [Quit: Leaving...]
Luke-Jr has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
rmilecki has quit [Quit: Konversation terminated!]
Tapper has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 482 seconds]
Rentong has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
<kpoman__>
Sorry for bugging the channel, just wanted to know how to make more room available for my firmware. I modified a wrong dts file and still dont see more free space for userspace. What should I check ? Boot logs ? The binary firmware generated and some specific part where the partitioning is done ? Something on the running firmware checking the mtd sizings ? Help please !
Rentong has quit [Ping timeout: 480 seconds]
<jow>
ldir: a lot of the dnsmasq / ipv6 / ubus / pd topic complex is already paged out in may head and I have currently only like 30-60minutes a day to spend on openwrt, if at all
<jow>
ldir: so not sure I am able or willing to tackle this topic in the near future, maybe Q4 or beginning next year
<jow>
s/may/my/
<jow>
ldir: allthough there is no active user of the ubus support in openwrt yet I wouldn't go as far as dropping it, it serves as an upstream endorsed baseline to add features upon, which is a good starting position
<jow>
one possible use I see for it is pi-hole-esque statistics reporting, afair pi-hole folcks patch dnsmasq to make it expose dns cache hit stats
<jow>
being able to obtain that same info via ubus would be a huge plus as well
<jow>
could help to beautify adblock in luci to show fancy stats
<jow>
pie charts and stuff
<lynxis>
kpoman__: it depends on the board. in general you've to remove packages. e.g. removing opkg might help, if you don't want to install anything. depending on your case you can try to remove more package. as alternative to removing opkg, you can removing some packages and install them into the ram after boot.
<lynxis>
kpoman__: also removing luci+uhttpd might be an option. it all depends on your usecase.
<kpoman__>
lynxis: the firmware is almost empty, like on a snapshot. The device has 8MB flash, but is giving me only ~6MB, with less that 600kB of free space on an empty firmware. The DTS is throwing away like say 2MB because of the layout, if you can, just check here, the space thrown away from partition@630000 to art: partition@7f0000 (lot of space between them, however only 0x20000 used). I dont know if that free space can be used to enlarge the rootfs. I
<kpoman__>
dont know which one holds the rootfs, I suppose the one labelled label = "firmware"; ?
<lynxis>
firmware will be split off between linux kernel and rootfs
<kpoman__>
I enlarged label = "config";, compiled and flashed the firmware and it worked, but I dont see space, I suppose because I enlarged a config instead of a rootfs
<lynxis>
kpoman__: I don't know which ones are used by the OEM bootloader. OpenWRT only uses firmware and art partition. The problem might be the partition-table, since the bootloader might use the partition table. so I'm not sure if it's possible to enlarge the firmware partition at all.
<kpoman__>
I suppose there is free space on the mtd, about 2MB of it, there between thos 2 last partitions. However the firmware (rootfs) is at the beginning of the mtd, and that free space at the end
<kpoman__>
lynxis: there is a uboot one
<lynxis>
yes, but u-boot is only the binary partition. it still might use the partition-table.
<lynxis>
you can try it out and might break your board.
<kpoman__>
lynxis: is there any way to let that config partition usable for the overlayfs, or create a partition after the config with empty space usable
<kpoman__>
Right now I have a hue config because I edited the dts. But config is not usable right now, I dont know if it is even mounted
<kpoman__>
hue = huge
<lynxis>
you have to add some sysupgrade code. it might be easier to replace the bootloader. But just look into the bootloader, maybe you can just throw away all partitions except u-boot, art and firmware and extend the firmware till the art.
<lynxis>
no, openwrt is ignoring the config partition. you can try to mount it by hand and you can add a partition entry into the dts. but in the end, I don't know if the effort is worth it. In theory you can create an overlayfs/jffs partition. I'm not sure where are all the bits and peace you've to edit to make it work. You should take a look into the kernel code which parse the "firmware" entry and into procd. And after you managed to get it work,
kpoman__ has quit [Remote host closed the connection]
kpoman has joined #openwrt-devel
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
kpoman has quit [Remote host closed the connection]
<kpoman>
the relevant dts part. The one I modified is "config" which is now large enough, but I suppose the more space is needed on rootfs_data instead
<PaulFertser>
kpoman: rootfs_data is created automatically, the kernel sees how much space squashfs takes, and splits the rest into rootfs_data.
<PaulFertser>
kpoman: and rootfs itself is splitted off firmware partition after determining the kernel size, again, dynamically on boot.
<PaulFertser>
kpoman: partitions named "config" are usually not used by OpenWrt at all, they're just kept for compatibility with vendor firmware.
<PaulFertser>
kpoman: "art" is used only on atheros targets and should always be at the very end of the flash.
<PaulFertser>
kpoman: normal OpenWrt system only cares about "firmware" (which is autosplit into kernel+rootfs+rootfs_data on boot) and "art" (to provide calibration data). MAC addresses of interfaces are sometimes stored in different formats in other partitions, but that's highly vendor firmware specific.
<PaulFertser>
kpoman: not sure if that answers your question as I do not really understand what you're asking :)
<kpoman>
PaulFertser: because of that original file, I only get ~700kB of free space, on an almost empty firmware. And ~2MB are lost from the mtd, as they dont have firmware nor overlay-upper stuff. Something is wrong there, in particular from config to art, where a lot of space is not used
<kpoman>
PaulFertser: I just want to use the not partitioned space, I am noob, I dont know much of the details
<PaulFertser>
kpoman: do you need to have compatibility with the original firmware?
<kpoman>
PaulFertser: I dont care about the original firmware
<kpoman>
but dont have JTAG or other cables
<kpoman>
(nor can I buy them here in Brazil, way too complicated country)
<PaulFertser>
kpoman: by default it's getting Ethernet MAC address from "info" partition, hm...
<PaulFertser>
kpoman: and wmac too.
<PaulFertser>
kpoman: I think if you relocate the MAC addresses elsewhere then you should be free to merge partition-table + info + config into "firmware".
<PaulFertser>
kpoman: surely you can get a way to attach to UART.
<PaulFertser>
karlp: using an SBC or UART converter. Do not tell me Brazil doesn't allow shipping electronic devices by mail ;)
<kpoman>
PaulFertser: I was thinking, isnt there a way to keep info where it is, but create 2 partitions and kinda merge them to make it as a bigger rootfs ? Or have an extra partition that I would mount on boot
<kpoman>
I mean, keep firmware and info where they are, keep config where it is, and between config and art, create a new empty one that I would give to the overlayfs part ?
<kpoman>
(in that case I wouldnt kill/move info)
<PaulFertser>
kpoman: this is not LVM, so probably not easily possible.
<PaulFertser>
kpoman: you can mount an extra partition on boot, sure, but what would you store there?
<PaulFertser>
kpoman: it's not really practical unless you want just some specific directory stored there.
<kpoman>
PaulFertser: not really a directory, I want the whole overlay mounted on it
<kpoman>
the upper I mean
<kpoman>
PaulFertser: maybe some way to mount the upper in that new partition
<PaulFertser>
kpoman: oh well, you can probably do that without too much effort. But how big that gap really is?
<kpoman>
in such case all my overlay would benefit from that extra space without much configuration
<PaulFertser>
kpoman: right, that can work
<PaulFertser>
kpoman: just name that partition rootfs_data and _disable_ kernel squashfs splitter.
<kpoman>
is it quite big, see: from <0x630000 0x020000>; to <0x7f0000 0x010000>; gives around 1.6MB
<kpoman>
PaulFertser: you mean I should add a section for a new partition, call it whatever, example here:
<PaulFertser>
kpoman__: beware, your arrangement is now kinda odd, so probably "sysupgrade -n" will actually keep the configs.
<kpoman__>
PaulFertser: I would prefer to make it more generic, like all the other firmwares. Why is this dts so f*cked up ?
<PaulFertser>
kpoman__: are you asking my why tplink is insane?
<PaulFertser>
s/my/me/
<PaulFertser>
I think that's just the way big companies like that (especially b2c) work.
<PaulFertser>
kpoman__: it is generic enough already, just do "firstboot" manually before sysupgrade if you intend to not keep your configs. Or reset them manually with firstboot after booting new version.
<kpoman__>
well, why on earth would they touch dts partitions from very similar devices ? why have them different at all ?
<kpoman__>
PaulFertser: from now on, I may be forced to always flash from my custom-built firmwares ? Or if I now flash a snapshot online, will it keep my partition new disposition ?
<PaulFertser>
kpoman__: who knows, probably was done by different teams or just different developers. Probably there was some "requirement" "from the business unit" and the developers didn't care to understand it properly. You know Peter's principle?
<kpoman__>
I dont know Peter's principle :o
Rentong has joined #openwrt-devel
<PaulFertser>
kpoman__: if you want to use that additional space you'll need to use your self-built firmwares. Flashing vanilla upstream will try to do the auto-splitting again and won't touch your neet rootfs_data area at all.
<kpoman__>
PaulFertser: can I push this change to the main openwrt repo ?
<PaulFertser>
kpoman__: https://en.wikipedia.org/wiki/Peter_principle not sure if it's scientifically backed up but judging by the popularity I guess many people involved in similar institutions share the impression.
<kpoman__>
(I mean it makes the device much more usable with 1.6MB than with 600kB)
<PaulFertser>
kpoman__: this -- certainly not, it's too "unconventional".
<kpoman__>
I saw about Peter's principle, quite common to see
<kpoman__>
PaulFertser: ok ! and any way to still install online kmods ?
<kpoman__>
overwriting some checksum ? I mean this kernel change is specific and unrelated to kernel itself
<PaulFertser>
kpoman__: I'm not sure. Easier to just compile all the kmods on your own and keep them just in case you need later.
<kpoman__>
PaulFertser: Ok, and define myself as local repo ?
<kpoman__>
I suppose there are wiki pages for this
SamantazFox has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<slh>
kpoman__: you do realize that you're doing eye surgery with torches and pitch forks there?
nlowe has joined #openwrt-devel
nlowe has quit []
nlowe has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
<rsalvaterra>
ldir: Another dnsmasq pet peeve… can't specify --bind-interfaces behaviour with UCI. To do that, I need to add bind-interfaces to /etc/dnsmasq.conf *and* set option nonwildcard '0' in /etc/config/dhcp, because WTF.
nlowe has quit []
nlowe has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
danitool has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rmilecki has quit [Read error: Connection reset by peer]
rmilecki has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
<ldir>
rsalvaterra: that's not a dnsmasq problem - that's an openwrt startup script problem
<rsalvaterra>
ldir: I know, working on it.
<rsalvaterra>
Hysterical raisins, I guess. This feature started in 2.63.
<kpoman__>
slh: sure, I know I am noob, but my devce right now is pretty unusable. I built a 802.11s, and with original firmware it doesnt work, and with openwrt I cant install required packages
<ldir>
rsalvaterra: and to be blunt, the multi-instance dnsmasq.init isn't exactly perfect
<rsalvaterra>
ldir: I think we can find a lot of things which aren't perfect in that script… :)
<ldir>
but why doesn't --bind-dynamic work for you ?
<rsalvaterra>
ldir: It does, but I don't like the idea of having stuff listening on the wildcard. A firewall misconfiguration and you have services exposed on the WAN. Nah.
<ldir>
rsalvaterra: isn't that what --except-interface is for
<rsalvaterra>
ldir: That makes it not listen on a specific interface. But with --bind-dynamic, you'll still listen on the wildcard, so the result is the same.
<ldir>
except dnsmasq knows to throw stuff from that interface away
<rsalvaterra>
ldir: If you take a look at the default configuration, you'll see there are no list {,not}interface entries. It will only listen on the wildcard by default.
<ldir>
at least there's /etc/dnsmasq.conf to cope with specific use cases.
<rsalvaterra>
ldir: Hmm… Does it? I'm inclined to believe you, I haven't looked at that part of the source code (actually, 99 % of the source code).
<rsalvaterra>
ldir: Well, fiddling with both /etc/dnsmasq.conf and /etc/config/dhcp is exactly what I'd like to avoid. :)