I found that the uftp bound IP is 0.0.0.0, which does not meet the security requirements of our products.
I tried to modify the source code and listen to the local network card IP, such as 9.37.22.235.
Finally, I can't receive any messages. Do you know what happened?
Thanks, help or hints around the problem, would be much apreciated
Yang
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When binding to a local IP on Linux, that prevents multicast packets from being received. You can only receive multicast if you bind to either 0.0.0.0 or to a multicast address.
If you bind to a multicast address, you'll only be able to receive packets sent to that one address. That means the private multicast IP must be the same as the public multicast IP, and you can only listen to a single public multicast IP.
Regards,
Dennis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dennis,
Thank you for helping me solve the above problem. But I have encountered a new problem that is the use of uftp transfer file prompts 'Transfer aborted by xxx: Transfer timed out'.
The server logs are as follows:
* Sending ANNOUNCE 50
----- PMSIMCEXECUTORV200R003C10.tar -----
File ID: 0001 Name: PMSIMCEXECUTORV200R003C10.tar
sending as: PMSIMCEXECUTORV200R003C10.tar
Bytes: 95846400 Blocks: 11700 Sections: 1
Sending FILEINFO 1.1
Received FILEINFOACK from client 0x00000099
Sending file
Starting pass 1
Sending section 0
Transfer aborted by 0x00000099: Transfer timed out
Transfer status:
Host: 0x00000099 Status: Aborted
Total elapsed time: 0.000 seconds
Overall throughput: 0.00 KB/s
uftp: Finishing at Fri Aug 4 15:30:53 2017*
The client log is as follows:
* 2017/08/04 15:30:52.149958: [1C7769A8/00:0]: grtt: 0.001
2017/08/04 15:30:52.149969: [1C7769A8/00:0]: found min timeout time: 1501831853:149968
2017/08/04 15:30:52.149978: read timeout: 0.999999
2017/08/04 15:30:52.153049: tos / traffic class byte = 00
2017/08/04 15:30:52.153075: [1C7769A8/00:0]: grtt: 0.001
2017/08/04 15:30:52.153086: [1C7769A8/00:0]: found min timeout time: 1501831853:153086
2017/08/04 15:30:52.153096: read timeout: 1.000000
2017/08/04 15:30:52.156248: tos / traffic class byte = 00
2017/08/04 15:30:52.156287: [1C7769A8/00:0]: grtt: 0.001
2017/08/04 15:30:52.156312: [1C7769A8/00:0001]: Name of file to receive: PMSIMCEXECUTORV200R003C10.tar
2017/08/04 15:30:52.156325: [1C7769A8/00:0001]: Bytes: 95846400, Blocks: 11700, Sections: 1
2017/08/04 15:30:52.156335: [1C7769A8/00:0001]: small section size: 11700, big section size: 11700, # big sections: 0
2017/08/04 15:30:52.156603: Free space: 500080164864
2017/08/04 15:30:52.156676: [1C7769A8/00:0001]: FILEINFOACK sent
2017/08/04 15:30:52.156688: [1C7769A8/00:0001]: send time: 1501831852.156724
2017/08/04 15:30:52.156698: [1C7769A8/00:0001]: found min timeout time: 1501831853:156697
2017/08/04 15:30:52.156708: read timeout: 1.000000
2017/08/04 15:30:52.158036: tos / traffic class byte = 00
2017/08/04 15:30:52.158096: [1C7769A8/00:0001]: grtt: 0.001
2017/08/04 15:30:52.158111: [1C7769A8/00:0001]: Got packet 0
2017/08/04 15:30:52.158127: [1C7769A8/00:0001]: found min timeout time: 1501831853:158127
2017/08/04 15:30:52.158140: read timeout: 1.000000
2017/08/04 15:30:52.158407: tos / traffic class byte = 00
2017/08/04 15:30:52.158474: [1C7769A8/00:0001]: grtt: 0.001
2017/08/04 15:30:52.158496: [1C7769A8/00:0001]: Got packet 1
2017/08/04 15:30:52.158519: [1C7769A8/00:0001]: found min timeout time: 1501831853:158518
2017/08/04 15:30:52.158536: read timeout: 0.999999
2017/08/04 15:30:53.159357: [1C7769A8/00:0001]: Transfer timed out
2017/08/04 15:30:53.159506: [1C7769A8/00:0001]: Wrote blocks 0 - 1 to disk from cache
2017/08/04 15:30:53.163453: [1C7769A8/00:0001]: starting file close
2017/08/04 15:30:53.163488: [1C7769A8/00:0001]: done file close
2017/08/04 15:30:53.163511: [1C7769A8/00:0001]: Writing restart file*
Do you know what might be the reason?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The logs indicate there was an interruption in the flow of data. At the time the timeout occurred at the client, it had not received any packets from the server in more than 1 second, while packets were arriving much more frequently before, less than 1 ms in some cases.
Run wireshark or tcpdump on both sides to see where packets might be getting lost.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Dennis,
I found that the uftp bound IP is 0.0.0.0, which does not meet the security requirements of our products.
I tried to modify the source code and listen to the local network card IP, such as 9.37.22.235.
Finally, I can't receive any messages. Do you know what happened?
Thanks, help or hints around the problem, would be much apreciated
Yang
To add, my OS is suse11 Linux
Yang,
When binding to a local IP on Linux, that prevents multicast packets from being received. You can only receive multicast if you bind to either 0.0.0.0 or to a multicast address.
If you bind to a multicast address, you'll only be able to receive packets sent to that one address. That means the private multicast IP must be the same as the public multicast IP, and you can only listen to a single public multicast IP.
Regards,
Dennis
Dennis,
Thank you for helping me solve the above problem. But I have encountered a new problem that is the use of uftp transfer file prompts 'Transfer aborted by xxx: Transfer timed out'.
The server logs are as follows:
* Sending ANNOUNCE 50
----- PMSIMCEXECUTORV200R003C10.tar -----
File ID: 0001 Name: PMSIMCEXECUTORV200R003C10.tar
sending as: PMSIMCEXECUTORV200R003C10.tar
Bytes: 95846400 Blocks: 11700 Sections: 1
Sending FILEINFO 1.1
Received FILEINFOACK from client 0x00000099
Sending file
Starting pass 1
Sending section 0
Transfer aborted by 0x00000099: Transfer timed out
Transfer status:
Host: 0x00000099 Status: Aborted
Total elapsed time: 0.000 seconds
Overall throughput: 0.00 KB/s
uftp: Finishing at Fri Aug 4 15:30:53 2017*
The client log is as follows:
* 2017/08/04 15:30:52.149958: [1C7769A8/00:0]: grtt: 0.001
2017/08/04 15:30:52.149969: [1C7769A8/00:0]: found min timeout time: 1501831853:149968
2017/08/04 15:30:52.149978: read timeout: 0.999999
2017/08/04 15:30:52.153049: tos / traffic class byte = 00
2017/08/04 15:30:52.153075: [1C7769A8/00:0]: grtt: 0.001
2017/08/04 15:30:52.153086: [1C7769A8/00:0]: found min timeout time: 1501831853:153086
2017/08/04 15:30:52.153096: read timeout: 1.000000
2017/08/04 15:30:52.156248: tos / traffic class byte = 00
2017/08/04 15:30:52.156287: [1C7769A8/00:0]: grtt: 0.001
2017/08/04 15:30:52.156312: [1C7769A8/00:0001]: Name of file to receive: PMSIMCEXECUTORV200R003C10.tar
2017/08/04 15:30:52.156325: [1C7769A8/00:0001]: Bytes: 95846400, Blocks: 11700, Sections: 1
2017/08/04 15:30:52.156335: [1C7769A8/00:0001]: small section size: 11700, big section size: 11700, # big sections: 0
2017/08/04 15:30:52.156603: Free space: 500080164864
2017/08/04 15:30:52.156676: [1C7769A8/00:0001]: FILEINFOACK sent
2017/08/04 15:30:52.156688: [1C7769A8/00:0001]: send time: 1501831852.156724
2017/08/04 15:30:52.156698: [1C7769A8/00:0001]: found min timeout time: 1501831853:156697
2017/08/04 15:30:52.156708: read timeout: 1.000000
2017/08/04 15:30:52.158036: tos / traffic class byte = 00
2017/08/04 15:30:52.158096: [1C7769A8/00:0001]: grtt: 0.001
2017/08/04 15:30:52.158111: [1C7769A8/00:0001]: Got packet 0
2017/08/04 15:30:52.158127: [1C7769A8/00:0001]: found min timeout time: 1501831853:158127
2017/08/04 15:30:52.158140: read timeout: 1.000000
2017/08/04 15:30:52.158407: tos / traffic class byte = 00
2017/08/04 15:30:52.158474: [1C7769A8/00:0001]: grtt: 0.001
2017/08/04 15:30:52.158496: [1C7769A8/00:0001]: Got packet 1
2017/08/04 15:30:52.158519: [1C7769A8/00:0001]: found min timeout time: 1501831853:158518
2017/08/04 15:30:52.158536: read timeout: 0.999999
2017/08/04 15:30:53.159357: [1C7769A8/00:0001]: Transfer timed out
2017/08/04 15:30:53.159506: [1C7769A8/00:0001]: Wrote blocks 0 - 1 to disk from cache
2017/08/04 15:30:53.163453: [1C7769A8/00:0001]: starting file close
2017/08/04 15:30:53.163488: [1C7769A8/00:0001]: done file close
2017/08/04 15:30:53.163511: [1C7769A8/00:0001]: Writing restart file*
Do you know what might be the reason?
The logs indicate there was an interruption in the flow of data. At the time the timeout occurred at the client, it had not received any packets from the server in more than 1 second, while packets were arriving much more frequently before, less than 1 ms in some cases.
Run wireshark or tcpdump on both sides to see where packets might be getting lost.