Categories

  • Get help with your FOG system.
    FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
    13k Topics
    115k Posts
    Tom ElliottT

    @AUTH-IT-Center I do believe snponly would be the recommended, rather than iPXE’s driver.

    The developers at iPXE wrote the driver on their own (of course using documentation and stuff, but for all intents/purposes it is still a handrolled driver) so anything is possible.

    We shipped the native iPXE 2.0.0 mainly because of the feature it allows with actual Secureboot capabilities and instead of embedding everyfile with a custom script, a more dynamic approach for when iPXE releases new version we can upgrade more easily.

    For what it’s worth, I would almost want more people to default to snponly.efi (or secureboot/snponly-shimx64.efi if using/wanting secureboot after enrolling your machines of course) because this is supposed to be using the generic driver for EFI boot protocols on the NIC rather then attempting to discover the NIC using a driver loaded.

  • Get the latest news on what's happening.
    Security Advisories
    184 Topics
    825 Posts
    A

    @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

  • View tutorials or talk about FOG in general.
    General Tutorials
    2k Topics
    19k Posts
    Tom ElliottT

    @rdr I don’t believe the FOG-Agent would be the right thing for this, and neither would the FOG Server.

    In very old versions of FOG the IP address was a distinguishing factor of what a “host” was.

    Relatively shortely after that became a norm, machines really started to come with multiple NICs, and/or with Wifi. That plus many systems prefering to move to DHCP for their networks (due to Wifi needs, and manual intervention to change an ethernet when a machine moved from one place to the other) FOG stopped trying to use the IP as a definition of what a host was.

    WOL Works on macs and generally locally to the subnet the FOG server (or local machines) run on, but with some finagling you can send WOL packets on different network subnets.

    Welcome the WOLBroadcast Plugin that already exists. I will admit I’ve not tested this plugin in quite some time now, so please see if that will be more what you’re looking for?

    The FOG Agent shouldn’t be simply spamming your network with WOL packets just because it doesn’t know what is on the same subnet (to your initial point), but the FOG Server should be able to especially if you have your network already done for this.

    I hope this helps with what you’re looking for. The FOG Agent, in my eyes, should only try to do things it knows about, instead of being a rogue “DDoS” vector.

  • Report bugs, request features, or get the latest progress.
    General Feature Request Bug Reports
    2k Topics
    21k Posts
    Tom ElliottT

    @scottrayr I’m not able to replicate the issue you’re seeing.

74

Online

12.8k

Users

17.6k

Topics

157.1k

Posts