github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-22 01:22:50 -05:00
Code Issues 959 Packages Projects Releases 74 Wiki Activity

[GH-ISSUE #1204] latest version has a weird issue with raw TCP #3749

New Issue
Closed
opened 2026-04-20 07:49:40 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-20 07:49:40 -05:00
Owner
Copy Link

Originally created by @mindgam3s on GitHub (Aug 2, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1204

I have stability issues with RAW TCP connections in the latest stack

gerbil 1.0.0
pangolin 1.8.0
traefik 3.4.0
newt 1.4.0

the latest combination working was with:

gerbil 1.0.0
pangolin 1.7.3
traefik 3.4.0
newt 1.3.4

I don't know exactly what it is, but the networking seems to be unstable. the first connection is fine for a few secs and then it aborts?

reverting back to the old versions completly fixes the problem.

no real logs sadly, as the program failing is "Hyperbackup" from my synology diskstation, which does not give anything helpful besides "the networking is not working"

Originally created by @mindgam3s on GitHub (Aug 2, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1204 I have stability issues with RAW TCP connections in the latest stack gerbil 1.0.0 pangolin **1.8.0** traefik 3.4.0 newt **1.4.0** the latest combination working was with: gerbil 1.0.0 pangolin **1.7.3** traefik 3.4.0 newt **1.3.4** I don't know exactly what it is, but the networking seems to be unstable. the first connection is fine for a few secs and then it aborts? reverting back to the old versions completly fixes the problem. no real logs sadly, as the program failing is "Hyperbackup" from my synology diskstation, which does not give anything helpful besides "the networking is not working"
GiteaMirror commented 2026-04-20 07:49:42 -05:00
Author
Owner
Copy Link

@mindgam3s commented on GitHub (Aug 4, 2025):

alright, nevermind :)

my smart a** installed the amd64 version on myraspi4 when updating :D
I previously used the arm32v6 which works.

but oddly enough the amd64 didn't throw any errors when starting

issue can be closed

<!-- gh-comment-id:3149599030 --> @mindgam3s commented on GitHub (Aug 4, 2025): alright, nevermind :) my smart a** installed the **amd64** version on myraspi4 when updating :D I previously used the **arm32v6** which works. but oddly enough the amd64 didn't throw any errors when starting issue can be closed
GiteaMirror commented 2026-04-20 07:49:43 -05:00
Author
Owner
Copy Link

@EricSand commented on GitHub (Feb 7, 2026):

Hi @mindgam3s, I try to get Synology HyperBackup working though Pangolin.

For that, I created a RAW TCP resource for port 6281 and the IP of the target NAS. The port is open and reachable though the Pangolin domain according to Rustscan porscanner (so firewall on the VPS is fine). However, I still get the generic "network not working" error on the source NAS.

Did you do anything else to make it work? Your support is very much appreciated.

<!-- gh-comment-id:3865143893 --> @EricSand commented on GitHub (Feb 7, 2026): Hi @mindgam3s, I try to get Synology HyperBackup working though Pangolin. For that, I created a RAW TCP resource for port 6281 and the IP of the target NAS. The port is open and reachable though the Pangolin domain according to Rustscan porscanner (so firewall on the VPS is fine). However, I still get the generic "network not working" error on the source NAS. Did you do anything else to make it work? Your support is very much appreciated.
GiteaMirror commented 2026-04-20 07:49:44 -05:00
Author
Owner
Copy Link

@mindgam3s commented on GitHub (Feb 7, 2026):

not that I remember doing anything fancy.

but my setup is a little different because I sync from one synology to a generic rrsync target.

<!-- gh-comment-id:3865186121 --> @mindgam3s commented on GitHub (Feb 7, 2026): not that I remember doing anything fancy. but my setup is a little different because I sync from one synology to a generic rrsync target.
GiteaMirror commented 2026-04-20 07:49:44 -05:00
Author
Owner
Copy Link

@EricSand commented on GitHub (Feb 7, 2026):

Thanks for your fast response!

It turns out that DSM 7.0 and newer requires in addition to port 6281 that also the HTTPS management port (defaults to 5001) is reachable (see: https://kb.synology.com/en-en/DSM/tutorial/What_network_ports_are_used_by_Synology_services).

So, I created another RAW TCP resources with port 5001 and it works.

However, I dont like the fact that the management UI is now reachable though the internet. Maybe its just needed for initial configuration / authorization of the backup task. I will check if disabling the 5001 resource brakes an existing backup task.

UPDATE: Indeed, you only need to activate the 5001 resource for creating the backup task. Ones created, it runs with only port 6281 exposed.

<!-- gh-comment-id:3865205908 --> @EricSand commented on GitHub (Feb 7, 2026): Thanks for your fast response! It turns out that DSM 7.0 and newer requires in addition to port 6281 that also the HTTPS management port (defaults to 5001) is reachable (see: https://kb.synology.com/en-en/DSM/tutorial/What_network_ports_are_used_by_Synology_services). So, I created another RAW TCP resources with port 5001 and it works. However, I dont like the fact that the management UI is now reachable though the internet. Maybe its just needed for initial configuration / authorization of the backup task. I will check if disabling the 5001 resource brakes an existing backup task. UPDATE: Indeed, you only need to activate the 5001 resource for creating the backup task. Ones created, it runs with only port 6281 exposed.
GiteaMirror commented 2026-04-20 07:49:45 -05:00
Author
Owner
Copy Link

@mindgam3s commented on GitHub (Feb 7, 2026):

that's where our setups differ.

but you shouldn't need to have 5001 be exposed as RAW-TCP! that's bypassing authentication then.

normal HTTP/S should be enough.

maybe it works now without exposing after setup, but it could be required again after a reboot or so.
keep an eye out for that.

<!-- gh-comment-id:3865231041 --> @mindgam3s commented on GitHub (Feb 7, 2026): that's where our setups differ. but you shouldn't need to have 5001 be exposed as RAW-TCP! that's bypassing authentication then. normal HTTP/S should be enough. maybe it works now without exposing after setup, but it could be required again after a reboot or so. keep an eye out for that.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#3749
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?