| 00:08.30 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:08.30 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:01.03 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 03:01.03 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 06:06.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:a84b:e4fe:cb19:89cd) |
| 06:08.33 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:08.33 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:07.58 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:31.08 | *** join/#asterisk-dev AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 11:15.35 | *** join/#asterisk-dev ahmed89 (~devops@134.0.214.254) |
| 11:24.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 11:54.20 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:56.16 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:2586:4c35:a41f:89d) |
| 11:56.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:23.49 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.43.249) |
| 13:00.34 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:00.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:03.21 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:a05e:9519:f311:86ca) |
| 13:06.30 | *** join/#asterisk-dev seanbright (~sean@asterisk/community-developer/seanbright) |
| 13:06.30 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 14:01.58 | *** join/#asterisk-dev sahmed (~sahmed@37.19.10.33) |
| 14:03.09 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-jptsivxoszpatrxe) |
| 14:03.09 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:05.27 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-lkqvzkbskkmkrrqo) |
| 14:05.27 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:22.36 | gtjoseph | coreyfarrell: does ref_debug catch things that the leak sanitizer does not? |
| 14:42.31 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-pznqahkpotznitha) |
| 14:42.31 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:51.39 | sahmed | Hi, If we configured encryption=DTLS and optimistic=yes on an endpoint, its working fine, if incoming call have no support for DTLS it reply without fingerprint. But if we set ast_sip_session_media=yes for that endpoint then the behavior get changed, if incoming call have no DTLS support then asterisk reply back with a fingerprint in SDP. |
| 14:52.57 | file | optimistic DTLS is not currently supported |
| 14:53.14 | sahmed | So, my question is why encryption optimistic flag get affected by ast_sip_session_media=yes flag settings. |
| 14:53.36 | file | you'll need to be more specific about what flag that is |
| 14:53.57 | sahmed | @file sorry for long and repetitive question :( |
| 14:55.50 | sahmed | While we set media_use_received_transport=yes along with ast_sip_session_media=yes and media_encryption = dtls, this changed the behavior |
| 14:56.13 | file | yes, that will alter the SDP to match the incoming a bit |
| 14:56.20 | sahmed | If we set only ast_sip_session_media=yes and media_encryption = dtls , this settings work fine |
| 14:56.21 | file | but optimistic with DTLS itself isn't written and won't work as you'd likely want |
| 14:56.37 | file | ast_sip_session_media=yes doesn't exist - what do you mean by that? |
| 14:57.34 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-wmcmwvepfpqmkkrj) |
| 14:57.34 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:59.05 | sahmed | @file I mistakenly paste ast_sip_session_media=yes, it will be media_encryption_optimistic = yes |
| 14:59.13 | file | ah |
| 14:59.33 | file | it's just really because the code wasn't written to work with optimistic and DTLS enabled |
| 15:04.03 | sahmed | Ok, got it, So actually we need this configuration to work, and we have changed few codes in res/res_pjsip_sdp_rtp.c, now we are little bit confused on those changes, we dont know is there any side effect on this changes. Could you please have a quick look into this and make us happy? |
| 15:05.12 | file | if you have specific questions I can try to answer them |
| 15:05.15 | file | as can anyone in here |
| 15:05.53 | file | but proper optimistic support probably isn't "easy" |
| 15:05.55 | sahmed | @file sure I am happy to do that :) |
| 15:06.27 | sahmed | yes, We don't work for that really, thats not easy job. |
| 15:11.23 | sahmed | Ok, my only confusion is if we set the session_media->encryption in negotiate_incoming_sdp_stream method after get return encryption from check_endpoint_media_transport method dose it have any bad impact? |
| 15:11.40 | sahmed | File: res/res_pjsip_sdp_rtp.c Method: negotiate_incoming_sdp_stream |
| 15:12.30 | file | I don't know off the top of my head, there's a lot of interaction in there |
| 15:13.27 | file | there are tests in the testsuite for SDP negotiation that would likely uncover anything based on how it should work now |
| 15:15.41 | sahmed | We also built few tests in the testsuite, like SDES_offered, SDES_not_offered, DTLS_offered, DTLS_not_offered. all of those tests are successfull |
| 15:16.15 | sahmed | but still confused and worried is there any side effect |
| 15:17.16 | file | without digging into it and labbing things up I can't really answer |
| 15:17.28 | file | it's complex code and interactions, so there is no quick answer |
| 15:17.30 | file | https://github.com/asterisk/testsuite/tree/13/tests/channels/pjsip/secure_calling |
| 15:17.38 | file | for all the tests covering it |
| 15:18.27 | *** join/#asterisk-dev csavinovich (sid296765@gateway/web/irccloud.com/x-vquabhhybtoxtpte) |
| 15:18.27 | *** mode/#asterisk-dev [+o csavinovich] by ChanServ |
| 15:19.16 | sahmed | Ok, Lets try those secure_calling tests, and Thanks a lot for your time. |
| 15:34.49 | sahmed | @file all the secure_calling tests are PASSED with that change |
| 15:35.05 | file | then it's probably fine? |
| 15:35.39 | sahmed | I think so :) |
| 15:38.14 | *** join/#asterisk-dev ahmed__ (~ahmed@85.154.169.183) |
| 15:39.42 | *** join/#asterisk-dev ahmed__ (~ahmed89@85.154.169.183) |
| 15:40.52 | *** join/#asterisk-dev ahmed89 (~ahmed89@85.154.169.183) |
| 16:02.27 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.171) |
| 16:16.50 | coreyfarrell | gtjoseph: I haven't used leak sanitizer before but I think it would actually tell you about all leaks, ref_debug only catches ao2 leaks. from what I can tell it won't tell you why an AO2 object leaked, only that it was allocated and never freed (no list of ref/unref to find the reference that leaked). |
| 16:17.30 | gtjoseph | yeah it catches more. i just wanted to check that it should at least catch what ref_debug does |
| 16:17.40 | gtjoseph | it's easier to run the leak sanitizer. :) |
| 16:19.59 | coreyfarrell | ao2 objects are allocated so if they are not freed then I'd expect leak sanitizer should report it. at that stage figuring out why the ao2 leaked probably requires reproducing with refdebug enabled (which is pretty easy to do in 15+). |
| 16:22.28 | seanbright | it's happeningggggg |
| 16:23.20 | off-nominal | should have just waited a week and you could have skipped the 14 branches :P |
| 16:24.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d005cda797562dd8584.ipv6.abo.wanadoo.fr) |
| 16:24.18 | coreyfarrell | another security release that doesn't apply to my deployments :) |
| 16:24.21 | rmudgett | :P |
| 16:25.10 | off-nominal | goes off to find AST-2018-010 |
| 16:25.25 | off-nominal | found it |
| 16:25.30 | off-nominal | patch coming |
| 16:26.35 | rmudgett | :P |
| 16:26.51 | off-nominal | it's an... off-nominal... issue |
| 16:27.12 | off-nominal | ::cue csi miami theme:: |
| 16:29.33 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-bvtlfhowwjnvhdbh) |
| 16:33.58 | rmudgett | wonders when the security patches will get the +1 validation before he can shove them in. |
| 16:34.14 | off-nominal | message received |
| 16:35.02 | rmudgett | I was looking for jenkins to finish its compile run. :D |
| 16:35.13 | off-nominal | oh. heh. |
| 16:35.28 | off-nominal | well. the code review is done. |
| 16:35.32 | off-nominal | LGTM |
| 16:45.25 | off-nominal | rmudgett: i think jenkins in at lunch |
| 16:45.30 | off-nominal | is* |
| 16:45.49 | rmudgett | seems like it to me too :D |
| 16:46.30 | gtjoseph | is looking |
| 16:46.56 | off-nominal | looks at gtjoseph looking at jenkins |
| 16:47.12 | file | warbles |
| 16:50.31 | gtjoseph | ok he's got all 8 slaves busy again. |
| 16:50.46 | gtjoseph | s/slaves/agents/ |
| 16:51.02 | gtjoseph | we're not supposed to use the word "slave" anymore I guess. |
| 16:51.09 | off-nominal | that is correct |
| 16:51.45 | off-nominal | infobot: stop logging this channel |
| 16:51.46 | infobot | ACTION leaps to his feet and stops logging this channel |
| 16:52.00 | kharwell | what's the rfc say? "should" or "must" not use those words? |
| 16:52.48 | off-nominal | i suggest we move on to another topic :D |
| 16:52.52 | off-nominal | we SHOULD move on |
| 16:53.12 | file | groan |
| 16:53.37 | off-nominal | i don't know about you people, but i intend to run for public office one day |
| 16:53.59 | off-nominal | and the last thing that i need is for someone to bring IRC logs to my confirmation hearing |
| 16:59.32 | *** join/#asterisk-dev ahmed89 (~ahmed89@85.154.169.183) |
| 17:04.08 | *** join/#asterisk-dev ahmed89 (~ahmed89@85.154.169.183) |
| 17:15.43 | *** join/#asterisk-dev pc-m (~pcm@cable-66-129-132-216.b2b2c.ca) |
| 17:16.08 | *** part/#asterisk-dev pc-m (~pcm@cable-66-129-132-216.b2b2c.ca) |
| 17:21.40 | jameswf | <PROTECTED> |
| 17:28.07 | off-nominal | infobot: dave |
| 17:28.08 | infobot | Don't give me any of that Star Trek crap. |
| 17:28.13 | off-nominal | infobot: dance |
| 17:28.13 | infobot | <(*.*<) <(*.*)> \(*.*)/ (>*.*)> |
| 17:30.28 | *** join/#asterisk-dev zerohalo (sid288136@gateway/web/irccloud.com/x-vhphrfkainrgfwto) |
| 17:53.01 | jameswf | infobot: bad monkey |
| 17:53.01 | infobot | Bad monkey, bad! No cookie for you! |
| 17:58.54 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-jfgdjyduzgxihthb) |
| 17:58.54 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:00.33 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-zffupqsvelsgrbpv) |
| 18:00.34 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:12.25 | *** join/#asterisk-dev Deeewayne (~dwayne@2605:a600:8050:5600:829d:1142:5677:7e57) |
| 18:12.25 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:12.33 | off-nominal | it is a well-known fact that people making seemingly profound statements should do so without typos |
| 18:13.24 | off-nominal | ergo... vis-a-vis... |
| 18:27.07 | gtjoseph | coreyfarrell: rmudgett: is there something different about how AO2_DEBUG works in master than 13? |
| 18:27.32 | gtjoseph | I use it in stasis.c but it's always undefined in master but works in 13 |
| 18:30.37 | coreyfarrell | gtjoseph: yes. see main/Makefile for how it is passed to astobj2.o. |
| 18:31.31 | coreyfarrell | in 16+ certain compiler defines are only provided to specific sources so it's more friendly to ccache. |
| 18:32.05 | gtjoseph | wow |
| 18:32.14 | gtjoseph | when did we do that? |
| 18:33.59 | coreyfarrell | gtjoseph: https://gerrit.asterisk.org/9870 was merged about a month ago |
| 18:35.11 | gtjoseph | i guess I was asleep on that one. |
| 18:35.20 | gtjoseph | so what does and what doesn't get passed? |
| 18:37.13 | gtjoseph | coreyfarrell: and wasn't there a patch to prevent an install of master from complaining about the downloadable modules? |
| 18:37.19 | coreyfarrell | the list is in build_tools/make_buildopts_h. |
| 18:38.15 | coreyfarrell | yes and no. configure itself doesn't automatically block those modules from master, tests/CI/buildAsterisk.sh does. |
| 18:58.38 | seanbright | so i just went down the rabbit hole of going through old IRC logs and i have one observation - i say 'heh' a lot |
| 19:00.54 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hsxsmtjlyhryuevk) |
| 19:00.55 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:24.17 | *** join/#asterisk-dev ahmed89 (~ahmed89@85.154.169.183) |
| 20:06.10 | cresl1n | heh is a good word |
| 20:23.02 | jkroon | in res_odbc, i've got a delay in reload() function after calling load_odbc_config(), there seems to be a delay of 5 secondds from calling ao2_iterator_init(class_container, 0) until ao2_iterator_destroy(&aoi) is called, and I cannot see a possible reason why. this seems to happen if (and only if) there were connections. So presumably it's waiting for all connections to be returned to the pool to be destroyed? |
| 20:33.08 | seanbright | jkroon: yeah, something is weird about that code |
| 20:33.52 | jkroon | seanbright, ok, as temporary stopgap I'm just going to increase my timeout from 5 to 15. |
| 20:34.10 | seanbright | it's looping through, setting ->delme on existing classes, then loading config, and then unlinking classes where ->delme is set |
| 20:34.28 | jkroon | not sure how to go about debugging that one though, is it asterisk, or could it somehow be myodbc that's not so hot? |
| 20:34.28 | seanbright | but nothing in load_odbc_config() is ever unsetting ->delme |
| 20:34.37 | seanbright | it's definitely asterisk |
| 20:34.40 | file | it's not reusing the class |
| 20:34.47 | seanbright | it should though, right? |
| 20:34.53 | file | it maybe could? |
| 20:35.00 | jkroon | seanbright, so load_odbc_config() creates all new classes, and all pre-existing classes gets nuked, the logic in reload() seems correct to me. |
| 20:35.08 | jkroon | no, it should not because parameters can change. |
| 20:35.13 | seanbright | otherwise what's the point of setting ->delme? |
| 20:35.32 | jkroon | however, why would ao2_unlink be so slow? |
| 20:35.34 | seanbright | jkroon: what if they don't? |
| 20:35.47 | seanbright | jkroon: because the class destructor is called |
| 20:35.49 | jkroon | seanbright, no harm in re-establishing the connections. |
| 20:36.06 | seanbright | ao2 object destructors have side effects |
| 20:36.13 | seanbright | some that might take... oh i dunno... 5 seconds? |
| 20:36.15 | jkroon | don't the connections have refs back to the class which means they'll only be destroyed once those connections gets returned? |
| 20:36.19 | seanbright | see what i'm saying? |
| 20:36.31 | seanbright | ok, we're talking over each other |
| 20:36.47 | seanbright | the 5 second delay happens because the 'class' objects are being deref'd out of existance and the dtor is being called |
| 20:36.52 | jkroon | ok, so where do i find that destructor? |
| 20:37.09 | jkroon | nm, stupid, got it. |
| 20:37.37 | seanbright | static void odbc_class_destructor(void *data) |
| 20:38.41 | seanbright | so the class is being destroyed, which deref's all of the connections causing them to be destroyed, so on and so forth |
| 20:38.59 | seanbright | and then they tell 2 friends... and then they tell 2 friends... |
| 20:39.15 | jkroon | there is only 1 open connection at the time of reload in my last tests. |
| 20:39.46 | seanbright | ok |
| 20:40.08 | seanbright | so you're just trying to figure out why closing and re-opening the connection takes 5 seconds? |
| 20:40.15 | jkroon | closing it. |
| 20:41.24 | jkroon | well, my situation started with Reload AMI action timing out. my timeout is 5 seconds. Upping that to 60 got it done in 8. The using CLI to reload one module at a time pointed out that res_odbc is the culprit. Then some foo-printing got it to that loop, and now I'm at why does closing the connections take 5 seconds. |
| 20:41.25 | seanbright | static odbc_status odbc_obj_disconnect(struct odbc_obj *obj) |
| 20:41.29 | seanbright | that is what does the closing |
| 20:41.41 | seanbright | you should add some ast_log()s with some timestamps |
| 20:42.03 | jkroon | adding loads of ast_debug(1, "pointX\n"); statements now. |
| 20:57.05 | jkroon | SQLDisconnect(con); <-- call that's taking long.and that's down into unixODBC land as far as I know. It also outputs this: [ERROR] Error in my_thread_global_end(): 1 threads didn't exit |
| 20:57.49 | seanbright | my_thread_global_end dpesn |
| 20:57.58 | jkroon | dpesn? |
| 20:57.59 | seanbright | 't exist in asterisk as far as i can tell |
| 20:58.12 | seanbright | at least in 13 |
| 20:58.24 | jkroon | no, i suspect it's part of mysql-connector-c |
| 20:58.29 | seanbright | also not in master, so it's not coming from asterisk |
| 20:58.31 | jkroon | on which myodbc relies. |
| 20:58.35 | seanbright | god speed |
| 20:58.47 | jkroon | SQLDisconnect is already "out of there" i believe. |
| 20:59.32 | file | res_odbc is a fairly thin wrapper, so many things end up being in the layer below |
| 20:59.49 | jkroon | 1100 lines of "fairly thin" |
| 20:59.56 | seanbright | ... |
| 21:00.30 | file | thin in that all of the hard work is below |
| 21:00.39 | jkroon | :) |
| 21:01.25 | jkroon | yea great, so SQLDisconnect function is in libodbc.so.2, so wherever this problem is, i'm hacking at unixODBC and myodbc :( |
| 21:01.39 | seanbright | sucks to be you |
| 21:02.47 | jkroon | hehehe, i'd much rather hack at asterisk core ... those two projects had to hunt bugs in them before. far from pleasant. |
| 21:02.54 | jkroon | anyway, thanks for the help, as usual. |
| 21:04.41 | coreyfarrell | jkroon: maybe try switching from mysql-connector-odbc to mariadb-connector-odbc? that's all I can think of. |
| 21:06.02 | coreyfarrell | ^^^ obviously do compatibility testing, switching could make things worse. |
| 21:06.09 | jkroon | coreyfarrell, let me look into that. |
| 21:12.49 | jkroon | coreyfarrell, myodbc doesn't like mariadb-connector-c at all. |
| 22:18.02 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-lkqvzkbskkmkrrqo) |
| 22:27.19 | jkroon | coreyfarrell, i'm wondering if the fact that we're creating multiple environments for unixODBC isn't perhaps the issue. The code samples I can find otherwise generally creates a single SQL_HANDLE_ENV, SQL_NULL_HANDLE and then use that to get connections given the DSN name. Contemplating if because we created a new environment and then try and unload the old one, both use the same instance of the mysql library, so my_thread_init() and |
| 22:27.19 | jkroon | my_thread_end() ref counting goes beserk. |
| 22:28.23 | jkroon | meaning we should re-use the environment for all connections. just not sure if we need to recreate the environment to get it to reload odbc.ini or whether that happens every time a new connection gets established. |
| 22:28.40 | jkroon | anyway, i'm about 4 hours over intended bed time ... so I'll look in the morning. |
| 22:37.22 | coreyfarrell | jkroon: sorry I already gave the only idea I had. |
| 22:38.06 | jkroon | i'm 90% sure. |