wanda
-
Posts
13 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by wanda
-
-
Just stumbled across something inconsistent after replacing iptables with nftables (the default on debian buster 10):
A check with lynis gave me a warning about the "leftover" iptables package:
-[ Lynis 2.7.5 Results ]- Warnings (2): ---------------------------- [...] ! iptables module(s) loaded, but no rules active [FIRE-4512] https://cisofy.com/lynis/controls/FIRE-4512/Is this dependency necessary?
aptitude purge iptables The following packages will be REMOVED: iptables{p} 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 1.444 kB will be freed. The following packages have unmet dependencies: armbian-config : Depends: iptables but it is not going to be installed The following actions will resolve these dependencies: Remove the following packages: 1) armbian-config [5.90 (buster, now)] -
17 hours ago, Igor said:
Possible.
In the meantime I found a workaround by inserting
cat /etc/rc.local [...] systemctl restart nftables exit 0Anyway, my first idea of a missing driver, is probably not correct:
It doesn't explain the correct working restart of nftables.service, when the system is up.
Regarding to your approach:
raspian and cubox is different hardware, so will the comparison really be helpfull?cubox lshw -c network *-network:0 DISABLED description: Ethernet interface physical id: 3 logical name: dummy0 serial: 92:c8:2f:98:51:2c capabilities: ethernet physical configuration: broadcast=yes driver=dummy driverversion=1.0 *-network:1 description: Wireless interface physical id: 4 logical name: wlan0 serial: 6c:ad:f8:1d:95:8b capabilities: ethernet physical wireless configuration: broadcast=yes driver=brcmfmac driverversion=5.90.125.104 firmware=5.90.125.104 multicast=yes wireless=IEEE 802.11 *-network:2 description: Ethernet interface physical id: 5 logical name: eth0 serial: d0:63:b4:00:c4:0f size: 1Gbit/s capacity: 1Gbit/s capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=fec driverversion=Revision: 1.0 duplex=full ip=nnn.nnn.nnn.nnn link=yes multicast=yes port=MII speed=1Gbit/sraspberry lshw -c network *-usb:0 description: Ethernet interface vendor: Standard Microsystems Corp. physical id: 1 bus info: usb@1:1.1.1 logical name: eth0 version: 3.00 serial: b8:27:eb:6c:7d:7d size: 1Gbit/s capacity: 1Gbit/s capabilities: usb-2.10 ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=lan78xx duplex=full ip=nnn.nnn.nnn.nnn link=yes maxpower=2mA multicast=yes port=MII speed=1Gbit/s *-network description: Wireless interface physical id: 2 logical name: wlan0 serial: b8:27:eb:39:28:28 capabilities: ethernet physical wireless configuration: broadcast=yes driver=brcmfmac driverversion=7.45.154 firmware=01-4fbe0b04 multicast=yes wireless=IEEE 802.11Anyway I compared the netfilter section as you suggested:
raspian config.gz exists aftersudo modprobe configs
diff -y -W 200 --suppress-common-lines raspian_nf cubox_nf # CONFIG_NF_LOG_NETDEV is not set | CONFIG_NF_LOG_NETDEV=m > CONFIG_NF_CONNTRACK_SECMARK=y # CONFIG_NF_CONNTRACK_TIMEOUT is not set | CONFIG_NF_CONNTRACK_TIMEOUT=y CONFIG_NF_CT_PROTO_GRE=m | CONFIG_NF_CT_PROTO_GRE=y > CONFIG_NF_CT_NETLINK_TIMEOUT=m CONFIG_NF_NAT_PROTO_DCCP=y < CONFIG_NF_NAT_PROTO_UDPLITE=y < CONFIG_NF_NAT_PROTO_SCTP=y < > CONFIG_NF_NAT_MASQUERADE=y > CONFIG_NETFILTER_SYNPROXY=m > CONFIG_NFT_XFRM=m CONFIG_NF_DUP_NETDEV=m | # CONFIG_NF_DUP_NETDEV is not set CONFIG_NFT_DUP_NETDEV=m | # CONFIG_NFT_DUP_NETDEV is not set CONFIG_NFT_FWD_NETDEV=m | # CONFIG_NFT_FWD_NETDEV is not set > CONFIG_NETFILTER_XT_TARGET_AUDIT=m > CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m > CONFIG_NETFILTER_XT_TARGET_SECMARK=m # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set | CONFIG_NETFILTER_XT_MATCH_CGROUP=m # CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set | CONFIG_NETFILTER_XT_MATCH_IPCOMP=m # CONFIG_IP_SET_HASH_IPMARK is not set | CONFIG_IP_SET_HASH_IPMARK=m # CONFIG_IP_SET_HASH_IPMAC is not set | CONFIG_IP_SET_HASH_IPMAC=m # CONFIG_IP_SET_HASH_MAC is not set | CONFIG_IP_SET_HASH_MAC=m # CONFIG_IP_SET_HASH_NETPORTNET is not set | CONFIG_IP_SET_HASH_NETPORTNET=m # CONFIG_IP_SET_HASH_NETNET is not set | CONFIG_IP_SET_HASH_NETNET=m # CONFIG_IP_VS_IPV6 is not set | CONFIG_IP_VS_IPV6=yTo be honest, I have no idea of all that options.
-
Armbianmonitor:
I just switched from iptables to netfilter.
After a reboot I get this kind of status for the service
systemctl status nftables ● nftables.service - nftables Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2019-07-12 16:04:59 CEST; 4min 28s ago Docs: man:nft(8) http://wiki.nftables.org Process: 287 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=3) Main PID: 287 (code=exited, status=3) Jul 12 16:04:59 cubox nft[287]: netlink.c:62: Unable to initialize Netlink socket: Protocol not supported Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. +++++++++++++++++++++++++++++++++++++ nftables installed ? +++++++++++++++++++++++++++++++++++++ p libnftables-dev - Development files for libnftables i A libnftables0 - Netfilter nftables high level userspace API library i nftables - Program to control packet filtering rules by Netfilter project +++++++++++++++++++++++++++++++++++++ update alternatives setup +++++++++++++++++++++++++++++++++++++ ip6tables auto /usr/sbin/ip6tables-nft iptables auto /usr/sbin/iptables-nftAnyway, a manual restart of the service works and the rules in /etc/nftables.conf are load properly.
I suppose there is a problem with a kernel module?
Doing the same upgrade on raspberries worked :
Linux bowerick 4.19.50-v7+ #896 SMP Thu Jun 20 16:11:44 BST 2019 armv7l GNU/Linux No LSB modules are available. Distributor ID: Raspbian Description: Raspbian GNU/Linux 10 (buster) Release: 10 Codename: buster -
I just stumbled across
usr/src/linux-headers-4.19.20-cubox$ make scripts scripts/kconfig/conf --syncconfig Kconfig net/Kconfig:89: can't open file "net/wireguard/Kconfig" scripts/kconfig/Makefile:69: recipe for target 'syncconfig' failed make[2]: *** [syncconfig] Error 1 Makefile:539: recipe for target 'syncconfig' failed make[1]: *** [syncconfig] Error 2 Makefile:635: recipe for target 'include/config/auto.conf' failed make: *** [include/config/auto.conf] Error 2Workaround was to comment this source-statement
grep -i wireg net/Kconfig source "net/wireguard/Kconfig" -
I just checked, I reinstalled armbian-firmware yesterday to be sure.
One idea: could I switch from armbian kernel to regular debian kernel and firmware for a test ?
-
1 minute ago, Igor said:
Which functiAonality are you missing?A correct status of systemd.
-
5 hours ago, Igor said:
Probably path in the kernel source is pointing elsewhere, to /etc/lib/firmware perhaps?In any case its safe to ignore.
Ok, I don't use a self-compiled kernel.
I am not sure if this helps to find the answer: I performed a
/usr/src/linux-headers-4.14.70-cubox# grep -ir "lib/firmware" * drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: /usr/lib/hotplug/firmware or /lib/firmware (depending on drivers/media/pci/ttpci/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/usb/ttusb-dec/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/gpu/drm/Kconfig: /lib/firmware directory or one of the provided built-in drivers/mmc/host/Kconfig: and put them in /lib/firmware. Note that without these additional drivers/net/wireless/intersil/p54/Kconfig: file is put at the right place. (usually /lib/firmware.) drivers/net/wireless/rtl8189es/Makefile:#EXTRA_CFLAGS += -DREALTEK_CONFIG_PATH=\"/lib/firmware/\" drivers/net/wireless/intel/iwlegacy/Kconfig: The microcode is typically installed in /lib/firmware. You can drivers/net/wireless/intel/iwlegacy/Kconfig: The microcode is typically installed in /lib/firmware. You can drivers/net/wireless/intel/ipw2x00/Kconfig: will need to place it in /lib/firmware. drivers/net/wireless/intel/iwlwifi/Kconfig: The firmware is typically installed in /lib/firmware. You can drivers/net/wireless/rtl8812au/Makefile:#EXTRA_CFLAGS += -DREALTEK_CONFIG_PATH=\"/lib/firmware/\" drivers/net/wireless/realtek/rtl8189fs/Makefile:#EXTRA_CFLAGS += -DREALTEK_CONFIG_PATH=\"/lib/firmware/\" drivers/net/wireless/rtl8188eu/Makefile: cp rtl8188eufw.bin /lib/firmware/. drivers/net/wireless/rtl8188eu/Makefile: mkdir -p /lib/firmware/rtlwifi drivers/net/wireless/rtl8188eu/Makefile: cp rtl8188eufw.bin /lib/firmware/rtlwifi/. drivers/net/wireless/rtl8814au/Makefile:#EXTRA_CFLAGS += -DREALTEK_CONFIG_PATH=\"/lib/firmware/\" drivers/base/Kconfig.orig: /lib/firmware/ on your system, so they can be loaded by userspace drivers/base/Kconfig.orig: default "/lib/firmware" drivers/base/Kconfig: /lib/firmware/ on your system, so they can be loaded by userspace drivers/base/Kconfig: default "/lib/firmware" drivers/remoteproc/Kconfig: loaded on the DSP. This file must reside in the /lib/firmware scripts/get_dvb_firmware:Now copy it(them) to either /usr/lib/hotplug/firmware or /lib/firmware scripts/extract_xc3028.pl:# cp xc3028-v24.fw /lib/firmware scripts/extract_xc3028.pl:# cp xc3028-v27.fw /lib/firmware sound/isa/Kconfig: files into the /lib/firmware directory.and I suppose this is the important part, or not ?
drivers/base/Kconfig: /lib/firmware/ on your system, so they can be loaded by userspace drivers/base/Kconfig: default "/lib/firmware"If yes, the path is correct, but the module is really missing:
tree /lib/firmware/sdma/ /lib/firmware/sdma/ ├── sdma-imx25-to1.bin ├── sdma-imx31-to1.bin ├── sdma-imx31-to2.bin ├── sdma-imx35-to1.bin ├── sdma-imx35-to2.bin ├── sdma-imx51-to3.bin └── sdma-imx53-to1.binIs there any way to get it ?
-
while checking the state of systemd I encountered
systemctl is-system-running degradedwith
systemctl --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION ● systemd-modules-load.service loaded failed failed Load Kernel Modulesand
in /var/log/messages
Nov 21 12:52:54 localhost kernel: imx-sdma 20ec000.sdma: Direct firmware load for imx/sdma/sdma-imx6q.bin failed with error -2Is there a module missing:
dpkg -L armbian-firmware | grep sdma /lib/firmware/imx/sdma /lib/firmware/imx/sdma/sdma-imx6q.bin /lib/firmware/sdma /lib/firmware/sdma/sdma-imx25-to1.bin /lib/firmware/sdma/sdma-imx31-to1.bin /lib/firmware/sdma/sdma-imx31-to2.bin /lib/firmware/sdma/sdma-imx35-to1.bin /lib/firmware/sdma/sdma-imx35-to2.bin /lib/firmware/sdma/sdma-imx51-to3.bin /lib/firmware/sdma/sdma-imx53-to1.binAny idea how I can fix it ?
armbianmonitor output -
I just updated cubox-i and udoo as well to 4.4.71-* .
Unfortunately no change armbian on udoo finds the usb-dac, on cubox it doesn't .
Well, last year I already changed the cubox-i device due to a similar "failure".
At that time I didn't run armbian but volumio and first for test purposes I switched to armbian.
The new cubox worked by now and the dealer informed me later that even the complained first device seemed not broken from his point of view and asked me to check my environment.
He tested just the usb-connectivity with a keyboard/mouse.But now I experience in the same way those problems again with the new cubox, i.e only with the cubox .
I also tested with a laptop and debian stretch installed without any problems. So, an environment problem is very unlikely.
Is it easy to switch to the legacy kernel or do I have to reinstall completely ?
-
but the udoo machine loads the driver after turning off/on of the dac:
May 28 14:21:12 localhost kernel: usb 1-1.1: new high-speed USB device number 4 using ci_hdrc May 28 14:21:12 localhost kernel: input: McIntosh Laboratory McIntosh Labs USB Audio as /devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.1/1-1.1:1.2/0003:2349:03E8.0001/input/input0 May 28 14:21:12 localhost kernel: hid-generic 0003:2349:03E8.0001: input: USB HID v11.01 Device [McIntosh Laboratory McIntosh Labs USB Audio] on usb-ci_hdrc.1-1.1/input2 May 28 14:21:12 localhost kernel: usbcore: registered new interface driver snd-usb-audioSo, this works.
But turning on/off or unplugging/plugging the dac to the cubox doesn't help.
-
after a few reboots I got the same result (no dac deteted) on th udoo-board as well ;-) .
So, it isn't any hardware that cause the problem.
-
Hi,
I run ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 4.9.12-cubox
and use an external DAC connected to USB.
Additionally and or comparison purposes I use ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 4.4.51-udoo .
Since a few days the kernel on the cubox doesn't seem to recognize the USB-DACs as sound device any more.
So, "aplay -l" doesn't list it:
aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SPDIF [Integrated SPDIF], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
A test with a udoo-board, shows the expected output:aplay -l **** List of PLAYBACK Hardware Devices **** card 0: imxvt1613audio [imx-vt1613-audio], device 0: AC97-analog vt1613-hifi-analog-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxhdmisoc [imx-hdmi-soc], device 0: i.MX HDMI Audio Tx hdmi-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Audio [McIntosh Labs USB Audio], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0
On the Cubox I find in "messages" following output with disconnections :
May 27 10:57:15 localhost kernel: input: McIntosh Laboratory McIntosh Labs USB Audio as /devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.2/0003:2349:03E8.0002/input/input3 May 27 10:57:15 localhost kernel: hid-generic 0003:2349:03E8.0002: input,hidraw0: USB HID v11.01 Device [McIntosh Laboratory McIntosh Labs USB Audio] on usb-ci_hdrc.1-1/input2 May 27 10:57:15 localhost kernel: usb 2-1: USB disconnect, device number 3 May 27 10:57:15 localhost kernel: usb 2-1: new high-speed USB device number 4 using ci_hdrc May 27 10:57:15 localhost kernel: input: McIntosh Laboratory McIntosh Labs USB Audio as /devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.2/0003:2349:03E8.0003/input/input4 May 27 10:57:15 localhost kernel: hid-generic 0003:2349:03E8.0003: input,hidraw0: USB HID v11.01 Device [McIntosh Laboratory McIntosh Labs USB Audio] on usb-ci_hdrc.1-1/input2 May 27 10:57:15 localhost kernel: usb 2-1: USB disconnect, device number 4 May 27 10:57:15 localhost kernel: usb 2-1: new high-speed USB device number 5 using ci_hdrc May 27 10:57:15 localhost kernel: input: McIntosh Laboratory McIntosh Labs USB Audio as /devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.2/0003:2349:03E8.0004/input/input5 May 27 10:57:15 localhost kernel: hid-generic 0003:2349:03E8.0004: input,hidraw0: USB HID v11.01 Device [McIntosh Laboratory McIntosh Labs USB Audio] on usb-ci_hdrc.1-1/input2 May 27 10:57:15 localhost kernel: usb 2-1: USB disconnect, device number 5 [...]
I also checked it with a different DAC to exclude problems with the DAC itself:May 27 12:49:44 localhost kernel: input: Lake People electronic GmbH VIO USB 2.0 as /devices/soc0/soc/2100000.aips-bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-1:1.0/0003:1852:5120.0005/input/input6 May 27 12:49:44 localhost kernel: hid-generic 0003:1852:5120.0005: input,hidraw0: USB HID v1.00 Device [Lake People electronic GmbH VIO USB 2.0] on usb-ci_hdrc.0-1/input0 May 27 12:49:44 localhost kernel: usb 1-1: USB disconnect, device number 6 May 27 12:49:44 localhost kernel: usb 1-1: new high-speed USB device number 7 using ci_hdrc May 27 12:49:44 localhost kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready May 27 12:49:44 localhost kernel: input: Lake People electronic GmbH VIO USB 2.0 as /devices/soc0/soc/2100000.aips-bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-1:1.0/0003:1852:5120.0006/input/input7 May 27 12:49:44 localhost kernel: hid-generic 0003:1852:5120.0006: input,hidraw0: USB HID v1.00 Device [Lake People electronic GmbH VIO USB 2.0] on usb-ci_hdrc.0-1/input0 May 27 12:49:44 localhost kernel: usb 1-1: USB disconnect, device number 7 May 27 12:49:44 localhost kernel: usb 1-1: new high-speed USB device number 8 using ci_hdrc May 27 12:49:44 localhost kernel: input: Lake People electronic GmbH VIO USB 2.0 as /devices/soc0/soc/2100000.aips-bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-1:1.0/0003:1852:5120.0007/input/input8 May 27 12:49:44 localhost kernel: hid-generic 0003:1852:5120.0007: input,hidraw0: USB HID v1.00 Device [Lake People electronic GmbH VIO USB 2.0] on usb-ci_hdrc.0-1/input0 [...] May 27 12:50:01 localhost kernel: usb 1-1: new high-speed USB device number 74 using ci_hdrc May 27 12:50:01 localhost kernel: input: Lake People electronic GmbH VIO USB 2.0 as /devices/soc0/soc/2100000.aips-bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-1:1.0/0003:1852:5120.0049/input/input74 May 27 12:50:01 localhost kernel: hid-generic 0003:1852:5120.0049: input,hidraw0: USB HID v1.00 Device [Lake People electronic GmbH VIO USB 2.0] on usb-ci_hdrc.0-1/input0 May 27 12:50:01 localhost kernel: usb 1-1: USB disconnect, device number 74
Ont the udoo board that looks straight forward without disconnections:May 27 13:06:06 localhost kernel: sensor-SUPPLY: disabling May 27 13:06:06 localhost kernel: 2P8V: disabling May 27 13:06:06 localhost kernel: ALSA device list: May 27 13:06:06 localhost kernel: #0: imx-vt1613-audio May 27 13:06:06 localhost kernel: #1: imx-hdmi-soc May 27 13:06:06 localhost kernel: Freeing unused kernel memory: 368K (80a1e000 - 80a7a000) May 27 13:06:06 localhost kernel: random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available) May 27 13:06:06 localhost kernel: usb 1-1.1: new high-speed USB device number 3 using ci_hdrc May 27 13:06:06 localhost kernel: input: McIntosh Laboratory McIntosh Labs USB Audio as /devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.1/1-1.1:1.2/0003:2349:03E8.0001/input/input0 May 27 13:06:06 localhost kernel: hid-generic 0003:2349:03E8.0001: input: USB HID v11.01 Device [McIntosh Laboratory McIntosh Labs USB Audio] on usb-ci_hdrc.1-1.1/input2 May 27 13:06:06 localhost kernel: usb 1-1.2: new high-speed USB device number 4 using ci_hdrc May 27 13:06:06 localhost kernel: usb 1-1.3: new high-speed USB device number 5 using ci_hdrcAny hint what could be the problem on the cubox ?
Thank you !
cubox-i;buster;nftables.services doesn't start after reboot
in Other families
Posted
Hi, thanks for the hint. To be honest I don't get the content of the link, I mean referring to my question about the package dependency armbian-config and iptables.
nft list ruleset (without any f2b-entry) is fine, it will be created with the first ban action.