Setting a blank guest password does not work for repeater (and room server).
Companion app shows the blue bar at the top "You're logged in as guest". However, stats/actions error out and no pyMC sessions/acls are registered. Room server same and does not accept messages.
If I set an actual password, like "hello", stats and actions work fine (with exception) and pymc registers an active session and acl. The exception is the owner info and telemetry.
The four variations tried results in what looks like a successful guest login. Blue banner at top says you're logged in as guest but nothing works and no pymc sessions.
A deliberate incorrect password errors out immediately (no blue bar).
-- ISSUE: ACL ---------------------
Its my understanding ACLs should be permanent until removed.
First time login creates the ACL, (guest or admin).
When ACL exists, a blank password login will check against the ACL. If exists it logs in ok. No acl login error (or should login in as guest. ie If a blank guest password is set and no acl exists, a first time login with blank password should login and create acl as guest.)
-Guest and admin ACL login appear to both be working fine, as long as an acl exists.
-Rebooting pymc_repeater clears out all acl's.
-Currently only way a guest ACL is created, is if a guest password is set and the password is used one time.
-manually trying to remove an ACL has error (screen shot). The ACL remains visible and active until pymc restarts.
#Failed to remove client: Missing required field: public_key
(A side note, I ran into trouble using remoteterm testing logins and acls. I think RT might have an issue with guest/acl login as well. I suggest testing this guest/acl problem with official meshcore mobile (and/or the web) client apps otherwise weird thing happens. For example, in RT, a first time guest login (to mc repeater fw v1.16) with blank password never works for me, where on mobile app blank password works fine and creates the guest acl. And then once i have ACL, RT still struggles to login as guest. Admin login seems to always work.)
Two issues that seem intertwined / related
-- ISSUE: Blank guest password --------------------
Setting a blank guest password does not work for repeater (and room server).
Companion app shows the blue bar at the top "You're logged in as guest". However, stats/actions error out and no pyMC sessions/acls are registered. Room server same and does not accept messages.
If I set an actual password, like "hello", stats and actions work fine (with exception) and pymc registers an active session and acl. The exception is the owner info and telemetry.
```
security:
admin_password: secret
allow_read_only: true
guest_password: hello
tried:
guest_password: (blank)
#guest_password: (commented out)
guest_password: '' (empty quotes)
guest_password: null (null)
```
The four variations tried results in what looks like a successful guest login. Blue banner at top says you're logged in as guest but nothing works and no pymc sessions.
A deliberate incorrect password errors out immediately (no blue bar).
<br>
-- ISSUE: ACL ---------------------
<br><br><br>
Its my understanding ACLs should be permanent until removed.
First time login creates the ACL, (guest or admin).
When ACL exists, a blank password login will check against the ACL. If exists it logs in ok. No acl login error (or should login in as guest. ie If a blank guest password is set and no acl exists, a first time login with blank password should login and create acl as guest.)
-Guest and admin ACL login appear to both be working fine, as long as an acl exists.
-Rebooting pymc_repeater clears out all acl's.
-Currently only way a guest ACL is created, is if a guest password is set and the password is used one time.
-manually trying to remove an ACL has error (screen shot). The ACL remains visible and active until pymc restarts.
#Failed to remove client: Missing required field: public_key
<img width="300" height="100" alt="Image" src="https://github.com/user-attachments/assets/a8782742-85a5-4794-8b17-7b6181fc70b1" />
<br>
<img width="300" height="100" alt="Image" src="https://github.com/user-attachments/assets/6d09493a-29a7-494c-ac3b-a8bf498e3742" />
<br>
<img width="1652" height="234" alt="Image" src="https://github.com/user-attachments/assets/5a076590-f207-4bbd-977f-98586ded5c07" />
(A side note, I ran into trouble using remoteterm testing logins and acls. I think RT might have an issue with guest/acl login as well. I suggest testing this guest/acl problem with official meshcore mobile (and/or the web) client apps otherwise weird thing happens. For example, in RT, a first time guest login (to mc repeater fw v1.16) with blank password never works for me, where on mobile app blank password works fine and creates the guest acl. And then once i have ACL, RT still struggles to login as guest. Admin login seems to always work.)
<!-- github-sync-id:4684968938 -->
The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again.
Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed.
I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification?
The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again.
Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed.
I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification?
<!-- github-comment-id:4762995941 -->
The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again.
Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed.
I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification?
RT aside, when rebooting or power cycle a repeater with meshcore firmware, the existing ACL's remains intact so it seems that is stored in firmware somewhere. I'm not sure if pymc_repeater is intentional about storing acl or not, either way im fine with I just thought it might be related to the issue I was most interested in which is the guest blank password issue. I could have worded the title better I suppose.
With pymc_repeater, is guest possible without a password like it is on the meshcore firmware? (ie blank or no password entered). I heard it should be possible but I have not had any success doing so with pymc_repeater.
> The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again.
>
> Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed.
>
> I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification?
RT aside, when rebooting or power cycle a repeater with meshcore firmware, the existing ACL's remains intact so it seems that is stored in firmware somewhere. I'm not sure if pymc_repeater is intentional about storing acl or not, either way im fine with I just thought it might be related to the issue I was most interested in which is the guest blank password issue. I could have worded the title better I suppose.
With pymc_repeater, is guest possible without a password like it is on the meshcore firmware? (ie blank or no password entered). I heard it should be possible but I have not had any success doing so with pymc_repeater.
<!-- github-comment-id:4763533092 -->
this was possible when first deployed, but something could have changed while updating, let me check and feed back.
this was possible when first deployed, but something could have changed while updating, let me check and feed back.
<!-- github-comment-id:4776923098 -->
found a solution, not sure if its best but it fixes the issue for repeater and room server guest login.
Bug 1: acl.py — blank-guest client never stored in ACL
File: openhop_repeater/repeater/handler_helpers/acl.py, lines 106-116
python
if not password:
client = self.clients.get(pub_key)
if client is None:
if self.allow_read_only:
logger.info("Blank password, allowing read-only guest access")
return True, PERM_ACL_GUEST # ← BUG: returns success but never creates client entry
else:
...
When a new client (not in ACL) sends a blank password and allow_read_only=True, the code returns (True, PERM_ACL_GUEST) but never calls self.clients[pub_key] = ClientInfo(...). The client is unknown to the ACL, so every subsequent REQ/telemetry check in protocol_request.py fails the get_client_from_acl() lookup → "REQ from unknown client".
Compare this to password-login (lines 133-154), which properly creates the ClientInfo entry, stores the shared secret, and updates timestamps.
Bug 2: login.py — allow_read_only defaults to False for repeaters
File: openhop_repeater/repeater/handler_helpers/login.py, line 98
python
"allow_read_only": security.get("allow_read_only", False),
For repeaters this hard-codes False as the default. For room servers (line 87) it defaults to True. This means even with guest_password: '', blank login is rejected by Bug 1's early path.
#######################################
Fix for acl.py (lines 106-116):
python
if not password:
client = self.clients.get(pub_key)
if client is None:
if self.allow_read_only:
logger.info("Blank password, allowing read-only guest access")
# Create client entry so subsequent REQ/telemetry lookups succeed
if len(self.clients) < self.max_clients:
client = ClientInfo(client_identity, 0)
self.clients[pub_key] = client
client.last_timestamp = timestamp
client.last_activity = int(time.time())
client.last_login_success = int(time.time())
client.permissions &= ~PERM_ACL_ROLE_MASK
client.permissions |= PERM_ACL_GUEST
client.shared_secret = shared_secret
logger.info(f"Added read-only client {pub_key[:6].hex()}...")
else:
logger.warning("ACL full, cannot add client")
return False, 0
return True, PERM_ACL_GUEST
else:
logger.info("Blank password, sender not in ACL and read-only disabled")
return False, 0
logger.info(f"ACL-based login for {pub_key[:6].hex()}...")
return True, client.permissions
Fix for login.py (line 98):
Before:
"allow_read_only": security.get("allow_read_only", False),
After:
"allow_read_only": security.get("allow_read_only", guest_password is None),
This way if guest_password is not set, allow_read_only becomes True (blank login allowed). If guest_password IS set, it stays False (blank login rejected, must use password).
found a solution, not sure if its best but it fixes the issue for repeater and room server guest login.
Bug 1: acl.py — blank-guest client never stored in ACL
File: openhop_repeater/repeater/handler_helpers/acl.py, lines 106-116
python
if not password:
client = self.clients.get(pub_key)
if client is None:
if self.allow_read_only:
logger.info("Blank password, allowing read-only guest access")
return True, PERM_ACL_GUEST # ← BUG: returns success but never creates client entry
else:
...
When a new client (not in ACL) sends a blank password and allow_read_only=True, the code returns (True, PERM_ACL_GUEST) but never calls self.clients[pub_key] = ClientInfo(...). The client is unknown to the ACL, so every subsequent REQ/telemetry check in protocol_request.py fails the get_client_from_acl() lookup → "REQ from unknown client".
Compare this to password-login (lines 133-154), which properly creates the ClientInfo entry, stores the shared secret, and updates timestamps.
<br><br>
Bug 2: login.py — allow_read_only defaults to False for repeaters
File: openhop_repeater/repeater/handler_helpers/login.py, line 98
python
"allow_read_only": security.get("allow_read_only", False),
For repeaters this hard-codes False as the default. For room servers (line 87) it defaults to True. This means even with guest_password: '', blank login is rejected by Bug 1's early path.
<br>#######################################<BR>
Fix for acl.py (lines 106-116):
```
python
if not password:
client = self.clients.get(pub_key)
if client is None:
if self.allow_read_only:
logger.info("Blank password, allowing read-only guest access")
# Create client entry so subsequent REQ/telemetry lookups succeed
if len(self.clients) < self.max_clients:
client = ClientInfo(client_identity, 0)
self.clients[pub_key] = client
client.last_timestamp = timestamp
client.last_activity = int(time.time())
client.last_login_success = int(time.time())
client.permissions &= ~PERM_ACL_ROLE_MASK
client.permissions |= PERM_ACL_GUEST
client.shared_secret = shared_secret
logger.info(f"Added read-only client {pub_key[:6].hex()}...")
else:
logger.warning("ACL full, cannot add client")
return False, 0
return True, PERM_ACL_GUEST
else:
logger.info("Blank password, sender not in ACL and read-only disabled")
return False, 0
logger.info(f"ACL-based login for {pub_key[:6].hex()}...")
return True, client.permissions
```
Fix for login.py (line 98):
```
Before:
"allow_read_only": security.get("allow_read_only", False),
After:
"allow_read_only": security.get("allow_read_only", guest_password is None),
```
This way if guest_password is not set, allow_read_only becomes True (blank login allowed). If guest_password IS set, it stays False (blank login rejected, must use password).
<!-- github-comment-id:4845502029 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Two issues that seem intertwined / related
-- ISSUE: Blank guest password --------------------
Setting a blank guest password does not work for repeater (and room server).
Companion app shows the blue bar at the top "You're logged in as guest". However, stats/actions error out and no pyMC sessions/acls are registered. Room server same and does not accept messages.
If I set an actual password, like "hello", stats and actions work fine (with exception) and pymc registers an active session and acl. The exception is the owner info and telemetry.
The four variations tried results in what looks like a successful guest login. Blue banner at top says you're logged in as guest but nothing works and no pymc sessions.
A deliberate incorrect password errors out immediately (no blue bar).
-- ISSUE: ACL ---------------------
Its my understanding ACLs should be permanent until removed.
First time login creates the ACL, (guest or admin).
When ACL exists, a blank password login will check against the ACL. If exists it logs in ok. No acl login error (or should login in as guest. ie If a blank guest password is set and no acl exists, a first time login with blank password should login and create acl as guest.)
-Guest and admin ACL login appear to both be working fine, as long as an acl exists.
-Rebooting pymc_repeater clears out all acl's.
-Currently only way a guest ACL is created, is if a guest password is set and the password is used one time.
-manually trying to remove an ACL has error (screen shot). The ACL remains visible and active until pymc restarts.
#Failed to remove client: Missing required field: public_key
(A side note, I ran into trouble using remoteterm testing logins and acls. I think RT might have an issue with guest/acl login as well. I suggest testing this guest/acl problem with official meshcore mobile (and/or the web) client apps otherwise weird thing happens. For example, in RT, a first time guest login (to mc repeater fw v1.16) with blank password never works for me, where on mobile app blank password works fine and creates the guest acl. And then once i have ACL, RT still struggles to login as guest. Admin login seems to always work.)
The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again.
Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed.
I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification?
RT aside, when rebooting or power cycle a repeater with meshcore firmware, the existing ACL's remains intact so it seems that is stored in firmware somewhere. I'm not sure if pymc_repeater is intentional about storing acl or not, either way im fine with I just thought it might be related to the issue I was most interested in which is the guest blank password issue. I could have worded the title better I suppose.
With pymc_repeater, is guest possible without a password like it is on the meshcore firmware? (ie blank or no password entered). I heard it should be possible but I have not had any success doing so with pymc_repeater.
this was possible when first deployed, but something could have changed while updating, let me check and feed back.
found a solution, not sure if its best but it fixes the issue for repeater and room server guest login.
Bug 1: acl.py — blank-guest client never stored in ACL
File: openhop_repeater/repeater/handler_helpers/acl.py, lines 106-116
When a new client (not in ACL) sends a blank password and allow_read_only=True, the code returns (True, PERM_ACL_GUEST) but never calls self.clients[pub_key] = ClientInfo(...). The client is unknown to the ACL, so every subsequent REQ/telemetry check in protocol_request.py fails the get_client_from_acl() lookup → "REQ from unknown client".
Compare this to password-login (lines 133-154), which properly creates the ClientInfo entry, stores the shared secret, and updates timestamps.
Bug 2: login.py — allow_read_only defaults to False for repeaters
For repeaters this hard-codes False as the default. For room servers (line 87) it defaults to True. This means even with guest_password: '', blank login is rejected by Bug 1's early path.
#######################################
Fix for acl.py (lines 106-116):
Fix for login.py (line 98):
This way if guest_password is not set, allow_read_only becomes True (blank login allowed). If guest_password IS set, it stays False (blank login rejected, must use password).