On 03/15/2012 02:38 PM, Warren Selby wrote:
Second, this is kind of outside the box thinking, so it may not work at
all, but try setting the NAT on that peer to no, and then tcpdump the
incoming registration attempts and see if you can see the internal
private IP address of the packet. If
On Wed, Mar 14, 2012 at 1:36 PM, Randall rand...@songshu.org wrote:
all works as expected only there is 1 extension that is trying to register
with a wrong password causing fail2ban to block the IP address, normally
that is ok behaviour but i have several extensions on that IP address.
On 03/13/2012 11:06 PM, Dave Platt wrote:
Ouch. That isn't going to be so easy to spot, then! You would have to guess
a bunch of likely passwords, fake up a challenge with some known nonce, and
compare the response against those you would expect with each of the various
possible passwords.
On Tuesday 13 March 2012, Randall wrote:
hi all,
have asterisk set up in combination with fail2ban.
all works as expected only there is 1 extension that is trying to
register with a wrong password causing fail2ban to block the IP address,
normally that is ok behaviour but i have several
On 03/13/2012 08:11 AM, A J Stiles wrote:
On Tuesday 13 March 2012, Randall wrote:
hi all,
have asterisk set up in combination with fail2ban.
all works as expected only there is 1 extension that is trying to
register with a wrong password causing fail2ban to block the IP address,
normally that
On 03/13/2012 02:11 PM, A J Stiles wrote:
On Tuesday 13 March 2012, Randall wrote:
hi all,
have asterisk set up in combination with fail2ban.
all works as expected only there is 1 extension that is trying to
register with a wrong password causing fail2ban to block the IP address,
normally that
On 03/13/2012 03:53 PM, Kevin P. Fleming wrote:
On 03/13/2012 08:11 AM, A J Stiles wrote:
On Tuesday 13 March 2012, Randall wrote:
hi all,
have asterisk set up in combination with fail2ban.
all works as expected only there is 1 extension that is trying to
register with a wrong password
On Tuesday 13 March 2012, Kevin P. Fleming wrote:
[tcpflow] will not help. Assuming we are talking about a SIP REGISTER here,
the password is *not* sent in the request. Asterisk issues a challenge
including a randomly generated value (called a 'nonce'), then the UA
attempting to register
Ouch. That isn't going to be so easy to spot, then! You would have to guess
a bunch of likely passwords, fake up a challenge with some known nonce, and
compare the response against those you would expect with each of the various
possible passwords. (You've already got the Source Code
