Re: [ntp:questions] GPS Weakness Could Sink Wireless
Jan Ceuleers wrote: Interesting Light Reading article on the degree to which infrastructure (in casu wireless networks) is dependent on GPS timing signals, how little is needed to jam GPS (intentionally or otherwise), and what the impact of such jamming would be. It also talks about how PTP might or might not mitigate some of these issues. http://www.lightreading.com/mobile/mobile-security/were-jamming-gps-weakness-could-sink-wireless/d/d-id/706895 I spent 2.5 years as the architect of a national cell phone network replacement project so I do know a little about this issue: The core do use GPS to sync up the central time servers, but they also have Rb local osc, which means that even if you were able to jam the GPS reception in all the areas that have reference gps receivers, you would also have to wait long enough so that the Rb clocks would drift apart. For the GSM/3G/4G networks we have we don't need to know exactly what the time is (unlike the US CDMA setup which do need single-digit us time sync), we only need to keep the frequencies the same, and these only need to match up at the 20 ppm level in order to be able to do seamless base station handovers at bullet train speeds. 20 ppm is a _lot_ compared to the stability of an Rb osc, it would take at least some months before things got that bad, and if you had an adversary who could do wide-area GPS denial over several months, without getting detected and caught, then you have a _real_ problem. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
unruh un...@invalid.ca wrote: On 2013-12-12, Rob nom...@example.com wrote: Jan Ceuleers jan.ceule...@computer.org wrote: Interesting Light Reading article on the degree to which infrastructure (in casu wireless networks) is dependent on GPS timing signals, how little is needed to jam GPS (intentionally or otherwise), and what the impact of such jamming would be. It also talks about how PTP might or might not mitigate some of these issues. http://www.lightreading.com/mobile/mobile-security/were-jamming-gps-weakness-could-sink-wireless/d/d-id/706895 It depends on the structure of the network and the required accuracy. Remember that the usual GPS jamming methods are quite local in nature. You can jam my GPS but that won't take out my DCF77 receiver or the three GPS-synced servers I have configured as internet NTP sources. If they are in the same locality (or, depending on the strength of the jamming, local could mean within a few Km) they could also be jammed. Could could could But how can the jammer know what sources the victim is using? And where the receivers are located? When they want to jam everything for sure, they could just detonate a nuclear weapon in the ionosphere above the victim. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
John Hasler wrote: In any case designers of things like cell towers should no more assume that GPS is always just there than they should assume that electric power is always just there. This is a _basic_ shortcoming in CDMA as designed and in use. ( think of it as the NTSC of mobile phone systems ;-) uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP to multiple networks via one interface.
On 13/12/13 04:08, sc0tt.v3r...@gmail.com wrote: We have several VM's on this host on the same x.x.75.x network so we have set the xenserver to broadcast ntp (it syncs from network switches) and the VM's to be broadcast clients . NTP is working ok in this scenario. This sounds a horribly contorted way of virtualising the time; does Xen not provide any hooks to allow VMs to have direct access to the host time, or at least a perfect hardware timer and a means to set the initial software time? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP to multiple networks via one interface.
I don't know much about VMs and nothing about xenserver, so beware of free advice. Here are three suggestions off the top of my head. 1. Would it be possible to have NTPD broadcast on both networks, x.x.75.x and x.x.75.x? 2. Under Windows it appears to be possible to bridge connections on a dual homed host. Can xenserver bridge the two networks 75 and 69? 3. In a book on Java and networking the author offered an example of a repeater written in Java. All the program did, as I recall, was listen on one interface and retransmit some packets to another interface. I tried it, and it worked. I could try to find that book again, if it would help. -Original Message- From: questions-bounces+elliott.ch=verizon@lists.ntp.org [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of sc0tt.v3r...@gmail.com Sent: Thursday, December 12, 2013 11:09 PM To: questions@lists.ntp.org Subject: [ntp:questions] NTP to multiple networks via one interface. Hi, We have a xenserver host. We manage it via an interface on x.x.75.x which is the only network that is actually plumbed in on the host. It has other interfaces but they are virtualised by xen and don't have IP's. We have several VM's on this host on the same x.x.75.x network so we have set the xenserver to broadcast ntp (it syncs from network switches) and the VM's to be broadcast clients . NTP is working ok in this scenario. However we've added a new network to xenserver on x.x.69.x but VM's on this network don't receive the NTP broadcast packets as they don't have an interface on the x.x.75 network. Is there any way to get the NTP packets to all VM's without dual homing either the xenserver or the VM's. Thanks in advance, Scott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
I wrote: In any case designers of things like cell towers should no more assume that GPS is always just there than they should assume that electric power is always just there. Uwe writes: This is a _basic_ shortcoming in CDMA as designed and in use. ( think of it as the NTSC of mobile phone systems ;-) But Terje points out above that they use Rb oscillators so short (or medium) term loss of GPS by cell towers is not actually a problem. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
John Hasler wrote: I wrote: In any case designers of things like cell towers should no more assume that GPS is always just there than they should assume that electric power is always just there. Uwe writes: This is a _basic_ shortcoming in CDMA as designed and in use. ( think of it as the NTSC of mobile phone systems ;-) But Terje points out above that they use Rb oscillators so short (or medium) term loss of GPS by cell towers is not actually a problem. you still have the higher requirement of syncronicity limiting your design. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
On 12/7/2013 7:35 PM, Magnus Danielson wrote: On 12/07/2013 11:39 PM, Harlan Stenn wrote: Magnus Danielson writes: The drift-file-accelerated lock-in isn't robust. Current behavior of response isn't very useful for most people experiencing it. I'm not sure I'd agree with the word most. It's certainly worked very well on hundreds of machines where I've run it, and the feedback I've had from people when I've told them about iburst and drift files has been positive except when they've had Linux kernels that calculate a different clock frequency on a reboot. Experiencing the problem that is. When it works, it's a lovely tool. Sorry if the wording was unclear in that aspect. There are at least 2 other issues here. One goes to robust, and yes, we can do better with that. It's not yet clear to me that in the wider perspective this effort will be worthwhile. Well, you can either choose a rather simple back-out method or if you think it is worthwhile a more elaborate method. Getting cyclic re-set of time is a little to coarse a method. I think it is better to back-out and one way or another recover phase and frequency. The other goes to the amount of time it takes to adequately determine the offset and drift. With a good driftfile and iburst, ntpd will sync to a handful of PPM in about 11 seconds' time. We've been working on a project to produce sufficiently accurate offset and drift measurements at startup time, and the main problem here is that it can take minutes to figure this out well, and there is a significant need to get the time in the right ballpark at startup in less than a minute. These goals are mutually incompatible. The intent is to find a way to get there as well as possible, as quickly as possible. Getting the time in the right ball-park is by itself not all that hard. However, frequency takes time to learn and getting phase errors down quickly becomes an issue. NTP has as far as I have seen reduced loop bandwidth and at the same time reduced the capture range, and whenever you reduce the capture range you need to have heuristics to make sure you back-out if things get upset. Recovery of old state is good, but one needs to make sure that you don't loose that robustness. As for method of locking in quickly, that can be debated on in length. Cheers, Magnus It has been debated! It will probably be debated for the next thirty or forty years. There is something about the topic that seems to to encourage debate! ;-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
