IRC log for #asterisk on 20210324

00:01.09ablakelyI tried --force and got [ 2362.661326] Dazed and confused, but trying to continue
00:01.17ablakelythats a first
00:02.06jm|laptopthat give ms sickening memories of "rpm -i --force --nodeps"
00:03.01jm|laptopthat never went particularly well either
00:13.13*** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood)
00:22.34*** join/#asterisk fstd_ (~fstd@unaffiliated/fisted)
00:28.51*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
00:58.54*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
01:16.33*** join/#asterisk Dovid (~dovid@96.56.22.146)
01:34.31*** join/#asterisk pchero (~pchero@211.178.226.108)
02:00.06*** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net)
02:22.18*** join/#asterisk tsal (~tsal@i59F5F664.versanet.de)
02:50.35*** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou)
03:58.14*** join/#asterisk Janos (~textual@201.204.94.76)
04:29.34igcewielingNothing quite like renumbering a remote network to get the adrenaline pumping!
04:29.46igcewieling(even when it goes right)
05:18.12*** join/#asterisk Maliuta (maliutamat@gateway/shell/matrix.org/x-poqlkvcjpylfifbk)
05:26.50*** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54)
07:40.00*** join/#asterisk BakaKuna (~Thunderbi@2a02-a446-ae46-1-4496-962e-3edc-596.fixed6.kpn.net)
08:26.48*** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com)
08:26.57*** join/#asterisk opal (~wowaname@volatile/founder/wowaname)
08:31.37*** join/#asterisk guest9183 (~martin@185.32.9.250)
08:34.37guest9183Hello! I am trying to include a external file into my [global] scope with pjsip. But it does not work, if I add the networking directly under [udp-transport] it works. I hope it is a basic thing I have overseen https://pastebin.com/raw/RBd7jzsv
08:35.21guest9183I wish not to define the networking separetly on all transport to keep the config slim.
08:39.19guest9183Hm, when testing I see that adding networking configurations under [global] does not affect the transport scopes
09:08.55*** join/#asterisk cation21 (cation21@gateway/vpn/protonvpn/cation21)
09:25.16*** join/#asterisk jkroon (~jkroon@165.16.204.100)
10:25.45*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
10:38.34*** join/#asterisk sinaowolabi (~Sina@41.190.30.26)
12:19.40*** join/#asterisk rpifan (~rpifan@p200300d2672b5d0091da27f0e2edaf9f.dip0.t-ipconnect.de)
13:01.40*** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net)
13:17.15*** join/#asterisk retentiveboy (~retentive@2601:cf:4500:5ea0:d7d4:5bb3:3637:fc81)
13:18.54*** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK)
13:19.15*** join/#asterisk retentiveboy (~retentive@2601:cf:4500:5ea0:d7d4:5bb3:3637:fc81)
13:49.00*** join/#asterisk lihora (~suporte@2804:14d:72b1:948e:7f49:c2f2:2854:320a)
13:49.06*** part/#asterisk lihora (~suporte@2804:14d:72b1:948e:7f49:c2f2:2854:320a)
14:10.57*** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-fvhnmxzjupirjrnb)
14:10.57*** mode/#asterisk [+o kharwell] by ChanServ
14:25.28*** join/#asterisk rpifan (~rpifan@p200300d2672b5d00dca0d45f9b9980a3.dip0.t-ipconnect.de)
14:30.11*** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-ndnunpjbodzwisan)
14:32.42*** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com)
14:33.22*** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-btarjksxptvymvni)
14:33.22*** mode/#asterisk [+o bford] by ChanServ
14:41.58*** join/#asterisk retentiveboy (~retentive@c-24-125-16-104.hsd1.ga.comcast.net)
15:07.40*** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK)
15:25.59KobazDoes pjsip's sip tls have support for writing a key log file
15:33.03SamotNot sure.
15:33.29Kobazhttps://wiki.wireshark.org/TLS#Using_the_.28Pre.29-Master-Secret
15:37.26Samothttps://www.asterisk.org/new-pjsip-logging-functionality/
15:37.51SamotAccording to that the logger function can write a pcap and even when it's TLS it's decrypted.
15:38.03SamotSince Asterisk has to decrypt the data at that point.
15:40.20Kobazwell this is for clients
15:40.37Kobazwireshark at the soft phone level, and then load the encrypted capture, and then decrypt for troubleshooting
15:45.43SamotWhy would PJSIP be involved at the phone level?
15:46.00SamotIf the wireshark is being take at that side, that's where the master secret should be added.
15:46.14Kobazwriting out the key log, so the data can get decrypted at the client for troubleshooting
15:46.32SamotWell to do it encrypted you have to do it before Asterisk.
15:46.43Kobazas far as I know, i, depending on the cipher, it might not be possible to decrypt even with the master key
15:47.02SamotTrue but also this has to be done before Asterisk.
15:47.19SamotSo at that point PJSIP is still irrelevant.
15:49.53Kobazit's passing the data to openssl for encryption, so... there would need to be the variables/flags passed to openssl to say 'write this key log'
15:59.02KobazWell, figured out the problem... didn't even have to decrypt the tls... their firewall is blocking outbound udp entirely
16:12.05*** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood)
16:29.25*** join/#asterisk hfb (~hfb@193.36.225.16)
17:05.21*** join/#asterisk jzvi12[m] (jzvi12matr@gateway/shell/matrix.org/x-eeraszeencghwsoe)
17:14.37*** join/#asterisk Maliuta (maliutamat@gateway/shell/matrix.org/x-ezcgitssewwveapx)
17:42.13*** join/#asterisk pchero (~pchero@211.178.226.108)
18:01.15*** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net)
18:22.43*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
18:25.38*** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood)
18:32.02*** join/#asterisk ilius (~ilius@c-98-33-209-27.hsd1.ut.comcast.net)
18:34.47*** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-nwuluoofgbbhxmsl)
18:45.47*** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1)
18:50.06*** join/#asterisk eXistenZ (~pectic@bzq-79-176-205-152.red.bezeqint.net)
18:50.06iliushttps://www.asterisk.org/pjsip-transport-reload-fun/ <= When was that?  Those blog posts don't include dates.
18:54.43*** join/#asterisk infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net)
18:54.43*** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 18.2.2, 16.16.2 (2021/03/04) Final Bugfix: 13.38.2, 17.9.3 (2021/03/04); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22
19:02.55*** join/#asterisk hfb (~hfb@193.36.225.16)
19:13.24seanbrightilius: hi
19:13.37*** join/#asterisk eXistenZ (~pectic@bzq-79-176-205-152.red.bezeqint.net)
19:13.42seanbrightwanted to make sure you saw https://gerrit.asterisk.org/c/asterisk/+/15689
19:13.48seanbrightcourtesy of kharwell
19:15.21fileilius: there has been no change to reloading of TLS certificate as of this time
19:20.06*** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK)
19:22.46*** join/#asterisk rpifan (~rpifan@p200300d2672b5d0092ffb42f9df677d7.dip0.t-ipconnect.de)
19:30.59*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
19:48.51*** join/#asterisk electronic_eel (~quassel@electroniceel.org)
19:57.04iliusseanbright, thank you so much!  it will be nice to use that statistic!
19:58.15*** join/#asterisk sinaowolabi (~Sina@41.190.30.26)
19:58.53iliusfile, thank you for the update.  so are most people who change certs often rebooting asterisk entirely?  or are they doing the "allow_reload" thing?
20:01.16*** join/#asterisk sinaowolabi (~Sina@41.190.30.26)
20:07.08seanbrightilius: kharwell did the work, i just remember you asking about it a few days/weeks ago
20:07.55tripleslashilius: <meta property="article:published_time" content="2021-01-20T18:00:21+00:00" />
20:07.57iliusseanbright, i am amazed that you remembered both the issue and that it was me!
20:08.27seanbrightirc logs help
20:08.48iliustripleslash, aaah, 1/20.  I didn't think to look in the source, though it'd be nice if it were displayed on the page.
20:10.09tripleslashilius, I agree.
20:10.19fileilius: I have no information or insight on the cert reloading thing
20:13.14Kobazilius: be wary of the allow_reload... i was warned... and i did eventually found out why allow_reload is bad.  it will bite you in mysterous and unexpected ways
20:13.24iliusfile, thanks
20:13.41iliusKobaz, yeah, that's what I'm afraid of
20:13.43seanbrightwhat does allow_reload actually do? tear down and recreate the transport?
20:13.49fileseanbright: yes.
20:13.54fileseanbright: except transport destruction is asynchronous.
20:14.12iliusI wonder if anyone else here is doing letsencrypt certs and how they deal with reloading
20:14.13Kobazand you might have things that want to use that transport.. while it's going away
20:14.28seanbrightthe pjsip api doesn't appear to provide a way to reload certs
20:14.43fileseanbright: it does now! kinda - you can restart transports
20:15.01Kobazwhat version of pj supports that?
20:15.29fileI don't know when it was added, it is not yet used in res_pjsip
20:15.42Kobazah okay, so it's there already, cool
20:15.58filehttps://pjsip.org/pjsip/docs/html/group__PJSIP__TRANSPORT__TLS.htm#ga2a58099d6d5a3f31b1f297dda83b30c3
20:16.01KobazIt sounded like that was something new
20:16.15seanbrightfile: right, i remember in a non-restart-transports way
20:16.19seanbrightrememer? meant*
20:16.41fileseanbright: ah - correct
20:16.51Kobazyeah like a reload instead of, destroy rebuild and hope for the best
20:17.16Kobazwell there's still possability of failure since it would still close the current one
20:19.09iliusfile, adding pjsip_tls_transport_restart() into res_pjsip the thing you were talking about in your blog post?
20:19.24fileit's a potential future change, yes
20:19.32iliusif it gets added, i hope it'll be backported to 16. :D
20:19.48fileI've done bits and pieces which are pre-reqs for supporting it
20:20.15iliusyay!
20:20.45Kobazfile: do you know if the new approach will say. batch up pending sip messages until the stack is restarted? or do you lose that in transition?
20:21.14*** join/#asterisk BakaKuna (~Thunderbi@2a02-a446-ae46-1-921b-9124-d7fa-5afe.fixed6.kpn.net)
20:21.39filewhat pending sip messages are you referring to? the restart is for TCP and TLS, established connections would remain up afaik
20:21.58fileyou don't restart a UDP transport
20:22.25KobazTLS
20:22.46fileit restarts the listener transport.
20:23.29Kobazlike the documentation says it will close the socket
20:23.46fileit closes the listener socket, in TCP and TLS Each accepted connection is a separate socket
20:23.58fileI would expect those to remain up and untouched
20:24.04Kobazoh right, the listener
20:24.16Kobazyeah makes sense
20:45.59joakoHas anyone ever seen an issue where you specify serveremail in voicemail.conf but the email refuses to come from anything other than username@fqdn? for e.g. asterisk@localhost.localdomain
20:46.28SamotHeh
20:46.54*** join/#asterisk overyander (~overyande@216.163.21.11)
20:47.05igcewielingjoako: that is your OS/mail system
20:49.01SamotBeen told
20:49.06SamotIts a postfix issue
21:00.52*** join/#asterisk TandyUK (~admin@TandyUK/staff/James)
21:17.29joakoigcewieling, I am not convinced of that. /usr/sbin/sendmail -t is the default mailcmd. I can replace it with /usr/sbin/sendmail -t -f something@some-domain.com and the message is sent properly. I also see in the app_voicemail.conf there is a line that defaults serveremail to ASTERISK_USERNAME which is consistent with what I am seeing.
21:18.28igcewielingyes, you use -f to set the from name.
21:19.40joakoper man page -f (lowercase) is sender -F is name
21:22.05igcewielingthis is what I use: https://paste.nyigc.net/view/7969e7f2
21:22.52joakoThats what I had to do. What I dont understand is why serveremail=noreply@nyigc.net does not accomplish the same result
21:27.46igcewieling*shrug*  I don't care.  It works.
21:29.32joakoExactly, it just took me a while to figure out the hack
22:14.17*** join/#asterisk electronic_eel (~quassel@electroniceel.org)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.