Jump to content

Orangepi R1 - odd dummy interface.


Shoka

Recommended Posts

I have a small group of Orangepi R2's that I'm setting up as remote snort monitors.

 

It's my first experience with Armbian, and Orangepi and I'm very impressed.

 

I have an odd issue that is puzzling, not of practical importance to what I'm doing,  but annoying none the less.

 

The set up I'm running is based on the main Armbian buster "Armbian_20.02.0-rc1_Orangepi-r1_buster_current_5.4.14.

 

Linux probe1 5.4.14-sunxi #rc1 SMP Sat Jan 25 15:19:01 CET 2020 armv7l GNU/Linux

 

I've substantially modified that to use systemd-networkd, systemd-resolved and systemd-timesyncd.

 

My issue is that I have a dummy interface appearing. I'm not clear where from.

 

I've used dummy interfaces on previous devices I've configured, so conceivably I've unwittingly used a config fragment from the Raspbian configs I use on my Raspberry Pi's, but if I have, I've not found it.

netadmin@probe1:/proc$ networkctl
IDX LINK             TYPE               OPERATIONAL SETUP     
  1 lo               loopback           carrier     unmanaged 
  2 dummy0           ether              off         unmanaged 
  3 eth0             ether              routable    configured
  4 eth1             ether              no-carrier  configuring
  6 wlan0            wlan               routable    unmanaged 

5 links listed.
netadmin@probe1:/proc$ networkctl status dummy0
● 2: dummy0
       Link File: n/a
    Network File: n/a
            Type: ether
           State: off (unmanaged)
          Driver: dummy
      HW Address: 32:eb:0b:5a:7d:c9
netadmin@probe1:/proc$ 

It has a MAC address associated ... 

 

netadmin@probe1:/proc/self/net$ lsmod | grep dummy


 

 

I'm running NetworkManager managing the wifi interface only. 

 

verbosity=1
logo=disabled
console=serial
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=usbhost2 usbhost3
rootdev=UUID=517456d9-9b61-4087-a1d3-087b2b583f20
rootfstype=ext4
extraargs=net.ifnames=0 ipv6.disable=1
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

I cannot find any stray netdev files...

 

root@probe1:/etc/sysctl.d# locate .netdev
/usr/share/man/man5/systemd.netdev.5.gz
root@probe1:/etc/sysctl.d# 

 

I'm very puzzled. Anybody got any other suggestions as to where this is coming from??

 

 

Harry

 

 

 

 

Link to comment
Share on other sites

Looks like it's included by default, compiled in, not a module.

Presumably because some users will be using SLIP connections?

I understand that the kernel impact of compiling the module in is zero.

 

Marginally irritating, I have one box with a config with two dummies. On a Raspbian box though, where dummy is a module.

I guess I'm going to have to re-learn how to compile my own kernel.... 

 

from config-5.4.20-sunxi 

 

CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=y <<<<<<<<<<< compiled in, not modular. 
# CONFIG_EQUALIZER is not set
CONFIG_IFB=m
# CONFIG_NET_TEAM is not set

 

From Kconfig...

 

config DUMMY

tristate "Dummy net driver support"

---help---

This is essentially a bit-bucket device (i.e. traffic you send to

this device is consigned into oblivion) with a configurable IP

address. It is most commonly used in order to make your currently

inactive SLIP address seem like a real address for local programs.

If you use SLIP or PPP, you might want to say Y here. Since this

thing often comes in handy, the default is Y. It won't enlarge your

kernel either. What a deal. Read about it in the Network

Administrator's Guide, available from

<http://www.tldp.org/docs.html#guide>.

To compile this driver as a module, choose M here: the module

will be called dummy. If you want to use more than one dummy

device at a time, you need to compile this driver as a module.

Instead of 'dummy', the devices will then be called 'dummy0',

'dummy1' etc.

Link to comment
Share on other sites

I'm not inclined to use docker, nor vagrant, and I don't have access to a Ubuntu system these days,  all the systems I have to hand are Linux Mint.

Linux Mint tricia is a derivative of Ubuntu 18.04, the supported build host.

 

So I'm being a naughty boy and trying to set up a build environment on an existing Mint system.

I'm not expecting support from here on setting this up, but a few of the hurdles I've overcome may reflect bugs/missing documentation in the supported build system.

 

The setup failed initially for the test for supported systems. Fixed that, not of interest here.

 

It failed for lack of ccache, again for lack of aria2 and again for lack of libusb-1.0.

 

I've tried to  determine if those would be installed in a new Ubuntu installation, but I don't seem to be able to locate the package manifest for 18.04.

 

So if someone can check if they are default installed, I'll forget about it, but if they are missing from a default Ubuntu install, I'll look at documenting the need for them.

 

Harry

Link to comment
Share on other sites

I know I'm not supposed to pester with issues on non supported build platforms.

This is probably due to my choice of build platform, but in case it's not:

 

 

build is quitting with this log....

 

