PXE boot problem



  • Hi,
    First, I’m am not very good at english but I will try to do my best. Sorry about this.

    I have finished setting up the FOG server (0.32) on a Ubuntu 12.04 server.
    Here is my problem:
    I work in a University and i cannot access to the DHCP server, so I installed dnsmasq.
    I have a test client connected to the same unmanaged Cisco switch the server is connected to. I am able to PXE boot the Test client, get to the FOG menu and everything is working fine there.
    When I try to PXE boot a client that is not connected to that unmanaged Cisco switch, it does not work. It does not seem to see the FOG server at all, even though it’s in the same subnet.

    [ATTACH=full]841[/ATTACH]
    Any idea of what could be wrong with this setup ?

    Thanks,

    [url="/_imported_xf_attachments/0/841_schema.jpg?:"]schema.jpg[/url]


  • Developer

    [quote=“George_Lebay, post: 28496, member: 24393”]If it works with the Ghost Console, is it supposed to work with Fog ? Are the settings on the switch the same ?[/quote]

    Incorrect, they are two systems and because one client works in one, do not assume it will work in another. while FOG is versatile and we can add drivers to accommodate systems, there are still some issues we have not yet over come. If a machine supports the PXE boot method, it can be used with FOG.

    The settings may or may not be the same, but it couldn’t hurt to check to see if the proper settings are turned on, that is if you have access to the administration settings.



  • [quote=“Tom Elliott, post: 28484, member: 7271”]To add on, it’s probably blocking UDP traffic altogether so I’ll go out on a limb and think the “Managed” side of the switch has Multicast Broadcasting Disabled. I’ll go even further and I’m going to guess that Wake On Lan functionality probably doesn’t work either.[/quote]

    If it works with the Ghost Console, is it supposed to work with Fog ? Are the settings on the switch the same ?


  • Senior Developer

    [quote=“Oscar Hilliker, post: 28485, member: 24172”]I am getting DCHP/BootP: Reply not for us, op[2] xid[642c17ed] and other xid codes. This now happens only after I create a task to download an image to a client.[/quote]

    Can you create your own thread?

    This sounds more like your environment has VoIP’s?



  • I am getting DCHP/BootP: Reply not for us, op[2] xid[642c17ed] and other xid codes. This now happens only after I create a task to download an image to a client.


  • Senior Developer

    [quote=“Jaymes Driver, post: 28483, member: 3582”]Then the problem lies in the network gear, you need to check the settings or talk to someone that manages the DHCP server to better understand why it is you can not pass boot information over. My GUESS is that there is a setting on one of the other switches that is preventing communication.[/quote]

    To add on, it’s probably blocking UDP traffic altogether so I’ll go out on a limb and think the “Managed” side of the switch has Multicast Broadcasting Disabled. I’ll go even further and I’m going to guess that Wake On Lan functionality probably doesn’t work either.


  • Developer

    Then the problem lies in the network gear, you need to check the settings or talk to someone that manages the DHCP server to better understand why it is you can not pass boot information over. My GUESS is that there is a setting on one of the other switches that is preventing communication.



  • [I]So if your ip address scheme was 10.1.1.x ALL clients on the network get the same 10.1.1.x ip address, is this correct?[/I]
    That is correct.

    [I]If you move one of the clients that “can’t boot” on one side of the switch to the side that does allow booting, does the client boot properly? [/I]
    Yes. I have tried and it works.


  • Developer

    [quote=“George_Lebay, post: 28448, member: 24393”]The only difference is that unmanaged switch that links the server to the client that actually pxe boot to FOG.[/quote]

    So if your ip address scheme was 10.1.1.x ALL clients on the network get the same 10.1.1.x ip address, is this correct? they may increase to 10.1.2.x or 10.1.6.x, but everything must increase sequentially. If that is the case you need to look into the switch gear between your DHCP and your clients that can’t boot.

    This is not a problem of FOG, your FOG server is working, and if your dnsmasq is working to boot your machines on one side of the switch but not the other, it is a setting in the network gear.

    If you move one of the clients that “can’t boot” on one side of the switch to the side that does allow booting, does the client boot properly?



  • The only difference is that unmanaged switch that links the server to the client that actually pxe boot to FOG.



  • I’ve read that part on the “Using FOG with an unmodifiable DHCP server/ Using FOG with no DHCP server” page, but all my computers are in the same subnet at the moment. At first the server was on a different one, I have changed the IP address to see if it would change anything, but obviously it didn’t.

    BTW the computer that is able to PXE boot and the client on which it’s not working are in the same subnet.


  • Developer

    [quote=“George_Lebay, post: 28436, member: 24393”]@Jaymes Driver: I have already done this. Thanks :)
    @variable205: I’d like to avoid dealing with these guys, but I might have to do it if there is no other solution.

    Thanks to both of you for your answers.[/quote]

    Pay attention to this part:

    Serving ProxyDHCP to multiple subnets

    If you are serving ProxyDHCP to multiple subnets some changes must be made to your switches/routers and your server config.
    Modify your /etc/dnsmasq.d/ltsp.conf file by adding the subnet mask option to line:
    dhcp-range=192.168.1.10,proxy
    to make it
    dhcp-range=192.168.1.10,proxy,255.255.0.0
    which will serve all 192.168.x.x subnets. If you are using 10.x.x.x addressing, use subnet mask “255.0.0.0” (8-bit) and if you are using 172.16.x.x, use subnet mask “255.240.0.0” (12 bit). Basically set the subnet mask so that all subnets on which ProxyDHCP should answer are covered. If you don’t do this, the ProxyDHCP server will not respond to DHCP requests for hosts outside of it’s own subnet.
    Add an IP Helper/DHCP Relay record to your router or switch so the DHCP broadcasts are sent to your normal DHCP server AND the Fog server.

    Add the correct setting to your ltsp.conf file and restart the dnsmasq service.



  • @Jaymes Driver: I have already done this. Thanks :)
    @variable205: I’d like to avoid dealing with these guys, but I might have to do it if there is no other solution.

    Thanks to both of you for your answers.


  • Developer

    I recommend DNSmasq. Anytime you have a DHCP server that you can not modify and you want to use fog, then you need to use the dnsmasq service to give out proxy dhcp addresses during the pxe boot process.

    [url]http://fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server[/url]



  • I have a feeling that’s what still blocking you then. At the moment, since options 66 and 67 aren’t configured to point back to your FOG server, it won’t relay any information to the client behind that DHCP server.

    You may need to get permission or have the guys managing the DHCP server to place in the necessary info here:
    [url]http://www.fogproject.org/wiki/index.php/Integrating_FOG_into_an_Existing_Network[/url]



  • I have no access to that DHCP server, so I have very little information about it. I know it’s a Windows server using a 10.xxx.xxx.xxx IP address.



  • What device/node is providing the DHCP services?


Log in to reply
 

358
Online

38982
Users

10712
Topics

101678
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.