getting remote m/c to see my IP address

My home machine has a dynamic IP address, which is connected to
an account at dyndns.org. So every time the IP address changes,
Dyndns is sent the update and keeps my hostname in sync. This
all works fine and on the remote machines (i.e. work boxes) I've tried
I can access my home box via the Dyndns hostname.
There's no problem with blocked ports.

However, we also have a remote machine which connects to the net
through a 3G modem/dongle. This runs a script which (should)
initialise the 3G connection and then connect to my home box.
This runs at a scheduled time every day. it worked fine when it
was being tested, but since we left it on site, it has only
connected through once - classic example of Sod's Law.

Now, the one time it *did* connect, the dynamic IP address of the
home system just (by pure flook - it was over a week later)
happened to be re-asssigned to the same IP address it had when we'd
ben testing. It seems to me that someone, somewhere isn't getting
the DNS updates for the home box's IP address.
Is there any way that I can force/push/persuade the remote system's
3G network to accept the IP address changes from Dyndns?

Thanks
Pete

pete wrote:
Now, the one time it *did* connect, the dynamic IP address of the
home system just (by pure flook - it was over a week later)
happened to be re-asssigned to the same IP address it had when we'd
ben testing. It seems to me that someone, somewhere isn't getting
the DNS updates for the home box's IP address.
Is there any way that I can force/push/persuade the remote system's
3G network to accept the IP address changes from Dyndns?

Have a look at the time-to-live presented by the 3G network with some DNS
lookups. For example:

$ host -a www.example.com
;; ANSWER SECTION:
www.example.com. [[124372]] IN A 208.77.188.166

