How to set wlan0 and eth0 to work simutaneously for Hokuyo LIDAR

I currently want a Hokuyo LIDAR sensor which uses the ethernet eth0 port to work with the wlan0 wireless network at the same time. I realized that the local loopback network enables the wifi to work, and with the current setup in /etc/network/interfaces, I cannot have eth0 and wlan0 working at the same time.
If I turn on eth0 for the hokuyo lidar, the wlan0 turns off, not permitting me to connect to roscore in ROS.
I have attempted to solve this issue by setting up the following commands in /etc/network/interfaces.
(When I used jetpack 2.0 preinstalled in the TX!, i did not have this issue.) Help would be greatly appreciated.

source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
auto wlan0
iface wlan0 inet dhcp
auto br0
iface br0 inet dhcp
bridge_ports eth0 wlan0

1 Like

Hello, gotenkscha:
Would you please use the native Jetson TX1 environment (without Hokuyo LIDAR sensor, which I have not worked on it.) and test whether eth0 and wlan0 can co-work well?


I do not understand what you mean by “native Jetson TX1 enviroment.” Are you asking me to check if the eth0 and wlan0 ports co-work without connecting the LIDAR sensor? I do not think this problem has anything related to the Hokuyo LIDAR sensor because the eth0 port does not co-work with the wlan0 port even for internet connections.

When I first received the TX1 Kit, the pre-installed software automatically connected me both to the eth0 and wlan0 ports. I was able to use them simultaneously without having to configure anything. However, after I did a fresh install with JetPack 2.1, the ports do not seem to co-work automatically. This is what I know for sure:

  1. The eth0 port works when the local loopback is turned OFF.
  2. The wifi connects via the wlan0 port when the local loopback is turned ON.
    In other words, local loopback must be on for wlan0 to provide Wifi
  3. The pre-installed Jetpack did a fine job of ensuring wlan0 and eth0 could co-work automatically.

I hope this issue can be solved. Thanks!

  1. The eth0 port works when the local loopback is turned OFF.

Let’s focus on eth0 first.
do you mean you need ifconfig lo down to make eth0 work?

what happened when eth0 and lo both up? can you paste log for details?


The Hokuyo LIDAR is connected via the ethernet port of the Tx1 and is connected as eth0.
The LIDAR can be assigned any IP address, Subnet Mask and Default Gateway via the UrgBenri tool.
The LIDAR seems to work fine with the wifi on my laptop PC, but the Lidar cannot work simultaneously with the wifi on the Tx1.
When the LIDAR works on my laptop PC, the IP address for both the LIDAR Ethernet port and wifi is 192.168.0.XX. (XX is assigned different numbers for the two however.)
When I type ifconfig, I can see the local loopback with the eth0 and wlan0 connection.
The only difference between the laptop PC and the Tx1 is this local loopback.
This is why I suspect I need to shut off the local loopback with ifconfig lo down to make eth0 work because I am guessing that there seems to be an address conflict between the local loopback and the LIDAR.

It may be an issue of default route. If you have only one network interface, then the default route is always over that interface and no application can fail to find the default route to the working interface.

If you have two interfaces (eth0 plus wireless), then default route might switch to either of those interfaces. If for some reason that second interface is not set up, but default route gets assigned to it anyway, then networking will not know this and attempt to use the invalid non-working interface. You’d have to tell it to assign default route to the configured device instead. I suspect that if wired stops working when wireless runs (but is not set up), then the default route got switched over to wireless.

Can you run the command “route” both with and without WiFi running? See if the “default” changes which interface (“Iface”) it is assigned to.

This is the result I get:

ubuntu@tegra-ubuntu:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default UG 0 0 0 wlan0 * U 1 0 0 eth0 * U 9 0 0 wlan0

ubuntu@tegra-ubuntu:~$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface * U 1 0 0 eth0

The error message I get when I try to run the urg node is

[ERROR] [1468288064.602608126]: Error connecting to Hokuyo: Could not open serial Hokuyo:
/dev/ttyACM0 @ 115200
could not open serial device.

I had no problem connecting the lidar and wifi at the same time when I was using the pre-installed jetpack; the problem occurred post-flashing.

There’s what I’m wondering about:

default UG 0 0 0 wlan0

Both eth0 and wlan0 have the same subnet, which they probably should not have.

Default route requires all traffic to go through WiFi, regardless of whether it is configured or not, and regardless of whether this is where you go to reach all of your end point connections or not. Unless there is some sort of redundancy and TTL is different as a kind of failover, two interfaces should not be on the same network. Can you change the subnet and mask on either WiFi or eth0? Basically an attempt to use an address specifically covered by a network and netmask would bind to that network…all traffic not explicitly within that subnet/netmask would go to the default route…when both interfaces are the same network it has no way to pick the one you really want so it all goes to the default route…WiFi in this case.

