Does VOXL deal well with multiple interfaces?
-
This is kindof a spin off of this thread...
I'm running VOXL with both WiFi and LTE modem. While I am able to bring up the LTE link, I'm noticing some strange happenings once it's up for while, so I've been digging into that...I'm tracing through the startup of the LTE modem interface (wwan0). Initially voxl-modem-start.sh is called, but the "meat" is really in the python script /usr/bin/sierra.py. At the very bottom of that script, udhcpc -q -f -i wwlan0 is called and prior to that call /etc/resolv.conf has a few lines that are applicable to wlan0, then after that executes those lines are gone and there's just one nameserver ip address specified (which I assume is applicable to the wwan0 interface), so at that point if wwan0 goes down, there's no specified nameserver for the wlan0 interface.
The executable "udhcpc" is actually a link to busybox, and according to busybox documentation if -s is not used on the command line (which it's not in this case), then the default script that runs is /etc/udhcpc/default.script. That file doesn't exist in VOXL. The only thing that is even close to that is /etc/udhcpc.d/50default, but I added a few lines of trace to that and can verify that it does not run.
Something is overriding the content of /etc/resolv.conf when the modem starts up. Can anyone point me to what udhcpc is actually doing here?
-
This is kindof a spin off of this thread...
I'm running VOXL with both WiFi and LTE modem. While I am able to bring up the LTE link, I'm noticing some strange happenings once it's up for while, so I've been digging into that...I'm tracing through the startup of the LTE modem interface (wwan0). Initially voxl-modem-start.sh is called, but the "meat" is really in the python script /usr/bin/sierra.py. At the very bottom of that script, udhcpc -q -f -i wwlan0 is called and prior to that call /etc/resolv.conf has a few lines that are applicable to wlan0, then after that executes those lines are gone and there's just one nameserver ip address specified (which I assume is applicable to the wwan0 interface), so at that point if wwan0 goes down, there's no specified nameserver for the wlan0 interface.
The executable "udhcpc" is actually a link to busybox, and according to busybox documentation if -s is not used on the command line (which it's not in this case), then the default script that runs is /etc/udhcpc/default.script. That file doesn't exist in VOXL. The only thing that is even close to that is /etc/udhcpc.d/50default, but I added a few lines of trace to that and can verify that it does not run.
Something is overriding the content of /etc/resolv.conf when the modem starts up. Can anyone point me to what udhcpc is actually doing here?
@Ed-Sutter Ok, I see in the actual busybox code for udhcpc it uses /usr/share/udhcpc/default.script, and I just verified that this script does execute on VOXL. Still I don't understand why /etc/resolv.conf gets overwritten. I don't know a lot about this, does anyone know if it is supposed to overwrite?
Reading along? Create a free ModalAI Forum account to join in.
With an account you can reply, ask your own question, get an email when a ModalAI engineer answers, and mark the reply that solved it. Your place in each thread is saved between visits.
Questions about VOXL, Flight Core, ESCs and ModalAI drones are answered here by the engineers who build them.
Register Login