VS1 non wifi modem connected to Night Hawk router

  • 1
  • Problem
  • Updated 9 months ago
  • Acknowledged
Stable network until turning on a chromebook.

After a couple minutes to 15 minutes later, no one can get internet.
Reboot router and all good again until chromebook goes online.

The chromebook works just fine, until it doesn't & seems to kill the entire network.
Works fine at school all day

Second router has exact same behavior as first one - NOT a router issue
Photo of Bob Lexus

Bob Lexus

  • 322 Posts
  • 114 Reply Likes

Posted 12 months ago

  • 1
Photo of Oliver

Oliver

  • 317 Posts
  • 103 Reply Likes
keep gmail and hangouts closed on the chromebook and report back. your seeing viasats web accelerator die at the headend for your pub ip's. Your in bridge mode correct?
(Edited)
Photo of Bob Lexus

Bob Lexus

  • 322 Posts
  • 114 Reply Likes
Oliver, the individual experiencing this is a high school teacher.
Using the school provided CB.

He uses it exclusively for school work, he has personal computers for family needs.

There is no bridge mode on a non wifi modem...btw
Photo of Michael Bunch

Michael Bunch

  • 6 Posts
  • 0 Reply Likes
I have nearly exactly the same issue with my new chromebook, even as to assuming it was the router and replacing it. Nope, Chromebook works fine for fifteen minutes, then internet fails at the modem level. So Viasat's web accelerator can't handle the load? Any more good advice on troubleshooting and/or working around the issue from my end, since it's been three months since the original poster and Viasat hasn't fixed it?

Can I bypass the web accelerator for instance? Maybe a VPN?
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4366 Reply Likes
Yes, a VPN might bypass the issue and would be worth a shot to see if it has any impact. Using a VPN has been known to work around any number of DNS related issues on Viasat. Christopher Jane's reply below suggests Google WiFi support thinks it might be DNS errors.

Not sure whether and under what circumstances Viasat "hijacks" DNS queries. They used to for web acceleration - in the past you couldn't specify your own DNS servers and expect it to have any impact; maybe that policy has changed.

Recently I'm getting some random drops with seemingly no explanation with the stand alone modem and an ASUS router - not to the extent Chromebook users are - once or twice weekly. Maybe the combination of Chromebook triggers a crisis or meltdown...

P.S. I suppose you could also configure your router to use Googles DNS servers - I'm just not sure that will have any impact with Viasat's past DNS "hijacking". 
(Edited)
Photo of Jab

Jab

  • 1155 Posts
  • 164 Reply Likes
RE: "new chromebook"

Suggestion, which may not work...Bottom right, click, then below WiFi, click to open dialog...then click on WiFi being used.  GoTo Network, and open it up.  At NameServers, try using Google, or use Automatic name server.

I've got ASUS Chromebook, without issues on RT-N66U router. 

If someone is using a school based chromebook, perhaps a proxy server is setup...and if their IT has configured it to see only "local" IP addresses....good luck getting it to work.
Photo of Christopher Jayne

Christopher Jayne

  • 4 Posts
  • 0 Reply Likes
Same here.  I have the non-wifi modem, use Google Wifi as the router.  I have tried 2 different chromebooks and I get about 15 min. of use before I have to reboot. I have spent 6 hrs on the phone with Google WiFi support and they say I have an unusual number of DNS errors.  I finally traded in one of the chromebooks for a low-end MacBook Pro.  I haven't had to mess with the connection for 3 weeks. 

I have been using Chromebooks for years, I think the problem has gotten worse in the last few months, although I wonder if my years of issues with finding a reliable router to use with Exede/ViaSat stemmed from this? I'm glad some others are having similar problems.  Maybe Google and ViaSat can figure it out. 

Photo of Michael Bunch

Michael Bunch

  • 6 Posts
  • 0 Reply Likes
Well, using a VPN had an immediate result -- it shut the modem down right away, instead of the fifteen minutes I usually get.