@linuxdev: I tried your suggestion of changing the subnet/netmask. The end result is the same with the wifi being the default route when wlan0 and eth0 are both active.
I think the correct way to turn both wifi and eth0 lidar on at the same time is to actually use the same subnet/gateway but different ip addresses then bridge them together, but I have trouble making that work. Help is appreciated. Thanks.

When I see two interfaces covering the same network/netmask combination, I expect there to be a different route “metric” (basically a marker of hop count or hop cost which is reflected in TTL) tied to each interface. An attempt to reach an address over both otherwise sufficient interfaces will pick the interface with the lowest metric. If one of the interfaces goes down, then the remaining interface will get the traffic (with the lower metric interface gone, the higher metric becomes the lowest metric).

Bonding two interfaces together (link aggregation) to act in parallel would mean equal metric, and require support at both origin and destination with some sort of virtual device to split traffic of a single connection between both interfaces (likely you would get a new virtual device and not talk to eth0 or wlan0 directly…it would be the virtual device doing the talking to eth0 and wlan0 and the routing tables). For example, if you need higher bandwidth and only DSL is available, you could get two DSL lines and you and your ISP could configure for aggregation…but the key is that simltaneous use via aggregation requires support at two points in the network, failover via metric does not. I do not believe that normally wlan0 and eth0 can bond for higher throughput without a third virtual interface at both ends of the connection.

Normally if a connection uniquely matches a combination of network and netmask, then that interface will be chosen. Normally no two interfaces will have the same network and netmask combination. If a connection is not directly served by a specific network and netmask combination, then the default route will be used under the assumption that the routing at the next hop can find a suitable interface, or find another router, and eventually find a suitable interface. So order of using an interface would be lowest metric of a specific network/netmask, followed by a default route.

For reference, your default route has metric 0 and aims at wlan0; wlan0 has metric 9, and eth0 has metric 1.

In your case, both wlan0 and eth0 are the same network/netmask (which I think is invalid if you want to use both at once), so only the one which has the lowest metric (eth0) will ever be used on something going to a combination. Yanking the eth0 cable and having the kernel detect a route failure would cause the same connections to then try to go over wlan0 (the next highest metric of a specific network/netmask match).

Your default route would be used if you are trying to reach an address outside of the combination. This specifically means it’ll try to talk to the router at the other end of the WiFi (default route is wlan0). I’m not sure how it may change things, but also notice that your default route has the lowest metric (highest priority if two routes can handle the same thing).

As an experiment, you could temporarily delete the default route, and then add it back:

sudo route delete default
#...when done testing:
sudo route add default gw
#...observe if default route now uses eth0...this would be good.

…since eth0 is now the highest priority (lowest metric) I hope it would become the interface used for any connection, or via default route (we just removed default and added it back in at a moment when eth0 has the lower metric). Without the default route, connections to any other network/netmask should fail. Had default route been assigned with eth0 as its interface to, then eth0 would work regardless of wlan0 status. Removing and adding the default route back in could change the interface to eth0, this would be one of the goals of the experiment. Perhaps if default route was assigned while bringing up interfaces such that wlan0 was there and eth0 was not yet configured, then this would explain the reason why the higher metric wlan0 was previously picked as default instead of eth0.

A big question is whether the things you are trying to network to are all in the address space? If not, is able to forward everything? Is the router accessible via WiFi?

@linuxdev Thank you for your feedback.
I tried to delete the default route but as soon as I attempt to use the ethernet connection, the default route turns right back on. When it turns on, the metric remains 0 (highest priority) for the default, 1 for the eth0 and 9 for the wlan0. The priorities are not changing.
As mentioned in my first post, my goal is to use the Hokuyo Lidar which connects to the TX1 on an ethernet cable along with the built in wifi of the TX1 . I need both because the Lidar will be used in conjunction with roscore in ROS.
If you look at the eth0, the genmask is and not I mistakenly wrote for eth0 when i posted my problem so I am not trying to network everything in the address space.
To be honest, I know nothing about routing so your explanation about network/netmasks were and still are pretty new to me. (I am a mechanical engineer) At this point, I am thinking about trying a hardware approach and simply getting a ethernet to usb coverter for the LIDAR and seeing if that does not disturb the wifi. I doubt this will work, but if you have any other solutions, I will be greatly grateful.

If you could put wifi and wired on addresses which provide a unique match without overlapping nets, then I think you’d succeed without any special effort. For example, if wired were on network, netmask, and the wifi were set to network and netmask, then both interfaces would function as desired.

If you really need wired and wireless on the same network, then the netmask scheme with on one and on the other would work if and only if one address end point fits in, while the other address end point fits in, but not

It seems like what you are trying to support probably requires both wifi and wired, but is there a reason both must be using the same network? Even with differing netmasks you’ll be required to make sure destinations belong to a specific netmask…if networks differ, no thinking or special configuration is required.

