Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

[Joshua Colp]

Marek Červenka wrote:

will be helpfull comparison table like this?
http://www.voip-info.org/wiki/view/Asterisk+Realtime+ODBC


Are you the one who experienced the crash on the table, and if so by 
upgrading did that fix it as mentioned on the table? If not what 
versions of things (UnixODBC / connector) are you also running?


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

[Joshua Colp]

Sean Brady wrote:

I am seeing the same issue on Asterisk 13.9.1 FYI.


Are you also seeing the deadlock that Ross has mentioned, or a crash? 
What version of things (UnixODBC and connector) are you also running - 
the same?


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Config reading and scanf with large numbers

[Richard Mudgett]

On Wed, Jun 1, 2016 at 5:25 AM, snuffy  wrote:

> Hello All,
>
> I noticed a bug report ASTERISK-25972,
>

The referenced issue has nothing to do with what you are talking about.


>
> Looking through the code we do the following:
>
> sscanf(string,"%30d",&my_int);
>
> Now issue is an integer can't hold a number of 30 digits in length, 32bit
> ints are safe with 9, and 64bit with 19.
>
> If we set a value of %9d, if there are any more digits after the first 9
> they will be lost but we know the value will be inside the range of an
> integer.
>
> For single value scans, like reading from config files we could 'mitigate'
> by checking the strlen of the value we intend to read before running scanf,
> if return is >9, emit a warning stating their value will be truncated and
> read only the first 9 characters into the integer.
>
> If we use just %d, followed by %n we can see how many characters have been
> consumed, if we determine that it would be too large, emit a warning
> stating that the value is most likely incorrect.
>
>
> Am I barking up the wrong tree? thoughts?
>

The reason Asterisk uses sscanf format specifiers like "%30d" is because of
the AST-2009-005 security issue
where a bug in libc allowed an attacker to crash Asterisk by supplying a
ridiculously long string of digits in a
SIP message and blow the stack.

As far as reading config files with excessively long integers, garbage in
gives garbage out.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

[Ross Beer]

Asterisk Version: 13.9.1

OS/Distro: Fedora Server 23

unixODBC: 2.3.4 (Fedora Package Manager)

Threading: 0

Pooling: yes

ODBC Connector: 5.3.6 (MySQL Fedora Repository) [ANSI or Unicode]
Status: No Crash, but unixODBC locks


From: asterisk-dev-boun...@lists.digium.com 
 on behalf of Marek Červenka 

Sent: 01 June 2016 11:24
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

will be helpfull comparison table like this?
http://www.voip-info.org/wiki/view/Asterisk+Realtime+ODBC
Asterisk Realtime ODBC - 
voip-info.org
www.voip-info.org
asterisk version OS/Distro unixODBC threading pooling odbc-connector SQL server 
status 13.9.1 Linux/Centos 6 2.3.2 (backport fc20) 0 yes 5.1.5 distro MySQL 
5.1.73 distro random segfaults 13.9.1 Linux/Centos 6 2.3.4 (backport fc23)0 yes 
5.3.6




Dne 1.6.2016 v 7:04 Matt Fredrickson napsal(a):

Hey Ross,

At this time, we’re not thinking about reverting the ODBC change,
although we are actually working on an issue internally related to
that particular change.  If it looks like that there is an underlying
systemic issue that we are unable to resolve in a timely manner, it’s
quite possible that the change could be backed out.

So in essence, my thoughts are twofold:
1. Keep moving forward with ODBC changes - but make sure that we’ve
got testing in place to prove functionality.
2. If it all goes down and we’re playing whack a mole with ODBC bugs,
revert the changes until we can do some better testing.

Certified Asterisk goes through its own testing and vetting process
and changes in the branch are driven almost exclusively by certified
customers.  Right now, the 13.8 certified branch is going through the
initial testing process.  There is at least one open issue that we’ve
found so far related to the ODBC change that may or may not be related
to your crash, which is being worked on by a member of the Asterisk
development team at Digium.

Additionally, and completely separate from the certified testing and
release process, a deadlock in the ODBC code is highly concerning, and
if it looks like there are systemic issues related to the performance
improvement added, we will almost certainly look into those as well.

I might add that although Digium as a commercial entity is a large
contributor to the Asterisk project, the goal is for it to also be a
community project.  With that perspective, we also encourage community
members to find ways to contribute as well, whether it be via Digium’s
products and services, or helping by employing others that can
contribute to the project.  We desire and welcome any and all positive
participation.

Thanks *so* much again for the valuable feedback.  Like I said,
hopefully we’ll be able to get a few of these hickups addressed soon.

Best wishes,
Matthew Fredrickson

