I purchased a used GameShell on eBay. The device seems to work fine. I can connect to my WiFi access point. It reads a pretty strong signal strength (~75%). But I can’t SSH into the device from my Windows PC with PuTTy, and any operations on the device that involve network operations (updates, refreshing the Warehouse listing, etc) fail.
Just for the sake of eliminating possibilities. Are you using it as it came or you reformated the SD card?
1 Like
I’m using it as it came. The About screen reads:
Processor: ARMv7 Processor rev 5 (v71)
CPU cores: 4
CPU Mhz: 1400.0
Features: half thumb fastmult vfp edsp neon vfpv3 tis vfpv4 idiva idivt vfpd32
Memor: 1029.04 MB
Kernel: Linux 5.5.9-clockworkpi-cpi3 armv71 GNU/Linux
Launcher: stable 1.25
OS Image: V0.5
Also, TinyCloud says it’s online
I would start with a fresh image as we don´t know the state of the OS as you got it, maybe there is some wrong setting or something corrupted.
2 Likes
Hello there! Welcome to the forums! 
There was an issue with earlier OS versions where sometimes the wifi modules wouldn’t initialise properly on boot.
Potentially try booting it up, and then restarting. And if that doesn’t work, try rebooting again.
Some users on the forums solved this by making the wifi drivers a module in the kernel. But we’ll cross that bridge once we get to it, if formatting with a stock 0.5 image doesn’t work.
Sometimes it can just be the wifi hardware/router/modem needs a reboot, so try that too. Realistically though, if you’re SSH’ing in to transferring files, if can be painfully slow over wifi, compared to connecting via Ethernet over USB, or just pulling out the SD card, and inserting it into your computer; assuming you can write to an EXT partition. If you don’t know if your computer currently can, it most likely can’t. We can cross that bridge when we get to it too.
Re: tiny cloud saying it’s online, what’s the IP address? If it starts with 169.xxx.xxx.xxx, it hasn’t been allocated an IP address properly. Under most normal circumstances, it’s usually something like 192.168.1.xxx or 10.0.1.xxx.
In which case, it could be a problem with DHCP IP table allotment, MAC filters, and a plethora of other things it could be. Are you the main administrator of your wifi infrastructure? I’m assuming you are.
1 Like
How do you find the IP address for GS?
Do you even have a Gameshell yet?
It’s in tiny cloud.
You mentioned using tiny cloud in this post.
It shows the IP addresses there; NOT the MAC address.
In a later revision/update of the launcher, you can also go into your wifi connection settings, and push Y (or X depending on your layout) to view details of your connection, including the IP address and MAC address.
I’m currently in the process of hunting down my SD card reader to reimage the device (and I’ve been really busy at work), but in the mean time I discovered through an unrelated issue that the USB cable I was trying to use to connect the CPi to my PC was bad. Was able to SSH in over USB once I scrounged up a good cable. So that’s good, at least.
Figured while I was there I’d mess around with some network config settings. Managed to eventually be able to ping external IP addresses, but never got DNS resolution to work. Oh well. This is at least encouraging that it’s not a hardware problem, so feeling pretty confident the re-imaging will work.
1 Like
Bad USB cables! those are my nemesis, now I tend to have them separated, I also bought a voltage/amp checker so I can also test their power performance. Ive had countless issues with brownouts because the cables I was using couldn´t provide enough power.
2 Likes
Okay, device is re-imaged. Saw a different picture on the boot screen. WiFi connected successfully. It claimed to receive an IP address from the AP. But still can’t get DNS to resolve anything.
> ping google.com
ping: google.com: Temporary failure in name resolution
But this works
> ping 172.217.13.238
PING 172.217.13.238 (172.217.13.238) 56(84) bytes of data.
64 bytes from 172.217.13.238: icmp_seq=1 ttl=113 time=30.3 ms
64 bytes from 172.217.13.238: icmp_seq=2 ttl=113 time=13.5 ms
64 bytes from 172.217.13.238: icmp_seq=3 ttl=113 time=18.8 ms
64 bytes from 172.217.13.238: icmp_seq=4 ttl=113 time=15.1 ms
64 bytes from 172.217.13.238: icmp_seq=5 ttl=113 time=23.8 ms
64 bytes from 172.217.13.238: icmp_seq=6 ttl=113 time=12.7 ms
64 bytes from 172.217.13.238: icmp_seq=7 ttl=113 time=13.2 ms
^C
--- 172.217.13.238 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6059ms
rtt min/avg/max/mdev = 12.793/18.241/30.334/6.161 ms
I tried poking around at all the IP commands I could figure out.
> ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 36:f2:c1:3a:d4:86 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
link/ether 6c:21:a2:44:97:d4 brd ff:ff:ff:ff:ff:ff
I don’t know what this tells me. I think it just means the hardware is recognized?
> ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 36:f2:c1:3a:d4:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.10.255 scope global usb0
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 6c:21:a2:44:97:d4 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.180/24 brd 192.168.10.255 scope global wlan0
valid_lft forever preferred_lft forever
…180 is the address my CPi has recieved. I can ping it from my PC, but only while the USB cable is plugged in.
> ip neigh
192.168.10.188 dev usb0 FAILED
192.168.10.173 dev usb0 lladdr be:40:e1:f5:64:00 REACHABLE
…188 is my PC’s WLAN address. …173 I believe is the Ethernet-USB connection back to my PC. Pining 188 gives me “Destination Host Unreachable”. Pinging 173 gives me nothing but dead air.
> ip netconf
ipv4 dev lo forwarding off rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
ipv4 dev usb0 forwarding off rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
ipv4 dev wlan0 forwarding off rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
ipv4 all forwarding off rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
ipv4 default forwarding off rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
IDK if any of this is useful.
> cat /etc/networks
default 0.0.0.0
loopback 127.0.0.0
link-local 169.254.0.0
> cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 clockworkpi
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
> cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
gshadow: files
hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
> cat /etc/resolv.conf
domain lan
search lan
nameserver 192.168.10.1
> cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
allow-hotplug usb0
auto usb0
iface usb0 inet static
address 192.168.10.1
netmask 255.255.255.0
Should there be a set of entries for wlan0 in /etc/network/interfaces, or is DHCP just assumed if no static config is set?
> networkctl
WARNING: systemd-networkd is not running, output will be incomplete.
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback n/a unmanaged
2 usb0 ether n/a unmanaged
3 wlan0 wlan n/a unmanaged
3 links listed.
That doesn’t look good
> sudo systemctl start systemd-networkd
> networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 usb0 ether routable unmanaged
3 wlan0 wlan routable unmanaged
3 links listed.
> ping google.com
ping: google.com: Temporary failure in name resolution
Yup, that did nothing
IDK, I’m just guessing at command names. I’m not super Linux knowledgeable.
1 Like
I changed
to
cat /etc/resolv.conf
domain lan
search lan
nameserver 8.8.8.8
(which is Google’s public, primary DNS) and now hostnames resolve!
I go to Settings > Update Launcher > Check for Updates and it no longer says “Update failed”! I now get an option to update to “e701756”.
2 Likes
The name server should not be fixed lieke that, sounds like the previous owner done something “wrong”.
What is the IP of your internet router?
Edit: Normally that file should be (re)created each time you connect to a WiFi access point. So if 192.168.10.1 is your router IP, you may have an issue on your network. (or your router)
1 Like
I’m having the same issue but the problem is I am so new to gameshell that as soon as I saw script I got lost lol
Yes, it that 192.168.10.1 number apparently is my router. And it appears my resolv.conf file gets rewritten every time I restart the device. I’m guessing it’s DCHP renewing?
It’s difficult to say that there is an issue with the network/router when about 20 other devices, across Windows, macOS, Linux, BSD, Android, iOS, have no problems.
Yup the file is more than likely to be rewritten each time your Gameshell reconect.
Wait. That could be exactly it. Sometimes a router has a set IP range it can allocate for devices, if it’s using DHCP to automatically assign addresses. If for some reasons your router is set to 20, it wouldn’t be assigning an IP properly; thus wouldn’t resolve a DNS served routing for a URL.
Sometimes, it can have an absurdly long expiration time for a device that has connected. Eg, if you let a friend use your wifi. Their MAC address will still be associated with one of the IP slots. Worse still, if someone’s hacked your wifi, they would be using up more IP slots, bandwidth and generally polluting the wifi channels/space.
If you have admin access, give increasing your IP range a go. Or possibly make a MAC address locked exception table/white list, with static routings containing all of your wifi devices; including the gameshell. This will also make SSHing easier, since the IP address will always be the same. Sometimes it changes, depending on which slots are empty.
@CeeCee Welcome to the forums! You shouldn’t technically have to use that script. Perhaps try reformatting, using a different image. I know that my custom image (search DEOT+ v2) and @Joao_Manoel’s minimal image have a modified wifi driver loaded as a kernel module. This could solve a lot of people’s problems with wifi drivers not always loading on boot.
1 Like
I’ll try that out. Gotta get a computer down into the basement and find a CAT5 cable, as I disabled the management interface over WiFi some time ago.
Actually, I’ve made two SD cards, one with the default v0.5 image, and one with your DEOT+ v2 build 200903 image, and both give me the same issue with WiFi.
Don´t worry and welcome!
We have this pinned post that it is an amazing starting point, at least it was for me 
3 Likes