The swap of the two LNFS  done on July 15th has been done without exchanging the eth address of the devices. As a consequence, while restarting the automation, it was trying to communicate with the old address, thus inverting the {6, 8, 56 }MHz signals with the {22, 81}MHz. We stucked at the Fmoderr state of the INJ node, untill we swapped the ethernet cables of the two LNFS (to be noted: it seems there is the possibility to swap the ports directly into the configuration file of the LNFS server.

Because of this, we found a peculiar corner case of the FmodErr loop: after the exchange of address, the LNFS_FREQ_3 was not anymore setted on 56MHz (was instead the old 81). The check of the Fmod, however, is based on a 56MHz demodulated channel, that gave 0 correction to the loop. Eventually, no change (both MC_Z or LNFS) has been requested, and the 8Mhz frequency has not been changed (and so the 6 and 56, which are automatically updated once the 8 changes).
As a result, this morning we didn't have any modulation at 56MHz. The problem has been solved applied a reset of the 8MHz. 

The Fmod loop will be updated consequently.