Forums - Static ethernet IP address

5 posts / 0 new
Last post
Static ethernet IP address
era_1
Join Date: 24 Sep 20
Posts: 6
Posted: Thu, 2020-10-15 08:51

I am having trouble cofiguring the ethernet interface in the RB5 to have a static IP address for a point-to-point connection.

I started by adding the following two lines to /etc/dhcpcd.conf

interface eth0
static ip_address=10.0.0.1/24 
 
That seemed to correctly change the ip address for eth0, but the computer at the other end of the ethernet link remained unreachable. After a lot of troubleshooting, I discovered that the eth0 interface was linked to a bridge on the RB5. Removing the bridge with the two following shell commands fixed the point to point connection.
 
ifconfig bridge0 down
brctl delbr bridge0
 
But every time the device reboots, bridge0 is configured and enabled again, so I have to re-enter those two commands every time.

Is there a way to permanently remove the bridge0 configuration? It suspect it is managed by QCMAP_ConnectionManager, but I have not found any documentation or examples that might illustrate how to do this.

Or is there a cleaner way to configure the ethernet interface with a static IP address while keeping the wifi interface configured via DHCP?

  • Up0
  • Down0
mistry Moderator
Join Date: 18 Apr 18
Posts: 26
Posted: Fri, 2020-10-16 09:07

Hi Enrique,

Would it work to add those two commands to a startup script?

Removing bridge0 config might have side effects that we might not know. We will try to see if there is a cleaner way to do this.

Can you help us understand the usecase? how are you planning to use the Point to Point connection?

Best Regards,

Rajan.

  • Up0
  • Down0
era_1
Join Date: 24 Sep 20
Posts: 6
Posted: Mon, 2020-10-19 01:17

Yes, I could run those commands in a startup script. But I am also worried about possible side effects, since I have no idea why the system has a bridge configured in the first place.

The use case is to provide a maintenance/update service daemon running on the device and only accessible with phyisical access to the machine. It would actually be better to use a "virtual" ethernet port over USB for that, but I thought it would be simpler to start with the real ethernet port, to avoid potential interference with adbd, which also uses USB.

I will probably go with the brctl hack on startup for now, and try to transition to USB later on.

Thanks!

Enrique.

  • Up0
  • Down0
ss.pandiri
Join Date: 29 May 18
Posts: 2
Posted: Thu, 2020-10-22 03:51

Dear Enrique,

I checked on my RB5, there's no bridge0 cofigured by default. Its possible that its configured in /etc/network/interfaces file in your case. If so, you can remove it from there. Found information here helpful:

https://wiki.debian.org/BridgeNetworkConnections

Thanks,

Steven

  • Up0
  • Down0
era_1
Join Date: 24 Sep 20
Posts: 6
Posted: Tue, 2020-10-27 12:07

Thanks for the suggestion, Steven. But the RB5 seems to be doing network configuration in a very different way than Debian/Ubuntu. There is not even a `/etc/network/interfaces` file in my device.

I finally figured out that what was bringing up the bridge0 interface was the presence of the 'bridge-utils' Ubuntu package. This is not installed by default with the recent versions of the firmware, so you are right, the bridge is not configured by default.

I am not sure how I got `bridge-utils` installed in the first place. I suspect that it was installed by default in a previous release, and when it went away, after reflashing a more recent release, I started installing it explicitly as part of my setup process because my setup scripts depended on it to remove the bridge :). But maybe I  installed it unintentionally in the first place as a dependency of something else. Either way, it is not an issue any more.

Enrique.

 

  • Up1
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.