starred/OpenEPaperLink
1
0
Fork 0
mirror of https://github.com/OpenEPaperLink/OpenEPaperLink.git synced 2026-03-21 00:04:28 +01:00
Code Issues 472 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #498] T-Panel Web Interface Not Responding After Connection to Network #863

New Issue
Closed
opened 2026-03-20 18:13:49 +01:00 by sascha_hemi · 4 comments
sascha_hemi commented 2026-03-20 18:13:49 +01:00
Owner
Copy Link

Originally created by @scanalyzer on GitHub (Sep 11, 2025).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/498

Describe the bug
When I follow the instructions for the T-Panel, I can access the web interface as long as I don't connect to my network SSID. Once I do that, the device doesn't respond on port 80 anymore. It pings back on the right IP and a nmap scan shows that 80 is open, it's just not doing anything.

To Reproduce
Steps to reproduce the behavior:

  1. Follow the instructions to flash a T-Panel (both chips).
  2. Connect to the OEPL device SSID.
  3. Connect to http://192.168.4.1/setup
  4. Enter SSID and PW info and save.
  5. Restart device.
  6. Attempt to connect to http://newipaddress

or

  1. Follow the instructions to flash a T-Panel (both chips).
  2. Use the web flasher to set and save SSID info.
  3. Restart device.
  4. Attempt to connect to http://newipaddress

Expected behavior
I honestly don't know, but I would expect it to load a home screen of some kind. I tried the setup url and others referenced as demos, also to no avail.

Screenshots
Happy to supply them if needed. Just let me know what you need.

Additional context
MacOS Sequoia, EERO WiFi, Chrome Browser

Thanks for your help!

Originally created by @scanalyzer on GitHub (Sep 11, 2025). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/498 **Describe the bug** When I follow the instructions for the T-Panel, I can access the web interface as long as I don't connect to my network SSID. Once I do that, the device doesn't respond on port 80 anymore. It pings back on the right IP and a nmap scan shows that 80 is open, it's just not doing anything. **To Reproduce** Steps to reproduce the behavior: 1. Follow the instructions to flash a T-Panel (both chips). 2. Connect to the OEPL device SSID. 3. Connect to http://192.168.4.1/setup 4. Enter SSID and PW info and save. 5. Restart device. 6. Attempt to connect to http://newipaddress or 1. Follow the instructions to flash a T-Panel (both chips). 2. Use the web flasher to set and save SSID info. 5. Restart device. 6. Attempt to connect to http://newipaddress **Expected behavior** I honestly don't know, but I would expect it to load a home screen of some kind. I tried the setup url and others referenced as demos, also to no avail. **Screenshots** Happy to supply them if needed. Just let me know what you need. **Additional context** MacOS Sequoia, EERO WiFi, Chrome Browser Thanks for your help!
sascha_hemi added the bug label 2026-03-20 18:13:49 +01:00
sascha_hemi commented 2026-03-20 18:13:50 +01:00
Author
Owner
Copy Link

@skiphansen commented on GitHub (Sep 11, 2025):

The display should show the IP address, what happens if you go to that address directly?

<!-- gh-comment-id:3281262764 --> @skiphansen commented on GitHub (Sep 11, 2025): The display should show the IP address, what happens if you go to that address directly?
sascha_hemi commented 2026-03-20 18:13:50 +01:00
Author
Owner
Copy Link

@scanalyzer commented on GitHub (Sep 13, 2025):

Thanks for your response. The page fails to load.

This site can’t be reached
http://192.168.xxx.xxx/ is unreachable.
ERR_ADDRESS_UNREACHABLE

I just checked other browsers and it appears to just be Chrome that has the issue. Response headers referenced strict-origin-when-cross-origin. I think this issue can be reclassified on that basis. Thank you for your support.

<!-- gh-comment-id:3287239605 --> @scanalyzer commented on GitHub (Sep 13, 2025): Thanks for your response. The page fails to load. This site can’t be reached http://192.168.xxx.xxx/ is unreachable. ERR_ADDRESS_UNREACHABLE I just checked other browsers and it appears to just be Chrome that has the issue. Response headers referenced strict-origin-when-cross-origin. I think this issue can be reclassified on that basis. Thank you for your support.
sascha_hemi commented 2026-03-20 18:13:51 +01:00
Author
Owner
Copy Link

@skiphansen commented on GitHub (Sep 13, 2025):

That's really odd, I use Chrome exclusively on a PC and have never had a problem. Glad you got it working. For completeness what OS are you running Chrome on?

<!-- gh-comment-id:3288319904 --> @skiphansen commented on GitHub (Sep 13, 2025): That's really odd, I use Chrome exclusively on a PC and have never had a problem. Glad you got it working. For completeness what OS are you running Chrome on?
sascha_hemi commented 2026-03-20 18:13:51 +01:00
Author
Owner
Copy Link

@scanalyzer commented on GitHub (Sep 13, 2025):

MacOS 15.6.1 (24G90)
Chrome Version 140.0.7339.133 (Official Build) (arm64)

I was having trouble updating the T-Panel tag, but I got it working. Had to do the OTA update.

<!-- gh-comment-id:3288776141 --> @scanalyzer commented on GitHub (Sep 13, 2025): MacOS 15.6.1 (24G90) Chrome Version 140.0.7339.133 (Official Build) (arm64) I was having trouble updating the T-Panel tag, but I got it working. Had to do the OTA update.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
88MZ100 FW
ARM Tag FW
ap fw
bug
documentation
enhancement
good first issue
nRF FW
pull-request
Mirrored from GitHub Pull Request
 question
tag fw
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
sascha_hemi
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#863
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?