Does TurboFloat server/client support ipv6 addressSolved

Our team has talked about this over email with you.

1. Use the latest version of TurboFloat library and the TurboFloat Server. (it appears like you're doing that.

2. Use a higher port number. Switches, routers, and firewalls don't like "low" port numbers. It sounds arbitrary (it is), but it actually makes a difference. Use something in the thousands.

3. If that still doesn't work (after doing both 1 & 2), then use TF / TFS over HTTPS to work around poorly configured routers / firewalls / switches. More information here: https://wyday.com/limelm/help/turbofloat-server/#config-https

Short answer: yes, TurboFloat fully supports IPv6. This is a configuration problem on your end.

Hi, Sam? Thanks for your reply. For current status, the issue is not related with hardware, for example router/switch as you mention. For 2) , although port 13 have work correctly in IPV4 case, that mean port 13 is OK to work. Anyway, I change it to port 1234 and it work correctly also. When I run ipv4 test example code, I use tcpdump to capture the packets, I can see TCP packet with destination port 1234 send out. Then I just replace one line of code as below to change ipv4 address to ipv6: hr = TF_SaveServer(tfHandle, _T("fe80::51f1:e86e:9e59:7add"), 1234, TF_SYSTEM); //hr = TF_SaveServer(tfHandle, _T("10.1.178.117"), 1234, TF_SYSTEM);

Then I rerun the example code, this time I also use tcpdump to capture the packets, it capture no any ipv6 packet, also not any packet with destination port=1234. Since tcpdump is run the same PC that the example code run, that mean the example code didn't generate any ipv6 packet at this time. So this issue is not only related to the example code itself.

In my case, both ipv4/ipv6 address are configurated for the ethernet port:[root@perf x64]# ifconfigeth0 Link encap:Ethernet HWaddr 00:0C:29:4C:50:12 inet addr:10.1.178.143 Bcast:10.1.178.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4c:5012/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:14811221 errors:0 dropped:0 overruns:0 frame:0 TX packets:5708143 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2250409712 (2.0 GiB) TX bytes:6800686209 (6.3 GiB)

What I want to know is, when both ipv4/ipv6 stack existed, can your library automaticlly know which stack it will used? If it can, why I change the ipv4 to ipv6 address, it don't send out any ipv6 packets and return failed with error 4.

For 3) Our customer want to use ipv6 address directly. Only under no other way can solve this issue, they will consider it.

Thanksdaniel

I have write another test program to verify ipv6 transportion. Using the same two pc, one is client side and another is server. They can exchange ipv6 packets through TCP connection. I can also capture ipv6 packets with tcpdump, either using port 13 or port 1234, ipv6 tcp session working correctly. So I think this is enough to prove that either ipv6 protocal stack or hardware or firewall is not the problem that cause this issue .

daniel

Hi, Wyatt: In the last topic, I have prove that there are not any configuration error in my ipv6 network, but TurboFloat just don't work under ipv6 case. Since you seem have close that topic so I am have to create a new one, sorry that. I wrote a simple test code to create a ipv6 client/and server on two pc using socket and I can successful exchange the TCP stream in ipv6 network, that is enough to prove that the ipv6 is working correctly. Now the issue is , I just using your example code, only change the ipv4 address to ipv6 address, no other changes and it just don't send out any ipv6 packets. I believed that they are must some initial code or other change need to do to let TurboFloat client to work in ipv6 case. If you are sure that it can work in ipv6 case, could you give me a example code that have been verify working here? And for Configuring TurboFloat Server for HTTPS communication, our customer don't want to start a web server just for license issue, they want us to sovled this issue ASAP and it have been delay for weeks. Could you give me the example code?

Thanks

daniel

In any case, TurboFloat client at least should send out a ipv6 packet to TurboFloat server to start the license verification, right? For now, the case is when I modified the ipv4 address to ipv6 address in our example code, it don't send out any packets. But if I change back to ipv4 address again, it will successful lease the license.

daniel

I capture the packets on client side, and that mean that the client application don't send out the packets and it has nothing to do with outside networking.

daniel

The other topic was still open (merging these new posts in the old topic). We marked it as solved because it's solved.

This is a problem with your network configuration. Not with TurboFloat. Fix your network.

>> "In any case, TurboFloat client at least should send out a ipv6 packet to TurboFloat server to start the license verification, right? "

No. It attempts to connect first. It doesn't just spray packets hoping they reach a destination. That's not how TCP connections work.

Do you see my notes carefully? I have already prove that the network configuration have no any problem. I write a simple socket test program, one client and one server, it can exchange the ipv6 packets without any problem. Do you really test the library by yourself before you can said it was OK. The test was so simple , it was the example code write by yourself, just replace a ipv4 adress to ipv6 address, pls test it firstly. I just don't understand why such a simple issue, sorry to say that, but customer have already push us for weeks, and I got not useful information from your FAE or forum.

daniel

We have tested it, we have confirmed there is no issue. If you want to work around your network issues we've already written the solution for you:

1. Use the latest version of TurboFloat library and the TurboFloat Server. (it appears like you're doing that.

2. Use a higher port number. Switches, routers, and firewalls don't like "low" port numbers. It sounds arbitrary (it is), but it actually makes a difference. Use something in the thousands.

3. If that still doesn't work (after doing both 1 & 2), then use TF / TFS over HTTPS to work around poorly configured routers / firewalls / switches. More information here: https://wyday.com/limelm/help/turbofloat-server/#config-https

#3 is the best option because it uses "well tread" path on most networks and switches (meaning it's harder for them to mess it up).

Hi: Could you post the example code here that you use to test ipv6? I have ask for that before but your FAE say they don't have time to test it. And now you said it have been test, it will be very help for us to get a test and working code for reference.

daniel

Without any example code and API documents but just said it was working, it don't help me to solve the issue. And I have said that our customer don't want to set up a another web server just to solve the license issue, and I have prove that the network don't have any problem. I am not here to ask for help to check customer's network setting, in fact, I test your example code in my lab, it was a simple network, I connect 2 pc with a switch, a very very simple network, not firewall, not any router as your think that may make ipv6 failed. I am here just to ask for a guide for how to make your float library working under ipv6 case. If you really test it, show me the test code that have been proved to work, is that impossible?

daniel

>> "If you really test it, show me the test code that have been proved to work, is that impossible?"

You don't need complicated code. It's a simple call to TF_SaveServer(). That's it.

Make sure the address is valid. And do all the other steps that I told you to do but you never did (ping the "server" using that address, use notification logging, use the latest version, fix the firewalls, etc., etc., etc.).

And, if all else fails, just use the HTTPS communication to bypass poor configuration.