Ground unit: eth0 not getting an IP

I have seen multiple threads on this forum about Ethernet-over-USB, but I seem to be stuck in a different place.

I want to do Ethernet-over-USB from the Ground unit to my network. I connect my Herelink to my router with an ethernet cable and adapters, something like this:

Ground unit <--> micro-usb to ethernet adapter <--> ethernet cable <--> router

In the ground unit, I can see a network interface called eth0 appear, and the ethernet adapter blinks. But the ground unit never gets an IP. It looks like this:

$ ip a
13: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-vxlan state UP group default qlen 1000
    link/ether f0:1d:bc:f2:cd:ea brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f21d:bcff:fef2:cdea/64 scope link 
       valid_lft forever preferred_lft forever

I tried rebooting the Ground Unit while the adapter is plugged, but that did not seem to change anything.

What am I missing? Is there a way to run a dhcp client to get an IP for eth0?

Note that by setting an IP manually to eth0, I can send data through it and receive it over the network. So the network adapter works, it’s just that Android is not configuring the network interface properly (looks like it’s not running DHCP).

there is no dhcp running
and there is no ip on the interface because it gets added to the bridge

Thanks for the answer!

I’m a bit confused though… how am I supposed to use eth0? My goal is to connect my Herelink to my router over Ethernet instead of WiFi. But then my router should assign an IP to Herelink, right?

Is that not possible?

Aha I just got it. It is just added to the bridge, and because there is no DHCP running, the laptop on the other side must set a static IP in the subnet

So it is not meant to replace a WiFi connection, rather it is extending the subnet.

By any chance, is there a way to change the network configuration from the OEM image?

yes, its a transparrent bridge, if you added your own dhcp. if you need access to the airunit/gndunit then you need to be within the ip range.

Well I can do (as root) exactly what I want with this:

ip link set eth0 nomaster # Remove eth0 from the bridge
/sbin/.magisk/busybox/udhcpc -i eth0 # Get an IP with a dhcp client I imported
ip a add brd dev eth0 # Set the address to the interface

It’s just that I would like to persist that.

regarding changing ip’s yes its possible, we would normally have a custom contract with your company for any real custom work. ie we have one client that runs dhcp clients on both air/gnd units

the air unit we also allow root access on so you can modify it yourself, however this will break future OTA updates on the air unit

you could just change the bridge ip if thats easier? the bridge interface ip has no effect on the system from our side

hmm it’s just that I want eth0 to behave like a typical ethernet interface: run a dhcp client when an ethernet cable is plugged, get an IP from the router, and be connected.

