In: https://sourceforge.net/forum/message.php?msg_id=4558358 snow_freak wrote: > Now the ftfp is running, at least on my local machine.
So does that mean you haven't tested it yet from a machine other than the one running tftpd? That's a pretty important step, as firewall rules or configuration errors causing services to bind to the loopback address (127.0.0.1) could be interfering with things. > tftp> connect 127.0.0.1 16869 At minimum you should try using your LAN IP address instead of the loopback address. > tftp> get dongle.bin.ver That's a good choice of a test file, as that's the first thing the MVP will try and retrieve. Absent from your message are the tftpd logs. Do you see log entries for the test transfers you preformed? And presumably no activity when you attempt a boot? How about log entries when you try and retrieve a file that doesn't exist? Once you've proven by showing tftpd logs that dongle.bin.ver is being retrieved, if it still isn't booting, we'll look at whether you created dongle.bin.ver correctly. > To get both ports working, i had to enter new entries for > tftp with new services names in /etc/services and inetd.conf. That really shouldn't have been necessary. You can use a literal port number in place of the symbolic service name in inetd.conf. Here are my entries for the BSD tftpd: tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd -s /var/lib/tftpboot 16869 dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd -s /var/lib/tftpboot But what you have should work too. > But I still have no tftp traffic with my media mvp. Here is the the > wireshark log... I'd put more credence in the absence of tftpd logs, providing you were successful in getting it to log both successful and failed retrieval attempts in your testing. The problem with wireshark and similar captures is that they are complex tools to use correctly and it is very easy to mistakenly filter out the very kinds of packets you want to capture. For example, are you sure you are capturing broadcast UDP packets? It looks like they're showing up in your log, so probably. Here too, a firewall could interfere with things. > 192.168.1.3 255.255.255.255 > WCCP Unknown WCCP message (1)[Malformed Packet] I don't know what WCCP protocol is (Web Cache Coordination Protocol, apparently), but this appears to be the broadcast packet the MVP sends to the relay service. It should be showing up as UDP. If the "malformed" designation is just wireshark failing to recognize it, then no big deal. But if this is your kernel making that determination, then maybe the packet is getting dropped before it gets to the relay service. Though didn't you post logs showing what appeared to be the relay service receiving and responding to packets? And the replies appear to be in your wireshark log, though they're tagged with "UDP CHECKSUM INCORRECT." It seems like there is something wrong with the handshake with the relay server, as the MVP sends its request multiple times and gets back a reply each time. Perhaps you are having networking problems and should try the MVP connected directly to the server via a cross-over cable. Here's the packet summary: First the DHCP stuff: [MVP] 0.0.0.0:68 (bootpc) -> [broadcast] 255.255.255.255:67 (bootps) DHCP Discover [server] 192.168.1.2:67 (bootps) -> [MVP] 192.168.1.3:68 (bootpc) DHCP Offer [MVP] 0.0.0.0:68 (bootpc) -> [broadcast] 255.255.255.255:67 (bootps) DHCP Request [server] 192.168.1.2:67 (bootps) -> [MVP] 192.168.1.3:68 (bootpc) DHCP ACK Here's the first request to the relay server: [MVP] 192.168.1.3:2048 -> [broadcast] 255.255.255.255:16881 Unknown WCCP message (1)[Malformed Packet] The server ARPs to get the MVP's hardware address for the reply: [server] RealtekS_c2:72:da -> Broadcast ARP Who has 192.168.1.3? Tell 192.168.1.2 [MVP] Hauppaug_0b:b0:1a -> [server] RealtekS_c2:72:da ARP 192.168.1.3 is at 00:0d:fe:0b:b0:1a And sends the reply: [server] 192.168.1.2:32773 -> [MVP] 192.168.1.3:16882 UDP [UDP CHECKSUM INCORRECT] The MVP repeats the request a second time: [MVP] 192.168.1.3:2048 -> [broadcast] 255.255.255.255:16881 Unknown WCCP message (1)[Malformed Packet] [server] 192.168.1.2:32773 -> [MVP] 192.168.1.3:16882 UDP [UDP CHECKSUM INCORRECT] And a third time: [MVP] 192.168.1.3:2048 -> [broadcast] 255.255.255.255:16881 Unknown WCCP message (1)[Malformed Packet] [server] 192.168.1.2:32773 -> [MVP] 192.168.1.3:16882 UDP [UDP CHECKSUM INCORRECT] When my H3 MVP boots using the mvpboot relay service, I normally see two request/reply exchanges. Three seems odd. And then here's this oddball netbios name service request you mentioned: [MVP] 192.168.1.3:2048 -> [server] 192.168.1.2:137 (netbios-ns) NBNS Name query NBSTAT [server] 192.168.1.2 -> [MVP] 192.168.1.3 ICMP Destination unreachable (Port unreachable) And now a 4th request to the relay service from the MVP. I'm pretty sure wireshark has incorrectly labeled this as NFS just because the source port happened to the the NFS port. [MVP] 192.168.1.3:2049 (nfs) -> [broadcast] 255.255.255.255:16891 UDP nfs But note the port number is 16891 instead of the usual 16881 that the relay service is on. Maybe this is something else? Are you sure you have an H3 MVP? Wired or wireless? These last entries imply that the MVP has figured out that 192.168.1.2 is your server and it needs to contact it: [MVP] Hauppaug_0b:b0:1a -> [server] RealtekS_c2:72:da ARP Who has 192.168.1.2? Tell 192.168.1.3 [server] RealtekS_c2:72:da -> [MVP] Hauppaug_0b:b0:1a ARP 192.168.1.2 is at 00:e0:4c:c2:72:da I'd expect these to be followed by the TFTP requests. What is the Linux distribution, version, and kernel version you are using? Have you set up anything custom with iptables? -Tom ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Mvpmc-users mailing list Mvpmc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
