Ethernet DNS and Gateway settings

Home Forums Conduit: AEP Model Ethernet DNS and Gateway settings

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #23457
    Robert Macklin
    Participant

    I am having trouble configuring the Ethernet interface after upgrading a Conduit to 1.4.16. The settings are not in the same location. I found some settings when I set the eth0 interface to WAN, I set these to the correct values, but I am still not getting any name resolution.

    I have done this successfully with the older 1.4.3 firmware in the Conduit, but I cannot figure it out with the new firmware. When I use the nslookup server command, it reports the server being 127.0.0.1.

    How do I correctly setup the eth0 interface so ping microsoft.com properly resolves the name?

    #23459
    Jeff Hatch
    Keymaster

    Robert,

    The server you found it pointing to is correct. The dnsmasq daemon is listening on 127.0.0.1. It is what is handling and forwarding all DNS requests. That is part of the WAN failover design.

    As for your DNS not working: Could you perform a “/etc/init.d/dnsmasq restart” and see if DNS works after restarting the daemon. If that works, could you do me a favor and describe your network setup -> what interfaces are WAN, LAN, and what their configurations are? I am interested if you have more than one WAN configured and are using failover.

    Thank You,

    Jeff

    #23474
    Robert Macklin
    Participant

    Hi Jeff,

    Thanks for the info. I was able to get resolution after restarting the daemon. I’ve tried restarting the entire system a few times and this didn’t fix the issue, why does this restart work?

    I am trying to setup a Conduit with a Verizon LTE modem installed. I started with the Ethernet interface set to LAN and the cell interface set to WAN. This didn’t work, so I set the Ethernet interface to WAN to give access to the DNS and gateway settings. This also didn’t work until restarting the daemon.

    My goal is to have the Conduit use Ethernet for cloud access until it cannot make a connection, then use the cell as backup. What is the best configuration to achieve this functionality?

    Thanks,
    Rob

    #23477
    Jeff Hatch
    Keymaster

    Robert,

    There is a race condition that gets exposed the longer it takes the radio and ppp to come up when Cell is the primary WAN. Verizon is one of the longest. I am not sure why you’re hitting it with Ethernet other than you also have a Cellular WAN. We do have a fix for this issue (restart dnsmasq when starting a new WAN). That fix should be in the next release of the 1.4.x AEP Conduit. I am not positive when exactly that will be, it should be within the next couple of months.

    You should be able to set up Ethernet as your highest priority WAN in the Web UI under Setup->WAN. Make the Cellular the second highest priority. If the Ethernet connection fails, it will fail over to Cellular. It should fail back to Ethernet if that interface again regains Internet access.

    Sometimes Verizon can be tricky to get working. All you should need to do is insert the SIM, enable Cellular under Cellular->Cellular Configuration, and restart the device. If that does not work, post the chat script logging from /var/log/messages. That along with whatever pppd is outputting should give us a clue.

    Jeff

    #23506
    Robert Macklin
    Participant

    Hi Jeff,

    I’ve run a few more tests and can’t get the failover mode working correctly. The cell connection is setup for dial on demand. I tried with Ethernet set to LAN and cell set to WAN. It properly dialed when needed, then disconnected shortly after the request was completed. When I set Ethernet to WAN, and the highest WAN priority, I get the same resolution problem that requires the daemon restart to fix.

    There’s lots of stuff in the log file. I filtered out the LoRa communications, here’s a link to what remained:

    https://drive.google.com/open?id=1KDLyM8CRnv-_1ur5lPdOnIRVaIZZ3l8I

    Thanks,
    Rob

    #23520
    Jeff Hatch
    Keymaster

    Rob,

    Could you open a case at https://support.multitech.com/ where you could upload the logs. I’d like to get a case going so that this can be investigated. Multitech can help you better that way, and it will get tracked internally.

    Thanks,

    Jeff

    #23521
    Robert Macklin
    Participant

    Done

    #23719
    Lorenzo Campana
    Participant

    Sorry, have you fix the problem?

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.