| 00:11.11 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:11.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:39.26 | *** join/#asterisk-dev zhando (~user@c-67-161-122-77.hsd1.wa.comcast.net) |
| 00:42.57 | zhando | why is using sound cards with * so hard? vlc does snd_pcm_open never a problem but * ? |
| 00:52.19 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 00:52.19 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 01:06.08 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 01:10.35 | WIMPy | zhando: This is the wrong channel, but have you tried chan_alsa instead? |
| 01:58.27 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:58.27 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:21.20 | zhando | WIMPy: yes I've used alsa/oss/console and had the most luck with oss but couldn't make it work without chmod 777 /dev/dsp.. That was a bit distasteful to me.. |
| 02:28.05 | zhando | wrong channel huh? ok lets talk development.. can anyone point to some examples of using tools like gdb or strace to debug channel drivers.. hmm.. like oss/alsa/console?? |
| 02:29.47 | zhando | just need pointers to get started... |
| 02:58.00 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:58.00 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 03:01.25 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:01.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:06.12 | zhando | I'll look for my answer at rikers.org |
| 03:06.15 | *** part/#asterisk-dev zhando (~user@c-67-161-122-77.hsd1.wa.comcast.net) |
| 04:56.50 | snuff-work | wedhorn: the fragment patch.. i wouldn't really know if we hit a large pkt.. since u loop on large pkt without any notices |
| 06:05.59 | wedhorn | snuff-work: I think I said you'd need to add a ast_log statement to see if it works |
| 06:06.39 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 06:07.47 | snuff-work | i did the big conversion.. like i said yest.. it passed the 'compile test' |
| 06:08.27 | wedhorn | on 25 jan - maybe you could add a line at the beginning of the do, if (byteread>0) ast_log("Woohoo, saved a session restart") |
| 06:09.26 | snuff-work | mm i wonder if it would be nice to add just a 'notice' or similar saying 'got large skinny pkt' that way i see it in the logs :) |
| 06:11.34 | snuff-work | think this logic is right.. |
| 06:11.44 | snuff-work | <PROTECTED> |
| 06:17.30 | wedhorn | that won't work (from memory). On the first pass through, bytesread will be 0, therefor if it's greater than 0 (at the beginning) it must be the second pass |
| 06:17.34 | wedhorn | or more |
| 06:19.04 | wedhorn | ignore ^^^, bad memory |
| 06:19.14 | snuff-work | mm yer it fail.. bytesread also bad cause its set to res on each pass |
| 06:20.04 | wedhorn | actually, either bytesread>0 or res>0 (seeing as they're equivalent), before the read |
| 06:20.52 | snuff-work | mm.. Got packet fragment res: 1848 frag: 0 |
| 06:21.16 | snuff-work | 1848.. that's larger than mtu.. of 1500.. |
| 06:21.54 | wedhorn | it seems a timing thing, if it has managed to have read and rejoined the second fragment before the read, it will only loop once |
| 06:22.16 | wedhorn | the problem is if it reads before the second packet has been appended |
| 06:22.49 | wedhorn | loop once mean single pass |
| 06:25.00 | snuff-work | mm |
| 06:25.58 | wedhorn | but it's all speculation. It's only an intermittent problem. The device sends that big packet everytime it registers, but occasionally it only seems to be able to read about MTU bytes |
| 06:26.45 | wedhorn | My guess is that on those occasions, the read is called before the second packet is added to the buffer |
| 06:27.01 | snuff-work | mm soo nice to be able to load/unload skinny without it blowing up :) |
| 06:27.29 | wedhorn | actually you should be able to just reset the device |
| 06:28.11 | snuff-work | i needed to recompile skinny to change to if bytesread=0 ;) |
| 06:28.39 | wedhorn | >0 ???? |
| 06:28.57 | snuff-work | also need to fix tab completion for the skinny reset / show device |
| 06:29.02 | snuff-work | yes i mean > 0 :) |
| 06:29.20 | wedhorn | just type it once, then up arrow return |
| 06:29.38 | wedhorn | but yeah, another thing for the todo list |
| 06:30.02 | snuff-work | i think i started on it and did a bad fail.. |
| 06:30.08 | wedhorn | talking of which, think I've found the button template stuff for attaching a service URL to a line button |
| 06:30.30 | wedhorn | so we can attach phone directories to line buttons |
| 06:31.06 | snuff-work | mm that was other thing i noticed when playing with calls today.. |
| 06:31.59 | snuff-work | mm now its not doing it.. |
| 06:32.14 | wedhorn | is confused |
| 06:32.59 | snuff-work | was to do with callinfo stuff |
| 06:34.25 | snuff-work | if i make an outbound call to say a international number.. (my current test) oracle sales.. 0011 1 650 506 7000 |
| 06:34.54 | snuff-work | it changes the callerid on connect to be unknown number |
| 06:36.10 | wedhorn | probably best to do a "skinny debug packet sub" and see where it's setting the number to unknown |
| 06:36.49 | snuff-work | mm |
| 06:39.12 | snuff-work | http://pastebin.ca/2311089 |
| 06:41.53 | wedhorn | does your placed calls log have the number? |
| 06:42.20 | snuff-work | just 'unknown number' |
| 06:43.16 | snuff-work | let me restart * altogether... see if skinny isn't palying ball because i did module load/unloads |
| 06:43.57 | wedhorn | actually, you've got a device alarm about the 14a message |
| 06:44.00 | wedhorn | can't be good |
| 06:44.53 | wedhorn | can you get a tcpdump of the callinfo packets (there seems to be 2 of them) |
| 06:45.17 | wedhorn | line 22 of your pastebin is the alarm |
| 06:46.48 | snuff-work | lookin @ pcap |
| 06:50.11 | snuff-work | mm seems my placed calls isn't even working for my mobile test now |
| 07:07.06 | snuff-work | so my call logging on phone appears broken atm :( |
| 07:07.58 | wedhorn | have you tried restarting everything (including a hard boot of the phones)? |
| 07:09.32 | wedhorn | have you changed firmware? |
| 07:13.22 | wedhorn | nope, still 8.5.4 |
| 07:13.42 | wedhorn | no idea, reboot the phone ... |
| 07:16.58 | snuff-work | it has been few times |
| 07:18.15 | snuff-work | mm.. gotta go.. will do more tests tomorrow.. but not looking good for my cutover now :( |
| 07:36.56 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 08:15.13 | wedhorn | snuff-home: you'll be glad to know I've the same issue with my v17 7961 |
| 08:15.28 | wedhorn | seems that anything over 10 digits throws a wobbly |
| 08:16.26 | wedhorn | you want to get a ccm pcap tomorrow of a number that display >10 digits |
| 08:36.01 | *** join/#asterisk-dev niluje (~niluje@bdv75-4-82-227-67-242.fbx.proxad.net) |
| 09:20.27 | *** join/#asterisk-dev hegars (~hegars@061092248178.ctinets.com) |
| 09:29.55 | *** join/#asterisk-dev hegars (~hegars@061092248178.ctinets.com) |
| 09:43.21 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:43.21 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:52.02 | snuff-home | wedhorn: as a test.. try not setting the toname/fromname on ones > 10 digits |
| 09:56.20 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:9cff:302e:befd:b86c) |
| 09:59.18 | *** join/#asterisk-dev niluje (~niluje@bdv75-4-82-227-67-242.fbx.proxad.net) |
| 11:23.56 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 11:40.01 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 12:01.04 | file | falls over |
| 12:03.02 | Marquis42 | picks file up and brushes him off. |
| 12:03.16 | Marquis42 | We need you to keep working on that fancy new SIP stuff. ;) |
| 12:03.32 | file | I have still not completely recovered from the FOSDEM trip |
| 12:03.58 | Marquis42 | Ah, yeah, overseas travel can do a number on you. |
| 12:09.17 | bulkorok | anybody can help with a segfaulting asterisk?! |
| 12:29.54 | snuff-home | have u got a backtrace? |
| 13:01.18 | bulkorok | obened a jira |
| 13:01.25 | bulkorok | https://issues.asterisk.org/jira/browse/ASTERISK-21041 |
| 13:02.14 | bulkorok | imho it's when receiveing fax via spandsp... but I can't reproduce it... |
| 13:05.35 | leifmadsen | file: you are a robot! back to work! |
| 13:05.48 | file | leifmadsen, go away. |
| 13:06.10 | snuff-home | any1 see my msg about utils.h ? |
| 13:06.31 | snuff-home | mm bulkorok ast_read lookin mighty sad with out of bounds stuff.. |
| 13:06.38 | *** part/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:07.53 | file | snuff-home, nope! |
| 13:08.33 | snuff-home | minor warning i found.. ast_assert() |
| 13:08.55 | snuff-home | should have static force_inline void... but atm has static void force_inline |
| 13:10.49 | file | GCC is forgiving, it'll allow you to throw it anywhere |
| 13:11.03 | file | (if my half asleep brain can be trusted) |
| 13:11.18 | bulkorok | snuff-home: what is telling me that!? |
| 13:11.34 | snuff-home | yes it is.. but it showed as a warning when i compiled with more flags :) |
| 13:12.04 | file | cheeky :P |
| 13:16.08 | snuff-home | its the 'only' 1 with the warning :) |
| 13:18.24 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 13:19.23 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:19.23 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:31.31 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:31.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:38.04 | bulkorok | is opticron still alive here sometimes!? |
| 13:40.49 | opticron | <_< |
| 13:40.50 | opticron | >_> |
| 13:40.56 | opticron | maayyybe |
| 13:40.58 | bulkorok | yeah :-) |
| 13:41.08 | bulkorok | need some goggles i suppose... |
| 13:41.54 | bulkorok | you helped me a while ago with a segfaulting freeswitch with udptl/t38/receivefax... |
| 13:42.03 | opticron | :) |
| 13:42.12 | bulkorok | well.. I have a new one :-/ |
| 13:42.41 | opticron | yay! |
| 13:42.55 | bulkorok | huh... s/freeswitch/asterisk |
| 13:43.47 | bulkorok | do you have some time to investigate?! it's the only one problem that do not let my * boxes be stable... |
| 13:44.05 | bulkorok | ASTERISK-21041 |
| 13:44.09 | opticron | looks |
| 13:44.17 | bulkorok | :-D |
| 13:46.45 | opticron | huh...looks like the same kind of crash as last time |
| 13:47.05 | bulkorok | ew |
| 13:47.37 | bulkorok | but the patch was applied to code afaik |
| 13:48.01 | bulkorok | I'll check that |
| 13:48.20 | opticron | may be a different code path generating the junk frame |
| 13:48.40 | bulkorok | If you say ;-) |
| 13:48.49 | bulkorok | that |
| 13:49.53 | opticron | is this reliably reproducible or is it more of a random one-off kind of thing? |
| 13:50.02 | opticron | where it happens rarely |
| 13:50.07 | bulkorok | random like... |
| 13:50.51 | bulkorok | I wish I could reproduce... |
| 13:54.15 | opticron | commenting on issue |
| 13:54.46 | bulkorok | :-D |
| 13:55.08 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rujltfkzhswujmrj) |
| 13:56.56 | bulkorok | ok... I'll see what I can get... |
| 14:08.25 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 14:14.14 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:14.14 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:00.44 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 15:08.10 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-awanwqkvuinbdguz) |
| 15:08.10 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:26.54 | newtonr | leifmadsen: re: a memo, Channels/chan_motif is already in the components list of JIRA, were you not able to add it to an issue? |
| 15:27.12 | leifmadsen | I didn't see it when I was looking last |
| 15:27.26 | leifmadsen | maybe it wasn't ordered correctly |
| 15:27.30 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 15:27.30 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:27.37 | leifmadsen | (I didn't scroll to the bottom or anything) |
| 15:27.46 | leifmadsen | just didn't happen to see it in the Channels part |
| 15:28.02 | newtonr | cool, i see it in admin, i'll make sure i can add it to an issue |
| 15:28.37 | newtonr | yah its good |
| 15:29.34 | newtonr | chan_jingle2 does need to be removed I believe. I'll see that it is. |
| 15:29.39 | newtonr | leifmadsen: thanks |
| 15:29.54 | leifmadsen | np |
| 15:31.01 | file | yeah... it was the old name |
| 15:32.28 | Kobaz | i really need an individual sip peer reloader |
| 15:32.48 | Kobaz | sip reload with 200+ peers will; make 50% of them go lagged for 30-40 seconds |
| 15:38.53 | pnlarsson | https://issues.asterisk.org/jira/browse/ASTERISK-18923 - refcount error - what can I do more? |
| 15:51.46 | wdoekes | pnlarsson: it seems I'm affected by that |
| 15:52.19 | wdoekes | spandsp in use count 151 since restart 4 hours ago |
| 15:53.07 | pnlarsson | I need the function but hesitant to put it in production |
| 15:54.15 | wdoekes | I don't have any stuck gateway channels though (not using the t38 translation functionality) |
| 15:57.11 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:57.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:59.17 | Kobaz | hwt: and the problem is?..... |
| 15:59.20 | Kobaz | er |
| 16:07.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:07.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:42.19 | seanbright | is there an official recommendation when it comes to hyperthreading and asterisk? |
| 18:46.44 | mjordan | seanbright: not that I'm aware of. I would make the completely unfounded guess that, since we don't do any thread affinity or other particular thread scheduling management, that would depend on the number of threads created on the particular Asterisk system and the Linux kernel support for hyperthreading. |
| 18:47.47 | seanbright | fair enough. i've seen a lot of anecdotal accounts of it being problematic, and just as many saying it's fine. |
| 18:48.08 | mjordan | this is relatively interesting: http://www.ibm.com/developerworks/library/l-htl/ |
| 18:49.26 | seanbright | mmhmm, right, mmhmm... i know some of these words |
| 18:49.33 | seanbright | reads |
| 18:52.03 | mjordan | from the speed up marks, I'd say disk accesses suffer (makes sense, more cache contention); but for systems with lots of thread (Asterisk) you usually do better, since you can do more in parallel. I'd guess that if you're doing a lot of call recording with very few calls, it *might* not be much bang for the buck, but I'd guess that disk write times are going to affect you more than hyperthreading |
| 18:54.29 | seanbright | makes sense to me |
| 18:54.31 | seanbright | thanks |
| 19:10.39 | Juggie | i dont think it should matter one way or the other. |
| 19:11.21 | Juggie | i suppose, if enabled it could possibly slow performance per thread but overall performance should improve you would think |
| 19:11.33 | Juggie | i'd assume the implementation ot HT has gotten better since p4 :) |
| 19:11.36 | Juggie | *of |
| 19:11.52 | Juggie | and by that i mean on the northbridge/southbridge/cpu level. |
| 19:22.01 | snuff-home | wow Juggie is alive :) |
| 19:25.00 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 19:25.00 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 19:56.17 | wedhorn | snuff-home: I use a wildcard dialplan when testing the callinfo stuff. Anything >10 digits caused the issue, anything <=10 was fine |
| 19:57.13 | wedhorn | makes sense because any more than 10 digits starts placing them under the call timer on the display |
| 20:10.09 | *** join/#asterisk-dev w9sh (~w9sh@50-79-224-193-static.hfc.comcastbusiness.net) |
| 20:20.06 | acidfoo | erm, with 1.8.20.1, ast_devstate_changed() has one more parameter ... ? |
| 20:20.14 | file | yes. |
| 20:20.31 | acidfoo | I thought there was only bug fix |
| 20:20.48 | file | if it is unavoidable stuff like that happens |
| 20:21.04 | file | in that case it was a resource exhaustion vulnerability |
| 20:21.05 | acidfoo | when I do |
| 20:21.14 | acidfoo | grep "ast_devstate_changed" * -RHn | grep -v CACHABLE in channels/ |
| 20:21.31 | acidfoo | it returns nothing, which means that _everybody_ use AST_DEVSTATE_CACHABLE, |
| 20:21.43 | acidfoo | why not juste making it by default ? |
| 20:21.56 | acidfoo | I feel like it was avoidable |
| 20:23.20 | acidfoo | correct me if I'm wrong |
| 20:23.21 | file | we could have made a #define that just did that - but forcing developers to think about that behavior is really needed to ensure the issue doesn't occur/reoccur |
| 20:25.09 | acidfoo | I'm not sure anyone thought about it if every channel use the same argument |
| 20:28.07 | opticron | acidfoo, that's going to return nothing forever, it's AST_DEVSTATE_NOT_CACHABLE vs AST_DEVSTATE_CACHABLE |
| 20:28.17 | opticron | both have "CACHABLE" in them |
| 20:28.27 | acidfoo | youre right about that |
| 20:28.50 | acidfoo | I see DAHDI needs it |
| 20:28.56 | opticron | and SIP |
| 20:29.05 | opticron | and locals |
| 20:29.32 | acidfoo | erm, I see DAHDI and SIP |
| 20:29.36 | acidfoo | using AST_DEVSTATE_NOT_CACHABLE |
| 20:29.53 | opticron | for certain channel creations |
| 20:29.59 | acidfoo | I see |
| 20:30.00 | opticron | like SIP guest calls |
| 20:31.04 | acidfoo | good |
| 20:31.23 | acidfoo | and no announce in the ChangeLog about that ? ;/ is it the right place for that kind of announce ? |
| 20:32.41 | file | announce about what - the API changes? |
| 20:33.06 | acidfoo | yup, |
| 20:33.28 | acidfoo | just so I know for the next time :) |
| 20:33.35 | Juggie | snuff-home, i speak once a year... and now i've used up 2014 as well :) |
| 20:34.08 | file | I don't remember how detailed stuff was, that was awhile ago |
| 20:34.49 | acidfoo | well, thank you for the inputs |
| 20:35.01 | acidfoo | I was just curious about all it ;) |
| 20:35.16 | acidfoo | because some of my code has been impacted, just need to update it |
| 20:35.31 | acidfoo | all this* |
| 20:35.39 | file | yeah the commit log just covered the what was happening, why, and how it was fixed |
| 20:35.43 | file | not API level specific, beside the code itself |
| 20:36.31 | acidfoo | do you have the url of that specific commit log ? (thank you) |
| 20:36.44 | file | URL no but the revision was 378303 |
| 20:36.50 | acidfoo | ok ill check that |
| 20:38.04 | acidfoo | ok I see it here |
| 20:38.04 | acidfoo | https://code.asterisk.org/code/changelog/asterisk?cs=378303 |
| 20:53.42 | mjordan | acidfoo: usually, CHANGES is updated for users. They shouldn't notice that this thing even happened. That being said, it probably could have been sent out to -dev when it happened. Usually that would get caught in a code review, but because it was a security vulnerability no e-mails can be sent until the commit |
| 21:30.55 | wedhorn | snuff-work: if you get a chance, can you try a long number on ccm, see what's displayed and get a pcap. I think we probably need 3 fields, displayname, displayno, realno |
| 21:59.27 | mjordan | oh RAII_VAR, what can't you do |
| 22:14.51 | file | my internet is, uh, down |
| 22:14.56 | file | but my IRC remains active |
| 22:15.46 | file | putnopvut, so I'm reading your review comments on my cellphone and making changes lol |
| 22:18.37 | putnopvut | aren't you special |
| 22:27.22 | snuff-work | wedhorn: will do now |
| 22:27.49 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 22:27.49 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 22:31.59 | file | putnopvut, ack re: cheeky pj_thread_is_registered usage |
| 22:32.24 | putnopvut | yar |
| 22:32.49 | file | that thread WILL be registered with pjlib, but may not be a threadpool thread |
| 22:32.50 | putnopvut | file: What about pushing the outbound INVITE transmission as a synchronous task? |
| 22:33.01 | file | fine with that too |
| 22:33.06 | putnopvut | Okay, cool. |
| 22:47.38 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-awanwqkvuinbdguz) |
| 23:02.45 | *** join/#asterisk-dev Corydon76-home (eleven@c-69-137-80-31.hsd1.tn.comcast.net) |
| 23:02.45 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |