ax25ipd issue

ax25ipd issue

[Chuck Hast]

Folks,
I am using ax25ipd to route some connections over the wire to other sites
while we get the RF paths back up and running. The issue I am having is
that some of these sites do not have fixed addresses, and the lease exp-
ires every 12 hours or so. If I use the domain name address it will pick up
the numerical address when ax25ipd is first started but once started it
appears to cash the address it got and continue to use it rather than try
to resolve the domain name each time it needs to make a connection.

In my particular case I am trying to make connetions to people using
the no-ip.com domain, but I tried it with another and the same thing
happens. It resolves the first time and continues to use that address
even after the dhcp assignment has changed which indicates to me
that it is only doing address resolution when ax25ipd is starting.

-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: ax25ipd issue

[John Hurst]

Chuck,

It is possible that your DNS resolver is doing the caching. Try 
configuring your host to use the no-ip servers directly. In your 
/etc/resolv.cong file:

         nameserver   8.4.112.74
         nameserver   216.66.37.13
         nameserver   63.208.74.226

If this solves the problem, you may then troubleshoot by a) testing the 
TTL values on the A records given out by no-ip, b) testing the default 
cache value on your resolver (is it yours or your ISP's? many ISPs 
ignore TTL).

-jh



On Jun 11, 2005, at 6:38 AM, Chuck Hast wrote:

> Folks,
> I am using ax25ipd to route some connections over the wire to other 
> sites
> while we get the RF paths back up and running. The issue I am having is
> that some of these sites do not have fixed addresses, and the lease 
> exp-
> ires every 12 hours or so. If I use the domain name address it will 
> pick up
> the numerical address when ax25ipd is first started but once started it
> appears to cash the address it got and continue to use it rather than 
> try
> to resolve the domain name each time it needs to make a connection.
>
> In my particular case I am trying to make connetions to people using
> the no-ip.com domain, but I tried it with another and the same thing
> happens. It resolves the first time and continues to use that address
> even after the dhcp assignment has changed which indicates to me
> that it is only doing address resolution when ax25ipd is starting.
>
> -- 
> Chuck Hast
> To paraphrase my flight instructor;
> "the only dumb question is the one you DID NOT ask resulting in my 
> going
> out and having to identify your bits and pieces in the midst of torn
> and twisted metal."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ax25ipd issue

[Bernard Pidoux]

Hi all,

Some hams using ROSE / FPAC packet switch through AXIP connexions faced 
this problem with non permanent IP stations.

We solved it by running a script every hour that calls host to resolve 
the ip address and append the route at the end of an original 
ax25ipd.conf without the no-ip route. Then this file is copied onto 
ax25ipd.conf.
Finally ax25ipd is killed and started again.
This solution works fine.

For those who are interested I put here an example of the script for one 
specific station.
Note : the two calls to ax25ipd at the end are intentional.

-----------beginning of the script ------------

#!/bin/bash
# Syntax: "majip.f5mtz.sh"
# by F4BVC, F1TE and F6BVP
#
/usr/bin/host f5mtz.no-ip.org > ip-f5mtz
export IP=`more ip-f5mtz | grep -w address | cut -b 29-`
cp /etc/ax25/ax25ipd_sav.conf /etc/ax25/ax25ipd.conf
if test "$IP" ; then
  echo "route F5MTZ-0 $IP udp 10093" >> /etc/ax25/ax25ipd.conf
fi
/usr/bin/killall -KILL ax25ipd
sleep 1
/usr/local/sbin/ax25ipd -l4
sleep 1
/usr/local/sbin/ax25ipd -l4
#

-----------------end of the script---------

73 de Bernard, f6bvp

> On Jun 11, 2005, at 6:38 AM, Chuck Hast wrote:
> 
>> Folks,
>> I am using ax25ipd to route some connections over the wire to other sites
>> while we get the RF paths back up and running. The issue I am having is
>> that some of these sites do not have fixed addresses, and the lease exp-
>> ires every 12 hours or so. If I use the domain name address it will 
>> pick up
>> the numerical address when ax25ipd is first started but once started it
>> appears to cash the address it got and continue to use it rather than try
>> to resolve the domain name each time it needs to make a connection.
>>
>> In my particular case I am trying to make connetions to people using
>> the no-ip.com domain, but I tried it with another and the same thing
>> happens. It resolves the first time and continues to use that address
>> even after the dhcp assignment has changed which indicates to me
>> that it is only doing address resolution when ax25ipd is starting.
>>
>> -- 
>> Chuck Hast

Re: ax25ipd issue

[Chuck Hast]

On 6/12/05, Bernard Pidoux <pidoux@ccr.jussieu.fr> wrote:
> Hi all,
> 
> Some hams using ROSE / FPAC packet switch through AXIP connexions faced
> this problem with non permanent IP stations.
> 
> We solved it by running a script every hour that calls host to resolve
> the ip address and append the route at the end of an original
> ax25ipd.conf without the no-ip route. Then this file is copied onto
> ax25ipd.conf.
> Finally ax25ipd is killed and started again.
> This solution works fine.
> 
> For those who are interested I put here an example of the script for one
> specific station.
> Note : the two calls to ax25ipd at the end are intentional.
> 
> -----------beginning of the script ------------
> 
> #!/bin/bash
> # Syntax: "majip.f5mtz.sh"
> # by F4BVC, F1TE and F6BVP
> #
> /usr/bin/host f5mtz.no-ip.org > ip-f5mtz
> export IP=`more ip-f5mtz | grep -w address | cut -b 29-`
> cp /etc/ax25/ax25ipd_sav.conf /etc/ax25/ax25ipd.conf
> if test "$IP" ; then
>   echo "route F5MTZ-0 $IP udp 10093" >> /etc/ax25/ax25ipd.conf
> fi
> /usr/bin/killall -KILL ax25ipd
> sleep 1
> /usr/local/sbin/ax25ipd -l4
> sleep 1
> /usr/local/sbin/ax25ipd -l4
> #
> 

Bernard,
Does double ax25ipd command at the bottom start up two instances of
ax25ipd? Also I believe that the -l4 is log level 4 correct? 

Sure would be nice not to have to kill the thing and restart it but I guess if
you do it fast enough your links may not even notice it...

Need to get someone to look at coming up with perhaps a new version or
something that will keep things running without dropping the whole thing.

I guess the only things I need to change are the call signs, IP domaine
names and the paths which may be different.



-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: [fpac] Re: ax25ipd issue

[Bernard Pidoux]

Chuck Hast a écrit :
> Bernard,
> Does double ax25ipd command at the bottom start up two instances of
> ax25ipd? Also I believe that the -l4 is log level 4 correct? 

No, It starts only one instance of ax25ipd.
The second call is in case ax25ipd will not be able to connect 
immediately to remote ip stations, it only gives it a second chance. 
Otherwise, the system would have to wait for one more hour until the 
script starts again.

By the way, I had to introduce a small patch into ax25ipd source code 
for it would fail if a LAN connexion through UDP port is not reachable, 
All the AXIP system would lock and thus FPAC.