I do find the network management software on Ubuntu to be a bit irritating at times (and actually on other distributions which use the same software for net management). Attempts by NetworkManager to keep someone doing average things happy when wifi goes up and down really get in the way when you want to do something more specific without NetworkManager stomping on your toes. FYI, if NetworkManager gets hold of a USB ethernet device, then you can have the same issue with that as well.

@linuxdev. I tried doing what you told me. I still cannot get the lidar to work with the wifi at the same time.
Here are the Results.

ubuntu@tegra-ubuntu:~ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default UG 0 0 0 wlan0 * U 1 0 0 eth0 * U 9 0 0 wlan0 ubuntu@tegra-ubuntu:~ ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:4b:58:06:67
inet addr: Bcast: Mask:
inet6 addr: fe80::204:4bff:fe58:667/64 Scope:Link
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:372 (372.0 B) TX bytes:1968 (1.9 KB)

lo Link encap:Local Loopback
inet addr: Mask:
inet6 addr: ::1/128 Scope:Host
RX packets:2516 errors:0 dropped:0 overruns:0 frame:0
TX packets:2516 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:312106 (312.1 KB) TX bytes:312106 (312.1 KB)

wlan0 Link encap:Ethernet HWaddr 00:04:4b:58:06:65
inet addr: Bcast: Mask:
inet6 addr: fe80::204:4bff:fe58:665/64 Scope:Link
RX packets:4755 errors:0 dropped:0 overruns:0 frame:0
TX packets:3685 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2498339 (2.4 MB) TX bytes:417780 (417.7 KB)

A summary of info from the above…

…this will route anything through
…very few packets used this interface.

…this will route anything through
…a lot of traffic used this interface.

Default route:, wlan0…packets not exactly matching an interface would route through this.
…the higher packet count attempting wlan0 could have been exact wlan0 matches, or they could have been default route to an address not covered directly by an interface.

To complete the puzzle, what addresses are used by each device or application? Knowing what the LIDAR and other applications are configured for can be matched against those rules and we’ll at least know the basics of where the failure is. I suspect the very few packets which went through eth0 are simply configuration, and that no application requested an address in that network/netmask range.

Also, if ping is enabled to whatever the destinations are, see if from the Jetson you can ping those addresses. If you can, see what traceroute does to each address (from the Jetson).

The eth0 is for the ethernet port with the Lidar plugged in.
The wlan0 address is for the Wifi on the TX1
I don’t know what the default route does. The lo link seems to be linked to wlan0.
The LIDAR IP address is and this was set with the URGBENRI tool.
The LIDAR works when I link it to my laptop with an IP address of
(Note that the Lidar IP address ends in a 10 and the laptop address ends in a 15)

I need to visualize what hardware is connected where…

It seems from the above LIDAR is on wired ethernet to the Jetson. Given the above IP addresses, the laptop must also be on the wired ethernet…is this correct? The 192.168.1.x addresses can only be served by the wired ethernet (due to the network/netmask combinations above).

If the above is correct, what is wifi used with? If the above is incorrect, which devices are using wired versus wifi?

The LIDAR is connected via wired ethernet to the TX1. The Laptop is not on the wired ethernet. I merely checked the LIDAR on my laptop to see if it worked. Right now it is just the TX1, the built in wifi on the TX1 and the wired ethernet LIDAR.
Wifi is used to run the jetson with ROS.

What is the address the laptop attempts to reach the Jetson at over wifi (I am assuming laptop initiates connection to Jetson, rather than Jetson initiating contact with laptop)?

If the address the laptop tries to reach is in the network/netmask range of, then wifi (wlan0) will succeed.

If the address is in the range of 192.168.1.x/, then wired ethernet would succeed and wifi would fail (eth0 handles this, so wlan0 won’t get a chance to see it).

If the address the laptop uses is outside of both of those ranges, then success would depend on a router upstream in the default route (if is an upstream router then this router would forward…the default route only sees traffic if no other interface qualified).

Note that if the laptop initiates connection, and if the address is not within the laptop’s network/netmask, then success or failure would depend on the router used with the laptop being configured to find the address.

I think you are mistaken about what role the laptop plays here. The laptop has nothing to do with the problem I posted. The reason I mentioned the laptop was to say that there is nothing wrong with the LIDAR. The Jetson and the Laptop do not communicate. The Jetson communicates with the LIDAR. ( I almost regret mentioning the laptop because of the confusion it created.)

I guess the question then is which devices or programs use the wifi? When wifi is used, does the network connection originate from the Jetson or from outside the Jetson? What program or device is involved at each end of the wifi when wifi is used? Is ethernet used simultaneously, and is LIDAR the only thing dependent upon wired ethernet? In every case (regardless of wifi or ethernet). what address is a software or device trying to reach?