I might try other VPNs, since that one was just the first free one on the list in Google Play, but still not a good sign. I'd imagine that if no Chromebooks at all worked with Viasat there would be much more of an outcry, so I'm thinking that some of us just have an unfortunate combination of incompatible or old equipment.

My Chromebook is a Lenovo C330, and the modem I am using is the Surfbeam 2, Model number RM4100. I can't remember when they sent me this one, but it is probably more than a few years old. I guess I'll get on the phone and see if they can send me an upgraded/newer modem -- might make a difference.
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4366 Reply Likes
Consistency is often a good thing - even that symptom jogs a memory from long ago and far away where I had a similar issue that killed an entire router's WAN (Internet) connectivity; at the same time it corrupted the database I was working with whenever it occurred requiring a database restore  - we struggled with it for weeks on end.

As I recall, it was MTU (Maximum Transmission Unit) related. At the time, I was working with Windows and resolved it by tweaking MTU. In this case if I were the ambitious type I might try that but not sure the Chromebook supports configuring that. If not, I might try it on the router itself - if your router supports it. Skip the VPN,
 it only jogged my memory regarding setting the VPN's MTU in a prior life on specific VPN services.

In my case it involved ping tests to determine the optimal MTU for my windows box (or just try 1400 and work up or down as needed).

Basically what is outlined in the following:

https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router

except I was setting it on Windows at the time rather than a router as described at:

https://kb.netgear.com/24015/How-do-I-change-the-MTU-size-on-my-Nighthawk-router

Then again, I'm foolhardy and often throw caution to the wind figuring it's already broken what am I going to do break it some more? Sometimes the answer is yes so try it at your own discretion, YMMV. Depending on your technical expertise this may be one of those do not try this at home scenarios.    

Otherwise Viasat phone support is probably your best option if you can bust through the tiered level 1 scripted support...

Good luck, these can be bears to identify and fix...    

P.S. In the event it's DNS related, you could try changing your router's DNS servers to Google's or some other reputable public DNS servers - I'm just not sure that has any real impact with Viasat's past where DNS queries were "hijacked" for acceleration purposes.   
(Edited)
Photo of Michael Bunch

Michael Bunch

  • 6 Posts
  • 0 Reply Likes
I went ahead and tried the next VPN down on the list (Thunder VPN, I think) and hey I haven't been disconnected for hours.

So... Maybe good, maybe just coincidence.

If it fails again I'll tinker with the MTU settings. Never messed with those in Chrome (Windows and other routers, yes) but I guess it might be time to learn.

Thanks for all the help!
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4366 Reply Likes
Yeah VPNs can be finicky with Viasat and some just wont work; probably not MTU and sounds like Viasat's web acceleration just isn't playing nice with all the other kids whether that be the router or Chromebook. VPN bypasses the acceleration.

Hopefully it puts the Viasat folks in the right haystack to see what's really going on.
(Edited)
Photo of Steve Frederick-VS1/Beam314

Steve Frederick-VS1/Beam314, Champion

  • 3154 Posts
  • 2030 Reply Likes
I am using the Surfbeam  2, non WiFi modem, with an ASUS RT-AC1900C router. My modem is at least 5 years old and works just fine. My Chromebook is a Samsung, about 15 months old, and works fine on Viasat, no disconnect problems.
Photo of Michael Bunch

Michael Bunch

  • 6 Posts
  • 0 Reply Likes
Thanks Steve. Figured it couldn't be universal. I probably need to make a call in to tech support and see if they can run a diagnostic. Might be my modem is on its last legs anyhow.

Or maybe the Lenovo is just hard on satellites...
Photo of Oliver

Oliver

  • 317 Posts
  • 103 Reply Likes
It's not an MTU problem, ask via sat to turn off the client side proxy for testing and you will see the problem go away. Again modem is alive its viasats proxy to modem crashing.
Photo of Jab

Jab

  • 1160 Posts
  • 164 Reply Likes
