**** BEGIN LOGGING AT Sun Sep 30 03:00:01 2018
Sep 30 08:18:53 <stintel> Hauke: cool (brcm2708)
Sep 30 08:19:09 <stintel> I'm really looking forward to see brcm2708 on 4.14 finally
Sep 30 08:19:23 <stintel> there was some effort before but it was never properly reviewed/tested/merged iirc
Sep 30 08:20:01 <stintel> Hauke: https://github.com/openwrt/openwrt/pull/589
Sep 30 08:20:19 <stintel> Hauke: https://github.com/openwrt/openwrt/pull/606
Sep 30 08:25:54 <biangbiangmian> is there a way to make a firmware image compatible with multiple devices?  do i just add a new entry in compatible = {} ?
Sep 30 10:04:34 <biangbiangmian> what to check when LED's are showing up under /sys/proc/leds but can't be controlled?
Sep 30 15:07:19 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Sep 30 16:24:35 <ldir> definitely an issue with sysupgrade's sometimes not sticking.  Of course the affected devices are remote, so can't serial port them.
Sep 30 16:46:14 <stintel> ldir: I've had that problem when I used wrong combination of ath10k-ct vs firmware
Sep 30 16:46:41 <stintel> ldir: causing ath10k kernel module to hang, some process unable to be killed, result -> sysupgrade just reboots
Sep 30 16:46:59 <stintel> very annoying to debug, since sysupgrade kicks you out
Sep 30 16:47:53 <ldir> hmm, and we recently forced to ath10k-ct
Sep 30 16:48:42 <stintel> pfff, I am messing with some asus ar71xx/ath79 device, added a serial console, but output is mostly garbled
Sep 30 16:48:49 <stintel> and it keeps spitting output
Sep 30 16:50:39 <ldir> I've seen that sort of behaviour when my soldering to serial port ground was less than good!
Sep 30 16:51:16 <ldir> Now there's a surprise... ath10k-firmware-qca988x-ct-htt.  Wasn't expecting htt - what does that do?
Sep 30 16:52:01 * ldir hits ? in menuconfig and is enlightened.
Sep 30 16:53:44 <stintel> ldir: find it in "git log"
Sep 30 16:53:54 <stintel> ct-htt does not work with ath10k stock
Sep 30 16:54:02 <stintel> that could be your issue
Sep 30 16:54:27 <stintel> ldir: if the solder is bad, would it not be random garbled output?
Sep 30 16:54:36 <stintel> in my case, u-boot output is *always* good
Sep 30 17:00:13 <stintel> hmm, maybe the wires were too close
Sep 30 17:00:17 <stintel> it's ok now
Sep 30 17:00:26 <stintel> should have waited until I got a pin header :)
Sep 30 17:02:10 <jwh> heh, killed 2 erx-sfp boxes doing that
Sep 30 17:02:22 <jwh> they have some real electro static sensitivity problems
Sep 30 17:02:31 <jwh> don't even need to short anything to kill them
Sep 30 17:02:57 <jwh> even replugging the uart (usb side) can finish them off
Sep 30 17:03:00 <jwh> its bizarre
Sep 30 17:04:12 <stintel> m25p80 spi0.0: mx25l6405d (8192 Kbytes)
Sep 30 17:04:20 <stintel> yay, this is good
Sep 30 17:04:34 <jwh> o/
Sep 30 17:04:59 <stintel> Memory: 28648k/32768k available (2481k kernel code, 4120k reserved, 525k data, 196k init, 0k highmem)
Sep 30 17:05:00 <stintel> damn
Sep 30 18:20:25 <stintel> wow that was easy
Sep 30 18:29:40 <philipp64|laptop> Hauke: ping
Sep 30 19:13:29 <Hauke> philipp64|laptop: pong
Sep 30 19:17:17 <Hauke> stintel: ping
Sep 30 19:17:34 <Hauke> should we really go with the 450 patches, or remove some?
Sep 30 19:17:43 <Hauke> when we take all of them updating this is easier
Sep 30 19:18:21 <stintel> Hauke: honestly I don't know
Sep 30 19:18:28 <stintel> if it's easier to take all of them, I'd do that?
Sep 30 19:20:32 <Hauke> ok
Sep 30 19:24:10 <Ycarus> Some are not needed
Sep 30 19:24:27 <Ycarus> Patch that was applied and patch that remove previous patch :)
Sep 30 19:24:41 <Hauke> yes I already tried to find them and removed both
Sep 30 19:25:06 <Hauke> the brcmfmac patches are also useless to us
Sep 30 19:25:16 <Hauke> but i do not know how to handle them
Sep 30 20:54:46 <philipp64|laptop> Hauke: sorry, was cooking lunch for the family.  Did you see my email about adding tarpitting to the firewall?  I like the idea of OpenWrt helping fight botnets by tying up their resources and making them hold connections open for no reason at all…  If their attack is based on subverting tens of millions of routers, let those routers fight back…
Sep 30 20:56:39 <philipp64|laptop> action "REJECT" being the worst possible response because it quickly frees them up to try someone else… "DROP" makes them keep retrying until they timeout… but TARPIT would cause them to wait at the application layer and allocate resources both in the kernel and user-space.
Sep 30 21:19:41 <Hauke> philipp64|laptop: I do not know if we should change this
Sep 30 21:20:06 <Hauke> philipp64|laptop: jow is more familiar with the firewall
Sep 30 21:23:34 <philipp64|laptop> yeah… no one answered my email, so I thought I'd cast a wider net.
Sep 30 21:25:25 <philipp64|laptop> different question… currently busybox and ubox both potentially provide "modprobe", "insmod", "modinfo", "rmmod"…  I'd like to use the "kmod" version but ubox stops that from happening.
Sep 30 21:26:07 <philipp64|laptop> Hauke: can we create a ublox-modutils (or whatever) subpackage that can be deselected to allow "kmod" to be used instead?
Sep 30 21:26:31 <philipp64|laptop> does that seem reasonable?
Sep 30 21:26:56 <Hauke> I do not get waht you want to do
Sep 30 21:28:17 <philipp64|laptop> I can't install "kmod" because I get the warning that "ubox" already provides rmmod/insmod/modprobe/modinfo...
Sep 30 21:28:59 <philipp64|laptop> so I was thinking of creating a subpackage of ubox-modutils that I could choose to omit… and hence allow "kmod" to be installed instead.
Sep 30 21:30:51 <philipp64|laptop> Hauke: that make more sense?
Sep 30 21:31:23 <Hauke> hmm we can put the files from kmod somewheer else
Sep 30 21:37:28 <philipp64|laptop> That's a bit of a kludge… and it creates indeterminism about which of the two gets used at boot.
Sep 30 21:38:43 <philipp64|laptop> As someone who messes with package/kernel/linux/modules/ all of the time, a full-featured "modinfo" is useful for knowing if your modules really got built the way you wanted them to, or not.
Sep 30 21:39:05 <philipp64|laptop> Yeah, we could put things in /usr/sbin/ but then what about busybox?
Sep 30 21:39:53 <philipp64|laptop> What about ALTERNATIVES?
Sep 30 21:41:03 <Hauke> hmm
Sep 30 21:42:50 <Hauke> I only see the two options which we had here
Sep 30 21:43:27 <philipp64|laptop> which were what?
Sep 30 21:43:38 <Hauke> usingv the busybox kmod tools does not make much sense to me
Sep 30 21:43:55 <philipp64|laptop> isn't that what we used to do, before ubox?
Sep 30 21:44:10 <Hauke> either create a pakcage that you can remove the kmod stuff at build time or put the full versions into a different directory
Sep 30 21:44:37 <Hauke> yes we used busybox before, but with ubox I do not see any advantage of busybox
Sep 30 21:44:59 <philipp64|laptop> That assumes that one wants a system with both installed.  What if I want to be absolutely sure that ubox isn't polluting my system?
Sep 30 21:45:40 <philipp64|laptop> I'm using busybox to point out that we can't use /sbin vs /usr/sbin because we've got a 3-way conflict.
Sep 30 21:45:55 <philipp64|laptop> The real issue is ubox vs everything else.
Sep 30 21:46:14 <philipp64|laptop> blogic: you following this?
Sep 30 21:49:35 <philipp64|laptop> Tangibly, ubox installs "libvalidate.so", insmod/lsmod/modinfo/modprobe/rmmod, "validate_data" (???), and "getrandom".  We could subpackage the modules stuff because they don't seem to be tied in with the rest.
Sep 30 21:58:46 <Hauke> I think blogic is the better person to discuss this with you
Sep 30 21:58:55 <Hauke> or jow
Sep 30 22:01:40 <philipp64|laptop> okay. jow seems to be a little bandwidth-limited lately.
Sep 30 22:01:54 <philipp64|laptop> or maybe I'm just asking boring questions.
Sep 30 22:04:07 <philipp64|laptop> occam's razor, after all. ;-)
Sep 30 22:36:18 <karlp> and it's sunday night? :)
Sep 30 22:37:11 <karlp> I understand the motivations behind drop vs reject, but it's still infuriating when you're trying to actually diagnose networking problems, and someone's just dropping stuff.
Sep 30 22:44:15 <Slimey> sup
**** ENDING LOGGING AT Mon Oct 01 03:00:02 2018