Upload crashed wifi on macbook

Developer Discussions DCS
1

When i try to upload file with uplink it will run to 2% but then it stops, and turns off the wifi on my macbook.

./uplink_darwin_amd64 cp ~/Downloads/movie.mp4 sj://test

Error log

2020-01-14T21:27:21.356+0100 INFO Configuration loaded from: /Users/dude/Library/Application Support/Storj/Uplink/config.yaml
57.97 MiB / 2.34 GiB [->_________________________________________________________] 2.42% 425.60 KiB p/s
2020-01-14T21:29:41.178+0100 FATAL Unrecoverable error {"error": "segment error: ecclient error: successful puts (0) less than or equal to repair threshold (35); segment error: ecclient error: successful puts (0) less than or equal to repair threshold (35)", "errorVerbose": "group:\n--- segment error: ecclient error: successful puts (0) less than or equal to repair threshold (35)\n\tstorj.io/storj/uplink/ecclient.(*ecClient).Put:173\n\tstorj.io/storj/uplink/storage/segments.(*segmentStore).Put:67\n\tstorj.io/storj/uplink/storage/streams.(*streamStore).upload:236\n\tstorj.io/storj/uplink/storage/streams.(*streamStore).Put:92\n\tstorj.io/storj/uplink/storage/streams.(*shimStore).Put:49\n\tstorj.io/storj/uplink/stream.NewUpload.func1:53\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\n--- segment error: ecclient error: successful puts (0) less than or equal to repair threshold (35)\n\tstorj.io/storj/uplink/ecclient.(*ecClient).Put:173\n\tstorj.io/storj/uplink/storage/segments.(*segmentStore).Put:67\n\tstorj.io/storj/uplink/storage/streams.(*streamStore).upload:236\n\tstorj.io/storj/uplink/storage/streams.(*streamStore).Put:92\n\tstorj.io/storj/uplink/storage/streams.(*shimStore).Put:49\n\tstorj.io/storj/uplink/stream.NewUpload.func1:53\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}

I am on macbook pro 2015, macos catalina, bash,

2

it looks like your wifi driver is crushing? may be try trase wifi error? did you tried by cable connected, have same error?

3

I dont have the RJ-45 extension with me now. I checked macos console for wifi and i captured this this error log

Tue Jan 14 21:58:35.348 <kernel> postMessage::1349 APPLE80211_M_BSSID_CHANGED received
Tue Jan 14 21:58:35.348  <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:58:35.348 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:58:35.348 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:58:35.348 <kernel> AirPort_BrcmNIC::getSSIDData(): Get failure: APPLE80211_IOC_SSID: 6
Tue Jan 14 21:58:43.863 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:58:43.863 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:58:43.864 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:58:52.175 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:58:52.175 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:58:52.175 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:59:00.474 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:59:00.474 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:59:00.474 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:59:08.778 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:59:08.778 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:59:08.778 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:59:13.276 <airportd[222]> _processIPv4Changes: ARP/NDP offloads disabled, not programming the offload
Tue Jan 14 21:59:13.334 <airportd[222]> _processIPv4Changes: ARP/NDP offloads disabled, not programming the offload
Tue Jan 14 21:59:17.096 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:59:17.096 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:59:17.097 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:59:25.387 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:59:25.387 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:59:25.387 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:59:33.674 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:59:33.675 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:59:33.675 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]
Tue Jan 14 21:59:41.966 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link
Tue Jan 14 21:59:41.966 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable
Tue Jan 14 21:59:41.966 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[disabled]```
4

looks like problem with wifi, power adapter plugged ? sometime it try low power it.

5

When i plugged in the power chord it did not helped.

It always fail at 57.97 MiB. When i try to upload smaller file than this size it uploads OK. But bigger files never succeed.

6

I tried cabled connectin on my Mac and on first try i got same result, small files upload OK but bigger one not. It did not disconnected the thunderbolt adapter in system, but during the uplink process the internet is not working, chrome is lagging and cant interect with it.
On second try the uplink and cabled connection resulted that the uplink hanged for about ten minutes, then i tried to kill it with kill pid and it didnt work, and my whole system was unresponsive so i had to cold reboot.

I know it is action “Sign up before production”, but i did not expect that it is that far away and that it will break whole system…

7

Try this:

./uplink_darwin_amd64 cp ~/Downloads/movie.mp4 sj://test/mymovie.mp4

8

also same file to same location you can send only 1 time. Even if it faild but sended some parts, you cant send it any more there, it is known issue, Zombie segments, SJ looking for solution now also for this.

9

i tried uploading different files too, that is why i noticed the 57,97MiB issue.

10

Welcome to our community @donAFRO and thank your very much for reporting the issue.

Can you please check the uplink version that you have (i.e. /uplink_darwin_amd64 -v)?

11 
Version: v0.29.3
Build timestamp: 08 Jan 20 19:59 CET
Git commit: 990f537e5aee4e92968eda0f10c4cbf0facd803d
12

Thanks!
Sorry, I forgot to ask you, which satellite are you using?

13

EU

Lorem Ipsum is simply dummy text of the printing and typesetting industry.

14

A few people have suggested that this is a zombie segment issue - but I do not think so. Usually, we see zombie segment issues when slightly more than 64mb has been uploaded (64mb is the size of one complete segment). In this case, slightly less than 64mb has been uploaded. In addition, the zombie segment error we typically see is related to satellite/metainfo. The issue here is related to the fact that there were 0 successful puts to storagenodes, meaning we never even got to the satellite/metainfo step. Given the amount of data uploaded (almost 64mb), it seems that all of the pieces for the first segment were almost successfully uploaded, but they all failed for some reason before completion.

We are working on debugging this, but I am not sure whether we will be able to replicate it. In the meantime, would you mind letting us know which satellite you are using (as @ifraixedes asked)? I am also curious whether you still see the issue when you are on a different network entirely.

15

When it asked me i choosed EU satellite, i dont know where it is stored now. Or which one exactly it uses.

I tried uploading from work, there is internet faster than 100/100 and my 2.5 GB file got uploaded to 90% but then it crashed the wifi. I expected it was some wifi issue at work, for example someone restarted the access point, i was in hurry so i tried that at home, when i discovered it always crashes my Wifi on macbook. At home i have tested with VDSL internet, around 50/6 mbit.

16

57.97 i think is file initial size. with read solomon will be 57.97*2,5 = 144.925 MB ? then it is over 64 MB?

17

64MB is the segment size prior to RS encoding. So it applies to the original file/transfer size.

18

After discussing the issue with @stefanbenten, our current best theory is that the number of concurrent DNS lookups required by the uplink during the upload is too high for the router you are using. For a single segment, we open 95 storagenode connections at once, and you might get disconnected from wifi if your router does not support this many DNS lookups.

On our end, we are working on a fix where the satellite returns the IP addresses for the storagenodes directly, rather than requiring the uplink to find these through the DNS.

To figure out if this might be the issue you are running into, please do the following:
In a separate terminal, run $ ping 8.8.8.8, then attempt your upload. Monitor the output of the ping command. If it spikes during the upload, it could be a hint that the concurrent DNS lookups are the issue.

2 Likes
19

i run ping during the uplink of file with size150MB, here is the output

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=52 time=11.084 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=12.058 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=30.381 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=36.555 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=10.468 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=52 time=11.247 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=52 time=66.414 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=52 time=312.728 ms
Request timeout for icmp_seq 8
64 bytes from 8.8.8.8: icmp_seq=8 ttl=52 time=1492.227 ms
Request timeout for icmp_seq 10
64 bytes from 8.8.8.8: icmp_seq=9 ttl=52 time=2482.280 ms
Request timeout for icmp_seq 12
64 bytes from 8.8.8.8: icmp_seq=10 ttl=52 time=3456.963 ms
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
64 bytes from 8.8.8.8: icmp_seq=12 ttl=52 time=4823.895 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=52 time=4788.503 ms
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
64 bytes from 8.8.8.8: icmp_seq=16 ttl=52 time=4474.089 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=52 time=4603.047 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=52 time=4641.396 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=52 time=4560.182 ms
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
ping: sendto: Network is down
Request timeout for icmp_seq 26
ping: sendto: No route to host
Request timeout for icmp_seq 27
ping: sendto: No route to host
Request timeout for icmp_seq 28
ping: sendto: No route to host
Request timeout for icmp_seq 29
ping: sendto: No route to host
Request timeout for icmp_seq 30
ping: sendto: No route to host
Request timeout for icmp_seq 31
ping: sendto: No route to host
Request timeout for icmp_seq 32
Request timeout for icmp_seq 33
64 bytes from 8.8.8.8: icmp_seq=34 ttl=52 time=10.898 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=52 time=10.364 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=52 time=148.880 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=52 time=8.709 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=52 time=9.519 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=52 time=12.214 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=52 time=11.668 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=52 time=10.702 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=52 time=13.880 ms
^C
--- 8.8.8.8 ping statistics ---
43 packets transmitted, 26 packets received, 39.5% packet loss
round-trip min/avg/max/stddev = 8.709/1386.552/4823.895/1963.362 ms

I then connected my macbook to iphone hotspot on LTE and tried upload same file, this time it uploading succesfully, but some pings also failed…
ping output

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=51 time=35.022 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=28.474 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=40.119 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=28.033 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=51 time=48.689 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=51 time=29.309 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=51 time=48.066 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=51 time=71.764 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=51 time=34.251 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=51 time=479.359 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=51 time=79.529 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=51 time=472.849 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=51 time=491.756 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=51 time=655.946 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=51 time=811.455 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=51 time=451.206 ms
Request timeout for icmp_seq 16
64 bytes from 8.8.8.8: icmp_seq=16 ttl=51 time=1081.869 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=51 time=1539.819 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=51 time=537.211 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=51 time=153.107 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=51 time=191.780 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=51 time=38.788 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=51 time=193.336 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=51 time=41.329 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=51 time=61.848 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=51 time=59.788 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=51 time=33.891 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=51 time=277.686 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=51 time=42.518 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=51 time=35.392 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=51 time=34.162 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=51 time=34.367 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=51 time=34.898 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=51 time=50.814 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=51 time=36.813 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=51 time=40.167 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=51 time=32.739 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=51 time=47.699 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=51 time=32.345 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=51 time=40.286 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=51 time=31.567 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=51 time=46.728 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=51 time=44.812 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=51 time=41.695 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=51 time=358.068 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=51 time=33.726 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=51 time=41.823 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=51 time=46.637 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=51 time=39.259 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=51 time=34.521 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=51 time=33.986 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=51 time=37.591 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=51 time=33.706 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=51 time=48.132 ms
64 bytes from 8.8.8.8: icmp_seq=54 ttl=51 time=353.943 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=51 time=64.945 ms
64 bytes from 8.8.8.8: icmp_seq=56 ttl=51 time=36.514 ms
64 bytes from 8.8.8.8: icmp_seq=57 ttl=51 time=82.916 ms
64 bytes from 8.8.8.8: icmp_seq=58 ttl=51 time=108.725 ms
64 bytes from 8.8.8.8: icmp_seq=59 ttl=51 time=101.082 ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=51 time=50.095 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=51 time=52.874 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=51 time=55.569 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=51 time=299.878 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=51 time=64.609 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=51 time=39.267 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=51 time=45.291 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=51 time=58.877 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=51 time=42.438 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=51 time=77.856 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=51 time=37.585 ms
64 bytes from 8.8.8.8: icmp_seq=71 ttl=51 time=43.440 ms
64 bytes from 8.8.8.8: icmp_seq=72 ttl=51 time=40.364 ms
64 bytes from 8.8.8.8: icmp_seq=73 ttl=51 time=42.221 ms
64 bytes from 8.8.8.8: icmp_seq=74 ttl=51 time=41.892 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=51 time=32.820 ms
64 bytes from 8.8.8.8: icmp_seq=76 ttl=51 time=39.050 ms
64 bytes from 8.8.8.8: icmp_seq=77 ttl=51 time=36.291 ms
64 bytes from 8.8.8.8: icmp_seq=78 ttl=51 time=59.809 ms
64 bytes from 8.8.8.8: icmp_seq=79 ttl=51 time=529.453 ms
64 bytes from 8.8.8.8: icmp_seq=80 ttl=51 time=891.352 ms
Request timeout for icmp_seq 82
64 bytes from 8.8.8.8: icmp_seq=81 ttl=51 time=2082.350 ms
64 bytes from 8.8.8.8: icmp_seq=82 ttl=51 time=1078.070 ms
64 bytes from 8.8.8.8: icmp_seq=83 ttl=51 time=232.620 ms
64 bytes from 8.8.8.8: icmp_seq=84 ttl=51 time=506.707 ms
64 bytes from 8.8.8.8: icmp_seq=85 ttl=51 time=36.306 ms
64 bytes from 8.8.8.8: icmp_seq=86 ttl=51 time=43.862 ms
64 bytes from 8.8.8.8: icmp_seq=87 ttl=51 time=522.585 ms
64 bytes from 8.8.8.8: icmp_seq=88 ttl=51 time=34.452 ms
64 bytes from 8.8.8.8: icmp_seq=89 ttl=51 time=70.304 ms
64 bytes from 8.8.8.8: icmp_seq=90 ttl=51 time=109.783 ms
64 bytes from 8.8.8.8: icmp_seq=91 ttl=51 time=35.011 ms
64 bytes from 8.8.8.8: icmp_seq=92 ttl=51 time=47.947 ms
64 bytes from 8.8.8.8: icmp_seq=93 ttl=51 time=31.586 ms
64 bytes from 8.8.8.8: icmp_seq=94 ttl=51 time=35.447 ms
64 bytes from 8.8.8.8: icmp_seq=95 ttl=51 time=40.140 ms
64 bytes from 8.8.8.8: icmp_seq=96 ttl=51 time=31.053 ms
64 bytes from 8.8.8.8: icmp_seq=97 ttl=51 time=31.981 ms
64 bytes from 8.8.8.8: icmp_seq=98 ttl=51 time=638.430 ms
64 bytes from 8.8.8.8: icmp_seq=99 ttl=51 time=35.743 ms
64 bytes from 8.8.8.8: icmp_seq=100 ttl=51 time=40.570 ms
64 bytes from 8.8.8.8: icmp_seq=101 ttl=51 time=48.849 ms
64 bytes from 8.8.8.8: icmp_seq=102 ttl=51 time=313.491 ms
64 bytes from 8.8.8.8: icmp_seq=103 ttl=51 time=40.660 ms
64 bytes from 8.8.8.8: icmp_seq=104 ttl=51 time=49.384 ms
64 bytes from 8.8.8.8: icmp_seq=105 ttl=51 time=288.081 ms
64 bytes from 8.8.8.8: icmp_seq=106 ttl=51 time=39.957 ms
64 bytes from 8.8.8.8: icmp_seq=107 ttl=51 time=43.694 ms
64 bytes from 8.8.8.8: icmp_seq=108 ttl=51 time=40.481 ms
64 bytes from 8.8.8.8: icmp_seq=109 ttl=51 time=30.249 ms
64 bytes from 8.8.8.8: icmp_seq=110 ttl=51 time=35.334 ms
64 bytes from 8.8.8.8: icmp_seq=111 ttl=51 time=31.507 ms
64 bytes from 8.8.8.8: icmp_seq=112 ttl=51 time=30.780 ms
64 bytes from 8.8.8.8: icmp_seq=113 ttl=51 time=28.497 ms
^C
--- 8.8.8.8 ping statistics ---
114 packets transmitted, 114 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.033/170.051/2082.350/310.443 ms```
20

It definitely appears to be an issue with the number of concurrent DNS requests. It could be your physical router that is the limiting factor, but it is also possible the issue is caused by something further upstream.

As far as fixing it goes, as I mentioned above, we are working on satellite-side DNS resolution - no ETA yet. On your end, it may help to do some investigation related to your router, but my ability to help with that is limited.

3 Likes