**** BEGIN LOGGING AT Fri Jun 19 02:59:57 2020
Jun 19 04:42:55 <owrt-snap-builds> build #333 of lantiq/falcon is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Ffalcon/builds/333  blamelist: Alan Swanson <reiver@improbability.net>, Chen Minqiang <ptpt52@gmail.com>, Karel Ko?? <karel.koci@nic.cz>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Kuan-Yi Li
Jun 19 04:42:55 <owrt-snap-builds> <kyli@abysm.org>
Jun 19 04:44:31 <owrt-snap-builds> build #360 of mpc85xx/p1020 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/360  blamelist: Alan Swanson <reiver@improbability.net>, Chen Minqiang <ptpt52@gmail.com>, Karel Ko?? <karel.koci@nic.cz>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Kuan-Yi Li
Jun 19 04:44:32 <owrt-snap-builds> <kyli@abysm.org>
Jun 19 07:50:17 <jow> nick[m]: the typical usage for blob buffers is to keep them in a global static variable
Jun 19 07:50:46 <jow> nick[m]: the next blob_buf_init() call on the global blob buf will free the previous memory
Jun 19 07:51:17 <nick[m]> jow: ahhh thanks! that's very important information for me! :)
Jun 19 07:52:27 <jow> maybe free is the wrong term, lets say it reclaims (overwrites) the previously allocated memory area
Jun 19 07:52:52 <jow> and that memory area is reallocated as needed if the contents you put into the blub buffer exceed the previous maximum size
Jun 19 08:44:22 <mangix> github's down looks like
Jun 19 08:44:39 <mangix> error 500
Jun 19 08:49:56 <Borromini> yep
Jun 19 08:56:39 <yanosz> heiho ... I'm confused again. I'd to monitor the wifi status on an OpenWRT router every 100-200ms...
Jun 19 08:56:39 <yanosz> To keep the load low, I'm thinking of reading from /proc instead of spawning an userland process such as iw or iwconfig.
Jun 19 08:56:39 <yanosz> I know, that I can read from /proc/net/wireless, but that gives me solely the signal. Association details as provided by
Jun 19 08:56:39 <yanosz> iw dev DEV link or iw dev DEV info are not provided.
Jun 19 08:56:39 <yanosz> Do you know of other inodes, different vom /proc/net/wireless?
Jun 19 09:02:19 <PaulFertser> yanosz: "iw" is using nl80211 API, not ioctl or files.
Jun 19 09:02:37 <yanosz> ah, thx
Jun 19 09:02:56 <PaulFertser> yanosz: and if you do not want to waste time polling better stay listening and waiting for events
Jun 19 09:03:22 <PaulFertser> yanosz: you can do it even from shell with "iw event"
Jun 19 09:03:33 <yanosz> sek - I'll check
Jun 19 09:03:43 <yanosz> does this include beacon frame events?
Jun 19 09:04:30 <PaulFertser> yanosz: I guess no, usually APs beacon every 100 ms. Why would you need that?
Jun 19 09:04:30 <yanosz> -f -t  -nice :=
Jun 19 09:04:36 <yanosz> thanks! I a lot!
Jun 19 09:04:48 <yanosz> I didn't know this before. That's perfect!
Jun 19 09:05:03 <PaulFertser> Easy when you know where to look :)
Jun 19 09:05:25 <PaulFertser> What's your cool project, why do you need that info?
Jun 19 09:05:32 <yanosz> master thesis, sdn handover
Jun 19 09:05:52 <yanosz> I have a video. sek
Jun 19 09:06:24 <yanosz> https://www2.jluehr.de/VID_20200618_140814.mp4
Jun 19 09:06:34 <yanosz> doing the handover in scale 1:100 ;)
Jun 19 09:08:10 <yanosz> Hmm... I don't see beacon frames in iw -t -f event, yet
Jun 19 09:08:14 <yanosz> is there a catch?
Jun 19 09:09:20 <PaulFertser> yanosz: pretty cool! Please feel free to ping me if you have more nl80211 questions. Just beacon frames from an AP that you've already connected do not lead to any events. You can be getting beacon frames with tcpdump or any other capture application.
Jun 19 09:09:44 <yanosz> but I can still query /proc/net/wireless to get the rssi
Jun 19 09:09:44 <yanosz> thx ... I'think, I'll monitor /proc/net/wireless
Jun 19 09:10:05 <yanosz> exposing kernel data, that pretty much gives me, what the kernel has.
Jun 19 09:10:07 <yanosz> execelt
Jun 19 09:10:10 <PaulFertser> yanosz: beware, rssi is often fake
Jun 19 09:10:23 <yanosz> why?
Jun 19 09:10:32 <yanosz> it looks somewhat reasonable, here
Jun 19 09:11:11 <jow>  /proc/net/wireless is deprecated
Jun 19 09:11:15 <yanosz> ah.
Jun 19 09:11:26 <jow> and only available if kernel wext support is enabled
Jun 19 09:11:48 <yanosz> it's available and looking reasonable using ath10k / owert 19.07
Jun 19 09:12:03 <yanosz> do you know other problems?
Jun 19 09:12:16 <yanosz> OpenWRT 19.07
Jun 19 09:12:18 <PaulFertser> yanosz: and the data you get from it are going through a compatibility layer which is lossy wrt rssi. But not only that, the number itself is fake because the driver doesn't have it.
Jun 19 09:12:23 <jow> the main issue is that it is not future proof
Jun 19 09:13:39 <yanosz> That's strange - if the kernel does it have (does it, for ath10k) how is it faked, then?
Jun 19 09:13:41 <PaulFertser> yanosz: this discussion has some details with proof links to the kernel source code: https://github.com/jaor/xmobar/pull/429
Jun 19 09:15:24 <yanosz> thanks a lot - that's execellent
Jun 19 09:16:08 <yanosz> I guess, that'll be fine monitoring the RSSI nevertheless, just mentioning problems and this PR
Jun 19 09:17:18 <yanosz> That's a nice argument for a) not doing a rssi-based handover (missing data / different drivers) b) explaining the data
Jun 19 09:17:40 <yanosz> the data -> the quality of the data
Jun 19 09:18:38 <yanosz> Plotting the rssi is motivated by rssi-based handovers in classic mobile phone networks, but discouraged by the nl80211 API architecture
Jun 19 09:18:46 <yanosz> thanks again, that's an eye opener ;)
Jun 19 09:19:09 <PaulFertser> It looks ath10k hardware just doesn't report real RSSI at all, it's not part of their firmware API.
Jun 19 09:19:27 <yanosz> perfect!
Jun 19 09:20:11 * yanosz is querying lwn.net for nice articles ;)
Jun 19 09:22:48 * yanosz and haven't found much yet, but is afk
Jun 19 09:25:13 <PaulFertser> yanosz: GSM networks are not using unregulated bands, they do not compete for the airtime with uncollaborative devices etc.
Jun 19 09:25:30 <yanosz> I know
Jun 19 09:26:17 <yanosz> whereby the costs of licencsend bands and appropiate hardware, making the case for 802.11 based train2ground networks
Jun 19 09:39:06 <nick[m]> yanosz: how to u want to do the handover? just running every ap with same bssid and do something like virtual access point?
Jun 19 09:41:31 <dwmw2_gone> yanosz: nice video. I normally just walk around the house :)
Jun 19 09:42:04 <stintel> https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image
Jun 19 09:42:05 <stintel> interesting
Jun 19 09:42:35 <stintel> I remember when I was experimenting with Kodi on OpenWrt on Raspberry Pi Zero W that python scripts in kodi were horrendously slow
Jun 19 09:42:52 <nick[m]> yanosz: or do u something like 2 wifi cards?
Jun 19 09:47:27 <PaulFertser> yanosz: I think the most clue about current throughput capabilities is present in rate control state machine (but only when it's actively pushing traffic). So you can probably combine that with scan results, gather statistics from different places and runs and invent some heuristic that would optimise handovers for at least the cases you know about.
Jun 19 09:48:34 <rsalvaterra> Alright, userspace patch sent. :)  https://lists.openwrt.org/pipermail/openwrt-devel/2020-June/024022.html
Jun 19 10:16:37 <yanosz> PaulFenster: Thx, but I don't care about troughput
Jun 19 10:16:50 <yanosz> typically, rssi is used to determine the handover position
Jun 19 10:17:06 <yanosz> i.e. to trigger the handover
Jun 19 10:26:30 <PaulFertser> yanosz: it sounds like you have an "optimisation problem" but then the very first question would be what exactly you're optimising for. You need to have some specific measure and means to compare the results.
Jun 19 11:11:23 <yanosz> PaulFertser - not really, its more like a constructive proof of feasibility: OpenFlow as of 1.5.1 suffices for implementing a state of the art handover process in the forwarding plane.
Jun 19 11:11:49 <yanosz> I.e. it suffices to maintain certain realtime aspects
Jun 19 11:14:03 <yanosz> Most parameters (cell size, modulation, accuracy of positioning information) are determined by train engineering and ecomnic aspects.
Jun 19 11:14:03 <yanosz> I.e. having QAM-64 in train2ground communication depends on antennas, radio equipment, cell size, channel and not so much on the handover procedure
Jun 19 13:55:17 <dwmw2_gone> Do we have a tool I can use as part of image creation, which makes a binary uboot.env file from the text version?
Jun 19 14:07:17 <tmn505> dwmw2_gone: grep for "mkimage", not exactly binary output but script (with checksum) which can be sourced by U-Boot.
Jun 19 14:22:42 <xx_ns> PaulFertser: so i got around to probing the pins with a multimeter
Jun 19 14:23:10 <xx_ns> even when running the "blink" script on all GPIOs, SDA stayed on a consistent 3.3v
Jun 19 14:23:18 <xx_ns> i'm not sure what to think of this
Jun 19 14:23:54 <PaulFertser> xx_ns: pinmuxing
Jun 19 15:24:02 <dwmw2_gone> tmn505: that can make the partition or file contents that I can use with CONFIG_ENV_IS_IN_xxx  ?
Jun 19 15:25:45 <dwmw2_gone> mkimage -A arm -T script -d package/boot/uboot-mediatek/files/mt7623n_bpir2-uEnv.txt uboot.env
Jun 19 15:25:59 <dwmw2_gone> that doesn't look like what uboot wrote when I imported the text file then did 'saveenv'
Jun 19 15:27:03 <dwmw2_gone> Loading Environment from FAT... Boot From SD(id:1)
Jun 19 15:27:04 <dwmw2_gone> FAT Part 1:2
Jun 19 15:27:04 <dwmw2_gone> *** Warning - bad CRC, using default environment
Jun 19 15:27:12 <dwmw2_gone> U-Boot didn't like that
Jun 19 15:38:14 <tmn505> dwmw2_gone: then You need mkenvimage
Jun 19 15:53:52 <blogic> [submodule "opensync/core"]
Jun 19 15:53:52 <blogic>         path = opensync/core
Jun 19 15:53:52 <blogic>         url = https://github.com/plume-design/opensync.git
Jun 19 15:53:55 <blogic> oops
Jun 19 17:29:07 <dwmw2_gone> tmn505: that works; thanks
Jun 19 19:16:08 * enyc mumbles and grumbles about outdated chan topic
Jun 19 19:16:18 * enyc happy to help chanop ...... but  somebody needs to do something about op situation!
Jun 19 19:17:12 <enyc> jow: just seen your answer abou 18.06.9, thankyou =)
Jun 19 19:17:36 <enyc> jow: you pointed somebody at me r.e. chan-op problem, but nowt changed seemingly ... ;/
Jun 19 22:08:27 <owrt-snap-builds> build #334 of lantiq/falcon is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Ffalcon/builds/334
Jun 19 22:57:46 <owrt-snap-builds> build #361 of mpc85xx/p1020 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/361
Jun 20 02:12:57 <lmore377_> is the dts file structure different between kernel 4.19 and 5.4? I can build fine on both but when I use 5.4 there's just a bunch of kernel warnings and pretty much nothing works and if I flash to nand it kernel panics because it can't find it. Here's the kernel log in case anyone can help https://pastebin.com/KDswCxE5
Jun 20 02:16:06 <pkgadd> lmore377_: you probably want to add uboot-envtools to your device's DEVICE_PACKAGEs (target/linux/ipq806x/image/Makefile) as well, assuming that modifying uboot environment settings is necessary on the device - the rac2v1k/ askey,rt4230w-rev6 looks like a great device selling surprisingly cheap (sadly not available in Europe, nor anything similar in that general price range)
Jun 20 02:17:31 <pkgadd> Disclaimer: I haven't followed the development closely enough to judge if having uboot-envtools preinstalled would be necessary on your device
Jun 20 02:19:20 <lmore377_> pkgadd: nah it isn't really needed. i checked with the oem firmware if that was the case but nothing's changed and again it boots fine with 4.19 kernel
Jun 20 02:19:34 <pkgadd> lmore377_: even better :)
Jun 20 02:20:49 <pkgadd> diff -Nrupw target/linux/ipq806x/files-4.19/ target/linux/ipq806x/files-5.4/   should tell you about the necessary DTS changes between 4.19 and 5.4
Jun 20 02:30:49 <lmore377_> i based my dts off the r7800 dts and oh my god there's a lot that's different between 4.19 and 5.4 for r7800
Jun 20 02:31:36 <lmore377_> looks like another night of copy/paste/build/test/cry/repeat
Jun 20 02:32:30 <lmore377_> on the bright side i have 2 screens to work with now so not as much alt tab
Jun 20 02:33:34 <pkgadd> yep, dual-monitor setups are extremely convenient, couldn't live without them (but I'm very happy that I no longer need to use 20"/ 21" CRTs for that ;)
Jun 20 02:42:20 <lmore377_> my second monitor is actually just an old laptop screen  with some driver board from china
**** ENDING LOGGING AT Sat Jun 20 03:00:22 2020