• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Matthew73
    3. Topics
    M
    • Profile
    • Following 0
    • Followers 0
    • Topics 2
    • Posts 6
    • Best 0
    • Controversial 0
    • Groups 0

    Topics created by Matthew73

    • M

      Vlan, Ipxe, DHCPNAK

      General
      • • • Matthew73
      2
      0
      Votes
      2
      Posts
      413
      Views

      george1421G

      @matthew73 This is a unique condition. I can understand what is going on because we use NAC and VLAN switching on my campus. I can say that I have not seen this issue (anywhere) on my campus.

      I think I understand what needs to happen. Basically iPXE needs to say something and then wait XX seconds for your NAC system to identify the hardware and to switch it to the right vlan. The network link light winking happens 2 times during a normal pxe booting. The first time is when the PXE turns over control of the network adapter to iPXE and then when iPXE turns over control of the network adapter to FOS Linux. We see a similar issue when the network switches are using standard spanning tree and not one of the fast protocols (RSTP,MSTP, port-fast).

      The developers have created a specific group of iPXE boot loaders that have an embedded 10 second delay before iPXE tries to request an IP address. This gives STP and powersaver functions on the switch a chance to react before iPXE starts to talk. These files are in the 10secdelay folder. So to use these update dhcp option from ipxe.efi to 10secdelay/ipxe.efi This will call in the 10 second delay boot loader. See if that makes things better or not.

    • M

      Solved Failed dhcp, busybox network startup

      Bug Reports
      • • • Matthew73
      10
      0
      Votes
      10
      Posts
      6.8k
      Views

      M

      I have a working fog in my environment via my mods. The biggest part of the problem is clearly our switched network behaving badly so I don’t think there’s any in fog that should be changed cover that brokenness. I’ll be happier of course if our network folks can figure out why it takes so long.

      I do wish udhcpc had an option to “try one more time” if it failed to get a lease but it appears to be that it’s either one pass through or repeated passes until you succeed. I don’t really feel like it’s a good idea to default fog to “keep trying dhcp forever” mode. And even if fog could be set to dhcp for two or three attempted leases it’s still a bad solution - it would make things “work” in my case but at the cost of several extra minutes on the boot time and really the problem is my network is broken. That piece is just a bit out of my ability to fix while hacking fog to workaround the issue is possible - apparently. Learned a bunch figuring it out. 🙂

      If the code is useful then by all means use it, that’s why I posted it.

    • 1 / 1