**** BEGIN LOGGING AT Sat Dec 21 02:59:58 2019 Dec 21 09:42:25 ah, the install -f worked for me too. hmm, some corner case of base vs feed package handling I guess. I wonder if a make dirclean would have solved it too. Dec 21 10:01:02 ldir: i don't get segfaul Dec 21 10:01:10 ldir: i wasn't disussic that one with ynezz Dec 21 10:01:19 ldir: could you debug that, pleas? Dec 21 10:20:45 rmilecki: the honest answer to that at the moment is no. I'm lacking both time & skill/ability unless you can provide some idiot level instructions. Dec 21 10:22:45 the blockd changes are ok 'cos I had those as local patches for a while. It's something in the libblkid-tiny changeset Dec 21 10:24:53 I should try & work out how to use an X86 VM on my macbook to test the builds 'cos sacrificing my main router APU2 each time isn't convenient :-) Dec 21 10:28:06 enyc: I do not fully get what is your problem in https://bugs.openwrt.org/index.php?do=details&task_id=2667 Dec 21 10:30:27 Hauke: I might be able to provide some context if it will help Dec 21 10:31:19 ok Dec 21 10:31:48 but I will not look into this closely in this year Dec 21 10:32:50 Basically a 1500 MTU is desirable because otherwise TCPMSS hacks and/or path mtu issues. Dec 21 10:33:32 When running PPP over an ethernet i/f you lose 8 bytes due to PPP overhead. Hence 1492. Dec 21 10:34:54 However if your upper interface (carrying the PPP) can support larger than normal ethernet frames then PPP can be persuaded to use the default MTU of 1500 Dec 21 10:35:14 so now your upper interface frames are 1508 in length. Dec 21 10:36:18 In the UK, the incumbent VDSL provider generally uses PPP (over ethernet over ptm over vdsl) for connectivity. Dec 21 10:37:00 And the modem they supply understands 'baby jumbo' ethernet frames, so a PPP 1500 MTU is possible. Dec 21 10:37:46 They actually run the 'over ethernet' bit as a VLAN 101. Dec 21 10:38:53 So, when we have a VDSL modem in our openwrt box we need to define the 'virtual' ethernet interface as running on VLAN101 and ideally we also need to tell it that we can accept 'baby jumbo' frames of 1508 bytes. Dec 21 10:39:28 Then we can run PPP over that 'virtual' ethernet interface and get 1500 MTU Dec 21 10:40:46 My UK provider is sensible and doesn't try to run PPP over the PTM link and just presents an ethernet interface to which I just DHCP/v6 thereby avoiding all this PPP/MTU rubbish. Dec 21 10:41:34 That's as much context as I can provide.... maybe it helps explain the issue. Dec 21 10:42:39 From a luci point of view I don't think the L2 interface is exposed in way that you can set the 1508 mtu capability. Dec 21 10:43:45 and that's a known enhancement request. But I guess part of the request is to have 'mtu 1508' on the l2 interface by default. Dec 21 10:43:52 and now I'll shut up :-) Dec 21 10:45:36 Can someone please answer my question with regard to packages that are built from git repositories? It's common for software to call something like "git describe --all" during build to embed a version into the binary. How to make that work with OpenWrt properly? Dec 21 10:51:47 ldir: thanks now I undrstand this Dec 21 10:52:10 in Gemrnay VDSL also uses PPP over VLAN 7 over PTM Dec 21 10:52:55 Deutsche Telekom started with it some time ago and everyone does the same Dec 21 10:54:27 ldir: I was wondering if there is something which is impossible to configure in UCI first, but it is only that it is not possible in LuCi and complicated in UCI Dec 21 10:56:24 Hauke: "ppp.sh needs to start honouring "config device" settings for the target device " apparently it doesn't , so UCI config is not enough. Dec 21 10:56:38 PaulFertser: ah ok Dec 21 10:59:12 Do DK allow 'oversize' ethernet frames to permit full 1500 MTU over PPP ? Dec 21 10:59:47 incidentally glad I was able to help put some context in there, even more glad it helped. Dec 21 11:00:48 Hauke: reading Dec 21 11:01:34 Hauke: the main problem, is that the VDSL PTM interface "dsl0" does NOT expose MTU1508+ by default, which then creates all sorts of complications. Dec 21 11:02:07 Hauke: as an 'internal' device (as opposed to external ethrent-ocnnected PPPoE modem) this should be a given Dec 21 11:03:11 Hauke: jow observes the way that mtu's are configured in general needs big overhaul, which is secondary issue Dec 21 11:04:04 Hauke: other main point is that (due to both the above, really) its' not possible to set-up MTU1500 over PPPoE over VDSL using the luci web interface, have to fiddle with custom config Dec 21 11:05:08 Hauke: but, talking with jow and one-other in IRC, we agreed this particular part [VDSL internal modem MTU default], ought to go to the Lantiq-maintainer in first-instance. Dec 21 11:09:06 ldir, Hauke: aah i see ldir has also answered that part already =) . I note this is not just 'incumbent provider', there are a lot... Dec 21 11:09:29 lots of OpenReach-backhaul VDSL ISPs have this PPPoE arrangement. Dec 21 11:09:39 I know LLU sky etc. have the dhcpv6/bypass. Dec 21 11:10:42 enyc: I don't think it's actually an LLU thing - it's just how Sky (and I think talktalk) do it - it's an option in one of BT's SIN documents Dec 21 11:11:16 and incumbent in the sense that BT provide the last mile cabinet to home bit Dec 21 11:12:35 I guess actually the GEA to FTTC to Home bit really. it's the GEA interface that then turns into your ISP Dec 21 11:13:15 enyc: it should be possible to set the mtu manually to 1508, but I do not know if we should use this as a default value Dec 21 11:13:48 Hauke: the discussion in heree previously jow and aother seemed to agree it made sense Dec 21 11:14:01 Hauke: what is moer controversial is what PPPd attempts to negatiate above that layer Dec 21 11:14:22 Hauke: but much much easier is tha tthe underpinning vdsl driver exposes what _it_ can do (which is AT LEAST 1508) Dec 21 11:14:53 the driver already supports MTU sizes up to 1508 Dec 21 11:14:56 Hauke: in that way, it may only need one tweak to enable 1500mtu over PPPoE rather than (a lot of manual config) Dec 21 11:15:04 Hauke: right but it doesn't set up the interface right Dec 21 11:15:11 but is is probably using 1500 by default Dec 21 11:15:19 Hauke: the interface comes up dsl0 as 1500 whcih is the main problem Dec 21 11:15:35 Hauke: be really helpful if you can patch it to expose its' proper support and then see what happens Dec 21 11:15:37 because it is an ethernet device to Linux Dec 21 11:16:24 Hauke: this gets especially unnecesssarially complicated when adding a vlan e.g. dsl0.101 you end up having to specify that part twice nad so on Dec 21 11:16:59 Hauke: whereas i've seen many vdsl-intergrated-modem commercial router firmwares that "jsut work" with 1508 dsl0 under the hood nad don't have to fiddle to get 1500 mtu full pass through working Dec 21 11:17:31 enyc: this should work: ip link set dsl0 mtu 1508 Dec 21 11:17:47 Hauke: yes, MANUALLY, but souldn't have to do that Dec 21 11:17:50 Hauke: this being exactly the point Dec 21 11:18:04 Hauke: is this a netifd default do you think? Dec 21 11:18:22 Hauke: also seeed to have to manually sed on dsl0.101 as well.... Dec 21 11:18:40 I will try to find some time next year to fix this Dec 21 11:19:44 I *think* that netifd will create the dsl0.101 interface which is why I'm pondering if 1500 is a netifd default. Dec 21 11:21:35 netifd does not have a mtu default Dec 21 11:21:49 * ldir shuts up :-) Dec 21 11:22:00 the kernel usually defaults to 1500 Dec 21 11:22:04 unless the driver sets something else Dec 21 11:22:41 unfortunately the relevant conversation seems to have gone off scrollback in my irssi ! Dec 21 11:22:48 looked back right to the top Dec 21 11:23:15 nbd: right, which might suggest can just change in driver/kernel and see how that impacts things Dec 21 11:23:37 nbd: WITH ANY LUCK wil still have pppd 1492 but can then easily be set in config to try 1500 etc Dec 21 11:23:57 nbd: and no longer need to 'hack' the dsl driver configs and all that Dec 21 11:24:18 ldir: it's a kernel default -> https://elixir.bootlin.com/linux/latest/source/net/ethernet/eth.c#L378 Dec 21 11:24:24 nbd: OR, alternatively, (even better) the pppd internal fallbacks manage to cope with situations where 1500 doesn't work and fallback to 1492 ... Dec 21 11:26:01 * ldir goes to work - have fun! Dec 21 11:26:15 I would prefer not to change the driver default MTU, but configure the device in UCI to 1508 Dec 21 11:26:34 Hauke: in the deault configs provided for the lantiq ? Dec 21 11:27:00 Hauke: in a way that works when e.g. setting 'custom device dsl0.101' (UK) or dsl0.7 (DE) etc.? Dec 21 11:27:11 maybe we could add a mechanism to netifd to request a minimum mtu from a lower device Dec 21 11:27:23 so that pppoe would request mtu 1508 Dec 21 11:27:30 but could deal with the case where setting it fails Dec 21 11:27:40 Hauke: this being rather more complicated than just changing the default on driver to offer what it can actually do .... Dec 21 11:28:04 Hauke: when i set on dsl0 it didn't auto-propagate to dsl0.101 for example... which got ... messy Dec 21 11:28:22 dd Dec 21 11:28:30 did you set it before creating dsl0.101? Dec 21 11:29:03 nbd: very good question, this being where all the unnecessary-complexity comes in... if you have set-up a config that uses dsl0.101 it may well be auto-created and race condition gets you Dec 21 11:29:32 how did you set it? via ifconfig/ip or netifd? Dec 21 11:29:45 nbd: another reason why, just changing the driver default and 'dealing with that sensibly' (e.g. limit default config to mtu-1492 negotiation) would be much simpler and reliable... Dec 21 11:29:54 nbd: manually, with ip link set ..... Dec 21 11:30:09 well, if you set it in uci, the race condition should go away Dec 21 11:30:15 nbd: via config, at least 2 differet (messy) approaches, extra sections in config NOT offered by web interface Dec 21 11:30:39 nbd: indeed, and tried a different approach in config at jow's request Dec 21 11:31:18 nbd: who, came up with the comments about MTU handling in config and pppd in general, BUT, also agreed made sense for dsl driver to just offer the mtu it supports at moment Dec 21 11:31:37 we ought to try that and get it tested UK (i can help) and DE (can Hauke help?) Dec 21 11:36:15 Oh hey nbd :) I'm sure you know the answer to my "git describe" question :) Dec 21 11:41:33 PaulFertser: usually there is a fallback in case it is built outside of a git repo, if not, you need to add one Dec 21 11:42:47 KanjiMonster: what that fallback should be counting on? Dec 21 11:43:27 I mean isn't it reasonable to expect that a project cloned from git should be able to embed real version into its binary? Dec 21 11:43:28 PaulFertser: a file with a version, or a build parameter Dec 21 11:44:00 KanjiMonster: is it all just to save space on build hosts? Dec 21 11:44:26 but it is also common to provide simple source tarballs for release, which are not git repositories Dec 21 11:44:40 Yes, for releases. Dec 21 11:44:55 But I'm talking about how OpenWrt build system treats git downloads. Dec 21 11:45:31 the same as source tarballs, just a checkout of the files, without the git structure Dec 21 11:45:57 But it's reasonable to assume that upstream projects do not have that usecase in mind for non-release versions. Dec 21 11:46:25 well if they do releases with simple source tarballs then their build system should already be able to cope with that Dec 21 11:47:18 By having explicit version in configure.ac for releases only, yes. Dec 21 11:47:28 Maintainer changes the version, packs the release. Dec 21 11:48:44 so you may need to do that for openwrt builds as well in the configure step Dec 21 11:50:20 So for each project that should be built from git one needs to prepare an OpenWrt project-specific patch to be able to hardcode project version when passed from OpenWrt Makefile PKG_VERSION... Dec 21 11:50:28 That doesn't sound too elegant. Dec 21 11:53:19 I can understand it works for LuCI because it's a tightly coupled project. But as a general solution this seems to be suboptimal. Dec 21 11:53:53 PaulFertser: the alternative would be packaging the full git, which sounds even worse Dec 21 11:54:45 there's also always the option of submitting a patch/PR/MR upstream to allow setting a version to not require a patch Dec 21 11:54:47 KanjiMonster: if a depth=1 clone is made then it'll be less than 2x the sources size, not sure if it's really that bad. Dec 21 11:55:25 PaulFertser: then the version means nothing, since the commit hash doesn't match anything from the original git Dec 21 11:56:26 actually that's worse, since you now provide a "wrong" version Dec 21 11:56:57 KanjiMonster: depth=1 provides enough for git describe to output plain sha1 of that commit. Dec 21 12:05:26 PaulFertser: indeed it does. But I still think it is better to fix the issue upstream than trying to work around it Dec 21 12:05:49 KanjiMonster: as it is currently, any project with git describe will embed openwrt git version which is even more confusing. Dec 21 12:06:20 KanjiMonster: do you have such a project in mind, common among GNU/Linux users, that has sane means to provide git version externally to build system? Dec 21 12:06:29 PaulFertser: what happens if you build in the SDK (which isn't a git repo) Dec 21 12:07:02 PaulFertser: I don't even know what packages you are talking about that need it, or how many are affected Dec 21 12:07:05 KanjiMonster: then the project will get "not a git repo" as a version :) Dec 21 12:07:21 sounds a reproducability issue Dec 21 12:07:34 *like Dec 21 12:07:52 KanjiMonster: I faced that while testing git master of gpsd, but I would guess the situation is common enough. E.g. we have about the same code in OpenOCD etc. It's just natural to do something like that for non-release versions. Dec 21 12:10:27 PaulFertser: and, as I said earlier, their build system should cope with that and provide a way of building outside of the git Dec 21 12:12:59 KanjiMonster: I can provide a patch for any project but I need to understand a rationale and probably have some good examples to follow. Dec 21 12:21:52 PaulFertser: you can also look at how other distributions handle that Dec 21 12:21:56 e.g. debian Dec 21 14:13:00 nbd: hi. wondering if for mt7615 it's worth pulling a newer mt76 for testing instead of the 2019-10-10 OpenWrt is now at itself? i just got an mt7615e device and would like to test. Dec 21 14:45:04 Borromini: yes Dec 21 14:56:58 nbd: great, thanks. can i just pull the mt76 master as-is or should i pick a particular commit? Dec 21 15:28:29 Borromini: you can use master as-is Dec 21 15:29:07 i have a few more things that i'd like to resolve and then i'll update mt76 in openwrt master and 19.07 Dec 21 15:29:20 some time in the next few days Dec 21 15:29:31 maybe that will even include mt7622 support Dec 21 15:38:42 cool, thanks Dec 21 15:38:58 first things first... get this damn dir-878 to flash altogether :P Dec 21 15:40:06 so ... I'm usually not in the business of making feature requests I cannot contribute towards, but I have this small thing in my mind for ages now. what's the best way to go about making such a request? Dec 21 15:40:37 I know about the bug tracker, but I feel feature requests there get swamped out thoroughly (natch, they are not high priority for anyone). Dec 21 15:41:18 (FWIW: my feature request would be to introduce an "inverted" flag for LEDs, to simply invert their output, much like "link" does in a netdev trigger, but for _any_ trigger.) Dec 21 17:50:57 takimata: its called active low Dec 21 17:51:08 and you can define it in the dts file Dec 21 17:51:17 takimata: what board is it you see the issue on ? Dec 21 20:38:27 ldir, enyc, Hauke: to the best of my knowledge several ISPs (in particular Deutsche Telekom) don't support an mtu of 1508, so as a default that won't be a good idea Dec 21 20:40:21 I'm really surprised by that as it means you have to have working pmtu discovery and hacks like setting ceilings on TCPMSS Dec 21 20:41:08 it's been a while since I last looked into it, but I'm pretty sure that it doesn't work there Dec 21 20:42:03 so the ethernet frame that goes over the PTM link carrying PPP is oversize by 8 bytes but the payload is 1500 as opposed to 1492. Dec 21 20:44:01 afaik the DTAG BNG platform is hardcoded to 1492 bytes Dec 21 20:47:03 So much for German efficiency. ldir feels like a Bond villain now :-) Dec 21 20:47:33 hehe, no one ever said that VLAN tagging + PPPoE would be efficient Dec 21 20:47:50 a leftover from dial-up ADSL ISPs... Dec 21 20:48:14 oh yes - why is PPP a thing?!!! :-) Dec 21 20:48:35 ..even where pppoe wasn't needed by anything DSL related (: Dec 21 20:48:35 at higher WAN speeds it's a significant performance hog Dec 21 20:49:14 they got rid from pppoe on most finnish dsl's quite fast in early 2000's Dec 21 20:49:19 while it did exist Dec 21 20:50:12 someone told me recently even fiber can still use PPP it seems? Dec 21 20:50:35 yes, there are some that do that for ftth Dec 21 20:51:10 which should really be called wtfh Dec 21 20:51:19 but at least the one I'm switching to won't (VLAN + DHCP), but sadly I'm sacrificing my IPv4 address for that (DS-Lite) Dec 21 20:52:09 Pppoe and physical network ubderneath has little to do with eachothers really :) Dec 21 20:54:05 yeah I have vlan + dhcpv4/v6 Dec 21 22:45:15 blogic: not an issue with any board. not a bug. I just would like to have the opportunity to signal two things with one LED (concrete example: disk access trigger to blink the LED and have it solid to indicate awake.) Dec 21 22:45:55 blogic: and this would require to invert the LED, again, like "link" mode does for the netdev trigger. Dec 21 23:42:49 Hello everybody ! I have a silly question about building a (python3) package with the SDK : whenever I build my package it wants to also build (27) dependents packages, among which 'python3'. This 'python3' build fails in a non-evident (for me) way. Dec 21 23:44:17 I thus have some questions: 1) Is it necessary to rebuild all dependent packages (with the SDK) ; or is there another way that have all the (binaries, libraries, build artefacts...) from the buildbots so that I can "just" build my package, and not other (already built) packages ? Dec 21 23:45:23 2) Anybody having this error during 'python3' build ? (ipq40xx-generic-18.06.5) ( "make[3]: *** [Makefile:302: /home/build/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/Python-3.6.9/.built] Killed") Dec 21 23:46:33 (Note: I'm using the docker SDK image from https://hub.docker.com/r/openwrtorg/sdk/tags?page=1&name=ipq40xx-generic-18.06.5 ) Dec 22 00:05:25 I am on fiber (active Ethernet) at my parents and it is also pppoe + vlan 7 Dec 22 00:06:12 and you have a username and password for that Dec 22 00:06:27 but this is automatically configured over TR-69 Dec 22 00:06:59 with BNG the username/ password (at least for DTAG) isn't checked though, unless explicitly reconfigured in their webinterface Dec 22 00:08:14 it needs to be supplied, but abc@t-online.de with a password of 123 works just fine (VDSL2/ BNG) Dec 22 00:08:21 this is EWE Dec 22 00:09:18 yes for DSL the DTAG ignores the user name and password Dec 22 00:09:34 they can just check on which port you are connecting Dec 22 00:09:45 as there are no "dailup" DSL lines Dec 22 00:10:13 yep (and even if you disabled the automatic login, it'll revert to it at any opportunity) **** ENDING LOGGING AT Sun Dec 22 02:59:58 2019