On 12/26/07, Tom Metro <[EMAIL PROTECTED]> wrote:
>
> Jameson wrote:
> > when trying to load the newest stable MediaMVP MC:
> >
> > Dec 25 03:11:43 server mvpboot[3514]: sending mvpboot reply packet to
> > 192.168.1.101:16882 <http://192.168.1.101:16882/> (seq=1 id1=fafe
> > id2=babe hwaddr=0015f245811b client_addr=3232235877 client_port=2048
> > guiserv_addr=3232235827 guiserv_port=5906 conserv_addr=3232235827
> > conserv_port=6337 serv_addr=3232235827 serv_port=16886)
>
> A normal boot in my experience has a pair of DHCPDISCOVER requests (and
> the corresponding replies) and a pair of mvpboot request packets, and
> replies. I'm not sure why, but it is consistent.
>
>
> > After that it just cycles through the mvpboot steps...
>
> So perhaps you are seeing the same, but counting the second set of
> requests as part of the redundant looping?
Well, I've definately watched it go through more than two sets of relay
requests. The real problem is just that I never see it even trying to hit
my tftp server.
Is it expected that the above log shows the MVP at 192.168.1.101, while
> your other logs show it at 192.168.1.56.
Yeah, 101 was the generic IP it was getting before I updated my DHCP
configuration.
> But, then nothing from TFTP.
> > ...
> > I have tftp running on both ports, and have successfully pulled
> > dongle.bin.ver from both ports from another box.
>
> You mentioned you can successfully boot mvpmc from a Windows server. Try
> that, and then telnet to the MVP and from the command line try testing
> tftp to your Linux server on both ports.
It was actually the Hauppauge dongle that I booted from Windows if I
remember. Since I got closer that way, I'll give it another run with the
mvpmc dongle from Windows. I'm starting to get concerned that something has
been done to make my MVP incompatible, but it's an H3, and I wouldn't
imagine they would pull it off the shelf to make a change, and then put it
back.
Are you sure you are using the correct high numbered port? (You didn't
> post anything showing it.) How about posting your xinetd config.
The howto I origianlly folowed had me using rc.local, and I haven't moved
these out of it yet:
/usr/sbin/in.tftpd -l -a :16869 -s /var/tftpboot -v
/usr/lobal/bin/mvpboot
Then my xinetd for tftp looks like:
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /var/tftpboot -v
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}
Which tftp server are you using?
Just the standard tftp-server in Fedora 8.
-Tom
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/
