I’ve built a firmware for 2.8.1.
This includes all the changes since March 2014. Quite a few minor bug fixes and improvements.
Most noticeable new work is parameter #0x16, GPRSDNS. This can be configured as the fourth parameter to the GPRS command, and specifies the DNS server. It seems that the gprs protocol allows the mobile providers to push DNS server IPs to us, and the SIM908 recognises and stores those. But, for those providers that don’t support that, this parameter allows it to be explicitly set. We can now use DNS names (tmc.openvehicles.com <http://tmc.openvehicles.com/>), instead of IP addresses, for the Server IP parameter. This is a much better way of doing it.
I’ve also changed the COPS mechanism around a bit, to try to make it work better in marginal network conditions. In particular, in my garage ;-) The new logic is to wait for up to 5 minutes, after COPS fails, to see if we can get a network registration anyway. If we can, we continue with GPRS. If we can’t we try COPS again.
This is a release candidate now.
Regards, Mark.
By the way, anyone brave enough to try putting in ‘tmc.openvehicles.com’ into the ServerIP field, even without running this new code?
From what I can see (and tested here), if your ISP provides DNS servers as part of its GPRS profile, then it should just work. The change below is just to allow you to specify a DNS server directly (rather than rely on the ISP provided ones). Switching to use DNS names should allow us to avoid problems such as TMC experienced this past week.
Regards, Mark.
On 23 Sep, 2015, at 10:51 pm, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve built a firmware for 2.8.1.
This includes all the changes since March 2014. Quite a few minor bug fixes and improvements.
Most noticeable new work is parameter #0x16, GPRSDNS. This can be configured as the fourth parameter to the GPRS command, and specifies the DNS server. It seems that the gprs protocol allows the mobile providers to push DNS server IPs to us, and the SIM908 recognises and stores those. But, for those providers that don’t support that, this parameter allows it to be explicitly set. We can now use DNS names (tmc.openvehicles.com <http://tmc.openvehicles.com/>), instead of IP addresses, for the Server IP parameter. This is a much better way of doing it.
I’ve also changed the COPS mechanism around a bit, to try to make it work better in marginal network conditions. In particular, in my garage ;-) The new logic is to wait for up to 5 minutes, after COPS fails, to see if we can get a network registration anyway. If we can, we continue with GPRS. If we can’t we try COPS again.
This is a release candidate now.
Regards, Mark.
Mark,
I'm now running the new version, but without an explicit DNS, just changed the server to "tmc.openvehicles.com" and it works.
I just checked the DNS record for tmc.openvehicles.com:
tmc.openvehicles.com. 14399 IN A 54.197.255.127
I suggest reducing the TTL to 1 hour before we recommend the change to users.
Regards, Michael
Am 24.09.2015 um 08:07 schrieb Mark Webb-Johnson:
By the way, anyone brave enough to try putting in ‘tmc.openvehicles.com <http://tmc.openvehicles.com>’ into the ServerIP field, even without running this new code?
From what I can see (and tested here), if your ISP provides DNS servers as part of its GPRS profile, then it should just work. The change below is just to allow you to specify a DNS server directly (rather than rely on the ISP provided ones). Switching to use DNS names should allow us to avoid problems such as TMC experienced this past week.
Regards, Mark.
On 23 Sep, 2015, at 10:51 pm, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I’ve built a firmware for 2.8.1.
This includes all the changes since March 2014. Quite a few minor bug fixes and improvements.
Most noticeable new work is parameter #0x16, GPRSDNS. This can be configured as the fourth parameter to the GPRS command, and specifies the DNS server. It seems that the gprs protocol allows the mobile providers to push DNS server IPs to us, and the SIM908 recognises and stores those. But, for those providers that don’t support that, this parameter allows it to be explicitly set. We can now use DNS names (tmc.openvehicles.com <http://tmc.openvehicles.com/>), instead of IP addresses, for the Server IP parameter. This is a much better way of doing it.
I’ve also changed the COPS mechanism around a bit, to try to make it work better in marginal network conditions. In particular, in my garage ;-) The new logic is to wait for up to 5 minutes, after COPS fails, to see if we can get a network registration anyway. If we can, we continue with GPRS. If we can’t we try COPS again.
This is a release candidate now.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Thu, Sep 24, 2015 at 5:38 AM, Michael Balzer <dexter@expeedo.de> wrote:
I just checked the DNS record for tmc.openvehicles.com:
tmc.openvehicles.com. 14399 IN A 54.197.255.127
I suggest reducing the TTL to 1 hour before we recommend the change to users.
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.
Still, it makes sense to use the fully qualified name of the host rather than the IP address. IP addresses change, the goal of a FQN is to be static forever.
On Sep 24, 2015, at 5:46 AM, Collin Kidder <collink@kkmfg.com> wrote:
On Thu, Sep 24, 2015 at 5:38 AM, Michael Balzer <dexter@expeedo.de> wrote:
I just checked the DNS record for tmc.openvehicles.com:
tmc.openvehicles.com. 14399 IN A 54.197.255.127
I suggest reducing the TTL to 1 hour before we recommend the change to users.
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.
Brian
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@audiobanshee.com> wrote:
On Sep 24, 2015, at 5:46 AM, Collin Kidder <collink@kkmfg.com> wrote:
On Thu, Sep 24, 2015 at 5:38 AM, Michael Balzer <dexter@expeedo.de> wrote:
I just checked the DNS record for tmc.openvehicles.com:
tmc.openvehicles.com. 14399 IN A 54.197.255.127
I suggest reducing the TTL to 1 hour before we recommend the change to users.
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.
Brian
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi. Just tried to set the server ip parameter via the android app to tmc.openvehicles.com. Did a "Reset OVMS Modules" to be sure, and connection is fine. Carrier is Telenor in Norway
Regards, Karl Erik
On Fri, Sep 25, 2015 at 4:10 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
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 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@audiobanshee.com> wrote:
On Sep 24, 2015, at 5:46 AM, Collin Kidder <collink@kkmfg.com> wrote:
On Thu, Sep 24, 2015 at 5:38 AM, Michael Balzer <dexter@expeedo.de> wrote:
I just checked the DNS record for tmc.openvehicles.com:
tmc.openvehicles.com. 14399 IN A 54.197.255.127
I suggest reducing the TTL to 1 hour before we recommend the change to users.
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.
Brian
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 problems there.
It seems there is no general need for the GPRSDNS parameter?
Regards, Michael
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@audiobanshee.com <mailto:s2000@audiobanshee.com>> wrote:
On Sep 24, 2015, at 5:46 AM, Collin Kidder <collink@kkmfg.com <mailto:collink@kkmfg.com>> wrote:
On Thu, Sep 24, 2015 at 5:38 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I just checked the DNS record for tmc.openvehicles.com <http://tmc.openvehicles.com>:
tmc.openvehicles.com <http://tmc.openvehicles.com>. 14399 IN A 54.197.255.127
I suggest reducing the TTL to 1 hour before we recommend the change to users.
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.
Brian
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Switching the server to tmc.openvehicles.com worked great for me with old firmware.
I changed the address, established a live connection, then RESET and was able to get a live connection again a couple of minutes later.
Version 2.7.2/TR/V2, H2O Wireless (AT&T) in the US.
I'll update to the new firmware and try that as well.
Tom
Hi Mark,
Running one of Michael's recent builds of 2.7.2/RT/V2. "SERVER tmc.openvehicles.com" seems to work like a charm (still getting 'live' after 10/15 minutes at least) Using the 2€/month Free Mobile sim card in France (runs over Orange's 2G network as they don't have a 2G network themselves)
Best,
Julien ./.
Le 24/09/2015 08:07, Mark Webb-Johnson a écrit :
By the way, anyone brave enough to try putting in ‘tmc.openvehicles.com <http://tmc.openvehicles.com>’ into the ServerIP field, even without running this new code?
From what I can see (and tested here), if your ISP provides DNS servers as part of its GPRS profile, then it should just work. The change below is just to allow you to specify a DNS server directly (rather than rely on the ISP provided ones). Switching to use DNS names should allow us to avoid problems such as TMC experienced this past week.
Regards, Mark.
On 23 Sep, 2015, at 10:51 pm, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I’ve built a firmware for 2.8.1.
This includes all the changes since March 2014. Quite a few minor bug fixes and improvements.
Most noticeable new work is parameter #0x16, GPRSDNS. This can be configured as the fourth parameter to the GPRS command, and specifies the DNS server. It seems that the gprs protocol allows the mobile providers to push DNS server IPs to us, and the SIM908 recognises and stores those. But, for those providers that don’t support that, this parameter allows it to be explicitly set. We can now use DNS names (tmc.openvehicles.com <http://tmc.openvehicles.com/>), instead of IP addresses, for the Server IP parameter. This is a much better way of doing it.
I’ve also changed the COPS mechanism around a bit, to try to make it work better in marginal network conditions. In particular, in my garage ;-) The new logic is to wait for up to 5 minutes, after COPS fails, to see if we can get a network registration anyway. If we can, we continue with GPRS. If we can’t we try COPS again.
This is a release candidate now.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I entered tmc.openvehicles.com into my ServerIP field, hit back and the app closed. Upon restarting the OVMS app a moment later everything worked just fine. I am using
Firmware 2.6.5/TR/V2 App 1.65
Jack
On Sep 23, 2015, at 10:07 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
By the way, anyone brave enough to try putting in ‘tmc.openvehicles.com’ into the ServerIP field, even without running this new code?
From what I can see (and tested here), if your ISP provides DNS servers as part of its GPRS profile, then it should just work. The change below is just to allow you to specify a DNS server directly (rather than rely on the ISP provided ones). Switching to use DNS names should allow us to avoid problems such as TMC experienced this past week.
Regards, Mark.
On 23 Sep, 2015, at 10:51 pm, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve built a firmware for 2.8.1.
This includes all the changes since March 2014. Quite a few minor bug fixes and improvements.
Most noticeable new work is parameter #0x16, GPRSDNS. This can be configured as the fourth parameter to the GPRS command, and specifies the DNS server. It seems that the gprs protocol allows the mobile providers to push DNS server IPs to us, and the SIM908 recognises and stores those. But, for those providers that don’t support that, this parameter allows it to be explicitly set. We can now use DNS names (tmc.openvehicles.com), instead of IP addresses, for the Server IP parameter. This is a much better way of doing it.
I’ve also changed the COPS mechanism around a bit, to try to make it work better in marginal network conditions. In particular, in my garage ;-) The new logic is to wait for up to 5 minutes, after COPS fails, to see if we can get a network registration anyway. If we can, we continue with GPRS. If we can’t we try COPS again.
This is a release candidate now.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (8)
-
Collin Kidder -
HONDA S-2000 -
Jack West -
Julien (JaXX) Banchet -
Karl Erik Asbjørnsen -
Mark Webb-Johnson -
Michael Balzer -
Tom Saxton