| 00:03.40 | rmudgett | gtjoseph_: Well making the output "pretty" wasn't too difficult. |
| 00:03.57 | gtjoseph_ | excellent |
| 00:09.30 | rmudgett | Reviews refreshed. I also responded to your comment on https://gerrit.asterisk.org/#/c/4767/ |
| 00:09.41 | gtjoseph_ | kk |
| 04:20.01 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:801b:716c:44a4:a88f:6b22) |
| 04:20.02 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:53.43 | *** join/#asterisk-dev jkroon (~jkroon@154.73.35.201) |
| 06:15.41 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:15.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:39.29 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0055dc2b67b833cdbc.ipv6.abo.wanadoo.fr) |
| 07:13.24 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:16.11 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:16.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:50.28 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:02.59 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:04.43 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::c96) |
| 08:16.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:45.56 | *** join/#asterisk-dev tuxian_ (~tuxian@igilmour.plus.com) |
| 09:34.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:34.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:06.28 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:22.51 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 10:26.19 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 13:19.38 | *** join/#asterisk-dev oej (~oej@host-95-195-218-190.mobileonline.telia.com) |
| 13:19.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:52.11 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ozneudjyccyzghel) |
| 13:52.11 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:59.42 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 14:04.46 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:04.46 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:18.06 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-uufkufimmolxrxbn) |
| 14:18.06 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:32.56 | gtjoseph_ | @tzafrir: are your test_voicemail patches applicable to 13 and 14 as well as master? |
| 14:33.15 | tzafrir | I didn't have the time to test them yet |
| 14:33.41 | tzafrir | I suppose they should, as IIRC I had no problem appying them from master to 13 |
| 14:33.57 | gtjoseph_ | ok. i'll cherry-pick them for you |
| 14:58.46 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 15:20.53 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 15:32.32 | *** join/#asterisk-dev oej (~oej@194.15.212.5) |
| 15:32.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:37.31 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-omuhuyaseyoyngvu) |
| 15:37.31 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:47.47 | *** join/#asterisk-dev oej (~oej@194.15.212.5) |
| 15:47.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:50.10 | *** join/#asterisk-dev oej (~oej@194.15.212.5) |
| 15:50.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:40.24 | *** join/#asterisk-dev oej (~oej@95.209.28.124.bredband.tre.se) |
| 16:40.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:32.09 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-nxpjbmdbeqybaqll) |
| 17:32.09 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:39.35 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 17:39.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:56.04 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 18:29.10 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 18:29.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:23.14 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 19:24.32 | *** join/#asterisk-dev klow (~klow@66.114.139.162) |
| 19:43.00 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0001783136c2460e58.ipv6.abo.wanadoo.fr) |
| 19:43.59 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:43.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 20:50.17 | putnopvut | gtjoseph_: so after looking at things for a while, the idea of being able to reload a single registration from AMI is not going to be simple. Sorcery has a function that lets me reload all objects under sip_sorcery. It also has a function that lets me reload all registrations under sip_sorcery. But it doesn't have a function that lets me reload a registration under sip_sorcery with a specific ID. |
| 20:51.07 | gtjoseph_ | hmmm |
| 20:51.12 | putnopvut | I can certainly make an AMI command that will reload all registrations. But that would be no different from just issuing an AMI Reload of res_pjsip_outbound_registration.so |
| 20:51.47 | putnopvut | If you assume realtime usage, I can do a sorcery retrieve of an object by ID, and it would get applied. However, if using config files, that doesn't work. |
| 20:52.14 | gtjoseph_ | not worried about config files |
| 20:52.35 | gtjoseph_ | realtime only |
| 20:53.12 | gtjoseph_ | does doing a retrieve with caching trigger the apply? |
| 20:55.50 | gtjoseph_ | @putnopvut: ^^ |
| 20:56.16 | putnopvut | Nah, you'd need to invalidate the cache entry first. |
| 20:56.47 | gtjoseph_ | ok so the ami command could do just that |
| 20:56.50 | putnopvut | After expiring the cache entry, you could then do a retrieve, and you'd grab from the DB and cache the new registration |
| 20:57.07 | putnopvut | clarify "just that" |
| 20:57.30 | cresl1n | So, question to all |
| 20:57.34 | gtjoseph_ | what you just said |
| 20:57.43 | cresl1n | Especially those with some crypto experience |
| 20:58.57 | file | this is a trap |
| 20:59.17 | cresl1n | correct |
| 20:59.50 | cresl1n | When using md5 hashed passwords with PJSIP, since you essentially salt the password with the authentication realm anyways, is an additional salting at the storage layer really going to add significant additional value? |
| 21:00.28 | cresl1n | to construct an md5 hashed password you md5sum a string constructed as follows: |
| 21:00.56 | cresl1n | "username:realm:password" |
| 21:01.24 | rmudgett | :P |
| 21:01.29 | cresl1n | waits for it |
| 21:03.01 | cresl1n | thinks some more about it |
| 21:03.31 | gtjoseph_ | there has to be enough information in the db to recreate the hash |
| 21:03.38 | cresl1n | yeah |
| 21:04.45 | cresl1n | so what am I missing? |
| 21:04.46 | gtjoseph_ | so we know the username and realm from the authenticate header right? |
| 21:04.53 | cresl1n | yes |
| 21:05.15 | gtjoseph_ | thinks |
| 21:05.45 | cresl1n | ponders |
| 21:06.09 | gtjoseph_ | hmmm. i'm not sure it's going to work at all |
| 21:06.24 | cresl1n | that's what I was wondering too |
| 21:07.06 | putnopvut | gtjoseph_: Back on my thing, I said a few things. I said that 1) I can make an AMI command that reloads all registrations. 2) I can do a sorcery retrieve by object ID, and hope for the best. 3) something about invalidating a cache entry (I think you can actually do this already in AMI though). Which of those three were you saying to do? |
| 21:07.07 | cresl1n | I started to create an issue to add salting support at the storage layer, and I couldn't figure out if that would even be possible |
| 21:07.16 | gtjoseph_ | usually in the hashing case, the "server" gets a plain text password over a secure channel, then hashes it with the salt stored in the db |
| 21:07.53 | cresl1n | yeah |
| 21:07.58 | gtjoseph_ | @putnopvut: the last. a single command that invalidates the cache then does a retrieve to re-apply it |
| 21:08.20 | gtjoseph_ | @cresl1n: then the server compares the resulting hash with the has stored in the db |
| 21:08.23 | putnopvut | Ah, okay. So this would live in the sorcery memory cache, then, rather than some place else. That seems pretty simple. |
| 21:08.35 | putnopvut | I'll take a look. |
| 21:08.38 | gtjoseph_ | BUT... |
| 21:09.05 | gtjoseph_ | we still have to tell registration and options no? |
| 21:09.12 | cresl1n | tell them what? |
| 21:09.13 | gtjoseph_ | they have internal containers |
| 21:09.16 | putnopvut | We shouldn't have to because of sorcery observers |
| 21:09.23 | cresl1n | oh sorry, wrong discussion :-) |
| 21:09.23 | gtjoseph_ | ah |
| 21:09.31 | putnopvut | I, of course, will test :) |
| 21:09.42 | gtjoseph_ | :) |
| 21:09.48 | gtjoseph_ | cresl1n: back to this... |
| 21:10.10 | gtjoseph_ | if we get a hashed pw over an unsecure channel, how does that help us? |
| 21:10.43 | cresl1n | From a SIP auth perspective? |
| 21:10.47 | gtjoseph_ | yeah |
| 21:10.51 | cresl1n | or prior to the point where SIP auth occurs |
| 21:25.46 | seanbright | match=192.168.10.0/24 is valid for a pjsip ip identify correct? |
| 21:26.17 | file | yes |
| 21:26.34 | seanbright | k |
| 21:26.55 | seanbright | may or may not be broken in 13 |
| 21:27.17 | file | 13 git? |
| 21:27.22 | seanbright | yeah |
| 21:27.24 | seanbright | actually |
| 21:27.26 | seanbright | might just be on a reload |
| 21:28.09 | gtjoseph_ | seanbright: realtime or config files? |
| 21:28.12 | seanbright | config files |
| 21:28.16 | seanbright | barfs on reload |
| 21:28.23 | file | pjsip show identify show anything of note? |
| 21:28.54 | seanbright | if i have 'match=192.168.10.0/24' in pjsip.conf on asterisk start, it works |
| 21:29.11 | seanbright | if i add to it/change it after the fact, 'module reload res_pjsip.so' fails |
| 21:29.18 | file | saying what? |
| 21:29.46 | seanbright | res_pjsip_endpoint_identifier_ip.c:260 ip_identify_match_handler: Failed to add address '192.168.10.1/24' to ip endpoint identifier 'file-is-awesome' |
| 21:29.57 | file | interesting |
| 21:29.59 | gtjoseph_ | HAHAHA! |
| 21:30.38 | seanbright | config_options.c:738 aco_process_var: Error parsing match=192.168.10.1/24 at line 15 of |
| 21:30.54 | seanbright | and there is no filename |
| 21:31.31 | gtjoseph_ | well, 192.168.10.1/24 isn't really valid |
| 21:31.38 | seanbright | sure it is |
| 21:31.38 | gtjoseph_ | for a mactch |
| 21:31.47 | seanbright | the .1 should be ignored |
| 21:31.54 | seanbright | but either way it fails |
| 21:31.58 | seanbright | i'll test with .0 to make you happy |
| 21:32.33 | file | what's further interesting is that I can't reproduce it |
| 21:32.45 | seanbright | agreed |
| 21:32.46 | gtjoseph_ | i can |
| 21:32.49 | seanbright | YESHHHHHH |
| 21:32.52 | file | yay |
| 21:33.05 | seanbright | yay for reproduction, amirite? |
| 21:33.07 | gtjoseph_ | res_pjsip_endpoint_identifier_ip.c:255 ip_identify_match_handler: Failed to add address '192.168.10.0/24' to ip endpoint identifier 'voipms' |
| 21:33.21 | file | gtjoseph_: now... why? |
| 21:33.29 | gtjoseph_ | yeah that's weird |
| 21:33.41 | gtjoseph_ | that was git-14 |
| 21:33.56 | seanbright | i doubt it matters, but i am using bundled pjsip |
| 21:34.19 | file | I did git-13 myself |
| 21:34.53 | seanbright | i'm running git-13 from a few hours ago |
| 21:34.55 | seanbright | on xenial |
| 21:35.51 | file | ponders |
| 21:36.06 | file | I wonder if error isn't set to 0 by default |
| 21:36.35 | gtjoseph_ | actually it won't take any CIDR notation |
| 21:38.10 | seanbright | or netmask |
| 21:38.13 | file | set error to 0... before called ast_append_ha |
| 21:38.17 | file | er before calling |
| 21:38.25 | seanbright | UB ftw |
| 21:38.59 | file | my faultttttt |
| 21:40.09 | gtjoseph_ | recent change? |
| 21:40.15 | file | yes |
| 21:40.16 | seanbright | yesterdcay |
| 21:40.20 | gtjoseph_ | ah! |
| 21:40.21 | file | before that actually |
| 21:40.23 | seanbright | s/cay/ay/ |
| 21:40.39 | seanbright | either way - thanks guys! |
| 21:41.41 | file | change up for review |
| 21:41.43 | file | now dinner time |
| 22:12.44 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 22:12.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:27.02 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:27.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:30.08 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ovkkrfyfqzdllint) |
| 22:30.08 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |