Secure Scuttlebutt Room Not Showing Up Online

Weeell… It did not :stuck_out_tongue:

It would stay at indexing databases; maybe it’s fixed in the next release, or it does not expect to have nothing to index.

I tried downgrading to the previous version, that gave an error (maybe because the new version got stuck).

Uninstall worked, clean installed the latest version. It does not have my account, but restore from 24-word security code worked.

Log in (browser on desktop, show QR, scan QR on phone, open with Manyverse, allow access) works immediately.

The room is listed in Manyverse, and my account is listed in the room as a member (with addition ‘this is you, admin’ )

What do you mean? The hardware?

Hmmmm… but I also have the latest version of Manyverse 0.2201.7-beta on my desktop MacOS. You are using the QR code to connect to your Room with Manyverse on your phone, maybe that’s the difference. ??? I’ll have to see which versions my friends are using on their mobile android because 0.2201.7 is the newest but google play is still 0.2201.5 and fdroid is 0.2111.5, and I know some of my friends use Fdroid.

One of the bug fixes in the latest version is " Bug fix: room 2.0 invites also connect to room" - maybe doesn’t really work with MacOS, or work very well with anything, but only with QR code.

What do you mean? The hardware?

Yes, the hardware. DIY or offsite hosted server?

restore from 24-word security code worked.

Was that automatic, or did you have to setup a 24-word security code prior to uninstalling?

I think the QR code is nothing more than the URL to the room. When the browser on a phone pick it up and displays the website, the website offers the same button as is on the desktop, the difference being that in my case I do have an app installed on my phone that can understand what the button says to the OS.

DIY, more specific, pentium-class CPU on a mini-ITX board in a NAS-sized enclosure. I used to run Yunohost on Orange Pi’s, but at some point I couldn’t spill coffee on my desk without causing server outage.

Yes, ‘Backup’ under ‘Data & Storage’ in the Manyverse settings.

That would be such a waste. If your friends are somewhat flexible, have a look at Matrix for you Yunohost and Element (for example, there are quite a few clients by now) for their phones.

You can set up a private server, but can also federate with the wider network. The latest clients do offline chat, but the network is not dependent on accidental encounters to have data flowing.

have a look at Matrix for you Yunohost

Naw, I really want to go with SSB.

These are the things that come up in yunohost diagnostics:

Internet connectivity:

  • DNS resolution seems to be working, but it looks like you’re using a custom /etc/resolv.conf.

Ports exposure:

  • Port 25 is not reachable from outside. [blocked by my ISP]

Web:

  • Your local network does not seem to have hairpinning enabled.

Email (due to port 25):

  • The SMTP mail server cannot send emails to other servers because outgoing port 25 is blocked in IPv4. * The SMTP mail server cannot send emails to other servers because outgoing port 25 is blocked in IPv6.
  • The SMTP mail server is unreachable from the outside on IPv4. It won’t be able to receive emails.
  • The SMTP mail server is unreachable from the outside on IPv6. It won’t be able to receive emails.
  • The reverse DNS is not correctly configured in IPv4. Some emails may fail to get delivered or may get flagged as spam.
  • The reverse DNS is not correctly configured in IPv6. Some emails may fail to get delivered or may get flagged as spam.
  • Your IP or domain 50.98.175.154 is blacklisted on Invaluement
  • Your IP or domain 50.98.175.154 is blacklisted on SPFBL.net RBL

Then this too:

“Unable to update the cache of APT (Debian’s package manager). Here is a dump of the sources.list lines, which might help identify problematic lines:”

And this:

E: Repository ‘Index of /debian buster InRelease’ changed its ‘Suite’ value from ‘testing’ to ‘oldstable’

E: Repository ‘Index of /raspbian buster InRelease’ changed its ‘Suite’ value from ‘stable’ to ‘oldstable’

All else says “Everything looks good for…”

So, I will put some screenshots to show that local WiFi connections work fine as I have some local connections right now, I might as well take some screenshots for the record. Yes, I changed their names and avatars for anonymity:

I click on Connections and it goes to > Connected Peers:

Then, if I click anywhere on the white bar it goes to the Connections Panel:

But, as you can see there are no Room/Server connections, it is not detecting or not connecting to my Room for some reason.

Most things are no issue for SSB. If you don’t intend to use email, you can turn off email functionality for the domain:

That will spare you the warnings in diagnosis.

Hairpinning might come into play. Hairpinning is when the router recognizes you want to reach your (web)server from inside the LAN, and lets you visit it directly on the internal IP instead of going to the internet first, and then returning to your home LAN. When you ping your Yunohost by its hostname versus pinging it on the internal IP, is there a large difference in reply time?

Debian got a new version, ‘recently’. Since the image was created, the apt configuration is outdated. Are you familiar with SSH? Then have a look at this post on how to correct the configuration.

Home>Domains>mydomain>config
This screen does not exist for me.
I have YunoHost 4.1.7.2

If I go to Home>Domains>mydomain I see this:

" This is your default domain. "

  • View DNS configuration
  • Manage SSL certificate
  • Delete this domain

That’s it. No “feature”

Let’s see:

IP of my rasp pi: 39 packets transmitted, 39 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.625/2.204/2.709/0.303 ms

My yunohost web address: 23 packets transmitted, 0 packets received, 100.0% packet loss

Not sure if I did that correctly or not.

No, I’m not.

Hm…

It says, " The most straightforward way to fix it is to run sudo apt update from the command line where you’ll be asked to confirm this change."

I can’t see any way to access the terminal on my rasp pi. How do I get to the terminal?

Hm… so there’s this other access point, for other users, /yunohost/sso/ Hm, weird, I tried to login with my admin login… doesn’t work, so I guess I have to create a New User to be able to access /yunohost/sso/… maybe… okay, so I’ll try creating a New User, currently there are no users.

I tried creating a new user in Users.
I thought, okay, I guess I’ll just call the new user ‘admin’.
Hit ‘save’ and… it did nothing, there was an error, that user already exists.
Oh, what?? Hm… okay, I’ll create a new user with a different name then…
Now I get a “There is already a YunoHost operation running. Please wait for it to finish before running another one.” Shit, did I fuck it up. I waited and waited, I can’t do anything because everytime I click on something, “There is already a YunoHost operation running. Please wait for it to finish before running another one.” Huuuuuuuh. I did a reboot. Still getting the “There is already a YunoHost operation running. Please wait for it to finish before running another one.” message. Damn. Eventually that went away and I made a new user. Whew, I thought I fucked it up.

Oh, okay, the new user account is also the admin account it seems as the email is admin@mydomain.noho.st . Ah, I see now in the documentation, admin is reserved for the first user, gotta read ahead more, ha ha.
Uh… what the hell, that was pointless, all there is are links to the apps installed on Yunohost, nothing else. No access to terminal or anything.

Oh man, I see, I thought there was a terminal in yunohost somewhere, I just do it from terminal on my computer, okay, I’m in… jeez.

did
sudo apt update
sudo apt upgrade
cross fingers this doesn’t fuck everything up :crossed_fingers:
It asked me it I wanted to update or keep the current version of the modified “metronome.cfg.lua” and I chose to keep the current version, as I thought it must have been modified by YunoHost for some reason.

So, why is my Room not showing up in Manyverse, but your Room seems to work fine?

Anything to do with “hairpinning" or the " /etc/resolv.conf`”?

Okay, when I sign in to your Room, I can choose sign in with “Sign in with SSB”, and it works! It switches to Manyverse and asks me

" Allow sign-in?
A web browser is requesting permission to identify you. Do you want to sign in to the server server.name.com?"

I click ‘yes’ and when I go back to your Sign-In page, it refreshes and shows the Members Panel, sign-in was successful.

When I try to sign into my Room using "“Sign in with SSB”, it opens Manyverse, asks the same question, I hit ‘Yes’. It switches back to the browser and opens to a new blank tab. I switch back to the Sign-In tab. It says… ‘Waiting for confirmation’ then underneath appears a message:

Sign-in failed. Please make sure you use an SSB app that supports this method of login, and click the button above within a minute after this page was opened.

This is the same thing that happens for other members on different devices. So, this must be some kind of problem with my setup. It is a CLUE. :mag:

It does not receive confirmation. Why? And how can I fix this?

It is at least some hint of a clue :slight_smile:

These other users, do they connect via the internet or at home via the LAN/WiFi?

Did you try re-installing the SSB-room, or installing it a second time but on a new subdomain (like test.yourdomain.noho.st)? I think I would try creating a new domain and install a test there first.

These other users, do they connect via the internet or at home via the LAN/WiFi?

You are one of the ‘other users’, too, don’t forget.

They have tried to connect via the internet at another location, and locally on WiFi.

Did you try re-installing the SSB-room,

No. I guess I can try that. The reason I didn’t is because it was recommended not to in the Yunohost documentation, saying that reinstalling won’t solve any problems.

or installing it a second time but on a new subdomain (like test.yourdomain.noho.st)? I think I would try creating a new domain and install a test there first.

So, this would create a second instance of SSB Room?

Okay, I made a testing.domain.noho.st and will install SSB Room there…

Yes, SSB Room can handle multiple installs on a single server.

Yeah… That’s right as well. On the other hand, the whole SSB-universe is quite in flux and while useable, barely out of alpha. The resolv.conf warning in the diagnostics is something I would flag as “repair, don’t reinstall”, but with SSB we got different outcomes of a clean install, and no way to troubleshoot or understand. In this case I don’t see reinstalling itself as a solution, but as part of troubleshooting.
Lets install on another subdomain first, I’ll give that a try as well.

Okay.
I installed another instance on testing.mydomain.noho.st

I get an error “Did Not Connect: Potential Security Issue”.
This happened with my original room, until I installed an ssl certificate.
Should I do this for this room too, even if I will prob. delete it later?
It’s just a ‘spooky warning’ right? It shouldn’t affect the workings of the room, correct?

Yes, always create a certificate. More and more software will not connect when there’s a spooky warning.

To fix it for the time being, log in to your RPi via SSH (or log in as admin directly with a keyboard connected to your Pi)

$ ssh admin@domain.noho.st 
password
... some welcome text 
$ sudo mv /etc/resolv.conf /etc/resolv.conf.bak
$ sudo ln -s /etc/resolvconf/run/resolv.conf /etc/
$ exit

The first command renames the original file, the second command creates the symlink mentioned in the diagnosis.

I recall that on some of my Yunohost the warning kept coming back. Maybe there’s a mechanism in Armbian that creates /etc/resolv.conf on boot, triggering the warning in the diagnosis.

I tried to sign in with SSB.
Same problem. Opens manyverse, click yes, opens blank page in browser, SSB login doesn’t work. “Waiting for confirmation” … then the eventual error, Sign-in failed…

It HAS to be some problem with connecting from the APP back to the Yunohost/SSB-Room server. … the app can send Manyverse a confirmation signal, but the APP can’t send one back to the Server.

So, the APP tries to send the ‘confirmation’ back to the browser/server but instead something happens, a new blank tab opens as a result and the server doesn’t get the confirmation.

Likewise, this is probably the same thing that is preventing my Room from showing up in the APP. The APP to Server communication is not happening. But, the Server/browser to APP communication seems to work.

It doesn’t have to do with ports, because I completely turned off my router firewall before just to see if the firewall was interfering, no, no difference. Still could not connect.

To fix it for the time being, log in to your RPi via SSH

Okay, I did that. Ran the diagnostic, that warning not there anymore.
Not sure if you fixed it or just made the warning go away.

(or log in as admin directly with a keyboard connected to your Pi)

You know, I don’t know how to access the terminal directly on my pi. If I plug in a monitor, all I see is a blank screen. Anyway, remote access from my computer works.

1 Like

OMG, I thought I found the solution!! :confused:
I was reading through this doc:
Scuttlebutt Protocol Guide

“Peers constantly broadcast UDP packets on their local network advertising their presence.”

“UDP source and destination ports are set to the same port number that the peer is listening on TCP for peer connections (normally 8008).”

Okay, so maybe I need to change the portforwarding from TCP to TCP&UDP.
Tried it. Nothing different. Wait, I already tried turning off the router firewalls completely, so it’s not the ports. ARrrrggg~~!

I also had my server ip address set up in LAN DHCP, I deleted that. No difference. Still didn’t solve the prob.