I have several problems with a raspberry shake&boom that my employer tasked me of fixing.
First of all, I need to ensure the general possibility of a Wifi connection, which I tried to realize by using the Wifi-Dongle EW-7811UTC which I installed using this tutorial How to install EW-7811 AC600 Series and EW-7822UAC adapters on Raspberry Pi : EDiMAX .
It is recognized by the device but not building a connection. iwconfig gives this:
The next issues would be connecting the device to an eduroam network using a certificate, which they already tried with another raspberry shakes that has included wifi and can connect to normal networks. However, the settings set in the terminal seem to be overwritten by the surface and thus it cannot use the certificate to connect.
The third issue would be connecting the shake to a laptop directly via USB without a network and just showing the recorded data on the screen for educational purposes.
Lets first focus on the first issue though. I hope you can help me.
Kind regards.
When you can, could you please SSH into the Shake (if needed, instructions are here: How to access your Raspberry Shake’s computer via ssh), print out the contents of the interfaces file with cat /etc/network/interfaces and post them here? Thank you.
When you say “settings set in the terminal are overwritten by the surface”, do you mean the configuration page rs.local/ with “surface”? If so, after setting up the certificate, what action on the surface appears to overwrite the configuration you have made via the command line?
For the third query, we do not recommend a USB connection between Shake and a local PC, but an Ethernet cable connection. Remember to set the PC IP address in the Shake discovery range, as shown on this page of our manual: Discovery IP Once done, you will be able to easily access all the data the instrument is recording, and see it on screen with software like SWARM, or similar.
Exactly. I mean the rs.local page with the settings set via the terminal. That was the description handed to me and unfortunately I can not work with the device they tried this on so I dont really have more information. I will recreate it as soon as the network works with the device I have been given and post the logs.
The third query… Yeah. Terribly sorry because I could have thought of that myself. They are organizing an adapter and I will work with it next week.
Update: After second it up newly for the third time I have made the Wifi work on my home network. I will update as soon as I have interacted with eduroam.
I have finally arrived at the same problem my predecessors have. I have created an own certificate file from the python script installer from my employer and put it in place, but the shake will not connect. I have attached the iwconfig and the contents of wpa-supplicant…
I dont know how they tried to connect via the web interface as it will not work for eduroam imo…
Which log files do you need?
Thank you for keeping me posted with all the steps and progress you have made.
Regarding the logs, can you download the base package (the one from the orange button in the rs.local/ home, or the entire content of the opt/log folder) and attach it to your reply?
Also, can you post the cat output of the following files? Feel free to obscure any private network info.
Of course - It is in my own interest after all. Attached is everything you requested. I am in homeoffice right atm though, so not near the eduroam network.
Output of dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
#nohook loo
denyinterfaces wlan0
resolv.conf:
# Generated by resolvconf
nameserver 8.8.4.4
nameserver 180.76.76.76
interfaces:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
# Start wlan0 definition
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Thank you for all the details ryu, the logs were especially helpful as they indicate that, for some reason, no internet/DNS connection is found, even if your nameservers have been accepted and read by the OS.
2023 328 21:20:57: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
2023 328 21:20:57: No internet connection found
2023 328 21:21:09: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
If you have already tried (or please try if you haven’t), what is the result of pinging the two DNS addresses you have added, or the more generic Google 8.8.8.8?
If the result of the ping command is negative, can you try the following?
Please open the dhcpcd.conf file with
sudo nano /etc/dhcpcd.conf
Add the following at the very start of the file:
interface eth0
and do not modify anything else. Then do:
sudo service dhcpcd restart
to make sure those changes took hold and then check the output file with
nano /etc/resolv.conf
This should renew the configuration and possibly, solve your connectivity issue. If the Shake still doesn’t connect after this last command, try rebooting it again. If, even after this the Shake still doesn’t connect, please re-cat the files you have sent me in your previous message, alongside the new logs from the unit.
interface eth0
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
#nohook loo
denyinterfaces wlan0
resolv.conf
# Generated by resolvconf
nameserver 8.8.4.4
nameserver 180.76.76.76
interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
# Start wlan0 definition
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Sorry to hear that that has not worked as I hoped.
It seems we are stuck in the same situation as before, with the Shake not finding a DNS/internet connection:
2023 329 06:29:55: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
2023 329 06:29:55: No internet connection found
2023 329 06:30:07: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
I’m sure you already have, but have you tried to ping some common websites? Like Google on 8.8.8.8 or our server on 144.91.66.87? In any case, what are the ping results?
I assume they will (should?) be negative, and, in this case, can you execute and post the output of
traceroute 144.91.66.87
to see where the failure is along the connection pipeline?
If, instead, both ping and traceroute report no problems, can you please check
nc -zvw5 144.91.66.87 55555 and nc -zvw5 144.91.66.87 55556 to see if the ports needed to transmit data are open?
With the outputs of all these commands we should get a more detailed insight on what is possible causing the situation you are in.
Thank you again.
Ok, so there is an issue straight at the beginning, with the Shake unable to do anything else beyond trying to check for a connection (which is not found).
As the WiFi was working (message #4 on this topic) we can assume that adding the certificate is behind the current connectivity issues. On the Shake side, everything appears to be correctly configured.
Can you try the following?
Remove the interface eth0 from dhcpcd.conf and re-execute sudo service dhcpcd restart
Now, can you try to see if the, with the eduroam certificate installed, you manage to connect using the Shake internal WiFi adapter?
I would like to check if the dongle you are using could be the cause behind the connectivity problems, or if connecting via the Pi WiFi (which will be a test and not a solution in any case, as we don’t recommend using it) shows the same issue(s).
If you manage to connect, then maybe trying different dongles could help. If not, we will have to take a different approach and see what else can be done.
Are you certain that the Raspberry Shake&Boom has an internal Wifi adapter? Before connecting the dongle the device did not show me a wlan0 in iwconfig and, because the product page stated Wifi OR Ethernal, we presumed it did not. Thats why we started using the dongle in the first place.
I will still try what you have proposed as soon as I get on the campus again.
Additionally, if it wouldnt be too much trouble - Is there any possibility to schedule a chat to speed up this issue a little bit and so I can try things directly? That would help a bunch and i could try to summarize the solution here afterwards. If that does not fit your schedule it is completely understandable.
Funny story - It turns out that the dongle did not seem to be working, which means that by installing the driver for the dongle somehow the internal Wifi module started working again. So I have been working with the internal Wifi the whole time.
Interesting, thank you for the update. So it appears the missing connection was due to a possible “conflict” between the dongle and the Pi internal WiFi adapter? It would be an avenue to explore…
At this point, if you haven’t already solved the problem in the meantime, I would suggest re-burning the microSD card to go back to the Shake OS factory settings (no WiFi, no dongle drivers), and then restart from there, following this list, if you want:
Check Ethernet connectivity with no certificate (this should be immediate)
If all the above works, then disable the internal WiFi, install the Dongle, and try again to check connectivity without and with the certificate.
The steps above should cover all possible variations/combinations, so if one of them fails, it will be possible to focus on that before proceeding forward, without mixing things up.
Regarding your request for a chat, that would go beyond the standard tech support we provide and fall inside the 1-1 dedicated support hours, which is a paid service. If you are still interested, you can send an email to sales [at] raspberryshake [dot] org for a quote, citing this topic.
