Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dump connections shows wrong addresses #170

Open
igel-kun opened this issue Jan 18, 2018 · 4 comments
Open

dump connections shows wrong addresses #170

igel-kun opened this issue Jan 18, 2018 · 4 comments
Labels
1.1 Issue related to Tinc 1.1 needs_investigation Unexpected behaviours with uncertain causes - needs more investigation

Comments

@igel-kun
Copy link

hi and, first off, thanks for providing such an awesome piece of sorftware :)
here's the issue:
I'm running a tincd at home with an internal IP address of 192.168.1.55 and an external IP address of... let's say ext.ip (forwarding port 655->655 and 24000->655 (in case of restrictive net-admins)). When I'm out with my laptop, its tinc connects fine with with the one running at home, but tinc -n <netname> dump connections on my laptop sometimes shows the internal IP of the server at home instead of the external IP:

(laptop) # tinc -n <netname> dump connections
<servername> at 192.168.1.55 port 655 options 0 socket 11 status 4

but this cannot be true as 192.168.1.55 doesn't even exist in the network that my laptop is in at this moment. The host file of the server on the laptop contains

Address = 192.168.1.55
Address = ext.ip 655
Address = ext.ip 24000

PS: I'm running tinc-1.1pre15 on both systems

@fangfufu fangfufu added the bug Issues in which the users gave a clear indication to the causes of the unexpected behaviour label Jun 23, 2021
@fangfufu
Copy link
Collaborator

Does this still happen in 1.1pre17?

@fangfufu fangfufu added needs_investigation Unexpected behaviours with uncertain causes - needs more investigation and removed bug Issues in which the users gave a clear indication to the causes of the unexpected behaviour labels Jun 23, 2021
@fangfufu
Copy link
Collaborator

I have had another read. Perhaps the node at home is reporting the address it is binding at, which is its internal IP rather than the forwarded IP, and your laptop is reporting the IP that the node at home self-reported.

Anyways, does this affect connectivity? Does it cause stability issue?

@igel-kun
Copy link
Author

igel-kun commented Jun 24, 2021

Does this still happen in 1.1pre17?

I'm now running pre17 on my laptop (gentoo) and still pre15 on the home server (raspbian). I'll report back here when I'm out with my laptop again :)

I have had another read. Perhaps the node at home is reporting the address it is binding at, which is its internal IP rather than the forwarded IP, and your laptop is reporting the IP that the node at home self-reported.

Yes, that would explain the observations I made. But wouldn't it be more useful if my local tinc reported the address it is actually connected to instead of the home-server's local address?

Anyways, does this affect connectivity? Does it cause stability issue?

I've had some connectivity issues in the past that may or may not be linked to this, but ever since I'm running pre17 on my laptop, I have not observed any more problems.

@fangfufu fangfufu added the 1.1 Issue related to Tinc 1.1 label Jun 25, 2021
@fangfufu
Copy link
Collaborator

But wouldn't it be more useful if my local tinc reported the address it is actually connected to instead of the home-server's local address?

That is a good point 🙂

I am new to the project, I am just helping out by going through issues, labelling them, and figuring out some sort of priorities. I think if this affects connectivity and causes stability issue, it should be classified as a bug, if not, I would put it down as a wishlist item.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.1 Issue related to Tinc 1.1 needs_investigation Unexpected behaviours with uncertain causes - needs more investigation
Projects
None yet
Development

No branches or pull requests

2 participants