I doubt if MTU is the issue...if you want to open up your setup to receive ICMP traffic, try  this test:

http://www.letmecheck.it/mtu-test.php


(Edited)
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4367 Reply Likes
Yes we determined that and isolated it to web acceleration  and we were spitballing lacking anything resembling a response from a Viasat employee;) Trying out a VPN was probably quicker than going through the pain of scripted phone support ;)
(Edited)
Photo of Jab

Jab

  • 1160 Posts
  • 164 Reply Likes
RE: Viasat "hijacks" DNS queries

I don't think they are hijacked, but are not being used to fetch. 

In short, when URL is sent out from computer's browser, one "copy" of it will go to Viasat's equipment, and the other "copy" to DNS server configured. DNS server sends IP address back to your computer, and then it is sent to Viasat's modem, which will send the fetched page when it has a chunk of it.

If Viasat's DNS server is not in sync with a DNS server used, then no page will be displayed.

I suspect some of these lockups might be related to their modem's queue not being dumped.  If modem receives commands like resetting IP address, it will reset...which can cause another type of SNAFU.

As noted, if a school based Chromebook is used, I'd check proxy setting.  School's IT may have timeout configured, where high latency would kick it off.

Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4366 Reply Likes
Try not quoting out of context next time Doc - it irritates some of the natives around here.

I know that's really not what you're doing (you're using it more as a subject line lacking one but some view it as a "quote" ) and generally find your posts informative (even if I may disagree with parts)
(Edited)
Photo of Jab

Jab

  • 1160 Posts
  • 164 Reply Likes
Footnote - I'd make sure router and devices used are using a common DNS server.  Some routers may come preset to use their DNS server....I'd manually configure router/devices to use same DNS server, if there is an issue.  
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4366 Reply Likes
I would assume so also, but the long held assumption (either rightly or wrongly) has been that Viasat "hijacks" DNS - Viasat could put the confusion aside with a simple statement. Why don't they? Seems easy enough and a yes or no would suffice.

All my traces, tools, etc. indicate that's no longer the case (but may have been at one time and probably chnaged when they apparently moved off Accelenet to a different web acceleration technique) but doesn't really rule out the possibility of a transparent proxy that snoops without "hijacking" unless using a full VPN solution (Opera aint full).

We've beaten this horse to near death - what say ye Viasat on DNS "hijacking" ??? Yes or no? Did you at one time?

The answer might even be found in the new Wifi modems if anyones got one and can check - do they let you establish your own primary/secondary DNS servers? If so, why provide that functionality if it's not supported or somehow overridden?

When folks can't get to a particular web site we'd be able to at least provide them with a solid work around for your DNS caching issues.

But this particular issue here, yeah, a full VPN solution apparently gets around it - of course at some sacrifice of speed and data.

So far Viasat has been silent on this particular conversation (and its tangents) - marked as acknowledged but no solution or workaround directly from Viasat. Not even the ubiquitous send a message to viasatlistens or call support - go figure 3 months and counting!
(Edited)
Photo of Jab

Jab

  • 1160 Posts
  • 164 Reply Likes
DOCISS began as a cable protocol, and was manipulated for satellite.

WiMAX (Worldwide Interoperability for Microwave Access) "was initially designed to provide 30 to 40 megabit-per-second data rates,[3] with the 2011 update providing up to 1 Gbit/s[3] for fixed stations. "

Aircraft are capable now of 1 Gbits/s....and "The latest version of WiMAX, WiMAX release 2.1, popularly branded as/known as WiMAX 2+, is a smooth, backwards-compatible transition from previous WiMAX generations."

Modem design must account for buffer storage, and logically, the higher the throughput, the larger the buffer required, along with faster CPU.  Hence, from SB2 forward, one would expect buffer storage expanded, and faster CPUs.

DOCISS was twitched, and most likely WiMAX was twitched for satellite, but redesigning/revamping the code would be a waste of time, and require hours/hours of programming. 

DNS Hijacking - User experiences are best served via quickest means. In beginning Wildblue days, NRTC users were instructed to use NRTC's DNS servers, and installers were suppose to configure customers' DNS IPs addresses.  Around Nov. 2006, Wildblue implemented  ViaSat's traffic shaping technology called DAMA.  At this point forward, I can't say if NRTC's DNS servers were being used to fetch URLs for Wildblue's equipment.

Speedwise, its a no brainer to forward URLs to their equipment, and have it resolve the URL.  As was pointed out here,  DNS Bumsteer, it appears strongly their equipment receives URL, converts it with their DNS server, fetches packets, and then sends them to their modem .  When customer's computer sends resolved DNS lookup to their modem, then when their modem has enough packets, it will send them to customer's computer.  As noted, when their DNS server is not in sync with customer's assigned DNS server, then customer does not receive the web page.

There are two means to test this....the above is one way when blank pages exist with a legit site.  Other way, is to find some DNS server that takes forever to respond. Slowest I could find was located in Thailand:

C:\>ping 110.164.252.222
Approximate round trip times in milli-seconds:
    Minimum = 907ms, Maximum = 948ms, Average = 923ms

But, if a person could setup a DNS server to respond in ten seconds or more, this would be best.  203.144.207.29 is a DNS server in Thailand, but I could not ping it.

RE: Why don't they?

Trade secrets...Remember, Viasat's "listens" only....for years their techs monitored DSL_Reports, and said nothing...remember?
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4366 Reply Likes
I think the horse just died and I can recall having private exchanges with actual Viasat techs/engineers on the defunct Wildblue/Exede/Viasat forum.
(Edited)
Photo of Jab

Jab

  • 1160 Posts
  • 164 Reply Likes
Public conversations on DSL_Reports came in later years, but were not addressing issues, just Viasat's tech.  Users were requested to send email.
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4366 Reply Likes
I'm sure that's comforting to Bob Lexus, Michael Bunch, Christopher Jayne and other who may be experiencing this issue - they'd like it addressed.

Yep horse still ain't moving, still dead and resuscitation efforts are unsuccessful - let's call it.

Still waiting on an employee response here at least acknowledging that it's being investigated. Nothing, Nada, Zip, Crickets...

After that come back and tell us it's fixed or it's Chromebook's problem and provide a workaround (we've already provided a workaround that works apparently at the expense of performance and data).

