| 00:07.08 | *** join/#asterisk-dev moy (n=moy@CPE001d7260250c-CM00140454d33e.cpe.net.cable.rogers.com) |
| 00:35.38 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:35.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 00:42.26 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 00:42.26 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 00:50.13 | *** join/#asterisk-dev denon (i=denon@sassinak.net) |
| 01:01.56 | *** join/#asterisk-dev khratos (n=jespinal@190.80.200.56) |
| 02:19.20 | *** join/#asterisk-dev xpot-mobile (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 02:30.44 | *** join/#asterisk-dev moy (n=moy@CPE001d7260250c-CM00140454d33e.cpe.net.cable.rogers.com) |
| 03:37.06 | *** part/#asterisk-dev khratos (n=jespinal@190.80.200.56) |
| 05:54.41 | *** join/#asterisk-dev jtodd (i=flq7nvp4@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 05:54.41 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 05:58.27 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 06:30.52 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 06:41.09 | *** join/#asterisk-dev fiddur (n=fiddur@192.121.104.118) |
| 07:29.27 | *** join/#asterisk-dev jozza (n=chatzill@89-212-75-91.static.t-2.net) |
| 07:31.11 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:08.59 | *** join/#asterisk-dev Congzing (n=Congzing@125.235.3.158) |
| 08:18.20 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 08:18.20 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:25.33 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 09:25.33 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:12.02 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) |
| 11:40.49 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:40.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:55.43 | *** join/#asterisk-dev pyite_mac_ (n=dschreib@unaffiliated/pyite) |
| 12:34.22 | atis_work | is f->data for ast_frame necessary to be valid if f->datalen = 0? |
| 12:37.39 | kpfleming | well, technically no, but i suspect there are places in the code that don't check datalen before testing data for non-NULL |
| 12:38.02 | kpfleming | wait, that's not true |
| 12:38.18 | kpfleming | there are tons of places where we create frames with data==NULL and datalen==0, so it should be fine |
| 12:38.28 | atis_work | kpfleming: i've found one in ast_local_moh_start |
| 12:38.41 | atis_work | ast_frame->data points to out of bounds |
| 12:38.44 | atis_work | and datalen is 0 |
| 12:38.52 | kpfleming | where did the frame come from? |
| 12:39.06 | atis_work | i have no ide how to check that |
| 12:39.12 | atis_work | *idea |
| 12:39.12 | kpfleming | frame->src |
| 12:39.27 | atis_work | 0x0 |
| 12:39.34 | kpfleming | ugh |
| 12:41.28 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 12:42.59 | atis_work | i guess it's some HOLD frame, as it tried to trigger music_on_hold |
| 12:43.21 | kpfleming | what is the frame->type and ->subclass |
| 12:43.30 | atis_work | subclass = 16 |
| 12:43.44 | atis_work | no type |
| 12:43.52 | atis_work | 1.6.1.6 |
| 12:44.04 | kpfleming | yes, that's AST_CONTROL_HOLD |
| 12:44.16 | kpfleming | sorry, ->frametype |
| 12:44.34 | kpfleming | should be 4 |
| 12:46.15 | kpfleming | so that means something generated that frame without properly initializing it |
| 12:49.58 | atis_work | AST_FRAME_CONTROL |
| 12:50.55 | atis_work | so, i should look for something that generates AST_FRAME_CONTROL and sets ->datalen = 0 but doesn't initialize ->data.ptr |
| 12:51.42 | atis_work | or just put a check for ->datalen=0 before checking ->data.ptr in local_ast_moh_start |
| 12:55.18 | atis_work | i just wanted to know if it's bad to generate such frame or not check datalen before accessing data |
| 13:05.39 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 13:15.11 | kaii | there's so much interesting code located in the asterisk/team SVN .. pity most of the branches do not have a README-something that describes the purpose of the branch |
| 13:41.28 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:41.28 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:49.40 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:49.40 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:11.35 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:11.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:17.29 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:21.14 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:21.14 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:24.31 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:24.31 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:26.32 | *** part/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:31.11 | *** join/#asterisk-dev ebroad (n=EB@72.11.213.195) |
| 14:35.29 | atis_work | kpfleming: i created an issue for that frame: 16058 |
| 14:37.19 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:37.19 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:40.12 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:40.13 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:52.36 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:52.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:58.16 | *** join/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-ashaeqpqlywdhwmf) |
| 15:07.40 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:07.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:09.51 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 15:26.22 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:30.08 | *** join/#asterisk-dev atis_home (n=atis@193.238.213.215) |
| 15:32.28 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:32.28 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:15.47 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:30.24 | *** join/#asterisk-dev jetsnoc (n=brian@72.22.242.66) |
| 16:41.20 | *** join/#asterisk-dev xpot-mobile (n=james@173.8.94.1) |
| 17:20.40 | jpeeler | sruffell: for 14031 do you remember what you set up was to cause the issue? |
| 17:21.11 | jpeeler | M14031 |
| 17:21.14 | MuffinMan | [confirmed] [Asterisk] Channels/chan_dahdi 0014031: [patch] "pri_find_dchan: No D-channels available!" error on console when using wcb4xxp reported by sruffell (Karma: neutral) https://issues.asterisk.org/view.php?id=14031 |
| 17:23.17 | sruffell | looks... |
| 17:24.16 | sruffell | that was from a customer connected to france telecom I believe. |
| 17:39.04 | tzafrir_laptop | M16060 |
| 17:39.06 | MuffinMan | [new] [DAHDI-linux] dahdi (the module) 0016060: [patch] RX RBS signalling not reset on alarm reported by tzafrir (Karma: +121.50) https://issues.asterisk.org/view.php?id=16060 |
| 17:39.47 | tzafrir_laptop | sruffel: what do you think about this? Looks too simple so I suspect I forgot an obvious edge case |
| 17:39.58 | sruffell | looks... |
| 17:42.45 | sruffell | tzafrir: this wasn't with real RBS on the link? |
| 17:42.54 | sruffell | tzafrir_laptop: ^^^ |
| 17:43.05 | tzafrir_laptop | What do you mean? |
| 17:43.43 | sruffell | I thought that when RBS was used, the dahdi_rbsbits is constantly called with the actual status of the received bits. |
| 17:44.17 | sruffell | so when the span comes out of alarm...the driver would just pass up the actual bits that it's currently receiving. |
| 17:44.48 | tzafrir_laptop | Right. But if the driver notes an alarm, should it really care what signalling it has to properly reset the rbsbits? |
| 17:45.38 | tzafrir_laptop | the channel is also not really off-hook anymore |
| 17:47.34 | sruffell | hmm...and I notice that your patch has the 'if (!span->rbsbits)' check in it already. |
| 17:53.37 | *** join/#asterisk-dev errotan (n=errotan@5403E64C.catv.pool.telekom.hu) |
| 17:53.44 | tzafrir_laptop | I hope that this is the right sanity check |
| 18:16.55 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:21.18 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 19:58.49 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 20:09.18 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 20:09.18 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 20:10.24 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@212.179.75.202) |
| 20:10.24 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:17.00 | *** join/#asterisk-dev balaa (n=balaa@adsl-99-49-10-78.dsl.pltn13.sbcglobal.net) |
| 20:50.26 | *** join/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 21:54.24 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 22:22.55 | *** join/#asterisk-dev shido6 (n=shido6@74-132-202-71.dhcp.insightbb.com) |
| 22:32.46 | *** part/#asterisk-dev shido6 (n=shido6@74-132-202-71.dhcp.insightbb.com) |