On Tue, May 31, 2016 at 11:01 AM, Ross Beer 
 wrote:


Hi All,

I've been looking into the changes made to res_odbc and the removal of
connection handling. I can see that this change has been murged into the
next release of Certified Asterisk. Would it be possible to regress this
change until a sutible solution to the locking is found?

Kind regards,

Ross




On Mon, May 30, 2016 at 8:43 AM -0700, "Joshua Colp" 

wrote:

Ross Beer wrote:


Hi,


I'm having an issue with the latest asterisk verison 13.9.1 and SVN
MASTER:






There are currently around 9 locks held and no phones are able to
register. The system is using the latest unixODBC and
mysql-connector-odbc drivers. This has been working well up until
recently. However a change appears to have been made to the way
endpoints are authenticated. I'm exploring the possibility that this may
be a unixODBC issue however I would be great full if anyone could offer
any assistance?


A full backtrace[1] would be needed to see what is going on. You should
also file an issue and link it here.

[1]
https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & 
www.asterisk.org


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev




--
---
Marek Cervenka
===

-- 
__

[asterisk-dev] Config reading and scanf with large numbers

[snuffy]

Hello All,

I noticed a bug report ASTERISK-25972,

Looking through the code we do the following:

sscanf(string,"%30d",&my_int);

Now issue is an integer can't hold a number of 30 digits in length, 32bit
ints are safe with 9, and 64bit with 19.

If we set a value of %9d, if there are any more digits after the first 9
they will be lost but we know the value will be inside the range of an
integer.

For single value scans, like reading from config files we could 'mitigate'
by checking the strlen of the value we intend to read before running scanf,
if return is >9, emit a warning stating their value will be truncated and
read only the first 9 characters into the integer.

If we use just %d, followed by %n we can see how many characters have been
consumed, if we determine that it would be too large, emit a warning
stating that the value is most likely incorrect.


Am I barking up the wrong tree? thoughts?
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking

[Marek Červenka]

will be helpfull comparison table like this?
http://www.voip-info.org/wiki/view/Asterisk+Realtime+ODBC

Dne 1.6.2016 v 7:04 Matt Fredrickson napsal(a):

Hey Ross,

At this time, we’re not thinking about reverting the ODBC change,
although we are actually working on an issue internally related to
that particular change.  If it looks like that there is an underlying
systemic issue that we are unable to resolve in a timely manner, it’s
quite possible that the change could be backed out.

So in essence, my thoughts are twofold:
1. Keep moving forward with ODBC changes - but make sure that we’ve
got testing in place to prove functionality.
2. If it all goes down and we’re playing whack a mole with ODBC bugs,
revert the changes until we can do some better testing.

Certified Asterisk goes through its own testing and vetting process
and changes in the branch are driven almost exclusively by certified
customers.  Right now, the 13.8 certified branch is going through the
initial testing process.  There is at least one open issue that we’ve
found so far related to the ODBC change that may or may not be related
to your crash, which is being worked on by a member of the Asterisk
development team at Digium.

Additionally, and completely separate from the certified testing and
release process, a deadlock in the ODBC code is highly concerning, and
if it looks like there are systemic issues related to the performance
improvement added, we will almost certainly look into those as well.

I might add that although Digium as a commercial entity is a large
contributor to the Asterisk project, the goal is for it to also be a
community project.  With that perspective, we also encourage community
members to find ways to contribute as well, whether it be via Digium’s
products and services, or helping by employing others that can
contribute to the project.  We desire and welcome any and all positive
participation.

Thanks *so* much again for the valuable feedback.  Like I said,
hopefully we’ll be able to get a few of these hickups addressed soon.

Best wishes,
Matthew Fredrickson

On Tue, May 31, 2016 at 11:01 AM, Ross Beer  wrote:

Hi All,

I've been looking into the changes made to res_odbc and the removal of
connection handling. I can see that this change has been murged into the
next release of Certified Asterisk. Would it be possible to regress this
change until a sutible solution to the locking is found?

Kind regards,

Ross




On Mon, May 30, 2016 at 8:43 AM -0700, "Joshua Colp" 
wrote:

Ross Beer wrote:

Hi,


I'm having an issue with the latest asterisk verison 13.9.1 and SVN
MASTER:




There are currently around 9 locks held and no phones are able to
register. The system is using the latest unixODBC and
mysql-connector-odbc drivers. This has been working well up until
recently. However a change appears to have been made to the way
endpoints are authenticated. I'm exploring the possibility that this may
be a unixODBC issue however I would be great full if anyone could offer
any assistance?

A full backtrace[1] would be needed to see what is going on. You should
also file an issue and link it here.

[1]
https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev






--
---
Marek Cervenka
===

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev