Tengo dos UAV 3DR Solo. Tienen computadoras ARM tanto en el dron como en el controlador que ejecutan Busybox Linux.
Por lo que tengo entendido: de forma predeterminada, el controlador actúa como un punto de acceso inalámbrico. Tiene el SSID:SoloLink. Esta imagen muestra la configuración predeterminada:
El controlador es lo que tiene dos antenas y dice "SOLO" en la pantalla y el UAV/dron real es lo que tiene forma de X.
Esto funciona bien y puedo acceder directamente al controlador ( ) y al solo real con ( )ssh [email protected]ssh [email protected]
Puedo ejecutar un comando desde una utilidad de Python en la página de github de 3DR: github.com/3drobotics/solo-cli/blob/master/soloutils/wifi.py(lo siento, solo puedo tener 2 enlaces debido a mi reputación) para indicarle al controlador que se conecte a otra red WiFi. Configuré una Ubiquity PicoStation para que actuara como enrutador y tuviera el SSID:ubnt. Para conectar el controlador a la ubntred, me conecto a la SoloLinkred y ejecuto solo wifi --name=ubnt. Básicamente, lo que esto hace es crear un script bash y ejecutarlo:
if [ "$#" -lt "2" ]; then
echo "Usage: `basename $0` timeout_in_seconds command" >&2
echo "Example: `basename $0` 2 sleep 3 || echo timeout" >&2
exit 1
fi
cleanup()
{{
trap - ALRM #reset handler to default
kill -ALRM $a 2>/dev/null #stop timer subshell if running
kill $! 2>/dev/null && #kill last job
exit 124 #exit with 124 if it was running
}}
watchit()
{{
trap "cleanup" ALRM
sleep $1& wait
kill -ALRM $$
}}
watchit $1& a=$! #start the timeout
shift #first param was timeout for sleep
trap "cleanup" ALRM INT #cleanup after timeout
"$@"& wait $!; RET=$? #start the job wait for it and save its return value
kill -ALRM $a #send ALRM signal to watchit
wait $a #wait for watchit to finish cleanup
exit $RET #return the value
SCRIPT
cat > /tmp/setupwifi.sh << 'SCRIPT'
# Delete old files
rm /mnt/rootfs.rw/lib/modules/3.10.17-rt12-*/kernel/net/ipv4/netfilter/iptable_filter.ko || true
/etc/init.d/hostapd stop
killall wpa_supplicant || true
killall udhcpc || true
cat <<EOF > /etc/wpa_client.conf
network={{
{credentials}
}}
EOF
echo 1 > /proc/sys/net/ipv4/ip_forward
sed -i.bak 's/dhcp-option=3.*/dhcp-option=3,10.1.1.1/g' /etc/dnsmasq.conf
sed -i.bak 's/dhcp-option=6.*/dhcp-option=6,8.8.8.8/g' /etc/dnsmasq.conf
/etc/init.d/dnsmasq restart
sleep 2
echo 'connecting to the internet...'
wpa_supplicant -i wlan0 -c /etc/wpa_client.conf -B
/tmp/timeout.sh 15 udhcpc -i wlan0 || {{
echo -e "\\nerror: wrong credentials or couldn't connect to wifi network!\\n"
ifconfig wlan0 down
}}
/etc/init.d/hostapd start
sleep 3
wget -O- http://example.com/ --timeout=5 >/dev/null 2>&1
if [[ $? -ne '0' ]]; then
echo ''
echo 'error: could not connect to the Internet!'
echo 'please check your wifi credentials and try again.'
else
echo 'setting up IP forwarding...'
insmod /lib/modules/3.10.17-rt12-*/kernel/net/ipv4/netfilter/iptable_filter.ko 2>/dev/null
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -A FORWARD -i wlan0 -o wlan0-ap -j ACCEPT
iptables -A FORWARD -i wlan0-ap -o wlan0 -j ACCEPT
echo ''
echo 'success: Solo is now connected to the Internet.'
echo 'if your computer does not yet have Internet access, try'
echo "disconnecting and reconnecting to Solo's wifi network."
fi
SCRIPT
chmod +x /tmp/timeout.sh
chmod +x /tmp/setupwifi.sh
bash /tmp/setupwifi.sh > /log/setupwifi.log 2>&1
(La parte {credenciales} se debe a que este script está en una cadena grande en un script de Python y sustituye esa parte con las credenciales que le paso)
Parece habilitar el reenvío, reconfigurar dnsmasq, configurar wpa_supplicant para conectarme a mi nueva red WiFi, iniciar wpa_supplicant y luego reconfigurar iptables para reenviar el tráfico desde wlan0las wlan0-apinterfaces y viceversa. La última if/elsedeclaración allí la modifiqué para que no realice el wget y solo ejecute el elsebloque.
Esto funciona bien y puedo acceder al controlador desde la ubntred. Mi configuración ahora se ve así:
Puedo conectarme por ssh al controlador sin problemas, pero no veo el Solo en la red. Lo intenté desde la computadora portátil y solo veo el enrutador ( ), el controlador ( ) y a mí mismo ( ).ssh [email protected]nmap -sP 192.168.1.1/24192.168.1.1192.168.1.6192.168.1.76
Aquí es donde estoy atrapado
Quiero poder acceder al dron Solo desde la computadora. Entiendo que hay dos interfaces en el controlador pero no entiendo cómo conectarlas.
El propósito de esto es poder conectar otro par a la misma ubntred y luego puedo monitorear/controlar dos UAV desde una fuente central y un piloto puede estar en el circuito para tomar el control si es necesario.
Se agradecería cualquier ayuda o términos de Google. No tengo mucha experiencia con las redes y he estado en muchas madrigueras buscando los comandos y términos asociados con las redes.
Respuesta1
De hecho, un amigo me vinculó a este artículo y quería mi opinión; la compartiré aquí también.
El problema aquí es que faltan rutas. Para que su 192.168.1.76IP (o cualquier 192.168.1.xIP) llegue 10.1.1.x, necesita conocer el camino. Las IP en la misma subred (por ejemplo, [ 10.1.1.1y 10.1.1.10] o [ 192.168.1.76y 192.168.1.1]) no necesitan una ruta para comunicarse; utilizan una transmisión para encontrar el dispositivo con una IP determinada y enviar su tráfico directamente.
Para pasar de una subred a otra subred, hay que definir una ruta. Además, hay que definir una ruta de REGRESO. Entonces, puedes probar esto (si tu enrutador y el controlador individual lo admiten):
Necesitas una ruta en tu 192.168.1.1AP. La fuente sería cualquiera, el destino sería 10.1.1.0/24y el siguiente salto sería 192.168.1.6: el controlador Solo. El controlador conoce ambas redes, por lo que si envía tráfico destinado a 10.1.1.10, SolodeberíaYa sé cómo llegar ydeberíaenvíalo. Además, debido a que el controlador en sí es, efectivamente, la puerta de enlace de red para el dron ( 10.1.1.1), y estambiénconsciente de la 192.168.1.0/24subred, que no se requeriría ninguna ruta allí; la ruta de regreso está implícita.
Agregue esa ruta a su enrutador ( any>10.1.1.0/24>192.168.1.6) y vea si eso resuelve el problema.