**** BEGIN LOGGING AT Wed Apr 03 02:59:57 2019
Apr 03 06:58:26 <ynezz> cccccchdgggnfidhnvkfkeukhrnlnkbguijlghjhgegk
Apr 03 06:58:34 <ynezz> ^W
Apr 03 08:47:35 <ynezz> xback: what do you think https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=a61bbed0a41ac7b4331c7a61f6cf73711dcb5505 ?
Apr 03 08:49:24 <ynezz> hrm, that's wrong, try++
Apr 03 08:52:49 <ynezz> xback: so rather this one https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=dafbbf8eff947a81ccfd531cf0dab433b9c39c35
Apr 03 09:29:17 <jow> anyone here experience with ipsec on 10Gbps links?
Apr 03 09:30:22 <olmari> Offtopiv sidenote: I'd like to experience 10Gbps link... xD
Apr 03 09:31:43 <stintel> jow: heh. sounds like you're going to need a beefy machine ;)
Apr 03 09:32:55 <jow> stintel: yeah... usecase is building a somewhat secure overlay network from a 10Gbps LB to various backend servers over a more or less untrusted (shared) ethernet
Apr 03 09:33:24 <stintel> sounds like a fun project
Apr 03 09:33:44 <jow> right now I'm exploring possibilities, I guess anything user space based (openvpn etc.) is out of the question
Apr 03 09:33:59 <stintel> unfortunately my experience with IPsec is limited to WAN links up to 200Mbps
Apr 03 09:34:03 <jow> so its probably something like wireguard (likely too experimental for centos) or plain old ipsec
Apr 03 09:34:09 <jow> also read about gre over ipsec
Apr 03 09:34:31 <zorun_> with beefy machine and large MTU, wireguard can do 10G
Apr 03 09:34:53 <jow> zorun_: can you elaborate on beefy? cpu etc.
Apr 03 09:35:05 <zorun_> jow: recent intel, lots of cores
Apr 03 09:35:21 <jow> okay some some recentish Xeon
Apr 03 09:35:24 <olmari> Also, how much does good NIC help? I mean some overly expensive Intel comes in mind...
Apr 03 09:35:45 <olmari> Not that I have plenty experience from any 10G link
Apr 03 09:35:51 <stintel> there's this intel QAT thing but can Linux make use of it ?
Apr 03 09:36:19 <olmari> but in general those have various off-load things, I'd be damned if those wouldn't matter any at these speeds
Apr 03 09:38:53 <zorun_> jow: yeah, you basically need AVX
Apr 03 09:39:10 <zorun_> jow: if you're interested, I did some benchmarks a while back: https://lists.zx2c4.com/pipermail/wireguard/2017-May/001305.html
Apr 03 09:39:45 <zorun_> the best I got was 11.4 Gbit/s with a 65450 MTU and a ~recent kernel (at the time)
Apr 03 09:40:59 <zorun_> and that was with a Xeon from 2009 https://ark.intel.com/content/www/us/en/ark/products/40200/intel-xeon-processor-e5520-8m-cache-2-26-ghz-5-86-gt-s-intel-qpi.html
Apr 03 09:41:18 <zorun_> of course if you have realistic trafic, performance would drop because of small packets
Apr 03 09:45:44 <jow> right
Apr 03 09:46:01 <jow> I was thinking of using a pair of redundant Xeon E-2176G machines with 64GB RAM each
Apr 03 09:47:21 <stintel> nice clock speed on those
Apr 03 09:47:26 <zorun_> looks like a good bet, 6 cores with high frequency
Apr 03 09:47:35 <zorun_> you don't need the 64 GB RAM though
Apr 03 09:47:40 <jow> yeah, they'll run haproxy and terminate lots of http, so higher clock speed is advisable
Apr 03 09:48:04 <jow> those 64gb will be needed to hold tls sessions etc.
Apr 03 09:48:11 <zorun_> ah I see
Apr 03 09:51:00 <jow> zorun_: thanks for the link to that benchamrk, that really helps
Apr 03 09:51:55 <zorun_> you're welcome
Apr 03 10:28:44 <zorun_> jow: btw, if you want some more recent benchmarks (and good methodology!), check out https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf
Apr 03 10:30:27 <zorun_> for instance page 47
Apr 03 10:47:36 <ynezz> nice paper
Apr 03 10:48:36 <stintel> I need to bookmark it
Apr 03 11:01:32 <Tapper> jow why would you use 2 servers? redundancy?
Apr 03 11:05:01 <jow> Tapper: failover via VRRP
Apr 03 11:05:12 * Tapper nods
Apr 03 12:23:57 <zx2c4> zorun_: the multicore algorithm in wg still sort of sucks in some cases
Apr 03 12:24:06 <zx2c4> It should be scaling way better than it does
Apr 03 12:24:21 <rmilecki> jow: you were right about CONFIG_NF_CONNTRACK_IPV6=m - it seems to be =m for old and new kernels
Apr 03 12:24:28 <rmilecki> jow: i think the problem is: # CONFIG_NF_CONNTRACK_RTCACHE is not set
Apr 03 12:24:42 <rmilecki> jow: it disables compilation of rtcache completely!
Apr 03 12:24:44 <rmilecki> obj-$(CONFIG_NF_CONNTRACK_RTCACHE) += nf_conntrack_rtcache.o
Apr 03 12:33:01 <rmilecki> jow: nevermind, my config was corrupted... it's CONFIG_NF_CONNTRACK_RTCACHE=m
Apr 03 12:35:11 <rmilecki> jow: it's all fine with the nf_conntrack_rtcache.c
Apr 03 12:42:18 <stintel> speaking about nf_conntrack_rtcache
Apr 03 12:42:25 <stintel> try rmmod'ing that on a running system
Apr 03 12:42:36 <stintel> would be nice if that oops can be fixed too
Apr 03 12:57:59 <kab-el> nbd: hi felix, i bought mt7612e minipcie card from aliexpress and put it into my laptop. Tried latest mt76, mt76 in 4.19, mt76 with backprots, ...,with all of these I am getting the wifi works for a little while, but if I try for example copy remote big file via scp, i get "MCU message ... timed out" and then have to restart
Apr 03 12:58:41 <kab-el> nbd: i noticed that with new mt76, after this "MCU message ... timed out" there comes ieee80211: hardware reset requested (or something like that)
Apr 03 12:59:20 <kab-el> nbd: is this a problem specific for the minipcie card from aliexpress?
Apr 03 13:05:10 <jow> rmilecki: I love it when things fix themselves without me even looking
Apr 03 13:05:19 <rmilecki> ;)
Apr 03 13:17:01 <mamarley> greearb: On my 998x device, if I use the latest firmware build you have in https://www.candelatech.com/downloads/ath10k-fw-beta/, I get "ath10k_pci 0000:00:00.0: failed to enable adaptive cca: -122" and the interface never comes up.  The full boot log is in https://paste.ubuntu.com/p/JPpnZ2vc5H/.
Apr 03 13:18:57 <greearb> mamarley, I guess the driver needs updating.  I've not backported those changes to 4.19 yet, but can do so today
Apr 03 13:19:16 <mamarley> Ah, OK.
**** BEGIN LOGGING AT Wed Apr 03 14:09:24 2019
Apr 03 14:51:32 <brucethompson> Hello. Is this the right forum to ask a question about building new packages for OpenWrt??
Apr 03 14:54:30 <jow> sure, just ask :)
Apr 03 14:57:44 <brucethompson> Sorry, just saw that
Apr 03 14:58:06 <brucethompson> OK. I am trying to add a new package into the python library
Apr 03 14:58:18 <brucethompson> I have created the makefile and I have a build environment
Apr 03 14:58:59 <brucethompson> I have done make menuconfig and added this package to the build list
Apr 03 14:59:31 <brucethompson> 1st question is menuconfig is showing 2 targets for my package (and all python packages)
Apr 03 15:00:02 <jow> can you explain what you mean with "two targets" ?
Apr 03 15:00:03 <brucethompson> Target1=python-panacl Target1-python-panancl-src
Apr 03 15:00:08 <jow> ah
Apr 03 15:00:15 <brucethompson> Tareget2
Apr 03 15:00:31 <brucethompson> This is what shows up in UI of menuconfig
Apr 03 15:01:00 <brucethompson> I think the system is trying to install my new package from the OpenWrt source repository
Apr 03 15:01:58 <jow> This is a side affect of using python(3)-package.mk's PyPackage macro
Apr 03 15:02:12 <brucethompson> OK
Apr 03 15:02:19 <jow> it will behind the scenes define two packages, one containing .pyc files and one shipping the .py files (*-src)
Apr 03 15:03:06 <brucethompson> OK. I am getting this error:
Apr 03 15:03:11 <brucethompson> + curl -f --connect-timeout 20 --retry 5 --location --insecure https://sources.lede-project.org/pynacl-1.3.0.tar.gz
Apr 03 15:03:47 <brucethompson> There is nothing in the repository for thispackage because it does not exist yet
Apr 03 15:04:05 <brucethompson> So how do I build it from local source??
Apr 03 15:04:54 <brucethompson> I selected the python-panacl-src in menuconfig
Apr 03 15:05:11 <brucethompson> I unselected python-panacl in menuconfig
Apr 03 15:05:43 <brucethompson> But it looks like it is still trying to build python-panacl even though its not selected in menuconfig
Apr 03 15:05:50 <jow> this is normal. OpenWrt/LEDE will fall back to the above url when the package is not found
Apr 03 15:06:28 <brucethompson> OK. But what do I use for a make target to build only this package from local source?
Apr 03 15:06:28 <jow> python-xxx vs. python-xxx-src is completely unrelated to that, its about *.py vs. *.pyc files, but not related to downloading stuff during the package build process
Apr 03 15:06:39 <brucethompson> Oh. OK
Apr 03 15:06:41 <jow> how did you declare your Makefile header variables? PKG_SOURCE_URL etc. ?
Apr 03 15:07:04 <brucethompson> one second
Apr 03 15:08:05 <brucethompson> FYI. I used python-cffi makefile as a template for my makefile
Apr 03 15:09:04 <brucethompson> PKG_SOURCE_URL:=https://files.pythonhosted.org/packages/source/c/pynacl
Apr 03 15:09:33 <jow> can you pastebin all PKG_* variables somewhere?
Apr 03 15:09:45 <jow> I think they might be incomplete or some other subtle detail is off
Apr 03 15:10:06 <brucethompson> OK. You think I don't have the source directory quite correct.
Apr 03 15:10:24 <brucethompson> So it's backing off and trying to copy from OpenWrt repository, correct?
Apr 03 15:10:32 <jow> either that or the sha256sum is off and the download script thus falls back to the generic lede-project.org catch all mirror
Apr 03 15:10:52 <brucethompson> OK. Let me check that.
Apr 03 15:11:38 <brucethompson> Thanks greatly. That was very helpful.
Apr 03 15:11:53 <brucethompson> I'll look into this and get back if I have other problems.
Apr 03 15:12:05 <jow> allright, good luck :)
Apr 03 15:13:04 <brucethompson> Also, I'm using make -j1 V=sc
Apr 03 15:13:32 <brucethompson> Is that the right level of debug?
Apr 03 15:13:35 <brucethompson> output
Apr 03 15:14:36 <jow> yep
Apr 03 15:14:58 <brucethompson> ok.  thx
Apr 03 15:14:58 <jow> that should you get most things that are not deliberately hidden by using dev/null redirection or such
Apr 03 15:19:40 <mamarley> greearb: Based on your earlier comment about changes not yet backported to 4.19, I tried 4.20 with Hauke's mac80211-5.0 tree and get the following error on initialization: https://paste.ubuntu.com/p/bh5GCqxmtW/
Apr 03 15:19:58 <mamarley> (This is without any of the OpenWRT patches applied, so those aren't the problem.)
Apr 03 16:01:22 <gweentea> http://termbin.com/u3i1
Apr 03 16:08:16 <gweentea> I have 14c3:7612
Apr 03 16:08:19 <gweentea> weird
Apr 03 16:48:02 <brucethompson> This is Bruce Thompson. I am trying to build a new python package from source for OpenWrt.
Apr 03 16:49:17 <brucethompson> I have an error in my Makefile and could use some help on PKG_SRC_URL and PKG_HASH
Apr 03 16:49:35 <brucethompson> Not sure where to get the info for PKG_HASH
Apr 03 16:52:32 <brucethompson> Anyone there??
Apr 03 16:53:01 <jow> brucethompson: you download the file manually somewhere
Apr 03 16:53:11 <jow> then run "sha256sum downloaded-file.tar.gz"
Apr 03 16:53:22 <brucethompson> Oh
Apr 03 16:53:25 <jow> then set  PKG_HASH:=<resulting-sha256sum>
Apr 03 16:53:40 <brucethompson> They actually have the hash on the python source website
Apr 03 16:53:49 <jow> that is the even better option
Apr 03 16:54:24 <brucethompson> I could not figure out how SRC and HASH got translated into a URL.
Apr 03 16:54:47 <brucethompson> Let me try with the hash from the python website. Thx
Apr 03 16:54:50 <jow> Usually it is PKG_SOURCE_URL + "/" + PKG_SOURCE
Apr 03 16:55:28 <brucethompson> I understand. I think I can test the resulting URL with CURL
Apr 03 16:55:35 <brucethompson> That's what the makefiles does
Apr 03 16:56:12 <jow> you can also try   make package/python-pynacl/download V=sc
Apr 03 16:57:11 <brucethompson> Ah
Apr 03 16:57:28 <brucethompson> Where are all the make targets documented?
Apr 03 16:59:43 <jow> here's some info  https://openwrt.org/docs/guide-developer/packages
Apr 03 17:01:20 <jow> and some general guidelines: https://openwrt.org/docs/guide-developer/package-policies
Apr 03 17:02:56 <brucethompson> OK. Thx
Apr 03 17:08:21 <brucethompson> OK. I am definitely not doing something right
Apr 03 17:09:24 <brucethompson> I will try your manual process for downloading and getting SHA256 hash
Apr 03 17:20:18 <brucethompson> I am trying to use the manual process you described above to get the hash
Apr 03 17:21:42 <brucethompson> I used sha256sum and ran it on the downloaded tar file for python-cffi which is a package that works.
Apr 03 17:22:25 <brucethompson> The generated hash is different than either what is in the makefile or the actual URL for downloading
Apr 03 17:23:15 <brucethompson> Here is the correct download URL for the current version of python-cffi in OpenWrt
Apr 03 17:23:58 <brucethompson> https://pypi.python.org/packages/10/f7/3b302ff34045f25065091d40e074479d6893882faef135c96f181a57ed06/cffi-1.11.4.tar.gz
Apr 03 17:24:08 <brucethompson> This URL works
Apr 03 17:24:42 <brucethompson> Here are the source variables in the makefile for python-cffi:
Apr 03 17:25:53 <brucethompson> PKG_SOURCE_URL:=https://files.pythonhosted.org/packages/source/c/cffi
Apr 03 17:25:53 <brucethompson> PKG_HASH:=e113878a446c6228669144ae8a56e268c91b7f1fafae927adc4879d9849e0ea7
Apr 03 17:26:42 <brucethompson> Here is the actual hash for this makefile generated by sha256sum:
Apr 03 17:27:36 <brucethompson> df9083a992b17a28cd4251a3f5c879e0198bb26c9e808c4647e0a18739f1d11d  cffi-1.11.4.tar.gz
Apr 03 17:28:45 <brucethompson> There must be some type of translation between the hash generated by sha256sum and PKG_MASH in the makefile and the actual URL generated by the makefile to download.
Apr 03 17:28:54 <brucethompson> They are all different
Apr 03 17:35:37 <brucethompson> Also notice that the package source URL hostname= files.pythonhost.org is different than the package source URL hostname generated by the makefile = pypi.python.org
Apr 03 17:52:53 <jow> brucethompson: when the final url is https://pypi.python.org/packages/10/f7/3b302ff34045f25065091d40e074479d6893882faef135c96f181a57ed06/cffi-1.11.4.tar.gz
Apr 03 17:53:10 <jow> brucethompson: then you need to se  PKG_SOURCE_URL:=https://pypi.python.org/packages/10/f7/3b302ff34045f25065091d40e074479d6893882faef135c96f181a57ed06
Apr 03 17:53:35 <jow> PKG_SOURCE:=cffi-1.11.4.tar.gz (or rather PKG_SOURCE:=cffi-$(PKG_VERSION).tar.gz)
Apr 03 17:54:23 <jow> but apparently pythonhosted.org is some kind of cdn or whatever, so it might use different urls
Apr 03 17:54:37 <jow> however since you didn't yet mention what you actually try to package I can't really help :)
Apr 03 17:59:13 <brucethompson> I am packing PyNaCl. It does not exist in the OpenWrt package repository.
Apr 03 18:00:29 <brucethompson> https://pypi.org/project/PyNaCl/#files
Apr 03 18:01:11 <brucethompson> I think there may be some kind of trick for Python files.
Apr 03 18:02:15 <brucethompson> The correct download URL for PyNaCl is:
Apr 03 18:02:36 <brucethompson> https://files.pythonhosted.org/packages/61/ab/2ac6dea8489fa713e2b4c6c5b549cc962dd4a842b5998d9e80cf8440b7cd/PyNaCl-1.3.0.tar.gz
Apr 03 18:03:29 <stintel> fwiw, the gentoo ebuild downloads the pynacl source from github
Apr 03 18:03:50 <greearb_> I notice that the firmware loading logic in the kernel (4.20 at least), caches the file.  So if you change board.bin and reload the ath10k driver, for instance, you still get the old stale board.bin content when driver reloads.  Anyone know if this is on purpose?
Apr 03 18:07:44 <brucethompson> The readme for python makefiles in OpenWrt says to download source from pypi.org.
Apr 03 18:09:26 <brucethompson> Pypy.org is a website that includes links to the actual source on files.pythonhosted.org
Apr 03 18:20:53 <jow> brucethompson: hm, tried these?
Apr 03 18:21:03 <jow> PKG_SOURCE_URL:=https://files.pythonhosted.org/packages/61/ab/2ac6dea8489fa713e2b4c6c5b549cc962dd4a842b5998d9e80cf8440b7cd
Apr 03 18:21:17 <jow> PKG_SOURCE:=PyNaCl-$(PKG_VERSION).tar.gz
Apr 03 18:21:36 <brucethompson> I could
Apr 03 18:21:45 <brucethompson> What about HASH?
Apr 03 18:21:49 <jow> PKG_HASH:=0c6100edd16fefd1557da078c7a31e7b7d7a52ce39fdca2bec29d4f7b6e7600c
Apr 03 18:22:45 <jow> also of course set  PKG_VERSION:=1.3.0  before the other vars
Apr 03 18:30:03 <brucethompson> That worked!!!
Apr 03 18:30:46 <brucethompson> OK. So I should not have used the variables from cffi
Apr 03 18:30:54 <brucethompson> Not sure what that was about
Apr 03 18:31:16 <brucethompson> Instead use the actual source URL and the actual Hash of the package
Apr 03 18:31:22 <brucethompson> Now I get it.
Apr 03 18:31:56 <brucethompson> Thanks!!!!!!!!!!!!!!!!!!!!!!
Apr 03 18:32:10 <brucethompson> Thanks jow!!!!!!!!!!!!!
Apr 03 18:32:25 <brucethompson> Time for lunch
Apr 03 18:34:54 <jow> great. you're welcome
Apr 03 18:35:01 <cotequeiroz> brucethompson: you may simplify that URL.  Use https://files.pythonhosted.org/packages/source/P/PyNaCl, and then you won't have to change that hash for every version bump.
Apr 03 18:36:09 <jow> the hash in the url (.../61/ab/2ac6dea8489fa713e2b4c6c5b549cc962dd4a842b5998d9e80cf8440b7cd/...) just to avoid further confusion :)
Apr 03 18:36:22 <jow> PKG_HASH needs to change with every version bump of course
Apr 03 18:36:22 <cotequeiroz> Thank you jow.
Apr 03 18:36:26 <philipp64> jow: "depends EFI_IMAGES || GRUB_IMAGES" is causing problems (circular dependency)… I think the VMDK_IMAGES and VDI_IMAGES should be "select EFI_IMAGES\nselect GRUB_IMAGES" instead… see my patch.
Apr 03 18:38:37 <jow> philipp64: I don't see that here
Apr 03 18:38:42 <jow> the recursive dep
Apr 03 18:46:31 <philipp64> under VDI_IMAGES, you have "depends on GRUB_IMAGES || EFI_IMAGES" … should be two "select …" lines.
Apr 03 18:46:42 <philipp64> ditto for VMDK.
Apr 03 18:49:58 <philipp64> other change I made was putting "config EFI_IMAGES" before "config GRUB_IMAGES" so that the order is alphabetic in the generated .config file…
Apr 03 18:52:42 <philipp64> not sure that it's correct having "define Package/grub2-editenv" in 2 different files, though…
Apr 03 18:54:34 <philipp64> shouldn't package/boot/grub2/grub2/Makefile be inheriting the one from package/boot/grub2/common.mk
Apr 03 18:55:19 <philipp64> jow: or am I missing something obvious?
Apr 03 19:01:38 <jow> philipp64: why should it be two select lines?
Apr 03 19:02:20 <jow> VDI_IMAGES shall only be built if GRUB or EFI images are built
Apr 03 22:33:49 <jbenden> is there a way for a package to use a Git branch/rev instead of a release?
Apr 03 22:34:45 <jbenden> nvrm, im dumb
Apr 03 22:36:07 <pkgadd> there are plenty examples for that in the repo, as an example (just the first one coming to my mind, there are much easier ones) package/firmware/linux-firmware/Makefile
Apr 03 22:45:43 <stintel> some more examples: netifd, odhcpd, fstools
Apr 03 22:46:32 <greearb_> mamarley, I just pushed latest ath10k-ct repo, if you use that, it should work with latest wave-1 CT firmware.
Apr 03 22:48:48 <vk496> Hello. Someone know if is possible to define a subfunction to download a file during the install process?
Apr 03 22:49:15 <vk496> I'm trying something like this:
Apr 03 22:49:31 <vk496> define Download/tesseract-data
Apr 03 22:49:33 <vk496> 	FILE:=$(1).traineddata
Apr 03 22:49:34 <vk496> 	URL:=https://raw.githubusercontent.com/tesseract-ocr/tessdata/master/$(1).traineddata
Apr 03 22:49:35 <vk496> 	HASH=skip
Apr 03 22:49:37 <vk496> endef
Apr 03 22:50:03 <vk496> And call it from this during the install step: $(eval $(call Download,tesseract-data,$(1)))
Apr 03 22:50:31 <vk496> but it tries to download them all at beggining
Apr 03 23:03:30 <pkgadd> vk496: that's a bad idea for so many reasons, but should be possible via Package/foo/install directives
Apr 03 23:04:00 <mamarley> greearb: Awesome, thanks!  Does that fix the 4.20 issue too or just the CCA thing?
Apr 03 23:05:17 <pkgadd> vk496: or rather Package/foo/postinst
Apr 03 23:07:45 <greearb> 4.20 probaby won't compile, mac80211 backport mismatch that I have no easy fix for
Apr 03 23:08:46 <pkgadd> but again, while possible, it's one of the worst ways for installing stuff and basically never an acceptable approach (hint, you don't always have network access when installing a package - and you need corresponding postrm cleanup, etc.)
Apr 03 23:12:02 <mamarley> greearb: I patched my local tree with a 5.0 mac80211 and it does compile, but it errors out with a stacktrace on boot.  I pastebinned the stacktrace and sent you the URL earlier.
Apr 03 23:13:55 <greearb> oh, the CCA thing?  That should be fixed all the way back to my 4.9 tree
Apr 03 23:16:36 <mamarley> greearb: No, https://paste.ubuntu.com/p/bh5GCqxmtW/
Apr 03 23:18:49 <BigNerd95> My Netgear DM200 is not delivering packets on LAN after 300 seconds
Apr 03 23:18:59 <BigNerd95> I explained it here https://bugs.openwrt.org/index.php?do=details&task_id=1944&pagenum=4
Apr 03 23:19:11 <BigNerd95> can someone help?
Apr 03 23:24:53 <DonkeyHotei> BigNerd95: ipv6 support disabled how? (i don't see anything else special about your setup)
Apr 03 23:26:01 <DonkeyHotei> and is this the 18.06 branch, or trunk?
Apr 03 23:26:53 <BigNerd95> ipv6 disabled in menuconfig
Apr 03 23:27:05 <BigNerd95> i cloned the project from master
Apr 03 23:27:44 <DonkeyHotei> there is no "disable ipv6" option in menuconfig
Apr 03 23:28:52 <BigNerd95> Global build settings > Enable IPv6 support in packages
Apr 03 23:29:11 <DonkeyHotei> that's not the same thing
Apr 03 23:29:37 <BigNerd95> ook, so i should try to recompile with that option enabled?
Apr 03 23:29:45 <BigNerd95> may that option solve the problem?
Apr 03 23:29:58 <DonkeyHotei> as for your problem, if it's master and not 18.06, i can only speculate it may have to do with the new DSA switch driver
Apr 03 23:31:01 <BigNerd95> if i launch "swconfig list" it shows nothing
Apr 03 23:31:05 <BigNerd95> it this right?
Apr 03 23:31:19 <DonkeyHotei> unfortunately, it's the middle of the night for most people involved in the migration to DSA atm
Apr 03 23:33:27 <BigNerd95> ok, so i should re-ask tomorrow?
Apr 03 23:34:24 <DonkeyHotei> asking during a time when it's a decent hour in central europe could get better answers
Apr 03 23:34:39 <DonkeyHotei> idk
Apr 03 23:34:44 <BigNerd95> perfect, thank you very much!
Apr 03 23:35:08 <DonkeyHotei> BigNerd95: wait
Apr 03 23:35:21 <DonkeyHotei> BigNerd95: how old is the snapshot of master?
Apr 03 23:35:36 <DonkeyHotei> i notice you opened the bug a few months ago
Apr 03 23:35:55 <DonkeyHotei> the DSA driver for lantiq was only introduced this year iirc
Apr 03 23:36:16 <BigNerd95> mmm the running version on my router...maybe some months
Apr 03 23:36:16 <BigNerd95> OpenWrt SNAPSHOT, r7886+552-cad9519eba
Apr 03 23:36:26 <BigNerd95> tomorrow i can try to recompile the latest snapshot
Apr 03 23:36:49 <BigNerd95> wait
Apr 03 23:37:12 <DonkeyHotei> i hate how the banner garbles the revision now if it can't reconcile git hashes...
Apr 03 23:37:35 <BigNerd95> 9 november 2018
Apr 03 23:37:44 <BigNerd95> i compiled and flashed my router
Apr 03 23:38:32 <DonkeyHotei> if you're tracking master, that's quite old
Apr 03 23:39:14 <DonkeyHotei> but if you recompile, use the diffconfig script to review what you changed in menuconfig
Apr 03 23:39:52 <DonkeyHotei> trying to remove ipv6 might not be the only ill-advised change you made
Apr 03 23:40:30 <pkgadd> keep in mind, the more you diverge from a 'normal' build (and runtime) configuration, the more likely bugs are to show up
Apr 03 23:40:33 <DonkeyHotei> the defaults for ipv6 are the best ones to leave alone if you have no ipv6 service
Apr 03 23:41:06 <BigNerd95> ok, so i'll try to recompile leaving ipv6 as default
Apr 03 23:41:18 <BigNerd95> does i have to use branch 18.06 instead of master?
Apr 03 23:41:37 <DonkeyHotei> you can use master, but a more recent master
Apr 03 23:41:55 <DonkeyHotei> master will soon be branched for a new release anyway
Apr 03 23:42:32 <DonkeyHotei> the diffconfig script is ./scripts/diffconfig.sh
Apr 03 23:42:57 <BigNerd95> ok thank you
Apr 03 23:43:26 <BigNerd95> does i have to run "make defconfig" before recompile?
Apr 03 23:43:57 <pkgadd> that solely depends on what you want to accomplish
Apr 03 23:44:22 <BigNerd95> get a 'normal' build
Apr 03 23:44:26 <BigNerd95> like you said
Apr 03 23:44:29 <pkgadd> you /need/ to invoke make oldconfig, you /can/ use defconfig to answer new config symbols with the defaults
Apr 03 23:45:10 <pkgadd> the important part is to review your differences compared to a default build - to minimize those you don't (really-) need, at least to make debugging easier
Apr 03 23:45:35 <DonkeyHotei> that's where diffconfig with your existing options comes in
Apr 03 23:46:54 <DonkeyHotei> while you're at it, you will probably want to extract the VDSL DSP firmware from netgear's image to use instead of the one openwrt supplies
Apr 03 23:47:26 <DonkeyHotei> many people have reported it to work much better
Apr 03 23:48:09 <BigNerd95> i'm already using the driver of fritzbox
Apr 03 23:48:10 <BigNerd95> dsl_fritz_vr9-B-dsl.bin
Apr 03 23:48:24 <DonkeyHotei> you are in an Annex B country?
Apr 03 23:48:59 <BigNerd95> ATU-C Vendor ID:                          Broadcom 177.166 ATU-C System Vendor ID:                   Broadcom Chipset:                                  Lantiq-VRX200 Firmware Version:                         5.9.1.4.0.7 API Version:                              4.17.18.6 XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2 Annex:                                    B Line Mode:                     
Apr 03 23:49:20 <DonkeyHotei> i wasn't aware people used the dm200 for annex b also
Apr 03 23:49:37 <BigNerd95> i'm from italy
Apr 03 23:49:55 <DonkeyHotei> i thought italy used only Annex A
Apr 03 23:50:15 <BigNerd95> you mean for adsl?
Apr 03 23:50:19 <DonkeyHotei> yes
Apr 03 23:50:21 <BigNerd95> i'm using VDSL
Apr 03 23:50:22 <BigNerd95> 2
Apr 03 23:50:37 <DonkeyHotei> i suppose that makes it matter less
Apr 03 23:50:51 <DonkeyHotei> but if it works well for your line, ok
Apr 03 23:51:20 <BigNerd95> from what i understood, the firmware versions A and B only differ for ADSL part
Apr 03 23:51:24 <BigNerd95> not for VDSL
Apr 03 23:52:06 <BigNerd95> So i extracted the firmware without applying any patch
Apr 03 23:52:23 <DonkeyHotei> there are various other differences in vdsl. at least one person (in an annex b country) reported ONLY the speedport firmware to work on his line
Apr 03 23:52:52 <DonkeyHotei> it's all isp-dependent i guess
Apr 03 23:53:43 <BigNerd95> maybe, but i noticed some time ago, that there are some bugs in openwrt configs abount annex
Apr 03 23:53:54 <BigNerd95> for example, now my config is:
Apr 03 23:54:04 <DonkeyHotei> if i had vdsl myself, i'd be trying the netgear dsl firmware first
Apr 03 23:54:06 <BigNerd95> config dsl 'dsl' 	option xfer_mode 'ptm' 	option line_mode 'vdsl' 	option firmware '/etc/config/dsl_fritz_vr9-B-dsl.bin' # best 	option annex 'a' # se metto 'b' va solo a 4 mega in up
Apr 03 23:54:12 <BigNerd95> sorry
Apr 03 23:54:13 <BigNerd95> wait
Apr 03 23:54:24 <BigNerd95> option annex 'a'
Apr 03 23:54:28 <BigNerd95> also if it is annex b
Apr 03 23:54:50 <BigNerd95> if i put annex 'b', some configs make my driver to connect only at 4mbps
Apr 03 23:54:55 <BigNerd95> insted of 30mbps
Apr 03 23:55:10 <pkgadd> you'd be making your life easier by testing the dm200 firmware, with the correct annex
Apr 03 23:55:32 <DonkeyHotei> pkgadd: if it works, it works
Apr 03 23:55:55 <pkgadd> DonkeyHotei: obviously it doesn't, otherwise we wouldn't have this discussion.
Apr 03 23:56:03 <BigNerd95> but i used the correct annex
Apr 03 23:56:05 <pkgadd> it could be one factor
Apr 03 23:56:07 <BigNerd95> but well
Apr 03 23:56:12 <BigNerd95> i dont have problem on dsl line
Apr 03 23:56:16 <BigNerd95> only on LAN
Apr 03 23:56:16 <DonkeyHotei> pkgadd: the problem BigNerd95 is having is on the lan side, not the wan side
Apr 03 23:56:38 <BigNerd95> i dont know why we are talking about dsl now ahahah
Apr 03 23:56:42 <DonkeyHotei> and the lan side changed drastically in master after that snapshot
Apr 03 23:58:01 <pkgadd> o.k., I might have misunderstood that part, only watching with one eye, while working on something else
Apr 04 00:02:47 <BigNerd95> thank you very much guys, i'll update you tomorrow
**** ENDING LOGGING AT Thu Apr 04 02:59:57 2019