Recently we have begun to have problems with our browsers stopping to work, ask it to go to a bookmark address and nothing happens, everything stops until an error message comes up that the address can not be found.
Thunderbird continues to receive e-mail unless I restart Thunderbird, then it is unable to find gmail.com. The problem exists on two F-19 computers and several Apple computers on the LAN, in fact I often become aware of the problem when someone complains that the internet connection is down.
I can always restore normal operation by re-starting the Viasat modem, a process that takes several minutes and is an annoyance.
I have determined that I can enter a numeric address e.g. 199.106.52.212 for viasat.com and that works as expected. At the request of viasat tech support I tried taking the router out of the circuit and connecting directly to the modem, that effected no change. Curiously, at the time this this morning when the problem was manifest tech support's "computer was down" which left me wondering if there was a correlation with my apparent DNS problem. I was asked to call back in a few hours, I did that.
The tech support person seemed to take offense at my claiming there was a DNS problem and went on to explain that I probably have a dhcp problem and we need to start by "re-setting my NIC." From there on the conversation began to deteriorate and she accused me of shouting at her, I was able to extricate myself gracefully after that and agree that I would call back when I had more time to devote to troubleshooting.
Am I missing some point here? Is there some connection between dhcp and dns that I am not aware of. My dhcp server is in the router and deals with about thirty addresses on the LAN and works faultlessly as far as I can see.
Any thoughts appreciated,
Bob
On 11/10/2013 14:57, Bob Goodwin ~ Zuni, Virginia, USA wrote:
Recently we have begun to have problems with our browsers stopping to work, ask it to go to a bookmark address and nothing happens, everything stops until an error message comes up that the address can not be found.
Thunderbird continues to receive e-mail unless I restart Thunderbird, then it is unable to find gmail.com. The problem exists on two F-19 computers and several Apple computers on the LAN, in fact I often become aware of the problem when someone complains that the internet connection is down.
I can always restore normal operation by re-starting the Viasat modem, a process that takes several minutes and is an annoyance.
I have determined that I can enter a numeric address e.g. 199.106.52.212 for viasat.com and that works as expected. At the request of viasat tech support I tried taking the router out of the circuit and connecting directly to the modem, that effected no change. Curiously, at the time this this morning when the problem was manifest tech support's "computer was down" which left me wondering if there was a correlation with my apparent DNS problem. I was asked to call back in a few hours, I did that.
The tech support person seemed to take offense at my claiming there was a DNS problem and went on to explain that I probably have a dhcp problem and we need to start by "re-setting my NIC." From there on the conversation began to deteriorate and she accused me of shouting at her, I was able to extricate myself gracefully after that and agree that I would call back when I had more time to devote to troubleshooting.
Am I missing some point here? Is there some connection between dhcp and dns that I am not aware of. My dhcp server is in the router and deals with about thirty addresses on the LAN and works faultlessly as far as I can see.
Any thoughts appreciated,
Bob
DHCP is used to distribute DNS resolvers to your LAN.
What resolvers do you get via DHCP?
(Check Network Manager or /etc/resolv.conf)
On 10/11/13 15:10, staticsafe wrote:
On 11/10/2013 14:57, Bob Goodwin ~ Zuni, Virginia, USA wrote:
Recently we have begun to have problems with our browsers stopping to work, ask it to go to a bookmark address and nothing happens, everything stops until an error message comes up that the address can not be found.
Thunderbird continues to receive e-mail unless I restart Thunderbird, then it is unable to find gmail.com. The problem exists on two F-19 computers and several Apple computers on the LAN, in fact I often become aware of the problem when someone complains that the internet connection is down.
I can always restore normal operation by re-starting the Viasat modem, a process that takes several minutes and is an annoyance.
I have determined that I can enter a numeric address e.g. 199.106.52.212 for viasat.com and that works as expected. At the request of viasat tech support I tried taking the router out of the circuit and connecting directly to the modem, that effected no change. Curiously, at the time this this morning when the problem was manifest tech support's "computer was down" which left me wondering if there was a correlation with my apparent DNS problem. I was asked to call back in a few hours, I did that.
The tech support person seemed to take offense at my claiming there was a DNS problem and went on to explain that I probably have a dhcp problem and we need to start by "re-setting my NIC." From there on the conversation began to deteriorate and she accused me of shouting at her, I was able to extricate myself gracefully after that and agree that I would call back when I had more time to devote to troubleshooting.
Am I missing some point here? Is there some connection between dhcp and dns that I am not aware of. My dhcp server is in the router and deals with about thirty addresses on the LAN and works faultlessly as far as I can see.
Any thoughts appreciated,
Bob
DHCP is used to distribute DNS resolvers to your LAN.
What resolvers do you get via DHCP?
(Check Network Manager or /etc/resolv.conf)
Well this is what I see:
[bobg@box10 ~]$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.1.1
192.168.1.1 is my Linksys E3000 DD-WRT router.
On 11/10/2013 15:17, Bob Goodwin ~ Zuni, Virginia, USA wrote:
Well this is what I see:
[bobg@box10 ~]$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.1.1
192.168.1.1 is my Linksys E3000 DD-WRT router.
DD-WRT usually runs a forwarder, check your router to see where it is forwarding DNS queries.
On 10/11/13 15:19, staticsafe wrote:
On 11/10/2013 15:17, Bob Goodwin ~ Zuni, Virginia, USA wrote:
Well this is what I see:
[bobg@box10 ~]$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.1.1
192.168.1.1 is my Linksys E3000 DD-WRT router.
DD-WRT usually runs a forwarder, check your router to see where it is forwarding DNS queries.
I used to subscribe to open.dns but with this satellite system it no longer functions and we are required to use their dns which is part of some optimization system Viasat uses.
DD-WRT configuration is set for the following:
182.63.128.68 and 182.63.128.69
Normally it works well and does its job instantly as far as I can tell.
On 11/10/2013 15:29, Bob Goodwin ~ Zuni, Virginia, USA wrote:
I used to subscribe to open.dns but with this satellite system it no longer functions and we are required to use their dns which is part of some optimization system Viasat uses.
DD-WRT configuration is set for the following:
182.63.128.68 and 182.63.128.69
Normally it works well and does its job instantly as far as I can tell.
dresden ~ # dig google.com @182.63.128.68
; <<>> DiG 9.9.3-P2 <<>> google.com @182.63.128.68 ;; global options: +cmd ;; connection timed out; no servers could be reached
dresden ~ # dig google.com @182.63.128.69
; <<>> DiG 9.9.3-P2 <<>> google.com @182.63.128.69 ;; global options: +cmd ;; connection timed out; no servers could be reached
That might be your problem, I would suggest testing yourself to see if they are down for you as well.
As a temporary measure you can use Google Public DNS: https://developers.google.com/speed/public-dns/
On 11/11/13 05:38, staticsafe wrote:
On 11/10/2013 15:29, Bob Goodwin ~ Zuni, Virginia, USA wrote:
I used to subscribe to open.dns but with this satellite system it no longer functions and we are required to use their dns which is part of some optimization system Viasat uses.
DD-WRT configuration is set for the following:
182.63.128.68 and 182.63.128.69
Normally it works well and does its job instantly as far as I can tell.
dresden ~ # dig google.com @182.63.128.68
; <<>> DiG 9.9.3-P2 <<>> google.com @182.63.128.68 ;; global options: +cmd ;; connection timed out; no servers could be reached
dresden ~ # dig google.com @182.63.128.69
; <<>> DiG 9.9.3-P2 <<>> google.com @182.63.128.69 ;; global options: +cmd ;; connection timed out; no servers could be reached
That might be your problem, I would suggest testing yourself to see if they are down for you as well.
As a temporary measure you can use Google Public DNS: https://developers.google.com/speed/public-dns/
whois shows those IP's belonging to DiGi Telecommunications Sdn Bhd in Malaysia.
On 10/11/13 16:38, staticsafe wrote:
DD-WRT configuration is set for the following:
182.63.128.68 and 182.63.128.69
Normally it works well and does its job instantly as far as I can tell.
dresden ~ # dig google.com @182.63.128.68
; <<>> DiG 9.9.3-P2 <<>> google.com @182.63.128.68 ;; global options: +cmd ;; connection timed out; no servers could be reached
dresden ~ # dig google.com @182.63.128.69
; <<>> DiG 9.9.3-P2 <<>> google.com @182.63.128.69 ;; global options: +cmd ;; connection timed out; no servers could be reached
That might be your problem, I would suggest testing yourself to see if they are down for you as well.
As a temporary measure you can use Google Public DNS: https://developers.google.com/speed/public-dns/
No, it won't allow any other DNS server, no matter what I configure it for it always goes to theirs, that's why I gave up open.dns. This was a change when they began to offer this high speed service, before that I always used some other DNS server.
[bobg@box10 ~]$ dig google.com @182.63.128.68
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> google.com @182.63.128.68 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61788 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;google.com. IN A
;; ANSWER SECTION: google.com. 1 IN A 74.125.224.206 google.com. 1 IN A 74.125.224.192 google.com. 1 IN A 74.125.224.193 google.com. 1 IN A 74.125.224.194 google.com. 1 IN A 74.125.224.195 google.com. 1 IN A 74.125.224.196 google.com. 1 IN A 74.125.224.197 google.com. 1 IN A 74.125.224.198 google.com. 1 IN A 74.125.224.199 google.com. 1 IN A 74.125.224.200 google.com. 1 IN A 74.125.224.201
;; Query time: 5 msec ;; SERVER: 182.63.128.68#53(182.63.128.68) ;; WHEN: Sun Nov 10 17:28:41 EST 2013 ;; MSG SIZE rcvd: 204
I'll try dig next time it goes out. I should have done that this morning when it went down.
Thanks for the help.
Bob
On 11/11/13 06:32, Bob Goodwin ~ Zuni, Virginia, USA wrote:
No, it won't allow any other DNS server, no matter what I configure it for it always goes to theirs, that's why I gave up open.dns. This was a change when they began to offer this high speed service, before that I always used some other DNS server.
[bobg@box10 ~]$ dig google.com @182.63.128.68
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> google.com @182.63.128.68 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61788 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;google.com. IN A
;; ANSWER SECTION: google.com. 1 IN A 74.125.224.206 google.com. 1 IN A 74.125.224.192 google.com. 1 IN A 74.125.224.193 google.com. 1 IN A 74.125.224.194 google.com. 1 IN A 74.125.224.195 google.com. 1 IN A 74.125.224.196 google.com. 1 IN A 74.125.224.197 google.com. 1 IN A 74.125.224.198 google.com. 1 IN A 74.125.224.199 google.com. 1 IN A 74.125.224.200 google.com. 1 IN A 74.125.224.201
;; Query time: 5 msec ;; SERVER: 182.63.128.68#53(182.63.128.68) ;; WHEN: Sun Nov 10 17:28:41 EST 2013 ;; MSG SIZE rcvd: 204
I'll try dig next time it goes out. I should have done that this morning when it went down.
Thanks for the help.
Quite some time ago it was determined that your ISP uses "transparent DNS proxy" to force you to use their DNS servers.
But, I really would ask them about their use of IP addresses.... as this is the output of whois 182.63.128.68
inetnum: 182.62.0.0 - 182.63.255.255 netname: DIGI-MY descr: DiGi Telecommunications Sdn Bhd descr: Lot 10, Jalan Delima 1/1, Subang Hi-Tech Industrial Park, descr: 40000 Shah Alam, Selangor Darul Ehsan, Malaysia country: MY admin-c: DIA1-AP tech-c: DI39-AP mnt-by: APNIC-HM mnt-lower: MAINT-MY-DIGI-SB mnt-routes: MAINT-MY-DIGI-SB status: ALLOCATED PORTABLE remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ remarks: This object can only be updated by APNIC hostmasters. remarks: To update this object, please contact APNIC remarks: hostmasters and include your organisation's account remarks: name in the subject line. remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ mnt-irt: IRT-DIGI-MY changed: hm-changed@apnic.net 20100224 source: APNIC
One wonders if their screwing with IP addresses doesn't fail at times. Maybe, sometimes, they actually transmit the DNS request to Malaysia. I would ask the ISP what the IP address of their DNS servers should be.....
On 10/11/13 18:24, Ed Greshko wrote:
Quite some time ago it was determined that your ISP uses "transparent DNS proxy" to force you to use their DNS servers.
But, I really would ask them about their use of IP addresses.... as this is the output of whois 182.63.128.68
inetnum: 182.62.0.0 - 182.63.255.255 netname: DIGI-MY descr: DiGi Telecommunications Sdn Bhd descr: Lot 10, Jalan Delima 1/1, Subang Hi-Tech Industrial Park, descr: 40000 Shah Alam, Selangor Darul Ehsan, Malaysia country: MY admin-c: DIA1-AP tech-c: DI39-AP mnt-by: APNIC-HM mnt-lower: MAINT-MY-DIGI-SB mnt-routes: MAINT-MY-DIGI-SB status: ALLOCATED PORTABLE remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ remarks: This object can only be updated by APNIC hostmasters. remarks: To update this object, please contact APNIC remarks: hostmasters and include your organisation's account remarks: name in the subject line. remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ mnt-irt: IRT-DIGI-MY changed:hm-changed@apnic.net 20100224 source: APNIC
One wonders if their screwing with IP addresses doesn't fail at times. Maybe, sometimes, they actually transmit the DNS request to Malaysia. I would ask the ISP what the IP address of their DNS servers should be.....
I don't remember how I got those DNS addresses but they have been working for a couple of years without a problem until recently. I will look into it some more tomorrow.
Bob Goodwin ~ Zuni, Virginia, USA writes:
No, it won't allow any other DNS server, no matter what I configure it for it always goes to theirs, that's why I gave up open.dns. This was a change
DD-WRT does not give you the option to use fixed DNS servers, instead of whatever DHCP servers it gets via DHCP from your ISP?
I'm surprised to hear that. Or, rereading what you earlier wrote, maybe you're saying that your ISP blocks port 53 traffic, and will only let you use their DNS servers.
On 10/11/13 19:28, Sam Varshavchik wrote:
Bob Goodwin ~ Zuni, Virginia, USA writes:
No, it won't allow any other DNS server, no matter what I configure it for it always goes to theirs, that's why I gave up open.dns. This was a change
DD-WRT does not give you the option to use fixed DNS servers, instead of whatever DHCP servers it gets via DHCP from your ISP?
I'm surprised to hear that. Or, rereading what you earlier wrote, maybe you're saying that your ISP blocks port 53 traffic, and will only let you use their DNS servers.
DD-WRT will let me use any DNS I want, it's Viasat's system that changes it. They do some sort of caching to reduce traffic through the satellite apparently ... Initially I had it configured for open.dns but it wasn't long before I found it wasn't going there.
Bob Goodwin ~ Zuni, Virginia, USA writes:
On 10/11/13 19:28, Sam Varshavchik wrote:
Bob Goodwin ~ Zuni, Virginia, USA writes:
No, it won't allow any other DNS server, no matter what I configure it for it always goes to theirs, that's why I gave up open.dns. This was a change
DD-WRT does not give you the option to use fixed DNS servers, instead of whatever DHCP servers it gets via DHCP from your ISP?
I'm surprised to hear that. Or, rereading what you earlier wrote, maybe you're saying that your ISP blocks port 53 traffic, and will only let you use their DNS servers.
DD-WRT will let me use any DNS I want, it's Viasat's system that changes it. They do some sort of caching to reduce traffic through the satellite apparently ... Initially I had it configured for open.dns but it wasn't long before I found it wasn't going there.
The only option I can think of is to use an SSL-based VPN tunnel, to a friendly VPS provider. Of course, this is going to kill your bandwidth.
On Sun, Nov 10, 2013 at 5:41 PM, Bob Goodwin ~ Zuni, Virginia, USA bobgoodwin@wildblue.net wrote:
On 10/11/13 19:28, Sam Varshavchik wrote:
Bob Goodwin ~ Zuni, Virginia, USA writes:
No, it won't allow any other DNS server, no matter what I configure it for it always goes to theirs, that's why I gave up open.dns. This was a change
DD-WRT does not give you the option to use fixed DNS servers, instead of whatever DHCP servers it gets via DHCP from your ISP?
I'm surprised to hear that. Or, rereading what you earlier wrote, maybe you're saying that your ISP blocks port 53 traffic, and will only let you use their DNS servers.
DD-WRT will let me use any DNS I want, it's Viasat's system that changes it. They do some sort of caching to reduce traffic through the satellite apparently ... Initially I had it configured for open.dns but it wasn't long before I found it wasn't going there.
Wild guess: maybe the DNS information you have manually provided to DD-WRT got made wrong by changes in the network (seems plausible given the IP lookup data others have given), and something's going wrong with the magic they use to override other DNS servers besides theirs (including the one you're using which you thought was valid but perhaps has now changed).
Try reconfiguring DD-WRT to get its DNS information from your ISP's DHCP server and see if your problem persists. (I believe you just set Static DNS to all 0s in DD-WRT to accomplish this.)
-T.C.
On 11/10/2013 02:29 PM, Bob Goodwin ~ Zuni, Virginia, USA wrote:
DD-WRT configuration is set for the following:
182.63.128.68 and 182.63.128.69
Use 8.8.8.8 and 8.8.4.4 (Google Public DNS Servers) or 208.67.222.222 and 208.67.220.220 (OpenDNS)
The problem is probably with your ISP's DNS servers.
On 10/11/13 19:12, Steven Stern wrote:
Use 8.8.8.8 and 8.8.4.4 (Google Public DNS Servers) or 208.67.222.222 and 208.67.220.220 (OpenDNS)
The problem is probably with your ISP's DNS servers.
Yes, those worked well when I was able to use them, this system goes to it's own DNS no matter what I ask it, and the DNS they provide works well most of the time, it's just that recently I have been seeing it fail and fixing it requires rebooting the Viasat modem.
I need to convince them they have a problem, will check more next time it goes out.
Bob Goodwin ~ Zuni, Virginia, USA writes:
On 10/11/13 19:12, Steven Stern wrote:
Use 8.8.8.8 and 8.8.4.4 (Google Public DNS Servers) or 208.67.222.222 and 208.67.220.220 (OpenDNS)
The problem is probably with your ISP's DNS servers.
Yes, those worked well when I was able to use them, this system goes to it's own DNS no matter what I ask it, and the DNS they provide works well most of the time, it's just that recently I have been seeing it fail and fixing it requires rebooting the Viasat modem.
I need to convince them they have a problem, will check more next time it goes out.
Get someone on the horn who has a minimum of an understanding, and tell them you can't ping their DNS servers.
On 10/11/13 19:53, Sam Varshavchik wrote:
I need to convince them they have a problem, will check more next time it goes out.
Get someone on the horn who has a minimum of an understanding, and tell them you can't ping their DNS servers.
Yes, I intend to do that, thought I had enough information this morning but the tech support person took offense at being told their DNS was failing and began telling me some bazaar things, she was confusing mac addresses with URLs, wanted to test my NIC. I explained that the trouble was with two Linux computers and several Apple Mac devices. I was getting no where ... :-(
I will try again when the problem reoccurs.
Allegedly, on or about 10 November 2013, Bob Goodwin ~ Zuni, Virginia, USA sent:
I used to subscribe to open.dns but with this satellite system it no longer functions and we are required to use their dns which is part of some optimization system Viasat uses.
There is a chance that you could still use an outside DNS service, if you can access one that uses a different port than your ISP is intercepting. This would, also, depend on you either making up TCP/IP redirection rules on your gateway so your clients queries go to that unusual port. Or, running your own DNS server on a PC. You'd configure your clients to use that DNS server as a normal DNS server, and you'd configure the DNS server to do the unusual port queries.
ISPs are notorious for having awful DNS services, particularly ones that play silly games with forcing you to use them. So running your own DNS server, that's totally under your control, can be quite advantageous.
The mini DNS servers in some modem/routers are awful, and have no configuration options. Some modem/routers don't have a DNS server, they simply act as a proxy between you and the ISP supplied DNS server IPs.
On 10/11/13 19:54, Tim wrote:
There is a chance that you could still use an outside DNS service, if you can access one that uses a different port than your ISP is intercepting. This would, also, depend on you either making up TCP/IP redirection rules on your gateway so your clients queries go to that unusual port. Or, running your own DNS server on a PC. You'd configure your clients to use that DNS server as a normal DNS server, and you'd configure the DNS server to do the unusual port queries.
ISPs are notorious for having awful DNS services, particularly ones that play silly games with forcing you to use them. So running your own DNS server, that's totally under your control, can be quite advantageous.
The mini DNS servers in some modem/routers are awful, and have no configuration options. Some modem/routers don't have a DNS server, they simply act as a proxy between you and the ISP supplied DNS server IPs.
Yes,when I began using this service I was advised not to try to work around their system since it would result in my being charged for higher usage and my allotment is limited. Further more their system does other things that I don't want to lose, namely the "free time" during the wee hours when I can allow the Apple computers to connect with iCloud, etc. DD-WRT is configured to deal with thatand as I say it all works except for this intermittent loss of DNS that has cropped up recently.
Normally the system works well, I don't want to change it, I just need to convince them there is a DNS problem and I think it is in their system. This thread has provided some help in how to do that.
Allegedly, on or about 10 November 2013, Bob Goodwin ~ Zuni, Virginia, USA sent:
when I began using this service I was advised not to try to work around their system since it would result in my being charged for higher usage and my allotment is limited.
Unless you're doing something odd, the amount of traffic from DNS data is minuscule compared to everything else.
On 11/11/13 07:18, Tim wrote:
Allegedly, on or about 10 November 2013, Bob Goodwin ~ Zuni, Virginia, USA sent:
when I began using this service I was advised not to try to work around their system since it would result in my being charged for higher usage and my allotment is limited.
Unless you're doing something odd, the amount of traffic from DNS data is minuscule compared to everything else.
But what if they are caching stuff, e.g. foxnews, some popular video clips, etc. and delivering them to the user without going through the satellite loop? I don't know what they are doing but they claim to be "optimizing" the system with their caching. I'm not concerned about the trivial usage attributable to DNS. I just want it to work. As it has been I've had to restart the Viasat modem several times a week, an annoyance I will have to put up with it seems, my experience has been that such things eventually change, hopefully for the better.
Bob Goodwin ~ Zuni, Virginia, USA writes:
But what if they are caching stuff, e.g. foxnews, some popular video clips, etc. and delivering them to the user without going through the satellite loop? I don't know what they are doing but they claim to be "optimizing" the system with their caching. I'm not concerned about the trivial usage attributable to DNS. I just want it to work. As it has been I've had to restart the Viasat modem several times a week, an annoyance I will have to put up with it seems, my experience has been that such things eventually change, hopefully for the better.
Don't exclude the possibility that the modem itself is flipping out. My DSL started going down once a week or so, some years ago. Powercycling the modem always put me back online. Troubleshooting with the ISP wasn't very productive. I ended up buying a new modem, and that was it. The old modem is still sitting in a dusty cabinet, and I actually pulled it out, in a pinch, when I suspected a problem with my current modem.
On 11/11/13 08:40, Sam Varshavchik wrote:
Don't exclude the possibility that the modem itself is flipping out. My DSL started going down once a week or so, some years ago. Powercycling the modem always put me back online. Troubleshooting with the ISP wasn't very productive. I ended up buying a new modem, and that was it. The old modem is still sitting in a dusty cabinet, and I actually pulled it out, in a pinch, when I suspected a problem with my current modem.
I would not hesitate to try a new one if it was readily available to me but as I understandit the modem is unique to their service/system. The old one had transmit and receive coax cables between it and the antenna, this one uses only one coax but I believe part of the radio circuitry is in the modem with intermediate frequency signaling between it and the antenna. It needs to do things like control the subscriber transmitter power with varying weather conditions, stuff that would be different than a cable modem.
Tech support did suggest that it could be a modem problem but I generally try to avoid going through their troubleshooting procedure, at least leave that 'til last..
Tim:
Unless you're doing something odd, the amount of traffic from DNS data is minuscule compared to everything else.
Bob Goodwin:
But what if they are caching stuff, e.g. foxnews, some popular video clips, etc. and delivering them to the user without going through the satellite loop? I don't know what they are doing but they claim to be "optimizing" the system with their caching.
That'd be HTTP caching. They don't need to subvert DNS records for you to see cached websites. Unless they're doing something stupid, your web requests are still made of the original IPs, just the results are cached.
I have the same thing, here, on my LAN. A Squid proxy server, so that if I have guests doing the "look at this" thing amongst themselves, or a bunch of Windows PCs doing updates, everyone after the first query sees the cached version.
You can try it out, and see. Find a public DNS server that you can access on a different-than-usual port. Make a rule on your gateway that connection attempts to your router IP and DNS port get redirected to the external DNS server on the unusual port. It's probably possible to make an outgoing redirection rule on the PC that your testing, itself.
As far as them optimising things, with satellite internet, there's a prolonged propagation delay. So them doing local caching means that you get to see cached data on this side of the satellite, rather than have to wait for it to come through it.
Years ago I used an ISP that did that sort of thing, their service was dreadful. Everything was late, worse than dial-up. Their crap performance was the thing that pushed me into running my own DNS servers. Their DNS servers were even worse than their everything else that they did. Frequently, it could take half a minute for it to return a result. When you consider that way too many pages are a construct of data from here, there, and everywhere, not just the sites own service, it could take an age to load a page.
Any service that mucks you about, and fobs you off, and leaves you trying to resolve a problem for days on end, doesn't deserve your custom. Especially if the problem is theirs.
On 11/11/13 19:12, Tim wrote:
That'd be HTTP caching. They don't need to subvert DNS records for you to see cached websites. Unless they're doing something stupid, your web requests are still made of the original IPs, just the results are cached.
I have the same thing, here, on my LAN. A Squid proxy server, so that if I have guests doing the "look at this" thing amongst themselves, or a bunch of Windows PCs doing updates, everyone after the first query sees the cached version.
You can try it out, and see. Find a public DNS server that you can access on a different-than-usual port. Make a rule on your gateway that connection attempts to your router IP and DNS port get redirected to the external DNS server on the unusual port. It's probably possible to make an outgoing redirection rule on the PC that your testing, itself.
As far as them optimising things, with satellite internet, there's a prolonged propagation delay. So them doing local caching means that you get to see cached data on this side of the satellite, rather than have to wait for it to come through it.
Years ago I used an ISP that did that sort of thing, their service was dreadful. Everything was late, worse than dial-up. Their crap performance was the thing that pushed me into running my own DNS servers. Their DNS servers were even worse than their everything else that they did. Frequently, it could take half a minute for it to return a result. When you consider that way too many pages are a construct of data from here, there, and everywhere, not just the sites own service, it could take an age to load a page.
Any service that mucks you about, and fobs you off, and leaves you trying to resolve a problem for days on end, doesn't deserve your custom. Especially if the problem is theirs.
As I said I don't know exactly what they are doing but I do know that I'm not smart enough to work around it. I spent quite a bit of effort Googling "Viasat Exede" and it seems there's a dearth of information other than sales hype. Here's an excerpt from a interview I did find, still not very informative:
"The teleports are associated regionally with customers, so there's no dynamic routing being done by the satellite. "If we did routing in the satellite, we'd be getting about 10 gigabits of throughput," Dankberg said. "With bridging, we get more than 10 times that." Just for scale, 140 gigabits per second is 20 times the bandwidth capability of the previously existing WildBlue satellite service. "The two largest satellite operators have about a hundred satellites," Dankberg said, "and between them they have the same bandwidth as this one satellite."That sort of capacity, he says, alters the economics of satellite broadband.
There are some things bandwidth can't overcome, and one of them is the laws of physics. Satellite is still prone to latency, which means it's not the best choice for applications that need a short time-of-flight—like online gaming, for example (unless you're a big fan of lag). "We tell people up front if they're looking for a gaming connection, this isn't it," Dankberg conceded.
There's also a small, but noticeable delay on voice-over-IP phone calls over Exede, but not any more than a typical wireless call. I placed a call over a VoIP phone tethered to an Exede home unit, and the conversation was better than cellular quality."
Source: http://arstechnica.com/business/2012/01/how-viasats-exede-makes-satellite-br...
He makes it sound that it's essential to stick with their software, some parts of which are apparently contained in the modem. As I said I am quite happy with the service, it normally works well and there is nothing better available to me. I also recently subscribed to their voip service and find it superior to the cell phone [we discontinued the land-line long ago] there is usually no detectable delay due to transit time to the satellite. My only problem was the intermittent DNS. It has not failed today that I am aware of. The kids are not happy due to it's inability to handle on-line gaming with their brother in Chicago. That is not a requirement in my book.
If anyone understands what they are doing and can explain it to me I am interested.
Bob
Allegedly, on or about 11 November 2013, Bob Goodwin sent:
He makes it sound that it's essential to stick with their software, some parts of which are apparently contained in the modem. As I said I am quite happy with the service, it normally works well and there is nothing better available to me. I also recently subscribed to their voip service and find it superior to the cell phone [we discontinued the land-line long ago] there is usually no detectable delay due to transit time to the satellite. My only problem was the intermittent DNS.
Looking at that page, from what I can gather. They have a ground based network, with high speed and high bandwidth. It connects to you, other users, and probably other local services. The satellite is their link to things further away, and has latency by still high bandwidth, so things work well enough by the time that they've started and filled up a cache (e.g. watching streaming video). The modem has some custom compression to speed thing up even more - though any old BBS SysOp can tell you that you can only speed up still-compressible data, that way, not all data.
So, again, I say just find yourself a decent DNS server, and use it instead. You'll still be going through their caches and proxies for the data, you'll just be getting the addresses quicker.
Next time it happens, start playing with the dig tool. Make queries against your router, and against the DNS IPs the ISP provides (to the router), and try some external DNS servers that have different ports (the dig command lets you specify ports, read the man page, brief outline below). Do queries for different addresses, if you keep querying the same address, you'll just get results from a cache.
dig @server -p number address
Substituting "server" for the address of server you're going to query, "number" for the port number you're querying through (if not the usual port 53), and address for the address you want to query.
Have you tried OpenDNS on port 5353 instead of port 53? If you're lucky, your ISP is only doing a simplistic buggery of DNS on 53.
e.g. dig @208.67.222.222 -p 5353 www.bbc.co.uk ; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.fc17 <<>> @208.67.222.222 -p 5353 www.bbc.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61634 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.bbc.co.uk. IN A
;; ANSWER SECTION: www.bbc.co.uk. 291 IN CNAME www.bbc.net.uk. www.bbc.net.uk. 165 IN A 212.58.244.68 www.bbc.net.uk. 165 IN A 212.58.244.69
;; Query time: 98 msec ;; SERVER: 208.67.222.222#5353(208.67.222.222) ;; WHEN: Wed Nov 13 01:03:31 CST 2013 ;; MSG SIZE rcvd: 100
I get about a quarter or third of that time if I try other DNS servers. My own took 1500 mS the first time, then 6 ms for subsequent attempts (local cache is much quicker than internet propagation delays). Queries for other addresses took about 100 mS, so the BBC query must have been answered by something further away. My server checks it cache, then (if it doesn't have an answer) goes out to the root servers (to find out who would know the answer), then whatever servers the roots tell it, like a proper traditional DNS server.
I consider 1.5 secs for a response to be unusually long. I couldn't put up with that, or worse, consistently.
On 11/12/13 22:41, Tim wrote:
Next time it happens, start playing with the dig tool. Make queries against your router, and against the DNS IPs the ISP provides (to the router), and try some external DNS servers that have different ports (the dig command lets you specify ports, read the man page, brief outline below). Do queries for different addresses, if you keep querying the same address, you'll just get results from a cache.
If the ISP is doing transparent DNS proxy I seriously doubt that any of that matters.
On Tue, 2013-11-12 at 23:09 +0800, Ed Greshko wrote:
If the ISP is doing transparent DNS proxy I seriously doubt that any of that matters.
It depends on how they're doing it. If they simply intercept port 53 traffic, then not using port 53 for your queries will bypass it. But if they also snoop on some other ports, or snoop on all traffic for things that look like DNS queries, then you're screwed.
My opinion of ISPs that do transparent proxying, is rather low. I understand the point of view that some do that, so users don't have to configure their software. But my experience has been that ISPs do it to: Lower their operating costs, while still charging you the same, and to rake in more customers than their equipment (otherise) has bandwidth for.
On 12/11/13 09:41, Tim wrote:
I get about a quarter or third of that time if I try other DNS servers. My own took 1500 mS the first time, then 6 ms for subsequent attempts (local cache is much quicker than internet propagation delays). Queries for other addresses took about 100 mS, so the BBC query must have been answered by something further away. My server checks it cache, then (if it doesn't have an answer) goes out to the root servers (to find out who would know the answer), then whatever servers the roots tell it, like a proper traditional DNS server.
I consider 1.5 secs for a response to be unusually long. I couldn't put up with that, or worse, consistently.
I changed the router configuration to use 208.67.229.220:5353 and 208.67.222.222:5353 and see the following:
[root@box10 bobg]# dig www.bbc.co.uk
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> www.bbc.co.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35870 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.bbc.co.uk. IN A
;; ANSWER SECTION: www.bbc.co.uk. 176 IN CNAME www.bbc.net.uk. www.bbc.net.uk. 182 IN A 212.58.246.93 www.bbc.net.uk. 182 IN A 212.58.246.92
;; Query time: 616 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Nov 12 11:46:20 EST 2013 ;; MSG SIZE rcvd: 100
As you say the cache is much faster, 2 ms as opposed to 616 ms.
But I still don't know what DNS address it actually goes to, how do I find that?
On 11/12/2013 12:00 PM, Bob Goodwin ~ Zuni, Virginia, USA wrote:
On 12/11/13 09:41, Tim wrote:
I get about a quarter or third of that time if I try other DNS servers. My own took 1500 mS the first time, then 6 ms for subsequent attempts (local cache is much quicker than internet propagation delays). Queries for other addresses took about 100 mS, so the BBC query must have been answered by something further away. My server checks it cache, then (if it doesn't have an answer) goes out to the root servers (to find out who would know the answer), then whatever servers the roots tell it, like a proper traditional DNS server.
I consider 1.5 secs for a response to be unusually long. I couldn't put up with that, or worse, consistently.
I changed the router configuration to use 208.67.229.220:5353 and 208.67.222.222:5353 and see the following:
[root@box10 bobg]# dig www.bbc.co.uk
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> www.bbc.co.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35870 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.bbc.co.uk. IN A
;; ANSWER SECTION: www.bbc.co.uk. 176 IN CNAME www.bbc.net.uk. www.bbc.net.uk. 182 IN A 212.58.246.93 www.bbc.net.uk. 182 IN A 212.58.246.92
;; Query time: 616 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Nov 12 11:46:20 EST 2013 ;; MSG SIZE rcvd: 100
As you say the cache is much faster, 2 ms as opposed to 616 ms.
But I still don't know what DNS address it actually goes to, how do I find that?
The DNS that is in your router is what IP it goes to, which in most cases your Internet Provider .
In /etc/resolve.conf I put the Google DNS 8.8.8.8 and 8.8.0.0 and get better results.
You can goto http://getip.com and it will tell you what your IP is. Hech it will even show you and everybody where you live.
On 12/11/13 13:03, Jim wrote:
The DNS that is in your router is what IP it goes to, which in most cases your Internet Provider .
Yes, normally you would expect that but Viasat Exede forces you to their DNS no matter what you set your router for and there is nothing wrong with the way that works as long as it is working normally. I have had some intermittent problems recently but since my complaint yesterday it has worked well. Coincidence perhaps?
Bob
On 11/12/2013 01:19 PM, Bob Goodwin ~ Zuni, Virginia, USA wrote:
On 12/11/13 13:03, Jim wrote:
The DNS that is in your router is what IP it goes to, which in most cases your Internet Provider .
Yes, normally you would expect that but Viasat Exede forces you to their DNS no matter what you set your router for and there is nothing wrong with the way that works as long as it is working normally. I have had some intermittent problems recently but since my complaint yesterday it has worked well. Coincidence perhaps?
Bob
The DNS numbers you have in /etc/resolv.conf would be the DNS-IP that it would goto.
At least that is my understanding.
On 12/11/13 13:28, Jim wrote:
On 11/12/2013 01:19 PM, Bob Goodwin ~ Zuni, Virginia, USA wrote:
On 12/11/13 13:03, Jim wrote:
The DNS that is in your router is what IP it goes to, which in most cases your Internet Provider .
Yes, normally you would expect that but Viasat Exede forces you to their DNS no matter what you set your router for and there is nothing wrong with the way that works as long as it is working normally. I have had some intermittent problems recently but since my complaint yesterday it has worked well. Coincidence perhaps?
Bob
The DNS numbers you have in /etc/resolv.conf would be the DNS-IP that it would goto.
At least that is my understanding.
It goes to the router, 192.168.1.1 and presently the router is set to use open.dns.
[bobg@box10 ~]$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.1.1
On 12Nov2013 13:19, Bob Goodwin bobgoodwin@wildblue.net wrote:
[...] I have had some intermittent problems recently but since my complaint yesterday it has worked well. Coincidence perhaps?
Maybe, maybe not. If one of their DNS servers was flakey, your complaint would not be alone. If they replaced/repaired their server, everyone will see the fix.
And the front line phone staff may be unaware of the issue.
On 11/12/2013 04:03 PM, Cameron Simpson wrote:
And the front line phone staff may be unaware of the issue.
Speaking as somebody who did phone tech support for an ISP, that's quite possible. Granted, we did have a page that (supposedly) listed all known outages, but it was almost never up to date and usually just claimed that all was OK even when our email servers had been down for hours, or something like that.
On Wed, 2013-11-13 at 11:03 +1100, Cameron Simpson wrote:
Maybe, maybe not. If one of their DNS servers was flakey, your complaint would not be alone. If they replaced/repaired their server, everyone will see the fix.
And the front line phone staff may be unaware of the issue.
It depends on the ISP. I can mention two major ones in this country, Optus and Telstra, who don't just service customers, but are backbones for most other smaller ISPs, who will flatly refuse to admit that there's ever anything wrong with their equipment, will endlessly tell you reset your equipment, despite all evidence to the contrary that their system is up the creek - e.g. their support newsgroup is full of customers complaining that the DNS server isn't working. So I am as dismissive of anything they say, as they are of their customer complaints (they're as arrogant as that against their phone customers, as well).
I could mention an older ISP that doesn't exist anymore, Picknowl, that would get back to your support query and say they've checked their equipment, noticed something wrong and reset it, or didn't find a problem but reset it just in case. And, back in the dialup days, if you had trouble connecting, they'd ask you to dial a specific number, and they'd watch their terminal to check what your system was trying to do as it logged in. I had more faith in them. Unfortunately, they got bought out and ruined.
Another ISP (Adam) seems to publish their internal fault reports on their status pages. You can see fault history, scheduled maintenance, reported faults, and expected repair times. It's usually kept up to date quite promptly.
But if you're going to make a fault report to an ISP, with any hope of getting a proper response, you need to make a proper report that they can follow up on. Mention your own IP, addresses you've tried to access but failed, your time and timezone - so they can check their logs, not just their equipment at the current moment.
On 11/12/2013 10:03 AM, Jim wrote:
You can goto http://getip.com and it will tell you what your IP is. Hech it will even show you and everybody where you live.
Actually, no. It won't. What it shows is where the DSLAM you're connected to is, and in my case, that's several miles away.
Bob Goodwin:
I changed the router configuration to use 208.67.229.220:5353 and 208.67.222.222:5353 and see the following:
[root@box10 bobg]# dig www.bbc.co.uk
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> www.bbc.co.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35870 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.bbc.co.uk. IN A
;; ANSWER SECTION: www.bbc.co.uk. 176 IN CNAME www.bbc.net.uk. www.bbc.net.uk. 182 IN A 212.58.246.93 www.bbc.net.uk. 182 IN A 212.58.246.92
;; Query time: 616 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Nov 12 11:46:20 EST 2013 ;; MSG SIZE rcvd: 100
As you say the cache is much faster, 2 ms as opposed to 616 ms.
But I still don't know what DNS address it actually goes to, how do I find that?
Just to be clear, DNS means domain name *system* not *server*. So, are you asking you're not sure what DNS server has responded, or you don't know how to read the answers you got back from dig?
Looking at your above dig results:
Your command line asked whatever your computer's default DNS server was (configured in /etc/resolv.conf) to look up www.bbc.co.uk.
The ANSWER section gives results about your query addresses. A query for www.bbc.co.uk gets a CNAME answer of www.bbc.net.uk (i.e. it says use that second name, instead). Followed by two answers for IPs for www.bbc.net.uk, saying to use either 212.58.246.93 or 212.58.246.92 (either will do).
The QUERY TIME section says the server that answered was 192.168.1.1, so that would be the first DNS server address in your /etc/resolv.conf file. Second or third server addresses in that config file will only be consulted if the first one failed to respond, and there'd be a seriously long time-out period before that happened.
Your router, at 192.168.1.1 may have tried to query 208.67.229.220:5353 and 208.67.222.222:5353 to find the results (I don't know if your router/modem can accept port numbers attached to the IPs, like that), and may have connected to them. Or, your ISP may have intercepted that. You might try using those IPs and ports with the dig command, directly.
By default, dig will use your pre-configured DNS servers (in your /etc/resolv.conf file) unless you specify a server to query on its command line. That is *which* server to ask, not just what address you want to look up.
On 11/12/2013 10:13 PM, Tim issued this missive:
Bob Goodwin:
I changed the router configuration to use 208.67.229.220:5353 and 208.67.222.222:5353 and see the following:
[root@box10 bobg]# dig www.bbc.co.uk
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> www.bbc.co.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35870 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.bbc.co.uk. IN A
;; ANSWER SECTION: www.bbc.co.uk. 176 IN CNAME www.bbc.net.uk. www.bbc.net.uk. 182 IN A 212.58.246.93 www.bbc.net.uk. 182 IN A 212.58.246.92
;; Query time: 616 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Nov 12 11:46:20 EST 2013 ;; MSG SIZE rcvd: 100
As you say the cache is much faster, 2 ms as opposed to 616 ms.
But I still don't know what DNS address it actually goes to, how do I find that?
Just to be clear, DNS means domain name *system* not *server*. So, are you asking you're not sure what DNS server has responded, or you don't know how to read the answers you got back from dig?
Looking at your above dig results:
Your command line asked whatever your computer's default DNS server was (configured in /etc/resolv.conf) to look up www.bbc.co.uk.
The ANSWER section gives results about your query addresses. A query for www.bbc.co.uk gets a CNAME answer of www.bbc.net.uk (i.e. it says use that second name, instead). Followed by two answers for IPs for www.bbc.net.uk, saying to use either 212.58.246.93 or 212.58.246.92 (either will do).
The QUERY TIME section says the server that answered was 192.168.1.1, so that would be the first DNS server address in your /etc/resolv.conf file. Second or third server addresses in that config file will only be consulted if the first one failed to respond, and there'd be a seriously long time-out period before that happened.
Your router, at 192.168.1.1 may have tried to query 208.67.229.220:5353 and 208.67.222.222:5353 to find the results (I don't know if your router/modem can accept port numbers attached to the IPs, like that), and may have connected to them. Or, your ISP may have intercepted that. You might try using those IPs and ports with the dig command, directly.
By default, dig will use your pre-configured DNS servers (in your /etc/resolv.conf file) unless you specify a server to query on its command line. That is *which* server to ask, not just what address you want to look up.
If you want to use dig to query a DNS server that is NOT in your /etc/resolv.conf file, use something like:
dig @208.67.229.220 -p 5353 www.bbc.co.uk
The "@ip-address" would be the address of the DNS server you want to query. If you don't want to use the standard DNS port of 53, then include the "-p <val>" with "<val>" the non-standard port number to use (e.g. port 5353 in this example). See "man dig" for other options. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Diplomacy: The art of saying "Nice doggy!" until you can find a - - big enough rock. - ----------------------------------------------------------------------
On 11Nov2013 20:21, Bob Goodwin bobgoodwin@wildblue.net wrote: [...]
Source: http://arstechnica.com/business/2012/01/how-viasats-exede-makes-satellite-br...
He makes it sound that it's essential to stick with their software, some parts of which are apparently contained in the modem. As I said I am quite happy with the service, it normally works well and there is nothing better available to me. [...] If anyone understands what they are doing and can explain it to me I am interested.
If it is like the setup in our Gilat satellite modem here, there are two primary things going on. (Based on reading scattered stuff on the net when trying to debug an annoying problem some months ago.)
The modem/satellite system does HTTP prefetching; when you fetch a web page the traffic is sniffed and requests for the page content (images etc) are prefetched. This step may happen upstream of the modem (eg in a proxy at the ISP) or it may happen in the modem - this is unclear; that "HTTP acceleration" is a modem-side setting suggests it may be happening in the modem.
The other thing the Gilat modems do is "TCP acceleration". I gather a TCP connection is terminated localy at the modem, and the data stream sent with a more efficient protocol over the satellite section of the link and a TCP connection established on the upstream (far side of you->satellite->downstation) to carry the traffic from there to the target server. The TCP handshake takes place in real time - the modem does not falsely complete a connection only to have upstream fail, but past that the traffic is proxied.
This may sound ineffectual, but in fact it has throughput benefits.
The TCP connection from upstream to the target server can transfer data rapidly across the fast and low latency ground based network. The data beamed to/from the satellite is sent directly using the satellite specific data integrity protocols without the TCP packet tracking protocol, and the data from your host to the modem travels with low round trip latency to/from the modem
I'm speaking here of the TCP packet ACK stuff, which is now you<->modem and upstream<->target-server.
This results in greater throughput.
Cheers,
On 10Nov2013 20:18, Bob Goodwin bobgoodwin@wildblue.net wrote:
[...] Further more their system does other things that I don't want to lose, namely the "free time" during the wee hours when I can allow the Apple computers to connect with iCloud, [...]
Regarding reigning in the Apple stuff, what approach are you using here?
Cheers,
On 12/11/13 18:58, Cameron Simpson wrote:
On 10Nov2013 20:18, Bob Goodwin bobgoodwin@wildblue.net wrote:
[...] Further more their system does other things that I don't want to lose, namely the "free time" during the wee hours when I can allow the Apple computers to connect with iCloud, [...]
Regarding reigning in the Apple stuff, what approach are you using here?
Cheers,
Most of the time I only allow connection to the iCloud, iTunes, etc. between midnight and five local time which is what they allow without tracking usage. I can open that if there is a need to connect at other times.
I also have another filter that controls specific LAN addresses from connecting to the WAN except between midnight and five.
And another that I hope blocks WAN traffic to my NFS also on the LAN.
I use the Tomato 1.28 version of DD-WRT which permits a lot of control, logging, and I can view usage at any time even in real time which is a good way to see what my system download/upload speeds are as stuff is transferred.
I also keep a daily record of the ISP'slogged data for my daily usage so I always know where I stand. I get 25 gigs per month but it costs me $10 a gig for anything I want beyond that. I've been managing our usage for about seven years now and it works well for me.
Bob
Allegedly, on or about 10 November 2013, Bob Goodwin ~ Zuni, Virginia, USA sent:
Am I missing some point here? Is there some connection between dhcp and dns that I am not aware of. My dhcp server is in the router and deals with about thirty addresses on the LAN and works faultlessly as far as I can see.
(Almost) only as far as making sure that your DHCP server tells its clients the right IP to use for their DNS queries. Which it looks like it is, from subsequent replies.
DCHP servers tell the clients various things to configure their network, one of which is what DNS server IPs to use. Others are the clients own IP, and things like the gateway (where the clients connect through to the outside world), netmask (which sets the boundary between what's inside or outside).
So, if your clients have proper networking addresses, you can ignore debugging your DHCP server configuration. If they have some details wrong, then you need to check whether your DHCP server is doling out the right information, or your clients are ignoring it (some people set manual overriding configurations on their PCs).
-
Bob Goodwin -
Cameron Simpson -
Ed Greshko -
Joe Zeff -
Mickey -
Rick Stevens -
Sam Varshavchik -
staticsafe -
SternData -
T.C. Hollingsworth -
Tim