On 19 Nov 2008 at 14:10, Andrew M. Kinnard wrote:
> The RFC covers actual tftp protocol but has nothing to do with whatever
> discovery routines and traffic the mvpmc may use to find the tftp
> server.
That seems to be the problem, googling, list archives and wiki entries gives
me conflicting info on the boot process of the mvp.
> If you're not seeing any traffic from the mvpmc in the DMZ to
> your tftpd server at all, but you can use another device on the DMZ with
> tftp client to pull files from your tftpd server, and you have the
> next-server option (hopefully with filename and root-path options) set
> correctly (backed up by tftp-server-name option), then the most likely
Yes, the MVP's have all been working on the same lan for year successfully,
the only change was moving them to another subnet.
> cause is that the mvpmc is ignoring next-server and tftp-server-name
I've seen comments about the MVP boot process explicitly ignoring the next-
server directive in the archives, I think by Tom or Martin, can't remember.
> options and using broadcast (or otherwise unrouted or blocked) traffic
> to discover the tftpd server. Are you seeing any traffic on udp 16869
> (emanating from the mvpmc)?
Nada, my understanding is that's something the H3 units do, not the D3A's.
Might have to do some more sniffing as I do remember ports 16867 and 16868
traffic when I was doing some sniffing about a week ago. In hindsight, not
quite sure how I pulled that off given my all switched networking
environment.
> If you can disconfirm that, I'd start looking at putting a dhcp server
> on the dmz subnet so you can eliminate all dhcp functions as possible
> causes.
Not going to happen. At least not yet, my next step is to re-enable the dhcp
server on the router for the DMZ subnet and see if I can get the MVP talking
cross subnet WITHOUT using DHCP relay. This would simplify things
substantially and allow a much better separation of subnets and traffic.
As noted in a previous posting, using the proxy-arp feature of the router
allows it to work. Fortinet tech support also suggested the following
If possible configure the MVP to use a TFTP IP address that is on the MVP
subnet, then create a Virtual IP (VIP) that forwards the new IP to the real
TFTP server IP. Apply the new VIP to a firewall policy. While this is
destination NAT, it will have the same effect as proxy ARP. You can assign
another local IP to the WLAN interface and create another VIP for that.
Just a note, like Proxy ARP, you cannot use the same IP on two interfaces
which is why you will have to use local IPs on each interface.
But this gets back to the confusion I have with the MVP boot process.
Jon, Martin and the other devs, is there a site with the canonical
explanation of the MVP boot process for the D3A series?
> That's why I keep one old 10bT hub around. That thing is slow as a dog
> but super handy for sniffing where switches have no admin ports.
Heh, that's exactly what I got rid of, a nice compact one, now I have a big
16port 10/100 unit, not so portable :-( but it was all that was available at
FreeGeek in a 10/100 version at 10 minutes to 6pm (closing time).
--
Harondel J. Sibble
Sibble Computer Consulting
Creating Solutions for the small and medium business computer user.
[EMAIL PROTECTED] (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice)
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/
