MVallevand wrote: > On 2/25/07, Tom Metro <[EMAIL PROTECTED]> wrote: >> I had been wondering what logic led it to use the DHCP server's IP as >> the default for the MythTV server setting, rather than using the TFTP >> server's IP, which would be more logical, and in my case is the same as >> the MythTV server. > > I choose to use the DHCP address because if the TFTP address was > valid, a dongle.bin.mvpmc.config file would have loaded mvpmc so the > code you are talking about wouldn't even execute.
I'm guessing I'll need to consult the source code in order to be able to ask the right questions here, but before doing that I'll give it another go... I'm not following the logic in your statement above. My expectation for the boot sequence is something like: mvp: DHCPDISCOVER -> broadcast DHCP server: DHCPOFFER (IP) -> mvp (My logs show a DHCPREQUEST and DHCPACK handshake as well, but the gist is that the MVP gets an IP and optionally a host name assigned.) mvp: mvpboot request packet -> broadcast mvpboot server: reply packet w/TFTP IP -> mvp mvp: load dongle -> TFTP [EMAIL PROTECTED] 16869 TFTP [EMAIL PROTECTED] 16869: send dongle -> mvp mvp: load config -> TFTP server TFTP server: send config -> mvp My logs (of the Perl mvpboot daemon) show: got mvpboot request packet from 192.168.0.242:2048 (seq=1 id1=babe id2=fafe hwaddr=000dfe0c0128 client_addr=3232235762 client_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0) client hwaddr: 000dfe0c0128 ip: 192.168.0.242 port: 16882 sending mvpboot reply packet to 192.168.0.242:16882 (seq=1 id1=fafe id2=babe hwaddr=0004614bd133 client_addr=3232235762 client_port=2048 guiserv_addr=3232235723 guiserv_port=5906 conserv_addr=3232235723 conserv_port=6337 serv_addr=3232235723 serv_port=16886) The "serv_addr" that this log entry implies is included in the reply packet, 3232235723, when converted to dotted-quad format, corresponds to 192.168.0.203, which is the address of the server running mvpboot and the tftp server. So going back to the quote above: > I choose to use the DHCP address because if the TFTP address was > valid... What TFTP address? The one supplied by the DHCP server or the one supplied by the mvpboot server? I see an error in my original question. When I said "rather than using the TFTP server's IP," I should have said "rather than using the IP specified by the mvpboot server." Although I'm less than clear on what purpose the mvpboot server serves. I was under the impression that TFTP servers are designed to respond to broadcast UDP packets. So the "discovery" functionality should be built-in to the protocol - no? All I can guess is that Hauppauge decided to reinvent the wheel and crated a functionally equivalent discovery protocol, and thus the need for the mvpboot server glue. But maybe my understanding of TFTP is incorrect. I could see the mvpboot server being essential, if making the boot sequence work required having the DHCP server tell the MVP the IP of the TFTP server, because that is a requirement that can't easily be met by a typical user of a consumer product. Either their DHCP server (as embedded in some broadband router) would be incapable of supplying that information (no place in the GUI to configure it) or it would be too complicated for the user to configure it. Per the HOWTOs on the wiki, it supposedly isn't necessary to specify a TFTP server in the DHCP configuration, and it doesn't qualify that by saying the DHCP daemon needs to be running on the same machine as the TFTP daemon and MythTV back-end. In practice, the wiki is correct, and the MVP does boot without having a TFTP server in the DHCP configuration. Just that the MythTV IP ends up being wrong. > ...a dongle.bin.mvpmc.config file would have loaded mvpmc so the > code you are talking about wouldn't even execute. Assuming there is a config file and that there is a second TFTP server listening on the standard port to respond to the request for the config file. (Loading the config file isn't currently working in my setup.) But isn't the config file irrelevant at the moment. The point is that if the TFTP address supplied by the DHCP server was valid, then the boot sequence would continue by loading the dongle from the TFTP server. So what if the TFTP server isn't valid, or as in the case of my original setup, the DHCP server doesn't supply an address for a BOOTP server? > It has also tried to get the config file from a flash based IP so I am > running out choices for IPs to look for. As in my original email, if the purpose of the mvpboot server is to tell the MVP where to boot from, isn't it logical to use that address as the default for the MythTV server setting also, unless overridden by a config file? (Aside from other reasons, it seems logical that someone would group together MVP related stuff, like the mvpboot server and the TFTP server, on the machine running MythTV back-end, and not necessarily on the machine running their DHCP server.) >> Could you elaborate? You seem to be implying that mvpmc first tries to >> load the config file from the IP of the DHCP server, and then if that >> fails, tries the IP address of the TFTP server. > > The first time a tftp is tried it is based on the next-server setting > of the DHCP. Thanks for the pointer. Setting this does indeed fix the default IP used for the MythTV server. (BTW, "next-server" is a config directive specific to the ISC (isc.org) DHCP implementation. It seems that "siaddr" is the official field name, per the RFC. My DHCP server, dnsmasq, uses a "dhcp-boot=" directive.) And what if no "next-server" is supplied? In my observation, without a "next-server" the MVP still successfully boots, so it apparently finds the mvpboot server via a broadcast packet. >> > ...and a lot of users would be upset if it was changed. >> >> Are you sure? It sounded like a common setup these days was to use an >> existing "simple" DHCP server, such as what many users have built-in to > > Feel free to find out. No one has responded for or against this on the list. Regardless, I'm not convinced the change would be noticeable, or more accurately, that it would impact anyone in a negative way. The rule change I'm proposing is that the default for the MythTV server IP gets set to the IP address specified by the mvpboot server. The boot sequence itself would remain unchanged. Any user who currently has their mvpboot server at a different IP than their MythTV server is either already manually correcting that IP in the UI after every cold boot, or they've set it explicitly in the config, unless they have a really strange setup where MythTV and DHCP run on server A, and mvpboot and TFTP run on server B. >> What's the logic behind using the IP of the DHCP server at all? Isn't >> there an established protocol for locating the TFTP server? And once >> you've gone through the trouble of determining it, why wouldn't you use >> it for all transactions with the TFTP server? > > Why, simply to enable every single mvpmc option so they can be seen on > the main menu and modifed through the setup menu option or web config. I don't follow your response. What does enabling options in the UI have to do with the choice of default IP addresses for various media services? More details on the boot process...I noticed that there are actually two DHCP handshakes, with a few seconds pause between them: DHCPDISCOVER(eth0) 00:0d:fe:0c:01:28 DHCPOFFER(eth0) 192.168.0.242 00:0d:fe:0c:01:28 DHCPREQUEST(eth0) 192.168.0.242 00:0d:fe:0c:01:28 DHCPACK(eth0) 192.168.0.242 00:0d:fe:0c:01:28 DHCPDISCOVER(eth0) 00:0d:fe:0c:01:28 DHCPOFFER(eth0) 192.168.0.242 00:0d:fe:0c:01:28 DHCPREQUEST(eth0) 192.168.0.242 00:0d:fe:0c:01:28 DHCPACK(eth0) 192.168.0.242 00:0d:fe:0c:01:28 Any idea why? Similarly, the mvpboot server logs two seemingly identical handshakes, again with a couple of seconds pause between them: got mvpboot request packet from 192.168.0.242:2048 (seq=1 id1=babe id2=fafe hwaddr=000dfe0c0128 client_addr=3232235762 client_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0) client hwaddr: 000dfe0c0128 ip: 192.168.0.242 port: 16882 sending mvpboot reply packet to 192.168.0.242:16882 (seq=1 id1=fafe id2=babe hwaddr=0004614bd133 client_addr=3232235762 client_port=2048 guiserv_addr=3232235723 guiserv_port=5906 conserv_addr=3232235723 conserv_port=6337 serv_addr=3232235723 serv_port=16886) got mvpboot request packet from 192.168.0.242:2048 (seq=1 id1=babe id2=fafe hwaddr=000dfe0c0128 client_addr=3232235762 client_port=16882 guiserv_addr=0 guiserv_port=0 conserv_addr=0 conserv_port=0 serv_addr=0 serv_port=0) client hwaddr: 000dfe0c0128 ip: 192.168.0.242 port: 16882 sending mvpboot reply packet to 192.168.0.242:16882 (seq=1 id1=fafe id2=babe hwaddr=0004614bd133 client_addr=3232235762 client_port=2048 guiserv_addr=3232235723 guiserv_port=5906 conserv_addr=3232235723 conserv_port=6337 serv_addr=3232235723 serv_port=16886) If the responses to this posting clarify how the boot sequence works, I'll compile the details and post it to the wiki. -Tom ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
