gpg: failed to create temporary file '/var/lib/lurker/.#lk0x57130100.hantslug.org.uk.25129': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Fri Nov 6 21:12:13 2009 GMT
gpg: using DSA key 20ACB3BE515C238D
gpg: Can't check signature: No public key
On Fri, Nov 06, 2009 at 08:59:52PM +0000, Nick Chalk wrote:
> One for the network gurus.
>
> I have a Linux device that's monitoring two SIP
> servers. The health check method is to connect to
> port 5060/udp on each server, issue an OPTIONS
> command, then listen for a successful response.
>
> These health checks always succeed on one server,
> and always fail on the other. A packet dump shows
> that the successful server responds from 5060/udp;
> the failing server allocates a high port - around
> 50000/udp - for its response. Both servers are
> sending success responses.
>
> The packet trace shows a UDP SIP request from the
> Linux box, to 5060/udp on the failing SIP server.
> There's then a successful SIP response from the
> server, to the correct destination port on the
> Linux box, from the newly-allocated high port. The
> Linux box then responds with an ICMP Destination
> Port Unreachable.
>
> So, the question is whether this is correct
> behaviour on the part of the Linux box. I've yet
> to find a reference to UDP that mentions filtering
> on the source port of a datagram. The destination
> port obviously has to be correct, but I'm unclear
> on whether the source port also has to match.
I believe that the filtering is incorrect, and that the machine
returning its packet from a high port is correct, if unusual. I'm not
entirely sure *why* I believe that, though.
Do you have any packet filtering firewalls between the machines
(particularly NAT or any other kind of stateful packet tracking)?
Also, where are you capturing the packet dumps? Actually on the
monitoring machine, or at some point before the packets reach it?
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Nostalgia isn't what it used to be. ---
