First call to internet always times out

[april]

I'm using Xenialpup64 7.5
I connect to the internet via WiFi adapter -DLink- via a cell type WiFi from Optus - every time I boot up I have noticed the first call to any site times out . Second and all subsequent calls succeed as usual.

I'm wondering if anyone can suggest what might be causing that and what I might check or test to try to isolate the problem .

Personally I lean toward a scripting error in Xenialpup64 somewhere as it has first surfaced here but we will see what others think and see if I can narrow it down and perhaps eliminate it .

[ozsouth]

If IRC you put me onto the Huawei E5251 3G modem from Optus. I assume you're using something like that. I set a ping to 8.8.8.8 every 30 sec to keep it awake. I would also try Slacko64 (& perhaps Tahr64 or upupbb) to see if it's Xenial64 specific.

[jafadmin]

Do I unnerstan correctly that you are going: USB Wifi -> Optus WiFi modem -> The Innernets?

If so, try this diagnostic:

1) First connect your DLink wifi to your Optus Wifi modem. It will give you your local IP address.

2) Ping from your PC to the WiFi modem's IP address (usually the .1 address on your subnet)

3) Evaluate the response time. It should be 1 millisecond.

4) Try the same test again, but for step 3, ping 8.8.8.8

This will show you if the problem is between your wifi dongle and your Optus modem, or between the modem and internet.

Good luck, and good hunting ..

[tallboy]

I don't know how it is in Xenial, but in my Lucid 5.2.8.7, there is an option in the Internet section in the Menu: 'Stay connected to Internet'. It works!
I had the same problem with timeout in general, every time I forgot to activate that option!

[april]

MM OK thanks all
The problem is not disconnecting from the internet .
In fact it is very stable
It is simply the first call after boot up that hangs and it happens every time.
The below code is after

Code: Select all

root# ping 192.168.8.100
PING 192.168.8.100 (192.168.8.100): 56 data bytes
64 bytes from 192.168.8.100: seq=0 ttl=64 time=0.108 ms
64 bytes from 192.168.8.100: seq=1 ttl=64 time=0.088 ms
64 bytes from 192.168.8.100: seq=2 ttl=64 time=0.088 ms
64 bytes from 192.168.8.100: seq=3 ttl=64 time=0.106 ms
64 bytes from 192.168.8.100: seq=4 ttl=64 time=0.087 ms
64 bytes from 192.168.8.100: seq=5 ttl=64 time=0.088 ms
64 bytes from 192.168.8.100: seq=6 ttl=64 time=0.088 ms
64 bytes from 192.168.8.100: seq=7 ttl=64 time=0.089 ms
64 bytes from 192.168.8.100: seq=8 ttl=64 time=0.090 ms
64 bytes from 192.168.8.100: seq=9 ttl=64 time=0.089 ms
^C
--- 192.168.8.100 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.087/0.092/0.108 ms
root# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=113 time=275.630 ms
64 bytes from 8.8.8.8: seq=1 ttl=113 time=71.994 ms
64 bytes from 8.8.8.8: seq=3 ttl=113 time=81.680 ms
64 bytes from 8.8.8.8: seq=4 ttl=113 time=77.441 ms
64 bytes from 8.8.8.8: seq=5 ttl=113 time=63.348 ms
64 bytes from 8.8.8.8: seq=6 ttl=113 time=88.397 ms
64 bytes from 8.8.8.8: seq=7 ttl=113 time=71.519 ms
64 bytes from 8.8.8.8: seq=8 ttl=113 time=86.922 ms
64 bytes from 8.8.8.8: seq=9 ttl=113 time=70.106 ms
64 bytes from 8.8.8.8: seq=10 ttl=113 time=81.739 ms
64 bytes from 8.8.8.8: seq=11 ttl=113 time=71.117 ms
64 bytes from 8.8.8.8: seq=12 ttl=113 time=81.802 ms
64 bytes from 8.8.8.8: seq=13 ttl=113 time=80.807 ms
C64 bytes from 8.8.8.8: seq=14 ttl=113 time=90.717 ms
64 bytes from 8.8.8.8: seq=15 ttl=113 time=133.738 ms
64 bytes from 8.8.8.8: seq=16 ttl=113 time=80.659 ms
Z64 bytes from 8.8.8.8: seq=17 ttl=113 time=70.425 ms
^Z
[1]+  Stopped                 ping 8.8.8.8
root# 