Good customer service isn't a trade secret - and starts by engaging your customers to make them feel like you're actually listening.
(Edited)
Photo of Oliver

Oliver

  • 317 Posts
  • 103 Reply Likes
I've played with tcp over dns doing a proxy, works fine. So that makes me think no dns highjacking of requests is going on. It's webRTC crashing gateway proxy that links to client side modem proxy.
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4367 Reply Likes
Yes, I experimented - DaveRandom's second scenario seems the more likely culprit based on that experimentation. But yes outdated DNS propagation can lead to the problems being experienced. Other tests suggest that foxwelltech authoritative DNS server is misconfigured - DaveRandoms first scenario. If true then that misconfiguration would propagate to other DNS servers.  

But maybe Viasat can provide a definitive answer - oh, that's right they only listen.

Re: DNS

https://dzone.com/articles/world-dns-cache-king

and its links.

DNS propagation tests  suggest propagation errors on foxwelltech.com but not www.foxwelltech.com

https://www.whatsmydns.net/

Viasat isn't even involved with those checks being done from their servers. Now they aren't showing just a few minutes later and maybe TTL expired.

Is the horse dead yet?

If not, go to https://dnslookup.online/

The authoritative DNS servers for foxwelltech are:

ns15.xincache.com
ns16.xincache.com

ns15.xincache.com will not resolve foxwelltech,com while the secondary will. Both will resolve www.foxwelltech.com -  that inconsistency is being propagated globally to caches around the world.
(Edited)
Photo of Jab

Jab

  • 1160 Posts
  • 164 Reply Likes
