I'm trying hard to get my Mediamvp H3 to work. But it won't tftp.
I have followed the instuction in the wiki for H3 boot.
A dhcp servers is running and the mvp gets a IP-address.
tftp is configured in /etc/services/ to Port 69 and 16869 udp.
mvprealy is running. (mvprelay 16881 5906 6337 192.168.1.3)
I have logged the network traffic with wireshark an I have seen an nbns reqeust from the mvp on port 137.
Which is answered by my box with 'Port unreachable'. I could not see any tftp requests.
Has anyone an idea what's wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
snow_freak writes:
> ...the mvp gets a IP-address.
Good. How have you determined that?
> tftp is configured in /etc/services/ to Port 69 and 16869 udp
In /etc/services/? I'm not familiar with using the /etc/services/ directory, but I'm not sure putting multiple entries in the /etc/services file will cause inetd to listen on multiple ports for the specified service. The typical setup requires adding two entries in inetd.conf for tftpd. See the wiki for examples.
> I have logged the network traffic with wireshark
> an I have seen an nbns reqeust from the mvp on port 137.
> Which is answered by my box with 'Port unreachable'.
The NETBIOS Name Service requests might be happening when the mvpmc startup script attempts to mount a file share as a fall-back means of loading the dongle.bin.config, though that would imply that the mvpmc dongle has loaded, and it sounds like it hasn't. Perhaps the Hauppauge firmware is triggering the request. But in any case, it shouldn't be relevant, and the response is expected unless you are running samba on the target box.
What you want to look for with wireshark (or more simply in the mvpboot logs) are broadcast UDP packets aimed at the relay service on port 16881.
What do you see on the MVP screen while all this is happening? Do you ever see the mvpmc logo?
-Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
snow_freak writes:
> Like you suggested i tried two entries in /etc/inetd.conf...
> No success.
The log you quoted seemed to indicate that DHCP and the relay server portions are working.
Are you sure inetd is running? On some systems it isn't even installed by default, yet you may still have an inetd.conf, which can be misleading.
I'd recommend manually making a tftp connection to each of the ports and see what happens. You can use any other Linux or Windows machine to do that, or if necessary, connect from the same machine running the TFTP server.
-Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't noticed this in your earlier message, but...
> Like you suggested i tried two entries in /etc/inetd.conf:
> tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd --port 16869
> --trace -v 7 /tftpboot
The --port switch to aftpd is meaningless when it is being launched by inetd. The inetd process is the one responsible for making the network connection in this case. The --port option is used when atftpd is ran as a daemon without inetd.
As I mentioned in my other reply, the 'tftp' symbol at the start of the line is just a reference into the /etc/services file and can be replaced with a literal port number when you want to run something on a non-standard port.
-Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I'd recommend manually making a tftp connection to each of the ports and see what happens. You can .... connect from the same machine running the TFTP server.
What I have to do in order to test this?
/Jo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Windows, the supplied TFTP client uses the following command line syntax:
TFTP [-i] host [GET | PUT] source [destination]
-i Specifies binary image transfer mode (also called
octet). In binary image mode the file is moved
literally, byte by byte. Use this mode when
transferring binary files.
host Specifies the local or remote host.
GET Transfers the file destination on the remote host to
the file source on the local host.
PUT Transfers the file source on the local host to
the file destination on the remote host.
source Specifies the file to transfer.
destination Specifies where to transfer the file.
Unfortunately it doesn't seem to support non-standard ports. But you can still use it to try out the standard port:
% tftp -i 192.168.0.200 GET dongle.bin.config
Transfer successful: 962 bytes in 1 second, 962 bytes/s
Replace 192.168.0.200 with the IP or hostname of your machine running tftpd. I chose to use 'dongle.bin.config' as the test file because it is small and I know it exists on my server. Feel free to use 'dongle.bin' or some other file for testing. Another worthy test is prefixing the filename with a path, though until you get tftpd working well enough to log requests, you won't know what path the MVP is requesting.
And of course while running any of these tests you should be doing a tail -f on the appropriate log file for tftpd, or examining it after each attempt.
It's also worth trying to retrieve a file you know doesn't exist, to see if that gets logged. Some TFTP servers are poor at logging errors and the MVP may be requesting a file that doesn't exist. Though TFTP servers aren't typically all that great at logging, you should get at least a few clues. I found the BSD tftpd to be a little less buggy and better at logging than atftpd.
On a Linux system, you'll need to install a tftp client (it may not be installed with tftpd), and then run:
% tftp
tftp> binary
tftp> connect 192.168.0.200
tftp> get dongle.bin.config
Received 962 bytes in 0.0 seconds
tftp> quit
And then to test the other port:
% tftp
tftp> binary
tftp> connect 192.168.0.200 16869
tftp> get dongle.bin.config
Received 962 bytes in 0.0 seconds
tftp> quit
To gain the highest confidence that the alternate port is working, comment out the entry in inetd.conf for the standard TFTP port, and restart inet.d, then retry the last test above.
If you run into problems, there is a 'verbose' and 'trace' command to try.
The TFTP client supplied with the BusyBox shell used by mvpmc has yet another syntax, but it is irrelevant until you can succeed in getting the dongle loaded. But knowing how to use it can sometimes help in troubleshooting problems with loading the startup script (dongle.bin.config) or theme file.
-Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now the ftfp is running, at least on my local machine.
I tested with:
$ atftp
tftp> trace
Trace mode on.
tftp> connect 127.0.0.1 16869
tftp> get dongle.bin.ver
Overwite local file [y/n]? y
sent RRQ <file: dongle.bin.ver, mode: octet <>>
received DATA <block: 1, size: 40>
sent ACK <block: 1>
tftp> connect 127.0.0.1 69
tftp> get dongle.bin.ver
Overwite local file [y/n]? y
sent RRQ <file: dongle.bin.ver, mode: octet <>>
received DATA <block: 1, size: 40>
sent ACK <block: 1>
tftp> quit
To get both ports working, i had to enter new entries for tftp with new services names in /etc/services and inetd.conf.
/etc/services:
tftp 69/udp
tftp1 16869/udp
^
/etc/inetd.conf:
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd --verbose=7 /tftpboot
tftp1 dgram udp wait nobody /usr/sbin/tcpd in.tftpd --port 16869 --verbose=7 /tftpboot
^
But I still have no tftp traffic with my media mvp. Here is the the wireshark log:
No. Time Source Destination Protocol Info
1 0.000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x574d277a
Frame 1 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol
No. Time Source Destination Protocol Info
2 0.001385 192.168.1.2 192.168.1.3 DHCP DHCP Offer - Transaction ID 0x574d277a
Frame 2 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
No. Time Source Destination Protocol Info
3 0.000527 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x574d277a
Frame 3 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol
No. Time Source Destination Protocol Info
4 0.000832 192.168.1.2 192.168.1.3 DHCP DHCP ACK - Transaction ID 0x574d277a
Frame 4 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
No. Time Source Destination Protocol Info
5 0.050672 192.168.1.3 255.255.255.255 WCCP Unknown WCCP message (1)[Malformed Packet]
Frame 5 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 2048 (2048), Dst Port: 16881 (16881)
Web Cache Coordination Protocol
[Malformed Packet: WCCP]
No. Time Source Destination Protocol Info
6 0.056461 RealtekS_c2:72:da Broadcast ARP Who has 192.168.1.3? Tell 192.168.1.2
No. Time Source Destination Protocol Info
13 7.512556 192.168.1.3 192.168.1.2 NBNS Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
Frame 13 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: RealtekS_c2:72:da (00:e0:4c:c2:72:da)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: 2048 (2048), Dst Port: netbios-ns (137)
NetBIOS Name Service
No. Time Source Destination Protocol Info
14 7.512605 192.168.1.2 192.168.1.3 ICMP Destination unreachable (Port unreachable)
Frame 14 (120 bytes on wire, 120 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
Internet Control Message Protocol
No. Time Source Destination Protocol Info
15 9.015395 192.168.1.3 255.255.255.255 UDP Source port: nfs Destination port: 16891
Frame 15 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: nfs (2049), Dst Port: 16891 (16891)
Data (44 bytes)
0000 00 00 00 02 ab eb af ef 00 0d fe 0b b0 1a 00 00 ................
0010 c0 a8 01 03 41 fc 00 00 00 00 00 fa 00 00 00 1b ....A...........
0020 00 ff ff ff 00 02 61 c0 00 00 4f 1a ......a...O.
No. Time Source Destination Protocol Info
16 12.511867 Hauppaug_0b:b0:1a RealtekS_c2:72:da ARP Who has 192.168.1.2? Tell 192.168.1.3
On 10/8/07, Tom Metro <tmetro+mvpmc-users@gmail.com> wrote:
> > 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.
No, it's just a bad interpretatin of the type type of raw TCP traffic wireshark is seeing.
Snow_freak, I've found that a linux livecd like knoppix can be really good for testing tftp if you've got a Windows machine on your network.
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It'd be really nice to move this discussion over to the mvpmc-user list. There are more people there, I can reply faster there, and the answers will be archived where other people can find them easier.
I'm trying hard to get my Mediamvp H3 to work. But it won't tftp.
I have followed the instuction in the wiki for H3 boot.
A dhcp servers is running and the mvp gets a IP-address.
tftp is configured in /etc/services/ to Port 69 and 16869 udp.
mvprealy is running. (mvprelay 16881 5906 6337 192.168.1.3)
I have logged the network traffic with wireshark an I have seen an nbns reqeust from the mvp on port 137.
Which is answered by my box with 'Port unreachable'. I could not see any tftp requests.
Has anyone an idea what's wrong?
Please post follow-up questions to the mvpmc-users mailing list, where you will reach a wider audience. If you don't like using email lists, you can post via a web interface here:
http://www.nabble.com/MediaMVP-Media-Center---Users-f24861.html
snow_freak writes:
> ...the mvp gets a IP-address.
Good. How have you determined that?
> tftp is configured in /etc/services/ to Port 69 and 16869 udp
In /etc/services/? I'm not familiar with using the /etc/services/ directory, but I'm not sure putting multiple entries in the /etc/services file will cause inetd to listen on multiple ports for the specified service. The typical setup requires adding two entries in inetd.conf for tftpd. See the wiki for examples.
Are you launching tftpd from inetd?
> mvprealy is running
OK. You might want to try:
http://mvpmc.wikispaces.com/mvpboot
which provides better logging.
> I have logged the network traffic with wireshark
> an I have seen an nbns reqeust from the mvp on port 137.
> Which is answered by my box with 'Port unreachable'.
The NETBIOS Name Service requests might be happening when the mvpmc startup script attempts to mount a file share as a fall-back means of loading the dongle.bin.config, though that would imply that the mvpmc dongle has loaded, and it sounds like it hasn't. Perhaps the Hauppauge firmware is triggering the request. But in any case, it shouldn't be relevant, and the response is expected unless you are running samba on the target box.
What you want to look for with wireshark (or more simply in the mvpboot logs) are broadcast UDP packets aimed at the relay service on port 16881.
What do you see on the MVP screen while all this is happening? Do you ever see the mvpmc logo?
-Tom
Hello Tom,
thanks for your reply.
My entry in /etc/inetd.conf is:
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd --trace -v 7 /tftpboot
my entries in /etc/services are:
tftp 69/udp
tftp 16869/udp
Like you suggested i tried two entries in /etc/inetd.conf:
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd --port 69 --trace -v 7 /tftpboot
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd --port 16869 --trace -v 7 /tftpboot
No success.
mvpboot i have tried too. Here are the logs from /var/log/syslog:
Oct 5 20:09:57 snow dhcpd: uid lease 192.168.1.101 for client 00:0d:fe:0b:b0:1a is duplicate on 192.168.1/24
Oct 5 20:09:57 snow dhcpd: DHCPDISCOVER from 00:0d:fe:0b:b0:1a via eth1
Oct 5 20:09:57 snow dhcpd: DHCPOFFER on 192.168.1.3 to 00:0d:fe:0b:b0:1a via eth1
Oct 5 20:09:57 snow dhcpd: uid lease 192.168.1.101 for client 00:0d:fe:0b:b0:1a is duplicate on 192.168.1/24
Oct 5 20:09:57 snow dhcpd: DHCPREQUEST for 192.168.1.3 (192.168.1.2) from 00:0d:fe:0b:b0:1a via eth1
Oct 5 20:09:57 snow dhcpd: DHCPACK on 192.168.1.3 to 00:0d:fe:0b:b0:1a via eth1
Oct 5 20:09:57 snow mvpboot[4355]: got mvpboot request packet from 192.168.1.3:2048 (seq=1 id1=babe id2=fafe hwaddr=000dfe0bb01a client_addr=3232235779 clie
nt_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0)
Oct 5 20:09:57 snow mvpboot[4355]: client hwaddr: 000dfe0bb01a ip: 192.168.1.3 port: 16882
Oct 5 20:09:57 snow mvpboot[4355]: sending mvpboot reply packet to 192.168.1.3:16882 (seq=1 id1=fafe id2=babe hwaddr=00e04cc272da client_addr=3232235779 cli
ent_port=2048 guiserv_addr=3232235778 guiserv_port=5906 conserv_addr=3232235778 conserv_port=6337 serv_addr=3232235778 serv_port=16886)
Oct 5 20:09:59 snow mvpboot[4355]: got mvpboot request packet from 192.168.1.3:2048 (seq=1 id1=babe id2=fafe hwaddr=000dfe0bb01a client_addr=3232235779 clie
nt_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0)
Oct 5 20:09:59 snow mvpboot[4355]: client hwaddr: 000dfe0bb01a ip: 192.168.1.3 port: 16882
Oct 5 20:09:59 snow mvpboot[4355]: sending mvpboot reply packet to 192.168.1.3:16882 (seq=1 id1=fafe id2=babe hwaddr=00e04cc272da client_addr=3232235779 cli
ent_port=2048 guiserv_addr=3232235778 guiserv_port=5906 conserv_addr=3232235778 conserv_port=6337 serv_addr=3232235778 serv_port=16886)
Oct 5 20:10:03 snow mvpboot[4355]: got mvpboot request packet from 192.168.1.3:2048 (seq=1 id1=babe id2=fafe hwaddr=000dfe0bb01a client_addr=3232235779 clie
nt_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0)
Oct 5 20:10:03 snow mvpboot[4355]: client hwaddr: 000dfe0bb01a ip: 192.168.1.3 port: 16882
Oct 5 20:10:03 snow mvpboot[4355]: sending mvpboot reply packet to 192.168.1.3:16882 (seq=1 id1=fafe id2=babe hwaddr=00e04cc272da client_addr=3232235779 cli
ent_port=2048 guiserv_addr=3232235778 guiserv_port=5906 conserv_addr=3232235778 conserv_port=6337 serv_addr=3232235778 serv_port=16886)
Oct 5 20:10:35 snow mvpboot[4355]: got mvpboot request packet from 192.168.1.3:2049 (seq=1 id1=babe id2=fafe hwaddr=000dfe0bb01a client_addr=3232235779 clie
nt_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0)
Oct 5 20:10:35 snow mvpboot[4355]: client hwaddr: 000dfe0bb01a ip: 192.168.1.3 port: 16882
Oct 5 20:10:35 snow mvpboot[4355]: sending mvpboot reply packet to 192.168.1.3:16882 (seq=1 id1=fafe id2=babe hwaddr=00e04cc272da client_addr=3232235779 cli
ent_port=2048 guiserv_addr=3232235778 guiserv_port=5906 conserv_addr=3232235778 conserv_port=6337 serv_addr=3232235778 serv_port=16886)
Oct 5 20:10:35 snow mvpboot[4355]: got mvpboot request packet from 192.168.1.3:2049 (seq=1 id1=babe id2=fafe hwaddr=000dfe0bb01a client_addr=3232235779 clie
nt_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0)
Oct 5 20:10:35 snow mvpboot[4355]: client hwaddr: 000dfe0bb01a ip: 192.168.1.3 port: 16882
Oct 5 20:10:35 snow mvpboot[4355]: sending mvpboot reply packet to 192.168.1.3:16882 (seq=1 id1=fafe id2=babe hwaddr=00e04cc272da client_addr=3232235779 cli
ent_port=2048 guiserv_addr=3232235778 guiserv_port=5906 conserv_addr=3232235778 conserv_port=6337 serv_addr=3232235778 serv_port=16886)
While all this is happening on the screen is 'Contacting Servers'. I have never seen th mvpmc logo.
/jo
Please post follow-up questions to the mvpmc-users mailing list, where you will reach a wider audience. If you don't like using email lists, you can post via a web interface here:
http://www.nabble.com/MediaMVP-Media-Center---Users-f24861.html
snow_freak writes:
> Like you suggested i tried two entries in /etc/inetd.conf...
> No success.
The log you quoted seemed to indicate that DHCP and the relay server portions are working.
Are you sure inetd is running? On some systems it isn't even installed by default, yet you may still have an inetd.conf, which can be misleading.
I'd recommend manually making a tftp connection to each of the ports and see what happens. You can use any other Linux or Windows machine to do that, or if necessary, connect from the same machine running the TFTP server.
-Tom
I didn't noticed this in your earlier message, but...
> Like you suggested i tried two entries in /etc/inetd.conf:
> tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd --port 16869
> --trace -v 7 /tftpboot
The --port switch to aftpd is meaningless when it is being launched by inetd. The inetd process is the one responsible for making the network connection in this case. The --port option is used when atftpd is ran as a daemon without inetd.
As I mentioned in my other reply, the 'tftp' symbol at the start of the line is just a reference into the /etc/services file and can be replaced with a literal port number when you want to run something on a non-standard port.
-Tom
Hello,
inetd is definitly running.
> I'd recommend manually making a tftp connection to each of the ports and see what happens. You can .... connect from the same machine running the TFTP server.
What I have to do in order to test this?
/Jo
> What I have to do in order to test this?
On Windows, the supplied TFTP client uses the following command line syntax:
TFTP [-i] host [GET | PUT] source [destination]
-i Specifies binary image transfer mode (also called
octet). In binary image mode the file is moved
literally, byte by byte. Use this mode when
transferring binary files.
host Specifies the local or remote host.
GET Transfers the file destination on the remote host to
the file source on the local host.
PUT Transfers the file source on the local host to
the file destination on the remote host.
source Specifies the file to transfer.
destination Specifies where to transfer the file.
Unfortunately it doesn't seem to support non-standard ports. But you can still use it to try out the standard port:
% tftp -i 192.168.0.200 GET dongle.bin.config
Transfer successful: 962 bytes in 1 second, 962 bytes/s
Replace 192.168.0.200 with the IP or hostname of your machine running tftpd. I chose to use 'dongle.bin.config' as the test file because it is small and I know it exists on my server. Feel free to use 'dongle.bin' or some other file for testing. Another worthy test is prefixing the filename with a path, though until you get tftpd working well enough to log requests, you won't know what path the MVP is requesting.
And of course while running any of these tests you should be doing a tail -f on the appropriate log file for tftpd, or examining it after each attempt.
It's also worth trying to retrieve a file you know doesn't exist, to see if that gets logged. Some TFTP servers are poor at logging errors and the MVP may be requesting a file that doesn't exist. Though TFTP servers aren't typically all that great at logging, you should get at least a few clues. I found the BSD tftpd to be a little less buggy and better at logging than atftpd.
On a Linux system, you'll need to install a tftp client (it may not be installed with tftpd), and then run:
% tftp
tftp> binary
tftp> connect 192.168.0.200
tftp> get dongle.bin.config
Received 962 bytes in 0.0 seconds
tftp> quit
And then to test the other port:
% tftp
tftp> binary
tftp> connect 192.168.0.200 16869
tftp> get dongle.bin.config
Received 962 bytes in 0.0 seconds
tftp> quit
To gain the highest confidence that the alternate port is working, comment out the entry in inetd.conf for the standard TFTP port, and restart inet.d, then retry the last test above.
If you run into problems, there is a 'verbose' and 'trace' command to try.
The TFTP client supplied with the BusyBox shell used by mvpmc has yet another syntax, but it is irrelevant until you can succeed in getting the dongle loaded. But knowing how to use it can sometimes help in troubleshooting problems with loading the startup script (dongle.bin.config) or theme file.
-Tom
Hello Tom,
thanks for your good explanation.
Now the ftfp is running, at least on my local machine.
I tested with:
$ atftp
tftp> trace
Trace mode on.
tftp> connect 127.0.0.1 16869
tftp> get dongle.bin.ver
Overwite local file [y/n]? y
sent RRQ <file: dongle.bin.ver, mode: octet <>>
received DATA <block: 1, size: 40>
sent ACK <block: 1>
tftp> connect 127.0.0.1 69
tftp> get dongle.bin.ver
Overwite local file [y/n]? y
sent RRQ <file: dongle.bin.ver, mode: octet <>>
received DATA <block: 1, size: 40>
sent ACK <block: 1>
tftp> quit
To get both ports working, i had to enter new entries for tftp with new services names in /etc/services and inetd.conf.
/etc/services:
tftp 69/udp
tftp1 16869/udp
^
/etc/inetd.conf:
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd --verbose=7 /tftpboot
tftp1 dgram udp wait nobody /usr/sbin/tcpd in.tftpd --port 16869 --verbose=7 /tftpboot
^
But I still have no tftp traffic with my media mvp. Here is the the wireshark log:
No. Time Source Destination Protocol Info
1 0.000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x574d277a
Frame 1 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol
No. Time Source Destination Protocol Info
2 0.001385 192.168.1.2 192.168.1.3 DHCP DHCP Offer - Transaction ID 0x574d277a
Frame 2 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
No. Time Source Destination Protocol Info
3 0.000527 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x574d277a
Frame 3 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol
No. Time Source Destination Protocol Info
4 0.000832 192.168.1.2 192.168.1.3 DHCP DHCP ACK - Transaction ID 0x574d277a
Frame 4 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
No. Time Source Destination Protocol Info
5 0.050672 192.168.1.3 255.255.255.255 WCCP Unknown WCCP message (1)[Malformed Packet]
Frame 5 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 2048 (2048), Dst Port: 16881 (16881)
Web Cache Coordination Protocol
[Malformed Packet: WCCP]
No. Time Source Destination Protocol Info
6 0.056461 RealtekS_c2:72:da Broadcast ARP Who has 192.168.1.3? Tell 192.168.1.2
Frame 6 (42 bytes on wire, 42 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)
No. Time Source Destination Protocol Info
7 0.056664 Hauppaug_0b:b0:1a RealtekS_c2:72:da ARP 192.168.1.3 is at 00:0d:fe:0b:b0:1a
Frame 7 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: RealtekS_c2:72:da (00:e0:4c:c2:72:da)
Address Resolution Protocol (reply)
No. Time Source Destination Protocol Info
8 0.056675 192.168.1.2 192.168.1.3 UDP Source port: 32773 Destination port: 16882 [UDP CHECKSUM INCORRECT]
Frame 8 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: 32773 (32773), Dst Port: 16882 (16882)
Data (52 bytes)
0000 00 00 00 01 fa fe ba be 00 e0 4c c2 72 da 00 00 ..........L.r...
0010 c0 a8 01 03 08 00 00 00 c0 a8 01 02 17 12 00 00 ................
0020 c0 a8 01 02 18 c1 00 00 00 00 00 00 c0 a8 01 02 ................
0030 41 f6 00 00 A...
No. Time Source Destination Protocol Info
9 2.055734 192.168.1.3 255.255.255.255 WCCP Unknown WCCP message (1)[Malformed Packet]
Frame 9 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 2048 (2048), Dst Port: 16881 (16881)
Web Cache Coordination Protocol
[Malformed Packet: WCCP]
No. Time Source Destination Protocol Info
10 2.057219 192.168.1.2 192.168.1.3 UDP Source port: 32773 Destination port: 16882 [UDP CHECKSUM INCORRECT]
Frame 10 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: 32773 (32773), Dst Port: 16882 (16882)
Data (52 bytes)
0000 00 00 00 01 fa fe ba be 00 e0 4c c2 72 da 00 00 ..........L.r...
0010 c0 a8 01 03 08 00 00 00 c0 a8 01 02 17 12 00 00 ................
0020 c0 a8 01 02 18 c1 00 00 00 00 00 00 c0 a8 01 02 ................
0030 41 f6 00 00 A...
No. Time Source Destination Protocol Info
11 5.503267 192.168.1.3 255.255.255.255 WCCP Unknown WCCP message (1)[Malformed Packet]
Frame 11 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 2048 (2048), Dst Port: 16881 (16881)
Web Cache Coordination Protocol
[Malformed Packet: WCCP]
No. Time Source Destination Protocol Info
12 5.512525 192.168.1.2 192.168.1.3 UDP Source port: 32773 Destination port: 16882 [UDP CHECKSUM INCORRECT]
Frame 12 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: 32773 (32773), Dst Port: 16882 (16882)
Data (52 bytes)
0000 00 00 00 01 fa fe ba be 00 e0 4c c2 72 da 00 00 ..........L.r...
0010 c0 a8 01 03 08 00 00 00 c0 a8 01 02 17 12 00 00 ................
0020 c0 a8 01 02 18 c1 00 00 00 00 00 00 c0 a8 01 02 ................
0030 41 f6 00 00 A...
No. Time Source Destination Protocol Info
13 7.512556 192.168.1.3 192.168.1.2 NBNS Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
Frame 13 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: RealtekS_c2:72:da (00:e0:4c:c2:72:da)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: 2048 (2048), Dst Port: netbios-ns (137)
NetBIOS Name Service
No. Time Source Destination Protocol Info
14 7.512605 192.168.1.2 192.168.1.3 ICMP Destination unreachable (Port unreachable)
Frame 14 (120 bytes on wire, 120 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)
Internet Control Message Protocol
No. Time Source Destination Protocol Info
15 9.015395 192.168.1.3 255.255.255.255 UDP Source port: nfs Destination port: 16891
Frame 15 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: nfs (2049), Dst Port: 16891 (16891)
Data (44 bytes)
0000 00 00 00 02 ab eb af ef 00 0d fe 0b b0 1a 00 00 ................
0010 c0 a8 01 03 41 fc 00 00 00 00 00 fa 00 00 00 1b ....A...........
0020 00 ff ff ff 00 02 61 c0 00 00 4f 1a ......a...O.
No. Time Source Destination Protocol Info
16 12.511867 Hauppaug_0b:b0:1a RealtekS_c2:72:da ARP Who has 192.168.1.2? Tell 192.168.1.3
Frame 16 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a), Dst: RealtekS_c2:72:da (00:e0:4c:c2:72:da)
Address Resolution Protocol (request)
No. Time Source Destination Protocol Info
17 12.511890 RealtekS_c2:72:da Hauppaug_0b:b0:1a ARP 192.168.1.2 is at 00:e0:4c:c2:72:da
Frame 17 (42 bytes on wire, 42 bytes captured)
Ethernet II, Src: RealtekS_c2:72:da (00:e0:4c:c2:72:da), Dst: Hauppaug_0b:b0:1a (00:0d:fe:0b:b0:1a)
Address Resolution Protocol (reply)
/Jo
On 10/8/07, Tom Metro <tmetro+mvpmc-users@gmail.com> wrote:
> > 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.
No, it's just a bad interpretatin of the type type of raw TCP traffic wireshark is seeing.
Snow_freak, I've found that a linux livecd like knoppix can be really good for testing tftp if you've got a Windows machine on your network.
Martin
It'd be really nice to move this discussion over to the mvpmc-user list. There are more people there, I can reply faster there, and the answers will be archived where other people can find them easier.
I've replied to your message on the list:
http://www.nabble.com/Re%3A-H3-no-TFTP-tf4591296.html
-Tom