That’s the same kind of connection I get with the WiFi, except over ethernet. I don’t want the bridge because it forces me into the drone/radio subnet ( and I don’t want eth0 to be there.

ok, well it depends on what services you want/need access too

and i dont know your requirements.

the ground unit technically is a router with access to all the subnets, if the laptop was setup correctly with custom routes

I really want it to behave like the WiFi: with the WiFi, I connect to the WiFi, I get an IP from the remote access point (the router), and that’s it.

if the laptop was setup correctly with custom routes

I don’t connect to a laptop, I connect to a router. Just like when you connect your laptop to a router with an ethernet cable, I connect my Herelink to the router the same way :slight_smile:

can you draw a diagram.

reason i ask is i don’t know what services your accessing, and also which side your connecting to the router.

With text, I would describe it like this:

Ground unit <--> micro-usb to ethernet adapter <--> ethernet cable <--> router

With images, it could be described like this:

So I plug the Ethernet cable (blue) into the router on the right, and into the Herelink ground unit on the left (with an Ethernet-to-USB adapter, obviously). From there I expect the Herelink to get an IP (i.e. the ground station runs a DHCP client that talks to the router, the router provides an IP, and the ground station assigns it to eth0). Really, just like if I had the same setup but connecting over WiFi:

That’s also similar to the behavior I get when I plug e.g. my laptop into a router over Ethernet:

Or when I connect e.g. my phone to a router over WiFi:

This is also what the SIYI ground station does when I plug an Ethernet-to-USB adapter. The Herelink ground station behaves differently: it assigns the eth0 interface to the bridge (br-vxlan), and it does not connect to the router. Instead it is made to connect a laptop to the ground unit directly, just like what USB Tethering does. But that is not what I want (otherwise I would use USB Tethering :see_no_evil:).

As mentioned above, I get exactly the behavior I want by plugging my Ethernet-to-USB adapter and then running (as root):

ip link set eth0 nomaster # Remove eth0 from the bridge
/bin/busybox/udhcpc -i eth0 # Run the DHCP client, such that the router can assign an IP
ip a add brd dev eth0 # Assign the IP (assuming that the router offered "")

Currently, I believe that the Herelink ground station does this when I plug the adapter:

usbethx : /bin/busybox brctl addif br-vxlan eth0 # add eth0 to br-vxlan bridge

My question was therefore: is there a way for me, from the OEM image, to overwrite the usbethx behavior? I have been looking into build.prop and the various init.rc files, but I can’t seem to find how usbethx is triggered. Moreover usbethx is a binary blob.

Does that make more sense?

currently there is no way to modify this on the gnd unit via a oem image. it is not designed for this use case. the oem image is for apps.

one method around it would be to change your router to allocate ips in the 192.168.144.x range, set reservations for .10 and .11 and then everything would be in the same broadcast domain.

this leads me to the next question, are you using the gnd unit, or is it just for data transport? a air unit to air unit solution might be more suited

Oh, I think I see where you may be confused. So the same, with the subnets:

I don’t want my router to be in the “drone subnet”, I really want two separate subnets (just like what happens with the WiFi, really). I don’t want the bridge, because I don’t want people connected to my router to have direct access to the drone subnet.

I am running my own bridge app that forwards MAVLink/Video/etc between the two subnets. And that is what I want, because that bridge app does “fancy” stuff in the middle :slight_smile:.

one method around it would be to change your router to allocate ips in the 192.168.144.x range, set reservations for .10 and .11 and then everything would be in the same broadcast domain.

Yes, that’s right. But I don’t want everything in the same broadcast domain, unfortunately. First, because that would be inconsistent with the experience I have over WiFi (when Herelink is a client, or when it runs an Access Point) or with USB Tethering. Second, because MAVLink components tend to broadcast stuff all around, and I want to have control :sweat_smile:.

I think I can maybe hack my image to run a service that will check every few seconds if eth0 is up, and if it is, it will “undo” what usbethx did and run my commands instead. Or maybe I’ll just accept that Herelink cannot do that and I’ll find another solution (maybe that’s better than hacking the image :see_no_evil:).

Thanks for the help!

im not sure if you have root

stop usbethx

will stop the auto bridge add

the rest is just ip’s

the design intent was to provide a transparent bridge, as a lot of clients want other pc’s/cameras connected on the drone side, and transport that to the ground side to a laptop. etc.

you could run vpn software on the herelink gcs to route traffic to other places if that works as well.

Sure, it makes sense that some people may want that.

im not sure if you have root

I do, but I’m trying to help some university students who don’t, which is why I was trying to get it in the image they flash.

the rest is just ip’s

But again that requires root, and ideally that would happen automatically when the ethernet adapter is plugged :innocent:

Would be great if there was a way to set an option in the OEM image, e.g. in one of the “extra files”, to choose the Ethernet mode. But yeah, I know how it is, no worries :wink:

Oh, actually @Michael_Oborne you were right! It seems that disabling usbethx (with # stop usbethx) does the trick! Then the IP comes automatically (if the WiFi is not connected). It doesn’t persist across reboots though.

Too bad it can’t be disabled from the OEM image, but I can probably manually change the image to do what I want (i.e. remove usbethx).

Could you not have a property in oem.prop, for instance, to disable usbethx? Or even just check the existence of a file, like /oem/do_not_start_usbethx. Such that one could choose the mode from the OEM image…

Thanks again!

that could be possible yes. but we don’t have a release timeline for a change like this atm

1 Like