Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

Adapter binding in 2.25!!! Thank you!! Now, here's some bugs...

by Guest on 2015/11/06 03:26:54 AM    
First of all, thank you, thank you, thank you for bring adapter binding to Tixati. It's great to have a VPN kill-switch built right into the program. Unfortunately, it's not without bugs.

The new setting lists all ipv4 and ipv6 adapters. Each adapter is segregated by a random hardware ID-looking number (is this actually randomly generated within tixati? I couldn't find this number looking through the list of driver properties for a given adapter in Device Manager), the local name of the adapter itself, and then a list of active client IPs currently assigned to that network adapter. We have a choice to choose either the random hardware ID number, the particular adapter listed by name, or the a current IP assigned to the adapter. I assume that the binding is then set. My problem is that it appears as if the Adapter Name selection, which I chose as I assumed it was a way of simplifying the MAC address of that network adapter, and the Client IP address are the same setting.

When I make a new connection on my VPN, I'm assigned a random Client IP within a certain network range. The Adapter Name selection in the settings seems to want to only connect to the previous Client IP which is no longer available. In theory, this should be a binding to the adapter's MAC address and client IPs shouldn't matter. However, Tixati fails to connect to the tracker, as it's still waiting to connect back to the previously working Client IP.

Essentially, I want Tixati to be bound to my VPN adapter's MAC address. Am I doing something wrong or is this a bug? Thankfully, even if it's a bug, it's still effective in its current state as a VPN disconnect kill-switch. The only unfortunate thing is the somewhat trivial amount of settings changes needed to recognize a new binding to the Adapter name. This process for me has been to stop the current torrents, get a new Client IP through my VPN software, change the settings binding to anything else, close settings, reopen settings immediately, choose the VPN Adapter Name binding again, and reactivate my torrents by double-clicking on them. Tixati need not be closed to work again with the proper binding.
by Guest on 2015/11/13 01:16:58 AM    
I tried this and it works perfectly for me, without the bugs you mention.

Steps to test in Windows 7:

1)  Click start menu
2)  Type the letters VPN in the Search programs and files thing at the bottom of the menu and press return.
3)  Added the IP address and infos of a standard PPTP VPN (there are many free ones around)
4)  Connect to the VPN
5)  Go into Tixati > Settings > Network > Connections and clicked the button next to "Local IPv4 address or interface" and selected the name of the adapter, "VPN Connection" (this was the default name)
6)  Close settings

Now, when the VPN is up and I start Tixati, I get in the main log:
[20:50:33]  listening on tcp:10.11.0.15:29331
[20:50:33]  listening on udp:10.11.0.15:29331

So far, so good.

If I disconnect the VPN, this is logged:
[20:54:21]  Stopped listening on tcp:10.11.0.15:29331
[20:54:21]  Stopped listening on udp:10.11.0.15:29331
[20:54:21]  listening on tcp:127.0.0.1:29331
[20:54:21]  listening on udp:127.0.0.1:29331

Perfect behavior, it binds to the safe local loopback when it can't find the interface.

Now, on to the part that you say does not work, yet works perfectly for me.  I re-connect the same VPN Connection, wait for 30 seconds at most and this is logged:
[21:00:09]  Stopped listening on tcp:127.0.0.1:29331
[21:00:09]  Stopped listening on udp:127.0.0.1:29331
[21:00:09]  listening on tcp:10.11.0.6:29331
[21:00:09]  listening on udp:10.11.0.6:29331

Excellent, we are back in business, and the downloads are working again.

And this works for the "VPN Connection" by name, or the accompanying GUID, eg. {81168AFE-2B39-41FA-A25A-490B23237586}  (BTW that's not a MAC addr, you can't use those for binding interfaces in Windows socket API).

Try it again, make sure you wait 30s after re-connecting, and if you still have a problem, post some specific steps to recreate it.  Because to me, it looks like this feature is working fine just fine.




This web site is powered by Super Simple Server