scripts/dtc/pylibfdt/Makefile:27: recipe for target 'scripts/dtc/pylibfdt/_libfdt.so' failed
scripts/Makefile.build:432: recipe for target 'scripts/dtc/pylibfdt' failed
scripts/Makefile.build:432: recipe for target 'scripts/dtc' failed
Makefile:528: recipe for target 'scripts' failed
[ error ] ERROR in function compile_uboot [ compilation.sh:204 ]
[ error ] U-boot compilation failed 
[ o.k. ] Process terminated 
 

 

That first make fail seems to occur in here:

 

 13 PYLIBFDT_srcs = $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_SRCS)) \
 14                 $(obj)/libfdt.i
 15 
 16 quiet_cmd_pymod = PYMOD   $@
 17       cmd_pymod = unset CROSS_COMPILE; unset CFLAGS; \
 18                 CC="$(HOSTCC)" LDSHARED="$(HOSTCC) -shared " \
 19                 LDFLAGS="$(HOSTLDFLAGS)" \
 20                 VERSION="u-boot-$(UBOOTVERSION)" \
 21                 CPPFLAGS="$(HOSTCFLAGS) -I$(LIBFDT_srcdir)" OBJDIR=$(obj) \
 22                 SOURCES="$(PYLIBFDT_srcs)" \
 23                 SWIG_OPTS="-I$(LIBFDT_srcdir) -I$(LIBFDT_srcdir)/.." \
 24                 $(PYTHON2) $< --quiet build_ext --inplace
 25 
 26 $(obj)/_libfdt.so: $(src)/setup.py $(PYLIBFDT_srcs) FORCE
 27         $(call if_changed,pymod)
 28 
 29 always += _libfdt.so
 30 
 31 clean-files += libfdt.i _libfdt.so libfdt.py libfdt_wrap.c

 

 

 

I suspect something amiss with the python config on my build host, but python is definitely not my strong suit.

 

Anybody suggest tests to verify the python config?

 

Harry
  
 

 

 

 

Link to comment
Share on other sites

Suggested changes to general.sh

 

 

 796         export LC_ALL="en_US.UTF-8"
    797 
    798         # packages list for host
    799         # NOTE: please sync any changes here with the Dockerfile and Vagrantfile
    800         local hostdeps="wget ca-certificates device-tree-compiler pv bc lzop zip binfmt-support build-essential ccache debootstrap ntpdate \
    801         gawk gcc-arm-linux-gnueabihf qemu-user-static u-boot-tools uuid-dev zlib1g-dev unzip libusb-1.0-0-dev fakeroot \
    802         parted pkg-config libncurses5-dev whiptail debian-keyring debian-archive-keyring f2fs-tools libfile-fcntllock-perl rsync libssl-dev \
    803         nfs-kernel-server btrfs-progs ncurses-term p7zip-full kmod dosfstools libc6-dev-armhf-cross \
    804         curl patchutils liblz4-tool libpython2.7-dev linux-base swig aptly acl python3-dev \
    805         locales ncurses-base pixz dialog systemd-container udev lib32stdc++6 libc6-i386 lib32ncurses5 lib32tinfo5 \
    806         bison libbison-dev flex libfl-dev cryptsetup gpgv1 gnupg1 cpio aria2 pigz dirmngr python3-distutils \
    807         ccache aria2 libusb-1.0-0-dev"
    808 
    809         local codename=$(lsb_release -sc)
    810 

When I get my build environment working, and can adequately test, I'll submit this as a pull request.  Harry

Link to comment
Share on other sites

1 minute ago, Shoka said:

More missing packages. Getting further now I have swig and python-dev installed.

 Still failing though.

Harry


You understand now why we choose to stick to one host OS? :P You will eventually find the right combination, but after a few months something critically will be changed ... we will only fix it for actual Ubuntu version. Or Debian if we choose to move the base there.

Link to comment
Share on other sites

I understand the development teams position entirely. I'm only reporting the issues I've come up against, because they are rooted in required packages that are not identified in the existing install set up. I've put in a pull request to add the first three omissions to the hostdeps list, since even the supported host configuration is also vulnerable to upstream changes to the set of standard packages.

 I'll put in requests to add these two as well as any more I find.  So far none of the issues I've found are inherent in the choice of host,  I suspect I would have has similar issues with a fresh Ubuntu install. Possibly not if those packages are installed by default in that release of Ubuntu, but it's dangerous to rely on that.

Link to comment
Share on other sites

Built a kernel finally. :) :) :) . Not tested it yet, but it built with no errors.

 

The final total of packages missing from the build was:

ccache

aria2

libusb-1.0-0-dev

 

Already generated a  pull request to add them

AND

 

swig

python-dev

libncurses-dev

libstb-dev (not absolutely certain this is required, but I strongly suspect it is)

lzma

pixz

u-boot-tools

 

Will add an additional pull request to add those additional seven packages to the required list.

 

Harry

 

Edited by Shoka
Added note that I'm not 100% listd-dev is required, it may have come in automatically with u-boot-tools
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines