[Ovmsdev] Firmware 2.8.1
dexter at expeedo.de
Sat Sep 26 15:33:16 HKT 2015
User feedback: using the host name instead of the IP works with german
carriers Telekom (D1), O2 and E-Plus.
Only D2 (Vodafone) has not been tested yet, but I don't expect any
It seems there is no general need for the GPRSDNS parameter?
Am 25.09.2015 um 04:10 schrieb Mark Webb-Johnson:
> While I agree about the TTL and possibility of badly configured
> caching servers not honouring it, in the greater scheme of things it
> is really irrelevant.
> This last change of address was urgently made by TMC, not realising it
> would impact us. It is only by blind luck that they hadn’t released
> the old address back to the amazon pool. If that had happened, every
> user would have had to manually sms their cars to make the change.
> Luckily, they hadn’t released the address, so could assign it to
> another VM. I then did a socat on that machine, to forward the traffic
> to our new address. Then, some magic on the ovms_server.pl to
> reprogram cars connecting from the old address to switch to the new
> one. We’d done a similar thing a few years back, so I knew it would work.
> Faced with that, a couple of hours of downtime, due to a DNS switch,
> is not so worrying ;-)
> That said, I don’t see any option on register.com
> <http://register.com> to set the TTL. Seems fixed at 4 hours. I’ll
> check further.
> Regarding the change from server IP to server name, I would be
> grateful if more developers could try it, around the world. Let me
> know the results here. In particular, with the popular carriers in USA
> and Europe. It would be vastly simpler to just tell people to change
> to use a name, rather than messing around with google DNS servers.
> Regards, Mark.
>> On 25 Sep, 2015, at 12:17 am, HONDA S-2000 <s2000 at audiobanshee.com
>> <mailto:s2000 at audiobanshee.com>> wrote:
>> On Sep 24, 2015, at 5:46 AM, Collin Kidder <collink at kkmfg.com
>> <mailto:collink at kkmfg.com>> wrote:
>>> On Thu, Sep 24, 2015 at 5:38 AM, Michael Balzer <dexter at expeedo.de
>>> <mailto:dexter at expeedo.de>> wrote:
>>>> I just checked the DNS record for tmc.openvehicles.com
>>>> tmc.openvehicles.com <http://tmc.openvehicles.com>. 14399 IN
>>>> A 18.104.22.168
>>>> I suggest reducing the TTL to 1 hour before we recommend the change to
>>> Keep in mind that much of the internet is ruled by caching name
>>> servers that will be quite stubborn about having to update their
>>> records. I seriously doubt that a TTL of 1 hour will be honored by
>>> much of anything. You're lucky if the ISP name servers bother to check
>>> for updates more than once or twice a day.
>> I'm fairly certain that there are no caching servers that ignore TTL.
>> It would thwart emergency services if short TTL values were ignored.
>> My ISP has changed my server ip address only once, and they went
>> through the same process of shortening the TTL before the scheduled
>> change, then increasing it back to normal after the new ip address
>> was activated.
>> The catch is that any change does not take effect until the old TTL
>> expires. The "14399" above is 4 hours. So, if the TTL were changed to
>> 1 hour, it would not take effect on all caching servers until 4 hours
>> later. At that point, though, all DNS servers would be working with a
>> TTL of 1 hour. The typical is more like 24 hours, so the 4 hour entry
>> above is rather short. If 24 hours were used, then the ISP would need
>> to start the process 24 hours early by changing the TTL to 1 hour a
>> whole day in advance of the ip address change. But at long as you
>> know the current TTL and plan ahead, it's always possible to make a
>> prompt transition.
>> Those name servers that only bother to check once or twice a day are
>> doing exactly as they're told, and will check every hour if told to
>> do so instead.
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 206 bytes
Desc: not available
More information about the OvmsDev