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?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login