Menu

Couldn't get FILEINFO_ACK

2015-09-01
2015-09-04
  • Olaf Scheidt

    Olaf Scheidt - 2015-09-01

    Hi Dennis,

    first many thanks for your uftp software.
    The transfer to one or multiple hosts works with an IP address or with an broadcast IP address.
    I cannot use multicast when sender and receiver are on a different host. It fails with following info:

    Using private multicast address 230.5.5.207 Group ID: C691754A
    Initializing group
    Sending ANNOUNCE 1
    Received REGISTER from client 0xAC149264
    Sending REG_CONF 2.1
    Sending ANNOUNCE 2
    ...
    Sending ANNOUNCE 20
    ----- rt.jar -----
    File ID: 0001 Name: rt.jar
    sending as: rt.jar
    Bytes: 53818475 Blocks: 41399 Sections: 4
    Sending FILEINFO 1.1
    ..
    Sending FILEINFO 19.1
    Sending FILEINFO 20.1
    Couldn't get FILEINFO_ACK from 0xAC149264
    Announce timed out
    uftp: Finishing at Tue Sep 1 17:56:20 2015

    Regards,

    Olaf

     

    Last edit: Olaf Scheidt 2015-09-01
  • Dennis Bush

    Dennis Bush - 2015-09-01

    It looks like the receiver gets the ANNOUNCE which is sent over the public multicast address, but it's not getting the REG_CONF or FILEINFO which go over the private multicast address.

    Are the sender and receiver on the same networks segment, or are they separated by one or more routers? If there are routers in between, you might need to set up static routes for the range of multicast address that would be in use for the private addresses. It could also be that it's taking time for the ICMP join messages to propogate.

    If you use Wireshark or tcpdump on each machine and look at both IGMP and UDP packets, it should give you an idea of where the drops are happening.

     
  • Olaf Scheidt

    Olaf Scheidt - 2015-09-02

    Hi Dennis,

    thanks for your quick reply.
    I dont know my company network structure. I can reach both hosts from the sender directly via ssh.
    Both start with 172.20.0.0. With these IP address I can copy to both hosts.
    netstat -ng shows on all three hosts (snd,rcv1,rcv2)
    eth0 224.0.0.1

    Command executed from the senders host:
    [root@vm-170-147 data]# traceroute -n -I 172.20.146.22
    traceroute to 172.20.146.22 (172.20.146.22), 30 hops max, 40 byte packets
    1 172.20.146.22 1.068 ms 1.247 ms 1.162 ms
    [root@vm-170-147 data]# traceroute -n -I 172.20.146.100
    traceroute to 172.20.146.100 (172.20.146.100), 30 hops max, 40 byte packets
    1 172.20.146.100 0.874 ms 0.898 ms 0.665 ms

    I will see if I can determine the packages with Wireshark.

    Regards,

    Olaf

     
  • Olaf Scheidt

    Olaf Scheidt - 2015-09-02

    Hi Dennis,

    Wireshark shows an ICMP message with Destination unreachable (Port unreachable).
    I have set the uftpd -P 1044 and uftp to -P 1044. The Portscanner nmap from the sender detects the open port on the receiver. After sending the file via multicast the same message (s.a.) appears.
    I can connect via netcat listener on receiver and netcat sender on sender host via udp.

    Regards,

    Olaf

     

    Last edit: Olaf Scheidt 2015-09-02
  • Dennis Bush

    Dennis Bush - 2015-09-02

    If one host is 172.20.146.22 and the other is 172.20.146.100 they they're probably on the same LAN, and the traceroute seems to confirm this, so that simplifies things.

    You should be looking for IGMP, not ICMP. That was a typo on my part. When a host joins a multicast group, it sends out an IGMP message informing routers that they should route a particular multicast address. If you're on the same LAN, that shouldn't be an issue however.

    In the server Wireshark trace check that the REG_CONF and FILEINFO messages are going out with the correct address on the correct interface. In the client Wireshark trace, see if the REG_CONF and FILEINFO messages arrive, and also if the client sends an IGMP message for the private multicast address. Also run netstat -ng on the client after the ANNOUNCE arrives but before the session ends to see if it joined the group for the private multicast address.

     
  • Olaf Scheidt

    Olaf Scheidt - 2015-09-04

    Project has changed.
    I dont need any further support.

    Many thanks for your help and time.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.