SG-1100 restore does not succeed



  • I have had a few serious problems with the SG-1100. Mostly it has had to do with failure to recognize the WAN which is a PPPoE service in my case. The boot process will not pass this stage. It says that the link is not up - yeah what am I supposed to do. After much difficulty and I force the box to complete its boot by doing a factory reset and go directly to the web config.
    I can get the SG-1100 to start from a factory reset - straight in to the web config, tell it the PPPoE usr and pw for the WAN and it will start up as a barebones firewall after the dance with the getgo wizard.

    Then I want to configure it with file carefully saved from a month's work in getting serveral packages going - OVPN -pfblockerNG - snort etc. Failure! I have never succeeded in doing a reload of a backup file. It complains about the interfaces having an error. I don't know what to tell it. Each choice I make fails. It goes away to reboot and then ends up with the same deadly question that cannot be answered (by me anyway) which what is the WAN port name.
    It won't do an 'a' auto identify because it says the port is down (maybe that is true of a PPPoE service till it gets a tug from the DHCP?) it has never worked for me.
    The available NIC port names are
    mvneta0.4090 >>WAN
    mvneta0.4091 >>LAN (192.168.1.1)
    mvneta0.4092 >>OPT1
    I have seen these a thousand times./ It wont accept any of them which seems strange.

    There must be an easier way to manage an SG-1100 than this I have had about a month of success running the box but a mistake throws me back to basics and I cannot retrieve my work in a backup config file.
    I just watched Tom Lawrence do a backup and recover vid and it all worked. I would like some of that!
    Any ideas?



  • Setup your 1100 ones more - use the Factory settings, option 4.
    Do some minimal setup to make pppoe work.
    Don't import anything.

    Now, SAVE your config - make a config backup..
    Reboot your device ... the proper way, like Option 6 or the GUI option.
    Start it again and import your config that you just saved ...

    This goes well ?

    Yes / No ?

    Probably : Yes, so now you have an important fact : your backup file (the one that blows up your device when you import it), has something 'no good'

    Have a look at the file - and xml is human readable, and easy to understand.
    Compare this file with your the file you just created to test (see above).

    Check also you logs ...



  • OK, your advice solved the backup reload problem quickly. I inspected the XML on the newly created backup and compared with the one I was trying to reload and bingo. The interface names were different and as soon as I saw what they were I realized immediately I was being stupid. By misplacing a backup XML file I was trying to reload one from my experimental AMD64 setup I used before the little SG-1100 was delivered. I might have been able to edit the interface names but I did not realize what was going on. That problem solved.

    The other one is not. This is where after a reboot pfsense always wants to know which is the WAN port. if it is a PPPoE service (most are in UK for domestic users). If you choose 'a' for automatic pfsense says that the link is down when you plug it in. Of course if you have not yet provided a USR and PWD to pfsense for the PPPoE WAN it does not hook up. Pfsense in SG-1100 seems not to recognize the port you plugged the WAN into if it is a PPPoE service. This is a deadly loop you can't escape from.

    Choosing to name the WAN port as mvneta0.4090 fails for me it wont accept that as a valid name for the WAN. When the WAN has already bee established the name becomes pppoe0 like this

    WAN (wan) -> pppoe0 -> v4/PPPoE: xx.xx.xx.xx
    LAN (lan) -> mvneta0.4091 -> v4: 192.168.1.1/24
    OPT (opt1) -> mvneta0.4092 ->

    This did not happen to me with the AMD64 pfsense image where I never has a problem in naming the WAN port. I readily accepted the NIC name for the port.

    Any advice about the SG-1100 and this refusal to see the WAN as a valid circuit before you can get username and password into it would be appreciated.



  • @STEAMENGINE said in SG-1100 restore does not succeed:

    This is where after a reboot pfsense always wants to know which is the WAN port. if it is a PPPoE service (most are in UK for domestic users). If you choose 'a' for automatic pfsense says that the link is down when you plug it in. Of course if you have not yet provided a USR and PWD to pfsense for the PPPoE WAN it does not hook up. Pfsense in SG-1100 seems not to recognize the port you plugged the WAN into if it is a PPPoE service. This is a deadly loop you can't escape from.

    I'm used PPPOE for years also.
    Good news : your wrong, it doesn't work like that.
    When pfSense boots, the WAN NIC is initialized - you can see for yourself : lights come up on both the pfSense WAN NIC, and the modem's NIC must also be up.
    This is the moment when you see a "Link UP" in the dmesg log for the WAN.

    The fact that PPPPoE isn't initialzied yet is not important. For pfSEnse, there is a WAN assigned interface, that's all that counts.

    Check out for yourself what PPPoE is : it's a (point to point) Protocol over Ethernet. When PPPoE is started, the Ethernet is and must be already up.
    So, for pfSense the WAN interface is UP.

    If pfSense stops at the end of the boot, to ask to you to assign a WAN, this means the other side isn't UP yet -> your modem ! Solution : boot modem first, have it stabilize, and start the pfSense. This is a know situation and has been seen before. Especially if you have a uncontrolled power down and power up situation.
    Normally, xDSL modmes are dumb devices, and start up pretty quickly, faster as pfSense.

    You could also have a bas cable : test with another cable.

    Again, see the dmesg log for whatever messages related to the WAN NIC driver.
    It should show "Link UP" for all NIC's connected at the end of the log.

    Btw : I always used and use today an AMD64 version - PPPoE isn't possible anymore for me.


Log in to reply