[april]

This was after a reboot -this does not normally happen so I'm thinking it is to do with reception at Optus tower . They must have something hanging up there on the first call ?
I'll try it next time after I have been closed for some time.

Code: Select all

root# ping 192.168.8.100
PING 192.168.8.100 (192.168.8.100): 56 data bytes
64 bytes from 192.168.8.100: seq=0 ttl=64 time=0.174 ms
64 bytes from 192.168.8.100: seq=1 ttl=64 time=0.086 ms
64 bytes from 192.168.8.100: seq=2 ttl=64 time=0.086 ms
64 bytes from 192.168.8.100: seq=3 ttl=64 time=0.085 ms
64 bytes from 192.168.8.100: seq=4 ttl=64 time=0.086 ms
64 bytes from 192.168.8.100: seq=5 ttl=64 time=0.087 ms
^Z
[1]+  Stopped                 ping 192.168.8.100
root# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=113 time=311.900 ms
64 bytes from 8.8.8.8: seq=1 ttl=113 time=67.621 ms
64 bytes from 8.8.8.8: seq=2 ttl=113 time=67.512 ms
64 bytes from 8.8.8.8: seq=3 ttl=113 time=67.290 ms
64 bytes from 8.8.8.8: seq=4 ttl=113 time=67.211 ms
64 bytes from 8.8.8.8: seq=5 ttl=113 time=73.097 ms
64 bytes from 8.8.8.8: seq=6 ttl=113 time=66.987 ms
64 bytes from 8.8.8.8: seq=7 ttl=113 time=66.897 ms
64 bytes from 8.8.8.8: seq=8 ttl=113 time=66.753 ms
^Z
[2]+  Stopped                 ping 8.8.8.8
root# 

[april]

From a first boot up I opened the browser and went to Gumtree .
On the screenshot below you can see it is hung up doing a handshake with Gumtree while I do a console set of pings as discussed .

I can't see anything wrong but it is still waiting for Gumtree and it does not matter who I call first . It hangs on the first

Any suggestions?


PS missed the screenshot . ill put it in on the next reboot

[jafadmin]

Your browser is a very high level app. Many, many things in play with it. To troubleshoot a connectivity issue, we need to use low level diagnostic tools that only care about the physical connection and ignore the content issues.

I see you are locally pinging ".100" Is that your local machine IP address, or the address of your gateway? You can run the "route" command from the console to show the IP of your default gateway. This is the address you should be pinging as your first test. For your second test, ping 8.8.8.8

In the ping test results, pay close attention to the very 1st ping reply ..

[greengeek]

Could this be an issue with DNS? Occasionally I see similar occurrences (Slacko 32bit not xenial) but the blockage problem resolves over variable time online (rather than first call only).

How a blockage can resolve itself I don't know but I assume a server is "adapting" to something it did not like in my software, or switching be to a backup DNS server or something.

I have not pinned the cause down but do see a difference in outcome between internet calls that request an IP address - such as 8.8.8.8 - and site requests that have to go through a DNS server.

I recall once I tried comparing the browser startup reliability by setting homepage to the murga forum - this can be done directly by IP address or by webpage name (requiring DNS).

Maybe try setting your browser homepage to an IP address that you know is functional. The IP address of John Murga's forum start page is 45.33.15.200

If using an IP addr as homepage to avoid DNS issues makes no difference then maybe the problem is https? I have seen lots of weird messages regarding my ssl version being unacceptable - sometimes this seems permananet but often the site hang gets "pushed through" somehow.

I get the feeling that Google's current roll out of "compulsory https" is responsible for some of the web delays we see. Some blockages resolve by themselves over a few minutes, some almost immediately, and some not at all.

If it;s not DNS or SSL issues I have no clue.

(Maybe isolate if this is a browser issue or something else by using wget or curl, or even PPM download as the first internet call??)

[april]

Jafadmin.. does the same if I look for email first. Hangs on first call to email site . The .100 is the IP address ,the modem and nameserver are .1

greengeek..I've got to work through those suggestions thanks .The gumtree page is usually functional.

Wouldn't you know it . When I booted this am it worked first off.

Below is first call to yahoo . Fails and console pings just after