OK- just let me know if you find the source of the bogus IP.
I was asking about version as the 1.2.x (devel) contains IP blacklists
you could use to block such addresses:
Bogdan,
We will check the DNS. We are also using openser-1.1.0-notls
Thanks for you help.
Martin
On 2/6/07, *Bogdan-Andrei Iancu* < bogdan(a)voice-system.ro
<mailto:bogdan@voice-system.ro>> wrote:
Martin,
most probably you cannot get anything via ngrep because:
1 - the outbound message is not sent
2 - the inbound message may contain a domain name which leads to
0.0.1.244 <http://0.0.1.244> via DNS.
try to monitor the DNS traffic also to see if this address comes up.
what version of openser are you using?
regards,
bogdan
Martin Burns wrote:
Bogdan,
You are right it is the destination. I added the following to
udp_server.c when the error occurs:
LOG(L_ERR, "sa = %d, %s, %d\n", to->sin.sin_family,
inet_ntoa(to-> sin.sin_addr),
ntohs(to->sin.sin_port));
Which logs:
sa = 2, 0.0.1.244 <http://0.0.1.244>
<http://0.0.1.244>, 5060
This address is clearly invalid. Interesting thing though is that I
ran an ngrep to see if I could locate a message that contains
this IP
and could not find one:
ngrep -p port 5060 | grep "0.0.1.244 <http://0.0.1.244> <
http://0.0.1.244>"
The above came up clean even though the log kept reporting the
error.
Any more ideas?
Martin
On 2/5/07, *Bogdan-Andrei Iancu* < bogdan(a)voice-system.ro
<mailto:bogdan@voice-system.ro>
<mailto:bogdan@voice-system.ro
<mailto:bogdan@voice-system.ro>>>
wrote:
Martin,
after all, it look the root problem is the destination
address - the
detection of the egress socket (triggered by
mhomed) also fails
because
of an Invalid Argument (as originally).
my guess is that an invalid ip or port is used for sending the
message.
If you cannot track this down, I can try to prepare a patch to
print the
destination address/port in case of error.
regards,
bogdan