is a long TTL (I've added [[ ]]) - about 34 hours, while
;; ANSWER SECTION:
www.gnu.org. [[136]] IN CNAME gnu.org.

is about 2 minutes. Try from inside and outside to see if the 3G network
DNS is changing this value (it shouldn't, but...)

If it is, you could try setting up the 3G machine to use a different DNS -
depends whether outbound DNS would be blocked by the network. Or there
might be a DNS proxy you can run that'll change the TTLs on your machine.
But it won't help if the mobile network is caching lookups for longer than
permitted because you'll just refresh from their bad copy.

Theo

Theo Markettos wrote:
pete wrote:
Now, the one time it *did* connect, the dynamic IP address of the
home system just (by pure flook - it was over a week later)
happened to be re-asssigned to the same IP address it had when we'd
ben testing. It seems to me that someone, somewhere isn't getting
the DNS updates for the home box's IP address.
Is there any way that I can force/push/persuade the remote system's
3G network to accept the IP address changes from Dyndns?

Have a look at the time-to-live presented by the 3G network with some DNS
lookups. For example:

$ host -a www.example.com
;; ANSWER SECTION:
www.example.com. [[124372]] IN A 208.77.188.166

is a long TTL (I've added [[ ]]) - about 34 hours, while
;; ANSWER SECTION:
www.gnu.org. [[136]] IN CNAME gnu.org.

is about 2 minutes. Try from inside and outside to see if the 3G network
DNS is changing this value (it shouldn't, but...)

If it is, you could try setting up the 3G machine to use a different DNS -
depends whether outbound DNS would be blocked by the network. Or there
might be a DNS proxy you can run that'll change the TTLs on your machine.
But it won't help if the mobile network is caching lookups for longer than
permitted because you'll just refresh from their bad copy.

Theo
Theo has the bare bones. Its by no means unusual for poorly run DNS
servers or indeed resolvers to cache records LONG after the TTL has expired.

Without knowing more on whats the 3G is actually doing - does it
actually DO a DNS lookup? Or juts use what it found 'las week' its
impossible to say where the problem actually lies.

"The Natural Philosopher" wrote in message
...
Theo Markettos wrote:
pete wrote:
Now, the one time it *did* connect, the dynamic IP address of the
home system just (by pure flook - it was over a week later)
happened to be re-asssigned to the same IP address it had when we'd
ben testing. It seems to me that someone, somewhere isn't getting
the DNS updates for the home box's IP address.
Is there any way that I can force/push/persuade the remote system's
3G network to accept the IP address changes from Dyndns?

Have a look at the time-to-live presented by the 3G network with some DNS
lookups. For example:

$ host -a www.example.com
;; ANSWER SECTION:
www.example.com. [[124372]] IN A 208.77.188.166

is a long TTL (I've added [[ ]]) - about 34 hours, while
;; ANSWER SECTION:
www.gnu.org. [[136]] IN CNAME gnu.org.

is about 2 minutes. Try from inside and outside to see if the 3G network
DNS is changing this value (it shouldn't, but...)

If it is, you could try setting up the 3G machine to use a different
DNS -
depends whether outbound DNS would be blocked by the network. Or there
might be a DNS proxy you can run that'll change the TTLs on your machine.
But it won't help if the mobile network is caching lookups for longer
than
permitted because you'll just refresh from their bad copy.

Theo
Theo has the bare bones. Its by no means unusual for poorly run DNS
servers or indeed resolvers to cache records LONG after the TTL has
expired.

Without knowing more on whats the 3G is actually doing - does it actually
DO a DNS lookup? Or juts use what it found 'las week' its impossible to
say where the problem actually lies.

You could turn the problem around. Install a dynamic DNS client on the
remote system and get it to update its Dyndns record whenever it connects.
That way you can (in principle) manage the remote system from wherever you
like, and tell it explicitly how to connect to your home system.

--
Graham J

On Wed, 11 Feb 2009 14:18:30 -0000, Graham J wrote:

"The Natural Philosopher" wrote in message
...
Theo Markettos wrote:
pete wrote:
Now, the one time it *did* connect, the dynamic IP address of the
home system just (by pure flook - it was over a week later)
happened to be re-asssigned to the same IP address it had when we'd
ben testing. It seems to me that someone, somewhere isn't getting
the DNS updates for the home box's IP address.
Is there any way that I can force/push/persuade the remote system's
3G network to accept the IP address changes from Dyndns?

Have a look at the time-to-live presented by the 3G network with some DNS
lookups. For example:

$ host -a www.example.com
;; ANSWER SECTION:
www.example.com. [[124372]] IN A 208.77.188.166

is a long TTL (I've added [[ ]]) - about 34 hours, while
;; ANSWER SECTION:
www.gnu.org. [[136]] IN CNAME gnu.org.

is about 2 minutes. Try from inside and outside to see if the 3G network
DNS is changing this value (it shouldn't, but...)

If it is, you could try setting up the 3G machine to use a different
DNS -
depends whether outbound DNS would be blocked by the network. Or there
might be a DNS proxy you can run that'll change the TTLs on your machine.
But it won't help if the mobile network is caching lookups for longer
than
permitted because you'll just refresh from their bad copy.

Theo
Theo has the bare bones. Its by no means unusual for poorly run DNS
servers or indeed resolvers to cache records LONG after the TTL has
expired.

Without knowing more on whats the 3G is actually doing - does it actually
DO a DNS lookup? Or juts use what it found 'las week' its impossible to
say where the problem actually lies.

You could turn the problem around. Install a dynamic DNS client on the
remote system and get it to update its Dyndns record whenever it connects.
That way you can (in principle) manage the remote system from wherever you
like, and tell it explicitly how to connect to your home system.

Yes, that's one of the things I've been considering. At present when the
Autoit script wakes up, it connects over SSH to the host and sends it's IP address
(kludge) which I can then pick up, to use in a VNC session _back_ to the
remote to work on it. I've been thinking of putting a mini webserver on the
remote, so I wouldn't need to use VNC for when I just want to pull some data
off it. It primarily serves up weather data and some external webcam views.

pete wrote:
Yes, that's one of the things I've been considering. At present when the
Autoit script wakes up, it connects over SSH to the host and sends it's IP
address (kludge) which I can then pick up, to use in a VNC session _back_
to the remote to work on it. I've been thinking of putting a mini
webserver on the remote, so I wouldn't need to use VNC for when I just
want to pull some data off it. It primarily serves up weather data and
some external webcam views.

Don't forget that all 3G networks have NAT, so you'll have to mess around
with VPNs or SSH tunnels or something to get around it. If you're doing SSH
to notify the IP address then a simple port forward in the reverse direction
will probably do the job.

Theo

pete wrote:
Is there any way that I can force/push/persuade the remote system's
3G network to accept the IP address changes from Dyndns?

Your dongle thingy will be doing a DNS lookup against 3's DNS servers.
Presumably they're not keeping in sync with dyndns.

You could modify the TCPIP settings on the dongle to point DNS to some
other server that /does/ keep in sync? Opendns seem quite good in this
context.