IRC log for #asterisk on 20171220

00:18.27*** join/#asterisk TandyUK (~admin@TandyUK/staff/James)
00:34.50*** part/#asterisk kharwell (kharwell@nat/digium/x-usudchstjnyeycws)
00:41.05*** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com)
01:24.06*** join/#asterisk infobot (ibot@rikers.org)
01:24.06*** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.18.4 (2017/12/13), Standard: 15.1.4 (2017/12/13); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu
01:40.36*** join/#asterisk [TK]D-Fender (~joe@64.235.216.2)
01:46.18*** join/#asterisk Perlon (minimalist@2a03:b0c0:0:1010::36:1)
01:47.50*** join/#asterisk zapata (~zapata@2a02:b18:581:10:e866:955e:b53d:4291)
02:08.14*** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail)
02:09.15*** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co)
02:38.30*** join/#asterisk s-mutin (~s-mutin@85.234.114.134)
02:41.04*** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212)
02:57.08*** join/#asterisk robink (~quassel@unaffilated/robink)
03:21.05*** join/#asterisk overyander (~me@209.141.208.197)
03:23.53*** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com)
03:55.33*** join/#asterisk robinak (~quassel@unaffilated/robink)
04:38.39*** join/#asterisk justdave (~dave@unaffiliated/justdave)
04:54.37*** join/#asterisk paulgrmn_ (~paulgrmn@184.75.214.86)
05:05.09*** join/#asterisk nafg (uid214603@gateway/web/irccloud.com/x-dvqwwmjboheywyec)
05:53.27*** join/#asterisk Cory (~Cory@unaffiliated/cory)
06:20.36*** join/#asterisk evilman_work (~evilman@87.244.6.228)
08:12.19*** join/#asterisk tehgooch (~tehgooch@unaffiliated/tehgooch)
08:25.23*** join/#asterisk pchero_work (~pchero@109.70.54.56)
09:06.57*** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru)
09:07.18*** join/#asterisk DanB (~DanB@clt-195.192.205.166.ip-anschluss.net)
09:31.49*** join/#asterisk tzafrir (~tzafrir@local.xorcom.com)
09:33.57*** join/#asterisk DanB (~DanB@clt-195.192.205.166.ip-anschluss.net)
09:47.20*** join/#asterisk sekil (~sekil@nat-73.net011.net)
11:08.37*** join/#asterisk skirmisha (~skirmisha@213.16.62.70)
11:08.41skirmishahi guys
11:08.44*** join/#asterisk Cory (~Cory@unaffiliated/cory)
11:08.50skirmishacan someone give me quick tip
11:09.10skirmishain context i have several ext to dial...
11:10.00skirmishais there a way to define global hangup for all of them when i have them in the list like exten => 100,1,Dial, exten => 200,1 Dial etc...?
11:10.15skirmishai don't want to do hangup for each separately
11:10.19skirmishabut one for all
11:16.12skirmishaguys anyone here?
11:18.30*** join/#asterisk catphish (~charlie@unaffiliated/catphish)
11:18.30skirmishaif i have priority 1 for each ext and then i do regexp with priority 2 will that match the next?
11:19.15sibiriadon't quote me on it, but no, i don't think there's a way to define a global hangup context
11:19.59sibiriapossibly via a hangup handler, though
11:21.53sibiriaif i recall correctly you can specify a context for handlers, meaning you should be able to define a global one as long as you push that handler to every channel you create - but i have no experience with this, so i could be wrong
11:23.53sibiriaoh, i may have misunderstood you - were you asking about having one and the same hangup flow for every extension in ONE context?
11:24.05skirmishayes
11:24.16sibiriabecause that's how it works by default. you define -one- hangup for the context
11:24.21sibirianot one per extension set
11:24.31skirmishacorrect
11:24.34skirmishahttps://wiki.asterisk.org/wiki/display/AST/Contexts%2C+Extensions%2C+and+Priorities
11:24.37sibiriayou don't need to define several
11:24.39skirmishajust saw it here
11:24.59skirmishai did exten => _X.,n,Hangup()
11:25.15skirmishaIt may not be immediately intuitive, but the "_.!" extension with the "n" priority will be executed after any of the preceding lines are executed.
11:25.40*** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com)
11:28.18skirmishai have bunch of ext in the context, but want to define one single hangup for all of them
11:28.29sibiriaas i said, that's how it works by default
11:28.53skirmishayes, but matching is different
11:29.03sibiriawhenever that context is hung up, you will end up in the 'h' extension for that context
11:29.30skirmishabecause ext are like _100, _200, _300 etc... then i have final _X. which should be executed after that priority 2
11:30.02sibiriaand what's the problem? at the end of the entire context, just define your 'h' extension set
11:30.16*** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff)
11:30.34sibiriait doesn't matter *where* in your context you will hang up, you will still be sent to that one 'h' extension on Hangup
11:31.22sibiriaand if you don't want to specify Hangup everywhere, you can make use of auto fallthrough to end up in 'h'
11:31.39sibiria(some caveats apply)
11:31.44skirmishai am not defining exten => h, but rather exten =< _X.
11:32.26sibiriai think there's a language barrier here.
11:32.44skirmishaok let me explain it again
11:33.38skirmishainstead to have exten => 100,1, Dial then exten => 100,2, Hangup i want to make it exten => 100,1 Dial...exten => 200,1, Dial...last exten => X.,2, Hangup
11:34.06skirmishawill hangup be executed after first dial to whatever ext number?
11:35.39sibiriain that case, with the '2' prio there, i'm not really sure. but it's easily tested using a simple flow
11:35.53sibiriawithout thinking too much about it, i would make use of auto fallthrough
11:36.33sibiriawhen the dial plan for this or that extension comes to the end, asterisk will automatically send you to the most appropriate extension - if the call was considered connected, it will be hung up meaning you will end up in 'h'
11:36.44sibiriawithout having to specify a Hangup in some extension
11:38.38skirmishathe h ext does not allow me to modify hangup cause
11:38.46skirmishatested already
11:39.35sibiriahangupcase is a built-in function. you can't write to it
11:39.41skirmishaext h is just to execute the code after hangup
11:39.52skirmishayes you can modify it
11:39.54sibiriahangupcause*
11:40.24skirmishausing ISDN values of it
11:48.30*** join/#asterisk GoldenBear (~GoldenBea@hwsrv-209636.hostwindsdns.com)
11:58.44EmleyMoorI have a problem registering an Android Zoiper to my Asterisk box via IAX. The problem is basically that the phone uses the public IPv4 address of the Asterisk box, but the Asterisk box responds from its private address. There is no intervening router. Is there any way I can stop IAX working on the private address? (I don't actually need it to)
11:59.50sibiriaskirmisha, https://pastebin.com/raw/nx7VujTU works fine
11:59.57sibiriawith the ! matching
12:00.02sibiriaah, they left
12:06.16catphisham i right in thinking that all dns in pjsip is blocking? i'm considering how to resolve problems with DNS causing it to hang
12:07.33EmleyMoorLooks like I may well have fixed it with a bindaddr...
12:09.52*** join/#asterisk hehol (~hehol@gatekeeper.loca.net)
12:11.31*** join/#asterisk mahafyi (~chatzilla@106.201.133.209)
12:11.37sibiriacatphish: resolving a host has to be blocking, there's no way around it. the bigger question is perhaps if pjsip can handle dial plans in parallel
12:11.55sibiriainstead of taking tasks in a FIFO manner
12:12.34sibiriaasterisks threads a lot by default. it shouldn't be a problem if one channel is stalling
12:13.52catphishsibiria: i actually don't actually know what the thread model is like, but it's definitely the case that if enough channels are stalled on DNS, no other SIP packets are processes
12:14.30sibiriahave you tried putting "the most common hosts" in your local hosts file to guarantee fast lookup to see if that confirms the problem?
12:14.54catphishsibiria: yes, and it does
12:15.03sibiriasounds like you're onto the problem then
12:16.01catphishsibiria: the problem that we had specifically was that one of our peers had a dns name somewhere in their SIP packets, asterisk was trying to resolve it, and hanging (because the authoritative DNS for the domain was offline)
12:16.45catphishimmediately returning an NXDOMAIN for that domain resolves the problem, but it made me worry about the wider DoS implication
12:17.07sibiriayeah that definitely sounds like an attack vector
12:17.25catphishif someone accidentally (or worse deliberately) puts a bad domain name into sip requests, it can trivially take down pjsip
12:18.11catphishi don't know the threading model, but i do know that dns lookups block a thread, and it doesn't take many before it runs out (at least in my config)
12:20.39catphishi'm not really sure what the solution would be, maybe an async resolved in pjsip, but that's quite a complication, or a way to prevent unnecessary lookups, but i'm not sure this can be avoided while still allowing things like sip redirects
12:21.39sibiriaa quick look through the pjsip settings doesn't reveal any immediate ways to configure the behavior, not even a timeout setting. it sure seems like a very easy problem to attack by just flooding with doctored hosts
12:21.51sibiriathere's some limit to exactly how large threadpool you want to use, too
12:21.56sibirianot really a solution
12:23.46catphishi wonder if pjsip does have an async resolver in it, there's some google hits for those words
12:24.08catphishbut i don't know enough about it to comment further
12:27.20catphishi do know is that when a major UK SIP provider accidentally started sending SIP responses with a non-existent domain in them, it caused at least 2 people's asterisk installations to stall at regular intervals, unfortunately while i understand the problem, i lack the skill to solve it, issue documented here: https://issues.asterisk.org/jira/browse/ASTERISK-27242 and I believe this was cased by the same issue https://issues.asterisk.org/jira/brow
12:27.20catphishse/ASTERISK-27247
12:29.27catphishanother more concise report, this time with an answer: https://issues.asterisk.org/jira/browse/ASTERISK-20317
12:31.06catphishin fact, searching the issue tracker for "dns" reveals quite a few people talking about DNS lookups hanging chan_sip, where there's no thread pool to mitigate the problem
12:32.14catphishthanks anyway sibiria :)
12:36.32sibiriamaybe easier to try control and mitigare this in the system's resolver. good luck
12:38.36*** join/#asterisk eschmidbauer (~eschmidba@unaffiliated/eschmidbauer)
12:38.54filePJSIP DNS is async
12:38.55eschmidbauergood morning. are there asterisk debian 9 packages available?
12:41.04catphishfile: really? that's pretty interesting then, i wonder why issues were occurring then
12:41.12catphishalso good news
12:41.20filethere is a case where it can still do a blocking DNS query
12:41.32filewhich is if you are using realtime with hostnames in identify configuration
12:41.39sibiriaeschmidbauer: yes, asterisk is in the native debian repo
12:41.50sibiria13.14 currently unless my memory is off
12:41.57catphishi don't really use realtime any more
12:46.12eschmidbaueroh nice.
12:47.24eschmidbauerim going to migrate from 1.6.X version... probably before pjsip was implemented... is chan sip still avail in 13.14 ? will there be a lot of "gotchas" migrating?
12:47.51sibiriaeschmidbauer: it's still available
12:48.06sibiriai personally spent a bit of time getting into pjsip after using chan_sip
12:48.17sibiriaand i didn't really have any advanced configuration going
12:48.51sibiriaif it's worth the time is up to you - chan_sip still works
12:49.11sibiriait's just not getting the same amount of attention these days
12:49.15eschmidbauerok cool
12:49.26eschmidbauerim sure i'll be back w more questions after the actual migration
12:49.53catphishi migrated to 13 last year, and made the decision it was worth moving to pjsip at the same time, i'd recommend doing so
12:52.53*** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co)
12:55.08*** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff)
13:05.56*** join/#asterisk [TK]D-Fender (~joe@216.191.106.165)
13:13.01Kobazanyone know any carriers that have https fax (via audiocodes fax ata) other than vitelity ?
13:33.44*** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com)
13:38.28*** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772)
13:42.31*** join/#asterisk brad_mssw (~brad@66.129.88.50)
14:07.49Kobazheh, migrate from 1.6
14:07.51Kobazwe're on 1.8
14:08.07Kobazi had to move a customer back to 1.8 from 11 yesterday due to timing issues in chan_sip
14:08.21Kobazactually that's two customers i had to move to 1.8 from 11 this week
14:09.37*** join/#asterisk nighty- (~nighty@s229123.ppp.asahi-net.or.jp)
14:12.16[TK]D-Fendermeanwhile we're at * 15
14:12.25[TK]D-Fender#antideluvian
14:12.45Kobazright
14:13.03Kobazthat's like when pbxinaflash or whatever it was, was on 1.2 and 1.6 was out
14:13.19Kobazi reaaaaly want to migrate to 15 badly
14:13.38Kobazi need to add so much to my testing suite to make sure stuff wont break catistrophicly
14:13.52Kobazi had *though* that 1.8 -> 11 would be a fairly clean move
14:14.02Kobazbut there's just subtle differences that cause problems
14:14.27Kobazif you have straight up extensions.conf... phone A calls phone B and goes to voicemail
14:14.35Kobazsure, just drop in the latest asterisk whenever possible, you're probably fine
14:15.15Kobazbut when you have an entire platform, AGI, AMI, and tracking of transfers and masquerades and all that shenanigans, it's not so pretty to do upgrades
14:17.09Samot8:12:59 AM K<Kobaz> anyone know any carriers that have https fax (via audiocodes fax ata) other than vitelity ? <-- There's no such thing has a AudioCodes "FAX" ATA.
14:17.16Kobazyes there is
14:17.21SamotThey use the MP-202 which is just an ATA.
14:17.27Kobazhttp://faxata.com/
14:17.30Kobazright
14:17.41Kobazit's an ata that does t38 to a proxy
14:17.54Kobazhttps to the far-end, which then dumps it to a real fax machine
14:18.06SamotIt's an ATA
14:18.09Kobazright
14:18.16Kobazwith HTTPS for faxing transport
14:18.17SamotYou know that a Cisco SPA1x2 does this too?
14:18.24KobazNo, i did not
14:18.29SamotIt's TLS  with t.38 support
14:18.32SamotIt's not special
14:18.34Kobazthis is why I'm asking questions
14:18.35SamotIt's a common option.
14:18.54Kobazi really never got into faxing
14:19.05Samot1) It will require the provider to support TLS.
14:19.08Kobazother than plugging a fax into an FXS and it mostly works
14:19.16Kobazand when it doesn't.. it's bad
14:19.37Kobazgood to know that the audiocodes isn't anything special
14:19.52Kobazfrom the "papers" it sounds like they invented a new protocol
14:19.58SamotNo.
14:20.04KobazIf it's t.38 the whole way, that makes more sense
14:20.05SamotIt's SIP over TLS
14:20.09SamotWith t.38 support.
14:20.24SamotT.38 is just an encapsulation method.
14:20.28Kobazright
14:20.31Kobazsoooo, knowing that... back to the origial question
14:20.43SamotFirst the provider needs to support TLS
14:20.50SamotSecond they need to support T.38
14:20.51Kobazwith modification.... what providers have a nifty fax portal, and do TLS t.38
14:21.13Kobazbusiness partner of mine does vitelity vfax for everything
14:21.13SamotYou're going to have to do research on that.
14:21.19Kobazbut, meh, their setup is a bit, meh
14:21.41KobazSamot: that's what I'm doing... research via community participation
14:21.57SamotWhat you are looking for is specific.
14:22.04Kobazright
14:22.09SamotIt would require people to have specifically asked for that service from their carrier.
14:22.14SamotNot all carriers do this
14:22.17Kobazright
14:22.26SamotNot all carriers that support T.38/TLS have digital FAX platforms
14:22.32SamotThe platform, itself, is a feature.
14:22.35Kobazwhich is why if someone else was here, one of the 190 other people idling here... used a fax portal, they might chime in here
14:23.16Kobazi'm not sure why we're arguing over the merits of polling #asterisk to see if someone used something similar... i think it's a proper venue for the question... people ask about ITSP's all the time
14:23.28SamotDigital FAX Platforms are more specific.
14:23.35SamotBecause they generally don't involve Asterisk
14:23.52SamotAnd not all support "FAX Gateways" with their service.
14:23.56Kobazright
14:23.57Kobazof course
14:24.06Kobazi'm not making any assumptions to that effect
14:24.17SamotWell RingCentral has a Digital FAX platform..
14:24.24SamotNo analog device support.
14:24.34Kobazgood to know
14:24.49SamotDigital FAX is generally a stand alone service
14:24.55Kobazright
14:24.57Kobazi know all this
14:25.02SamotOr a bundled service for Hosted Voice.
14:25.21SamotYou may have to look at Digital FAX providers.
14:25.36SamotThose are ones that generally have their own platform because it's the only thing they do.
14:25.44Kobazyeah
14:26.25Kobazwho knows, after i finish 2017 projects, we may just develop our own
14:27.29Kobazi've thought about that for a while
14:27.43Kobazi wrote a proof of concept store and forward with asterisk 11 using t.38 over the summer
14:28.10Kobazit wouldn't be that much more of a chore to throw a gui on it and then progam t.38 atas to send out
14:28.42*** join/#asterisk jkroon (~jkroon@165.16.204.170)
14:32.08SamotWell a Digital FAX platform generally has Fax to Email and Email to Fax
14:32.16Kobazyeah
14:32.31Kobazamong other things
14:32.31SamotSo you would need some sort of email server running SMTP with POP/IMAP
14:32.43SamotNeed to be able to take attachments and process them
14:32.46Kobazyeap
14:32.56Kobazwe already run email internally
14:33.01Kobazwouldn't be a big deal
14:33.02SamotOK.
14:33.09SamotSo now you need to process incoming email.
14:33.14Kobazright
14:33.15SamotTear it apart..
14:33.23Kobazyeah i have support for all that
14:33.24SamotConvert the attachments and then stream them out
14:33.27SamotOK.
14:33.36Kobazwe already do email processing for system alerts and whatnot
14:33.43Kobazsend attachments, receive attachments
14:33.54Kobazit's really just putting a different spin on what we already have
14:54.56*** join/#asterisk kharwell (kharwell@nat/digium/x-ndfdkoplzgaiddac)
14:54.56*** mode/#asterisk [+o kharwell] by ChanServ
15:02.32*** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
15:02.32*** mode/#asterisk [+o cresl1n] by ChanServ
15:07.56*** join/#asterisk IzzyG (~IzzyG@108.41.159.2)
15:16.34*** join/#asterisk IzzyG (~IzzyG@108.41.159.2)
15:22.36tehgoochI think snom's redirection service may be compromised somehow. Some Chinese and Italian IPs accessed our provisioning server and immediately downloaded config files for phones that were in the redirection service. Soon after Chinese and Italian IPs were registered to those extensions and making international calls.
15:23.21tehgoochStill investigating the issue at this point, but that's what it seems like at face value.
15:24.45*** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1)
15:24.46*** mode/#asterisk [+o bford] by ChanServ
15:25.19Kobaztehgooch: ACLs
15:25.33Kobaztehgooch: for customers on static ips, it's an easy thing to do
15:25.48tehgoochUnfortunately almost none of our customers have static IPs.
15:26.09tehgoochI have been pushing to get them on them, but apparently that is a waste of money.
15:26.12*** part/#asterisk catphish (~charlie@unaffiliated/catphish)
15:26.27Kobazfor dynamic it's a bit more complicated
15:26.54Kobazwe maintain whitelists based on succssful registrations, and then lock it down after the customer is initially set up
15:27.14Kobazwe have at least one phone in the office set up with an idle url, which is basically a form of port knocking
15:27.19*** join/#asterisk zaf (~zaf@104.254.192.70)
15:27.39Kobazso it refreshes a system status page which continually checks the ip and sees if it needs to get added to the whitelist
15:27.56Kobazand then dynamically adjusts the ACLs
15:27.58tehgoochKobaz, all good ideas, but unfortunately we don't have time to implement them currently. :(
15:28.17Kobazso everyone in china and russia could download all the configs they want
15:28.52tehgoochyep, i've reported the risks, but it's been deemed to be lower priority
15:29.07*** join/#asterisk rmudgett (rmudgett@nat/digium/x-bfhuuzqebnzbplah)
15:29.08*** mode/#asterisk [+o rmudgett] by ChanServ
15:29.21Kobaza business partner of mine who has another company... one of his customers was getting pwned almost every week
15:29.27Kobazchange provision passwords, change sip credentials
15:29.34Kobaza few days later the phone's making high rate calls
15:29.45Kobazi helped him block all the high rate destinations and set channel limits
15:29.51tehgoochHonestly it hasn't been an issue up until now, so maybe this will change upper management's mind.
15:30.06Kobazbut there's something living on the customer network that's actually logging into the polycoms and grabbing credentials from phone's directly
15:30.58tehgoochWelp I have to get ready to go into the office. Luckily I was awake and noticed the alerts.
15:32.37Kobazapparently that's a thing... did a ton of research to find that one
15:32.59Kobazmalware will force a polycom to downgrade the firmware back to a version that shows credentials in plain
15:33.17Kobazand then it grabs the login and starts making calls
15:34.00*** join/#asterisk alejandrozf (c9ebb376@gateway/web/freenode/ip.201.235.179.118)
15:37.16SamotSNOM's redirection server is probably not compromised.
15:37.22IzzyGkobaz: haveyou seen such malware? where would it live? on a PC? or on a Polycom Phone ?
15:37.31SamotSince those services go "Oh this MAC belongs to X and should go here"
15:37.34KobazIzzyG: on a pc
15:38.21SamotIzzyG: The only way to force a firmware change is either via the GUI of the phone or the config files the phone uses.
15:38.38SamotSo if it's on the PC I'm not sure how that would impact the phone.
15:38.57SamotUnless the PC was compromised, they figured out what IP the phone was on and then got to the phone GUI.
15:39.12Kobazright, i'm talking about compromised machines
15:39.13IzzyGi have not heard of such malware in the past. in our deployments, majority of the time the phones are on a different network then the PC's..
15:39.33Kobazrogue dhcp... etc... you can do all kinds of crap to steal credentials
15:39.33SamotKobaz: That's a serious compromise.
15:39.49*** part/#asterisk alejandrozf (c9ebb376@gateway/web/freenode/ip.201.235.179.118)
15:39.52SamotBecause they are now getting the phone's IP and GUI somehow?
15:40.03SamotBy having a PC compromised.
15:40.06KobazSamot: that's SUPER easy on a flat network
15:40.06Kobazright
15:40.17Kobaznmap will show you ip phones within seconds
15:40.19SamotHow do they access the phone?
15:40.28SamotThrough the PC?
15:40.34SamotThrough the network?
15:40.38Kobazrogue dhcp, phone reboots, grabs new firmware
15:40.48SamotFrom?
15:40.51Kobaz"new" ie "old"
15:40.53SamotThat's now how those phones work.
15:41.01Samotnot
15:41.11Kobazdepends on the phones
15:41.28SamotOK. So via the Polycom GUI..
15:41.35SamotYou must first select where you want to get the firmware from..
15:41.39SamotThen it makes a request
15:41.44Kobazright
15:41.47SamotShows you a list of firmware to choose from.
15:41.55SamotSo how is a rogue DHCP server forcing this?
15:42.01Kobazpushing new provisioning
15:42.06SamotHOW?
15:42.13Kobazumm... option 66
15:42.17Kobazlike everyone else
15:42.20SamotOK.
15:42.23SamotSo they got into a PC
15:42.30SamotThen got into the DHCP server.
15:42.39Kobaznot necessarily 'the' dhcp server
15:42.45Kobazhence, rogue
15:42.50*** join/#asterisk pkx2 (~pkx@unaffiliated/pkx)
15:43.04Kobaza flat, unmanaged network, is *very* succeptable to all kinds of attacks like this
15:45.17Kobazif you have the bareist of minimum management, ie, dhcp snooping.  Voice vlans.  Most of this goes away
15:45.17*** join/#asterisk salviadud (~salviadud@201.163.226.6)
15:45.19SamotOK.
15:45.37SamotSo somehow people never noticed their phones reboot and their layouts looking completely different.
15:46.24Kobazi know you're paying devils advocate, but end-users are generally ill-prepared to notice anything
15:46.34Kobazmost setups are 'standard'
15:46.48Kobazout of the box sip.cfg, and the phone looks like any other phone
15:47.13Kobazyou may customize the heck out of your setups, but not everyone does
15:48.29Samot10:30:04 AM K<Kobaz> but there's something living on the customer network that's actually logging into the polycoms and grabbing credentials from phone's directly <-- For this statement to be true it would not be "Option 66" or a "Rogue DHCP" they are logging into the phone. Which is what my questioning was based on.
15:48.50SamotWhich then begs the question "Did they change the default user/admin passwords?"
15:49.04SamotBecause you said provisioning passwords and SIP creds were changed..
15:49.14Kobazright
15:49.18SamotNothing about the phones actual security...
15:50.32Kobazi don't recall that detail of the incident... it may have been default admin credentials
15:53.27Kobazi don't know how exactly what/where/when/why of the stealing credentials
15:53.52Kobazbut i'm throwing out items that are directly related and likly avenues for the attack
15:54.15Kobazbasically putting in a new router, re-imaging local pcs and changing EVERY password was what finally resolved the issue
15:54.26KobazSOMETHING was compromised on the local network
15:54.42Kobazat that point, very little on the lan was trustworthy
16:02.05*** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1)
16:02.05*** mode/#asterisk [+o bford] by adams.freenode.net
16:45.23*** join/#asterisk tafa2 (~tafa2@t.ldn.dsrtnet.com)
16:50.42*** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff)
17:32.43*** join/#asterisk pchero (~pchero@109.70.54.56)
17:33.52*** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood)
17:45.08*** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye)
17:47.57*** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net)
17:52.37*** join/#asterisk Demon_VoIP (~demon@109.60.222.253)
17:54.28*** join/#asterisk paulgrmn_ (~paulgrmn@184.75.214.86)
17:54.39Demon_VoIPasterisk 15.1.4. pjsip_realtime. Error: res_pjsip_outbound_registration.c: Invalid outbound proxy URI 'lr' specified on outbound registration
17:54.56Demon_VoIPvalue, for example: sip:195.239.174.100;lr    What's wrong?
17:55.44Demon_VoIPand the same: config_options.c: Error parsing contact=transport=TLS at line 0 of
17:56.46*** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff)
17:57.55*** join/#asterisk mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak)
17:58.14Demon_VoIPfile wrote it is correct value: https://community.asterisk.org/t/pjsip-anonymous-endpoint-dialing-via-proxy/65857/7
17:58.32fileyou need a \ in frnt
17:58.33fileer front
17:58.40Demon_VoIPit is realtime
17:58.45Demon_VoIPnot config file
17:59.00filedo you have ^3B in front?
17:59.02Demon_VoIPconfig file i use \;lr of course
17:59.32Demon_VoIPfile, do i need write \; in db field value (realtime)?
17:59.43filein realtime you put ^3Blr
18:00.00Demon_VoIPthanks. i'll try
18:00.41Demon_VoIPi test realtime to avoid hangs :( But.. i afraid it'will not help me
18:02.02Demon_VoIPi guess the reason of hangs is pjsip reload (offten). But... My first try of realtime hanged task processors after 10 secs
18:05.05*** join/#asterisk sekil (~sekil@cable-89-216-223-209.dynamic.sbb.rs)
18:08.45*** join/#asterisk miralin (~Thunderbi@81.177.59.227)
18:10.43*** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net)
18:17.10*** join/#asterisk sekil (~sekil@cable-89-216-223-209.dynamic.sbb.rs)
18:18.53*** join/#asterisk jamesaxl (~James_Axl@109.172.62.242)
18:31.21*** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff)
18:52.45Demon_VoIPrealtime doesn't live :( It hangs task processors during 10 secs after start. three tries, three hangs. No hop.
18:59.34Demon_VoIPfile, I and thousands of users of my free service with the hope of closing ASTERISK-26806. I am ready to try the fixes because there is nothing to lose.
19:02.04*** join/#asterisk evil_gordita (robert@70.188.41.127)
19:03.38fileI'm working on it in my spare time. When im confident I'll put it up.
19:03.51fileNo guarantee it will help your usage.
19:04.28Demon_VoIPI'm afraid that won't help. But I hope
19:18.39*** join/#asterisk robink (~quassel@unaffilated/robink)
19:24.00fileI uploaded the 13 patch.
19:30.15*** join/#asterisk kasanop (uid270352@gateway/web/irccloud.com/x-avsqzcycagynuqzd)
19:34.08Demon_VoIPfile, asterisk 13? I am using 15. Are they compatible?
19:34.36fileI doubt it
19:35.38Demon_VoIPSo, I'm willing to test, but apparently can't do
19:36.53Demon_VoIPAnd judging by the size of the patch, it is not so simple to port my powers.
19:44.05fileit's a complete rewrite of OPTIONS support.
19:49.57cresl1nsings the OPTIONS song
20:02.11*** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com)
20:41.25*** join/#asterisk wonderworld (~ww@ip-88-152-174-32.hsi03.unitymediagroup.de)
20:42.20wonderworldi have got an extension that sometimes dials a local extension. will the local extension inherit the variables i set in the original extension?
20:51.32*** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff)
21:43.53*** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood)
21:53.37*** join/#asterisk retentiveboy (~retentive@c-73-82-30-193.hsd1.ga.comcast.net)
22:13.06*** join/#asterisk retentiveboy (~retentive@c-73-82-30-193.hsd1.ga.comcast.net)
22:14.04*** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772)

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