RE: "Yes, I experimented"

I removed router from the equation, cleared DNS cache (ipconfig /flushdns), rebooted computer, made sure computer's adapter was set to find DNS server, and tried again for this URL: foxwelltech.com

Using "www" and without, the same results

C:\>nslookup foxwelltech.com
Server:  99-196-xxs-xxx.cust.exede.net
Address:  99.196.xx.xx

DNS request timed out.
    timeout was 2 seconds
===========================

Doing a gmail lookup...works fine

C:\>nslookup gmail.com
Server:  99-196-xxx-xxx.cust.exede.net
Address:  99.196.xxx.xxx

Non-authoritative answer:
Name:    gmail.com
Address:  172.217.1.xxx
=======================

Using both URLs (with and without www) in web browser, I get the same results:

Waterfox can’t find the server at www.foxwelltech.com.

This site will not come up, period when using Viasat's DNS server for WB-1:163 users, located most likely in Riverside. Ping stats below to this server:

    Minimum = 626ms, Maximum = 664ms, Average = 643ms

Ping stats to Quad9 (located in LA area...)
    Minimum = 624ms, Maximum = 654ms, Average = 635ms


This suggests this hypothesis has one empirical foundation....Viasat's processing center is doing a DNS URL-to-IP conversion since the Riverside DNS server does not, and can not do a URL-to-IP translation.  The CNAME (alias) record has nothing to do with this issue.

Now, via Windows adapter, I configured DNS for Quad9, and then flushed DNS resolver.  Using Quad9, nslookup has foxwelltech.com listed.  In browser, I use this URL: www.foxwelltech.com and this page comes up.  But, if I use foxwelltech.com, "HTTP Error 404. The requested resource is not found."

Consequently, when URL is inputted, these experiments suggests strongly that one copy goes to Viasat's processing center, and the other copy goes to an user's assigned DNS server.  Above represents experimental findings to show DNS Bumsteer is within valid reasoning.
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4367 Reply Likes
Nice try. You're getting closer.
(Edited)
Photo of Bev

Bev, Champion

  • 3287 Posts
  • 1462 Reply Likes
Interesting that the AU site works fine but the US site does not. http://www.foxwell.com.au/
Photo of Old Labs (VS1-329-L12FZ)

Old Labs (VS1-329-L12FZ)

  • 4281 Posts
  • 4367 Reply Likes
Different domain name - foxwell vs foxwelltech. Different authoritative DNS servers that are configure correctly and not propagating garbage.

foxwelltech authoritative DSN servers are in China - xincache.com - just in case the feds come knocking you'll have an explanation - tell them you're helping Jab out ;)






As currently configured, foxwelltech.com should yield HTTP 404 Not Found while www.foxwelltech.com should be found and display, but it really depends on how the non-authoritative source handles the requests and interpets propagation  - all DNS servers are not created equal and even some of the major players are having trouble with this one and tripping over it. Add what appears to be a virtual hosting confguration error and results are further muddled; nultiple sites appear hosted at the IP address which is the reason you can;t get there via IP address alone.

Cloudfare DNS  1.1.1.1 and 1.0.0.4 seems to handle it properly regardless and I'm using those on Viasat as we speak and see no ill effects (yet).

When I switch to Viasat's default DNS on the other adapter, no worka!

My only interest in this was determining whether we can now specify our own DNS servers to use - it would appear that the answer is yes and given what Cloudflare is currently doing privacy wise and in the future. I'm staying with the Cloudfare DNS for now.

So to the original poster and others, a full VPN should workaround your Chromebook issue but if not willing to incur the performance and data hit of VPN, try specifying DNS servers to use.No guarantee it will  and probably won't but a relatively painless shot none the less. Foxwelltech's issues aren't really relevant to your issue. Others will undoubtedly disagree with that assessment, which is their right and as always I could be wrong.

Somehow I don't think the discussion is over but for me it is - somebody filed an anonymous complaint against me over that horse ;)

(Edited)