SG135 Rev3 - Since Update not working correctly

Quick Update:

The SG135 is working now, but i dont know why.
I had now Links on my ETHs und lan & internet ist working again.

Only Problem ist that the Status LED is always blinking rapidly - and this dosnt stop.

That was not before the last Update.

Could somebody help me here to find out what is the Problem?

Same applies to my SG115 rev3 with SFOS 19.5.2 MR-2-Build624 on it. Reinstalled from Hardware version to Software version with Home License and now the status LED flashing occurs. Tried Firmware Version SFOS 19.5.1 MR-1-Build278 as well but no change. Everything works as already mentioned here but still seems weird.

Thanks for your answer.

As a side note: at least in my case, /etc/init.d/beep and of course /etc/asg do not exist. Reading the code you posted, without the asg file the led won't stop flashing.

To answer your question, no there are no beeps at any time of running the system.

But at least for me the flashing of the led makes sense now. The software version of Sophos XG Firewall does not contain any code to control the led of the Sophos SG 115 appliance.

Do you know if there is an option to create a script that will switch the status led to constant light?

Sorry, i somehow missed that you are using a home licence  with software ISO.

Maybe you have /usr/local/bin/ledctl

Usage (specifically for the nexcom boards in hardware appliances) is:

[DNA130S] NEXCOM CPLD - Status LED Control
Usage:
        ./DNA130S_LED { w VALUE | g | h }
        e.g. ./DNA130S_LED -w 0
        ---------------------------------------------
        Breakdown for Flags:
        -w [Value] - Set LED status
        -g         - Get LED status (Passed as return value)
        -h         - Print Help
        valid [Value] options:
        0: LED Off
        1: Green Blinking
        2: Red Constantly
        3: Green Constantly
        4: Red Blinking

so placing a "/usr/local/bin/ledctl -w 3" somewhere in the boot process should suffice.

Thanks again for your answer.

Unfortunately I don't have ledctl either under the mentioned path or anywhere else in the system. I assume these components to control the hardware are logically not present in the software version. I will do a research to find out if the control elements of the hardware can be "retrofitted" in the software version.

Any other ideas are really appreciated.

Alan Brand said:

According to /etc/init.d/beep the LED turns solid green only if no problem during startup:

i have this file, but it means /etc/init.d/beeps

Alan Brand said:

Did you hear the five beeps?

No, I don't hear any more beeping, but that was definitely not the case before, because I could always hear the beeping after a successful start.
I've also been wondering why the device suddenly stopped beeping after starting

Alan Brand said:

Maybe you have /usr/local/bin/ledctl

and i also have this file...

Alan Brand said:

so placing a "/usr/local/bin/ledctl -w 3" somewhere in the boot process should suffice

also i just tested it, when i run this command, the led stays on constantly like before

Time to watch the boot log (or dmesg) and compare it to previous boots before the update.
Something in the boot process might fail.

In the german forum there is a report about a nic issue with the i40E driver (digging some kernel mailing lists suggests, that it is an incompatibility issue between the NIC firmware and the linux driver), but this is a issue for 10GBit-NICS and probably not your case unless you added a flexiport module to the SG125.

no i have a "stock" SG135 with nothing added.
but unfortunately I can't say since when it really stopped working with the LED & the beeping.

Have a look at the german thread (I can't link, otherwise this post gets flagged as spam).

Could be an udev issue (I noticed, that tso disabling by udev applies also to e1000 nics).

i will search for this thread.
what is the title of this post?

community[.]sophos[.]com /utm-firewall/f/german-forum/141576/error-i40e-promiscuous-mode-after-update-from-9-715-to-9-716

Dirl L. hat viel geschrieben, bei ihm war es ein Fehlen (nicht-laden) der udev-rules in /etc/udev/rules.d/20-nic.rules, welches dazu führte, daß bestimmte Workarounds für Bugs in den Intel-Chips nicht ausgeführt wurden (konkret führt wohl das Offloading der TCP-Checksummen zu fehlerhaften Paketen und muß abgeschaltet werden). Wie gesagt andere Baustelle, aber irgendwas im 9.716er Update scheint subtil das Timing geäbdert zu haben, so daß Raceconditions entstehen.

community[.]sophos[.]com /utm-firewall/f/german-forum/141576/error-i40e-promiscuous-mode-after-update-from-9-715-to-9-716

Dirl L. hat viel geschrieben, bei ihm war es ein Fehlen (nicht-laden) der udev-rules in /etc/udev/rules.d/20-nic.rules, welches dazu führte, daß bestimmte Workarounds für Bugs in den Intel-Chips nicht ausgeführt wurden (konkret führt wohl das Offloading der TCP-Checksummen zu fehlerhaften Paketen und muß abgeschaltet werden). Wie gesagt andere Baustelle, aber irgendwas im 9.716er Update scheint subtil das Timing geäbdert zu haben, so daß Raceconditions entstehen.