The patch is in io_error() routine.

                         exit(2);
                 } else if (mode == UDP_MODE) {
                         syslog(LOG_ERR, "reading from udp socket, 
%s\n", strerror(errno));
//                      perror("reading from udp socket");
//                      exit(2);
                 } else if (mode == TTY_MODE) {

In case of read error, ax25ipd will keep on trying to read, instead of 
aborting.


> 
> Sure would be nice not to have to kill the thing and restart it but I guess if
> you do it fast enough your links may not even notice it...
> 
> Need to get someone to look at coming up with perhaps a new version or
> something that will keep things running without dropping the whole thing.
> 
> I guess the only things I need to change are the call signs, IP domaine
> names and the paths which may be different.
> 
> 
> 

73 de Bernard, f6bvp
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [fpac] Re: ax25ipd issue

[Chuck Hast]

On 6/13/05, Bernard Pidoux <pidoux@ccr.jussieu.fr> wrote:
> Chuck Hast a écrit :
> > Bernard,
> > Does double ax25ipd command at the bottom start up two instances of
> > ax25ipd? Also I believe that the -l4 is log level 4 correct?
> 
> No, It starts only one instance of ax25ipd.
> The second call is in case ax25ipd will not be able to connect
> immediately to remote ip stations, it only gives it a second chance.
> Otherwise, the system would have to wait for one more hour until the
> script starts again.

Ahh, now I understand. 

> 
> By the way, I had to introduce a small patch into ax25ipd source code
> for it would fail if a LAN connexion through UDP port is not reachable,
> All the AXIP system would lock and thus FPAC.
> 
> The patch is in io_error() routine.
> 
>                          exit(2);
>                  } else if (mode == UDP_MODE) {
>                          syslog(LOG_ERR, "reading from udp socket,
> %s\n", strerror(errno));
> //                      perror("reading from udp socket");
> //                      exit(2);
>                  } else if (mode == TTY_MODE) {
> 
> In case of read error, ax25ipd will keep on trying to read, instead of
> aborting.
> 
> 

OK, I shall find the source and add this to it so that the problem will  be
corrected.


-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ax25ipd issue

[Tomi Manninen]

On Sat, 2005-06-11 at 16:38, Chuck Hast wrote:

> I am using ax25ipd to route some connections over the wire to other sites
> while we get the RF paths back up and running. The issue I am having is
> that some of these sites do not have fixed addresses, and the lease exp-
> ires every 12 hours or so. If I use the domain name address it will pick up
> the numerical address when ax25ipd is first started but once started it
> appears to cash the address it got and continue to use it rather than try
> to resolve the domain name each time it needs to make a connection.
> 
> In my particular case I am trying to make connetions to people using
> the no-ip.com domain, but I tried it with another and the same thing
> happens. It resolves the first time and continues to use that address
> even after the dhcp assignment has changed which indicates to me
> that it is only doing address resolution when ax25ipd is starting.

Yes, it does the address resolution only at startup.

Ax25ipd is completely stateless, so the other alternative would be
to resolve for each packet. That would be braindead if you ask me...

-- 
Tomi Manninen / OH2BNS / KP20JF74

Re: ax25ipd issue

[Jeremy Utley]

On 6/11/05, Tomi Manninen <oh2bns@sral.fi> wrote:
> On Sat, 2005-06-11 at 16:38, Chuck Hast wrote:
> 
> > I am using ax25ipd to route some connections over the wire to other sites
> > while we get the RF paths back up and running. The issue I am having is
> > that some of these sites do not have fixed addresses, and the lease exp-
> > ires every 12 hours or so. If I use the domain name address it will pick up
> > the numerical address when ax25ipd is first started but once started it
> > appears to cash the address it got and continue to use it rather than try
> > to resolve the domain name each time it needs to make a connection.
> >
> > In my particular case I am trying to make connetions to people using
> > the no-ip.com domain, but I tried it with another and the same thing
> > happens. It resolves the first time and continues to use that address
> > even after the dhcp assignment has changed which indicates to me
> > that it is only doing address resolution when ax25ipd is starting.
> 
> Yes, it does the address resolution only at startup.
> 
> Ax25ipd is completely stateless, so the other alternative would be
> to resolve for each packet. That would be braindead if you ask me...

I don't know if it would be braindead or not.  I'm not familiar with
ax25ipd or how it works, but here's the question I would ask:

Does ax25ipd initiate a SYN/ACK handshake with the remote system only
at startup, and maintain the connection, or does it initiate the
connection, send it's data, and terminate the connection, reopening it
later when there is more data to send?  If it's the latter, then my
own personal opinion is that it should be doing a DNS lookup for each
connection it initiates.  And if it's using UDP instead of TCP, then
yes, each individual packet should be accompanied by a DNS lookup
request.

Just my .02 worth.

Jeremy, NW7JU

Re: ax25ipd issue

[Tomi Manninen]

On Sat, 2005-06-11 at 22:54, Jeremy Utley wrote:

> On 6/11/05, Tomi Manninen <oh2bns@sral.fi> wrote:
> > Ax25ipd is completely stateless, so the other alternative would be
> > to resolve for each packet. That would be braindead if you ask me...

> Does ax25ipd initiate a SYN/ACK handshake with the remote system only
> at startup, and maintain the connection, or does it initiate the
> connection, send it's data, and terminate the connection, reopening it
> later when there is more data to send?  If it's the latter, then my
> own personal opinion is that it should be doing a DNS lookup for each
> connection it initiates.  And if it's using UDP instead of TCP, then
> yes, each individual packet should be accompanied by a DNS lookup
> request.

AX25IP works with not TCP, not UDP, but with IP protocol 93. It's a
stateless protocol consisting of not much else than wrapping an
AX.25 packet to an IP frame. Then there are variants that use UDP 
to do pretty much the same.

If doing a DNS lookup for each outgoing AX.25 packet is ok for
people then so be it. You have the source. Modify it.

I find it braindead. The fix should be something else.

-- 
Tomi Manninen / OH2BNS / KP20JF74

Re: ax25ipd issue

[John Hurst]

On Jun 11, 2005, at 1:09 PM, Tomi Manninen wrote:
> I find it braindead. The fix should be something else.

How about using the TTL to decide when to re-query?

-jh

Re: ax25ipd issue

[David D. Hagood]

John Hurst wrote:
> How about using the TTL to decide when to re-query?


Or better still, just query a local nameserver on every packet, and let 
the local nameserver worry about nameserver type issues like TTL and 
caching.

Remember the Unix way - do what you do very well, and do nothing else - 
let others do what they do very well.

Re: ax25ipd issue

[Chuck Hast]

On 6/11/05, David D. Hagood <wowbagger@sktc.net> wrote:
> John Hurst wrote:
> > How about using the TTL to decide when to re-query?
> 
> 
> Or better still, just query a local nameserver on every packet, and let
> the local nameserver worry about nameserver type issues like TTL and
> caching.
> 
> Remember the Unix way - do what you do very well, and do nothing else -
> let others do what they do very well.
> -

Well, if I can figure out how to get ax25ipd to do so that is what I would do.
Problem is that it does not do any of that except at startup.

-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: ax25ipd issue

[Chuck Hast]

On 6/11/05, John Hurst <jhurst@utac.net> wrote:
> 
> On Jun 11, 2005, at 1:09 PM, Tomi Manninen wrote:
> > I find it braindead. The fix should be something else.
> 
> How about using the TTL to decide when to re-query?
> 
> -jh
> 

Yes, we need to come up on a work around,  Stewart Wilkinson sent
me a set of scripts that kill and restart ax25ipd when they detect a
out of date address. Would be much better to figure out how to come
up with a solution that will get a new one and go from there. We are
running this using UDP, it works until a address gets changed some-
where and then you have to restart the ax25ipd links so as to pick up
the new addresses.



-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: ax25ipd issue

[Steve Fraser]

Hi All,

Regarding the problem of IP addresses changing for AXIP links, Chuck 
Hast wrote:

> Yes, we need to come up on a work around,  Stewart Wilkinson sent
> me a set of scripts that kill and restart ax25ipd when they detect a
> out of date address. Would be much better to figure out how to come
> up with a solution that will get a new one and go from there. 

I've done some changes to the code. I've altered it so that every five 
minutes and after 10 seconds of inactivity (or every 15 minutes 
regardless) the IP entries for all route lines that have hostnames 
rather than IP numbers get requeried by DNS. (It would have been better 
to use TTL's, but I couldnt find any way to get the TTL without a lot of 
coding!)

Anyway, if you specify an IP number on a route line, then it's clearly 
fixed. If you use a FQDN then the IP number may change, so is 
re-checked. (If it is found to be invalid upon re-checking, the old IP 
number is re-used).

I think this will work OK, (without the overhead of a DNS lookup of 
every packet) but I dont have any partners who use dynamic dns, so I 
guess I need a volunteer to try it out for me..........

Drop me a line if you'd like to try it out.

73

Steve, vk5asf

Re: ax25ipd issue

[Chuck Hast]

On 6/23/05, Steve Fraser <sfraser@sierra.apana.org.au> wrote:
> Hi All,
> 
> Regarding the problem of IP addresses changing for AXIP links, Chuck
> Hast wrote:
> 
> > Yes, we need to come up on a work around,  Stewart Wilkinson sent
> > me a set of scripts that kill and restart ax25ipd when they detect a
> > out of date address. Would be much better to figure out how to come
> > up with a solution that will get a new one and go from there.
> 
> I've done some changes to the code. I've altered it so that every five
> minutes and after 10 seconds of inactivity (or every 15 minutes
> regardless) the IP entries for all route lines that have hostnames
> rather than IP numbers get requeried by DNS. (It would have been better
> to use TTL's, but I couldnt find any way to get the TTL without a lot of
> coding!)
> 
> Anyway, if you specify an IP number on a route line, then it's clearly
> fixed. If you use a FQDN then the IP number may change, so is
> re-checked. (If it is found to be invalid upon re-checking, the old IP
> number is re-used).
> 
> I think this will work OK, (without the overhead of a DNS lookup of
> every packet) but I dont have any partners who use dynamic dns, so I
> guess I need a volunteer to try it out for me..........
> 
> Drop me a line if you'd like to try it out.
> 

Steve,
Send me that sucker and I will pop it in here and test it. I have one and
soon two switch sites that have no-ip.com addresses and they change
about every 12 hours.. Be glad to give it a try.

-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: ax25ipd issue

[Bernard Pidoux]

Hi Steve,

I have two dynamic IP partners and would be glad to test your patch for 
ax25ipd.

Please feel free to send me your patch.

73 de Bernard, f6bvp


> Hi All,
> 
> Regarding the problem of IP addresses changing for AXIP links, Chuck 
> Hast wrote:
> 
>> Yes, we need to come up on a work around,  Stewart Wilkinson sent
>> me a set of scripts that kill and restart ax25ipd when they detect a
>> out of date address. Would be much better to figure out how to come
>> up with a solution that will get a new one and go from there. 
> 
> 
> I've done some changes to the code. I've altered it so that every five 
> minutes and after 10 seconds of inactivity (or every 15 minutes 
> regardless) the IP entries for all route lines that have hostnames 
> rather than IP numbers get requeried by DNS. (It would have been better 
> to use TTL's, but I couldnt find any way to get the TTL without a lot of 
> coding!)
> 
> Anyway, if you specify an IP number on a route line, then it's clearly 
> fixed. If you use a FQDN then the IP number may change, so is 
> re-checked. (If it is found to be invalid upon re-checking, the old IP 
> number is re-used).
> 
> I think this will work OK, (without the overhead of a DNS lookup of 
> every packet) but I dont have any partners who use dynamic dns, so I 
> guess I need a volunteer to try it out for me..........
> 
> Drop me a line if you'd like to try it out.
> 
> 73
> 
> Steve, vk5asf
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: ax25ipd issue

[Steve Fraser]

Hi All,

Tomi Manninen wrote:

> 
> If doing a DNS lookup for each outgoing AX.25 packet is ok for
> people then so be it. You have the source. Modify it.
> 
> I find it braindead. The fix should be something else.
> 
I agree. That would be a ridiculous overhead.

Some time ago I prototyped a "dynamic" ax25ipd. The lookup table 
(translating callsigns to IP's) was held in memory space that could also 
be accessed by other programs. The idea was that ax25ipd initially 
populated the table, then other programs (eg DNS, or a "learning" 
listener) could amend it. Each time ax25ipd sent a packet, it looked up 
that table, so if the entry had changed the packet went to the new 
destination.

It needed a simple locking mechanism, but before I got around to that 
someone did a major rewrite of ax25ipd and I never got around to 
re-doing it :-(  But I'm sure it could be re-done relatively easily 
(even if I can't find the code).

73

Steve, vk5asf

Re: ax25ipd issue

[Jeremy Utley]

On 6/11/05, Tomi Manninen <oh2bns@sral.fi> wrote:
> On Sat, 2005-06-11 at 22:54, Jeremy Utley wrote:
> 
> > On 6/11/05, Tomi Manninen <oh2bns@sral.fi> wrote:
> > > Ax25ipd is completely stateless, so the other alternative would be
> > > to resolve for each packet. That would be braindead if you ask me...
> 
> > Does ax25ipd initiate a SYN/ACK handshake with the remote system only
> > at startup, and maintain the connection, or does it initiate the
> > connection, send it's data, and terminate the connection, reopening it
> > later when there is more data to send?  If it's the latter, then my
> > own personal opinion is that it should be doing a DNS lookup for each
> > connection it initiates.  And if it's using UDP instead of TCP, then
> > yes, each individual packet should be accompanied by a DNS lookup
> > request.
> 
> AX25IP works with not TCP, not UDP, but with IP protocol 93. It's a
> stateless protocol consisting of not much else than wrapping an
> AX.25 packet to an IP frame. Then there are variants that use UDP
> to do pretty much the same.
> 
> If doing a DNS lookup for each outgoing AX.25 packet is ok for
> people then so be it. You have the source. Modify it.
> 
> I find it braindead. The fix should be something else.

Not to flame, but I find your implementation braindead.  IP addresses
change, and the whole purpose of DNS is to make it so you don't have
to remember ip's - you can use friendly names instead.  If your
application cannot respect the DNS TTL value as specified by the name
server that provides the reverse mapping (and on the dyndns services
such as no-ip this are naturally set very low), then IMHO, it's a
broken application.

Since the program is using a stateless mode of communication, then it
*IS* necessary for the program to either (a) respect the TTL setting
provided by the remote authoritative DNS server, or (b) make a call to
gethostbyname() (If I remember my c networking code that's the
function used) to translate the hostname to the IP each an every time.
 Anything else is irresponsible, and broken, because you're relying on
data that is outdated.

Jeremy, NW7JU

Re: ax25ipd issue

[Tomi Manninen]

On Sun, 2005-06-12 at 07:50, Jeremy Utley wrote:

> Not to flame, but I find your implementation braindead.

It's not my implementation. See the source:


-------------------------------------------------------------------------
 Copyright 1991, Michael Westerhof, Sun Microsystems, Inc.
 This software may be freely used, distributed, or modified, providing
 this footer is not removed.

-------------------------------------------------------------------------

Yes, it was designed for a different world. Free of todays evil dynamic 
IP address assignment... But I still don't think DNS is the correct
tool for fixing the issue. 

-- 
Tomi Manninen / OH2BNS / KP20JF74

Re: ax25ipd issue

[dplatt]

> AX25IP works with not TCP, not UDP, but with IP protocol 93. It's a
> stateless protocol consisting of not much else than wrapping an
> AX.25 packet to an IP frame. Then there are variants that use UDP 
> to do pretty much the same.
> 
> If doing a DNS lookup for each outgoing AX.25 packet is ok for
> people then so be it. You have the source. Modify it.
> 
> I find it braindead. The fix should be something else.

I'm not sure that actually doing a DNS lookup (via the resolver
interface) is necessary or desireable.

However, I do think that when the daemon does such a lookup, and
caches the resulting IP address, it should also cache the current time
and the time-to-live value from the DNS lookup.  Once the response's
time-to-live expires, it should discard the callsign-to-IP-address
mapping and look it up again.

For the daemon to assume that a DNS response has an effectively
infinite lifetime is not a good thing.