Gateway webinterface becoming unresponive

[J.sim]

Just a thought about the email alerts. How does OHS resolve address for smtp2go? I may have a different DNS setup (somehow I don’t know what you are running but my place is using dnsmasq from r-pi  and then I connect to mates place via a ubiquiti wireless bridge down the hill for internet).

 

I just had the sudden thought that you may have made the default gateway the DNS service which in my case it is not.

 

Im trying to figure it out by looking through the librarys. About time I learnt some more about it all…

[J.sim]

I think the bit I circled in red is meant to be the DNS Server address? Which you have presumed would be the same as the gateway?? Fair enough of course. Its just blokes like me that like to get the internet free from my mate that mucks it up…

[vysocan]

Hello,

you are right the function is: Ethernet.begin(mac, ip, dns, gateway, subnet);

And usually your NAT device, be it router or rpi(dnsmasq), also serves as local DSN. I'm pretty sure your dnsmasq is doing so, unless you configured it otherwise. Or do you have it setup differently? I mean the gateway is not at your place, but only at your mate place?

[J.sim]

Yes I have made the wireless bridge client my gateway and I set up a separate dns on a pi with the mqtt on it. The idea was because the wireless bridge unit  wasn’t able to do ntp – something I hadn’t managed to get work properly yet.

 

I will change that tonight as I think the bridge can act as a dns unit. Typically it is usually set up to assign the the isp’s DNS servers to dhcp requests.

[vysocan]

Hello,

just a question, why do you need a local NTP server? For the GW or there is different reason?

[J.sim]

Nope, there is no need for local ntp server, I was just not getting to pick up the ntp time earlier. However since I changed my network around to suit OHS better it seems to be working fine from the NZ ntp.org servers.

 

Interestingly on the note of emails I notice that in checking logs I found that it wasn’t logging in correctly so I double checked and found I had a mistake on the password. Then after that I was getting another error about the body of the email failing to load

 

Also sms or page doesn’t seem to work but it may because of my sim card plan running out. Im not sure just yet I have had time to follow that up.

 

Other than that all works well now and I will get started into the documentation soon.

[vysocan]

If I add DNS into setup, I would need to move to next major version, as this require EEPROM structure change. This I would like to avoid, since there was release just recently.

Body rejected, it means the actual message has some mistake in it. Which is not likely, do you have a correct email in some of your contacts? Is the contact enabled and has proper group or is it global?

Sim card has to have no pin set up. Maybe this?

Great

[alinkamaja]

If the gateway freezes exactly when an iButton is presented on an auth node, you’re likely hitting either a 1-Wire bus fault (line stuck low / brownout) or a software path that blocks/crashes on specific tag data. Quick triage:
• Reproduce systematically: try multiple iButtons and multiple nodes; note whether it’s a single token/node or any. If one token always triggers it, dump its full 64-bit ROM (family, ID, CRC) and test with/without CRC validation.  
• Check logs/metrics: enable debug around the badge handler; add timestamps for “badge detected → read ROM → verify CRC → lookup → decision.” Watch for CPU spikes, memory growth, or a watchdog reset.  
• Electrical sanity on the 1-Wire reader: verify pull-up (commonly ~4.7 kΩ), bus not in a star, cable length within spec, solid common ground, and no parasitic shorts from the reader’s metal housing. After a badge, if the line stays low on a scope, look for a shorted reader or ESD damage.  
• Power margin: a relay/backlight/vibrator triggered on badge can sag 5 V/3.3 V and hang the gateway—log supply rails or add a temporary bench PSU; separate supplies to test.  
• Software hardening:  
  – Make the iButton read non-blocking with timeouts; never wait indefinitely for presence/bit reads.  
  – Validate the family code and CRC; reject unknown/invalid frames without throwing.  
  – Guard lookups: handle “user not found” and null/empty fields safely; avoid assumptions about ID string length/format (pad hex, no unsigned overflow).  
  – Wrap the whole auth path in a top-level try/catch and fail closed with a clear error instead of hanging.  
  – If multiple threads hit the same bus, ensure a single lock with bounded wait; avoid deadlocks from nested locks/callbacks.  
• Networking: if the node RPCs the gateway on badge, ensure the call is async and resilient; a synchronous call waiting on itself (re-entrant path) can deadlock. Add correlation IDs and timeout/retry.  
• Isolation: test the node standalone on a bench cable; swap in a known-good reader; update firmware; roll back the last change touching auth/IO.  
If you can share the few lines around the badge handler and the stack when it freezes, I can point to the likely nil/block and suggest a concrete patch.

Au passage, si tu prépares une tenue pour un événement après avoir résolu ce bug, tu peux parcourir des robes et filtrer par coupe, longueur et couleur pour trouver rapidement la pièce adaptée.