**** BEGIN LOGGING AT Sat Feb 20 02:59:58 2016 Feb 20 07:11:06 Hi, which files has to be inside staging_dir/target-../host/inlude and which one in staging_dir/target-../include? Feb 20 07:13:07 libxml2 is placed in include, but the folder host/include/libxml2 is included as search path. Feb 20 18:26:51 so, still bisecting my lantiq annex a issue. getting closer Feb 20 18:27:30 about 6 commits mentioning lantiq are in the git bisect visualize at the moment Feb 20 18:28:03 er, maybe 8 Feb 20 18:28:16 anyway, one is starting to look suspicious Feb 20 18:28:40 r47934 Feb 20 18:29:39 but i have no idea where xtse bits are documented... Feb 20 18:29:41 nbd? Feb 20 18:32:44 (does blogic show up here much?) Feb 20 18:34:22 hey Feb 20 18:34:26 blogic usually isn't on irc Feb 20 18:35:25 * jakllsch tries another bisect point (with possible upcoming connection bounce) Feb 20 18:36:08 last time I saw him here was may last year :) Feb 20 18:51:13 anyway, only "about 4" steps left here. guess i'll let the mailing list know what i find Feb 20 18:56:18 jakllsch: the XTSE bits are documented in the ITU-T G.997.1 standard Feb 20 18:56:29 jakllsch: for instance ITU-T G.997.1 (06/2012) - section 7.3.1.1.1 and ITU-T G.997.1 Amendment 2 (04/2013) section 2.1 Feb 20 18:56:37 jakllsch: you can get the documents free of charge from https://www.itu.int/rec/T-REC-G.997.1 Feb 20 18:58:52 heh, an international standard you don't have to pay to view? i did not expect that. Feb 20 20:16:28 nbd: I am getting a weird error with uclient-fetch when I am trying to connect to my webserver via https. http works fine. jow_laptop suggested I to poke you about it Feb 20 20:16:40 (null) 0 - stalled - Feb 20 20:16:40 Connection reset prematurely Feb 20 20:16:54 my hunch was that it could be related to the ssl layer Feb 20 20:16:54 this is with libustream-openssl Feb 20 20:17:19 I am now building with openssl-util to see if I get anything similar with openssl s_client Feb 20 20:20:28 openssl s_client is able to establish a connection, I do get "unable to get local issuer certificate" Feb 20 20:20:51 but running uclient-fetch with --no-check-certificate does exactly the same Feb 20 20:35:01 stintel: can you try libustream-polarssl as well? Feb 20 20:47:24 japaric: what problem do you have? Feb 20 20:50:04 jakllsch: what problem do you have? Feb 20 20:50:46 Hauke: i think i figured it out Feb 20 20:51:33 in a configuration that works: Feb 20 20:51:46 (from dsl_control status) Feb 20 20:52:28 ... Feb 20 20:52:31 Firmware Version: 5.7.1.8.0.1 Feb 20 20:52:36 XTSE Capabilities: 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 Feb 20 20:52:56 but now that the -i argument works... Feb 20 20:53:10 we pass 0x04 as the first octet, which does not include a set bit 0 Feb 20 20:53:54 er, ITU calls it bit 1 Feb 20 20:54:17 "It is recommended that bit 1 be used for [b-ATIS 0600413]." Feb 20 20:54:21 but not required Feb 20 20:54:39 * jakllsch goes back to tip of origin/master and tests hypothesis Feb 20 20:54:49 jakllsch: make sure that there is no space between the -i and the numbers Feb 20 20:54:57 yeah, i noticed that Feb 20 20:56:39 i'm currently testing r47933 and have... Feb 20 20:57:01 xtse_adsl_a="05 01 04 01 00 01 00 00" and -i`echo $xtse | sed "s/ /_/g"` Feb 20 20:57:06 this managed to reach showtime Feb 20 20:59:09 so, basically, the problem is that here in capitolist america we have last-century DSL Feb 20 20:59:19 :P Feb 20 20:59:35 jakllsch: have you chaned anything? Feb 20 21:00:01 i (at least) changed the first octet from 04 to 05 Feb 20 21:00:17 xTSE 4 bit 0 is not supported by the firmware Feb 20 21:00:38 G.992.4 Annex A Feb 20 21:02:06 that was fixed in r47934 Feb 20 21:02:42 my bisect just happend to have it narrowed down to (approximately) either of those commits, so i started playing with the dsl_control file at runtime rather than rebuild Feb 20 21:03:19 jakllsch: do you have a working paramaterset and a non working paramater set? Feb 20 21:04:48 from what i can tell (i haven't literally tested this) T1.413 worked before r47933 with an unmodifed build, and afterwards it always fails to train Feb 20 21:05:44 presumably because whatever "-i" defaulted to when it was syntactically invalid included a set "bit 1" of the first xTSE octet Feb 20 21:08:45 hmm Feb 20 21:09:07 CONFIG_DEFAULT_ltq-vdsl-app=y Feb 20 21:09:20 (from current origin/master) Feb 20 21:11:36 ah. i see Feb 20 21:11:58 jakllsch: with an annex a fimrware it sets 05 00 04 00 0c 001 by default Feb 20 21:13:00 (i was wondering about the difference between ltq-adsl-app and ltq-vdsl-app, but it looks like the adsl-app is for not-VRx chips) Feb 20 21:13:28 nbd: with libustream-polarssl it seems to work, but it's very slow, takes ~10s to establish te connection Feb 20 21:14:00 yes it is for older chips Feb 20 21:14:35 jakllsch: youn are using a vrx200 ? Feb 20 21:15:00 Hauke: i think so? whatever's in a TD-W8970 v1.2 Feb 20 21:15:07 yes Feb 20 21:15:53 stintel: could be perfect forward secrecy Feb 20 21:15:58 stintel: that's usually quite slow Feb 20 21:17:19 nbd: yes, only FS ciphers allowed Feb 20 21:17:38 maybe enabling ECDHE might make it faster Feb 20 21:17:58 likely Feb 20 21:19:01 it's now using TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, and the webserver is configured with 4096 DH parms Feb 20 21:19:54 that's the last cipher that is in the server configuration Feb 20 21:20:10 is ECDHE not enabled for polarssl ? Feb 20 21:20:41 4096 DH parms is really slow Feb 20 21:20:55 and tbh I would prefer just to use openssl, I need openssl anyway and having another SSL library seems just silly Feb 20 21:31:01 stintel: it's not Feb 20 21:31:55 probably a good idea to do it, especially on slow hardware :) Feb 20 21:35:16 the old size vs features tradeoff, https://dev.openwrt.org/browser/trunk/package/libs/polarssl/patches/200-reduce_config.patch Feb 20 21:38:34 from my opinoen ECDHE is more important than DH Feb 20 21:38:52 yeah, i think we can disable DH and use ECDHE Feb 20 21:40:11 stintel: do you want to mesure the size difference and send a patch? Feb 20 21:49:10 nbd: fyi, server log says this with uclient-fetch/libustream-openssl: SSL_shutdown() failed (SSL: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call) while SSL handshaking Feb 20 21:56:55 stintel: ok. i haven't done much work on libustream-openssl in a while, i guess i need to take another look Feb 20 21:57:02 stintel: what's the address of your server, so i can test against it Feb 20 21:59:16 nbd: you can try https://stijn.tintel.eu Feb 20 22:00:10 looking at the source myself and trying to get a backtrace with gdbserver but failing Feb 20 22:00:36 anyway I'm going afk now, forgot dinner again **** ENDING LOGGING AT Sun Feb 21 02:59:58 2016