Jump to content

drscheme

Members
  • Posts

    22
  • Joined

  • Last visited

  1. Thank you Igor. I try the nightly builds tomorrow and post an update. Thanks!
  2. Hi, I run a wireguard server in my home. I have a Mac and a couple of iOS devices that can successfully connect to the server, my internet traffic is routed via the home wireguard server and I can access devices in my home network using an address like 192.168.178.200. No problem. Now I want to connect my cubitruck running Armbian Ubuntu 18.04 to my home network. I created a similar configuration as for all of the other devices, wireguard connects after I say `wg-quick up $configname`, with `ip a` I can see a new interface with an IP that corresponds to my configuration, there is a route set (Dst 10.9.0.0 -> Iface $configuration_wg0) BUT when I try to ping the IP of the WG server (in my case 10.9.0.1): no response when I try to ping a device in the home network (192.168.178.*): no response when I try to access the Internet: nope. Interestingly, on server side, when I say `wg show`, I notice that there is no sign that the client is/was connected. Here's my client conf: [Interface] PrivateKey = xx Address = 10.9.0.7/24 DNS = 1.1.1.1,1.0.0.1 [Peer] PublicKey = yy AllowedIPs = 0.0.0.0/0, ::/0 Endpoint = foo.bar.baz:10815 PersistentKeepalive = 25 And here the server.conf: [Interface] Address = 10.9.0.1/24 ListenPort = 10815 PrivateKey = aa SaveConfig = false # iphone [Peer] PublicKey = bb AllowedIPs = 10.9.0.4/32 # ipad [Peer] PublicKey = cc AllowedIPs = 10.9.0.5/32 # macpro [Peer] PublicKey = dd AllowedIPs = 10.9.0.6/32 # backuptruck [Peer] PublicKey = ee AllowedIPs = 10.9.0.7/32 I am actually pretty confident, that the configuration is correct. So I tested what happens when I run the same configuration on a Ubuntu notebook and here the configuration works. So my conclusion is that there might be something broken/incompatible/ with wireguard on Armbian.
  3. I am having a problem with my network settings. The machine has an internal NIC and a USB-WiFi stick. When the NIC is plugged in, both interfaces receive an IP via DHCP. When the NIC is unplugged, the WiFi stick does not receive an IP address. auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto wlan0 iface wlan0 inet dhcp wpa-ssid <name> wpa-psk <password> How can I solve this issue? Regards!
  4. Oh boy, ... I accidentally commented out the line that mounts /media/mmc/boot to /boot. So apt updated /boot on the harddrive (not on the mmc) and several other locations on the harddrive, like the modules directory. After the reboot, I still had the old kernel/settings but on the harddrive everything was updated to match the new kernel... That won't work, of cause. So I moved the new kernel and settings from /boot to /media/mmc/boot and everything is back to normal. Thanks for you help, Igor!
  5. I think I did not do anything 'extraordinary'. I installed the CubieTruck using your image and moved the system to a SATA harddrive using the script you provide some weeks ago. The last couple of days I only upgraded some packages and installed a new piece of software (some python wrappers for Spotify) from a non-standard repository. But I do not think that this is the reason for my problem... In my /boot directory I find the following files and directories: drwxr-xr-x 2 root root 4096 Okt 18 11:27 bin -rw-r--r-- 1 root root 115484 Okt 11 14:12 config-4.2.3-sunxi drwxr-xr-x 2 root root 12288 Okt 18 11:25 dtb drwxr-xr-x 2 root root 4096 Sep 30 21:21 dtb.old -rw-r--r-- 1 root root 1955569 Okt 11 14:12 System.map-4.2.3-sunxi -rwxr-xr-x 1 root root 5468416 Okt 11 14:12 vmlinuz-4.2.3-sunxi lrwxrwxrwx 1 root root 25 Okt 18 11:27 zImage -> /boot/vmlinuz-4.2.3-sunxi Oddly there's also files for the 4.2.3-kernel... The content of /media/mmc/boot/boot.cmd is the following: setenv bootargs console=tty1 root=/dev/sda1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1 #-------------------------------------------------------------------------------------------------------------------------------- # Boot loader script to boot with different boot methods for old and new kernel #-------------------------------------------------------------------------------------------------------------------------------- if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next then # sunxi mainline kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile} ext4load mmc 0 0x46000000 /boot/zImage || fatload mmc 0 0x46000000 zImage env set fdt_high ffffffff bootz 0x46000000 - 0x49000000 #-------------------------------------------------------------------------------------------------------------------------------- else # sunxi android kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x43000000 /boot/script.bin || fatload mmc 0 0x43000000 script.bin ext4load mmc 0 0x48000000 /boot/zImage || fatload mmc 0 0x48000000 zImage bootz 0x48000000 #-------------------------------------------------------------------------------------------------------------------------------- fi # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr # I did not modify any of these files manually. It seems like apt updated some parts of the system to 4.2.x kernel but did not install the kernel itself. Now I remember that the automatic updater sends error reports via mail since a couple of days: /etc/cron.daily/apt: Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 1016, in <module> main(options) File "/usr/bin/unattended-upgrade", line 798, in main allowed_origins=allowed_origins) File "/usr/bin/unattended-upgrade", line 75, in __init__ self.adjust_candidate_versions() File "/usr/bin/unattended-upgrade", line 92, in adjust_candidate_versions if is_allowed_origin(pkg.candidate, self.allowed_origins): File "/usr/bin/unattended-upgrade", line 364, in is_allowed_origin if match_whitelist_string(allowed, origin): File "/usr/bin/unattended-upgrade", line 272, in match_whitelist_string what, token)) __main__.UnknownMatcherError: Unknown whitelist entry for macher 'n' (token 'n=wheezy') Maybe that was the cause for this problem. But what caused apt to fail? Interestingly, manual updates work just fine.
  6. Unfortunately is is not so easy to solve I rebooted several times since that problem occurred...
  7. I am on Debian 7.9, kernel 4.1.6-sunxi. Since a couple of days I get an error message when I want to open a LUKS container (e.g. cryptsetup luksOpen ...). /dev/mapper/control: open failed: Kein passendes Gerät gefunden --> no device found Failure to communicate with kernel device-mapper driver. Check that device-mapper is available in the kernel. Kann die Gerätezuordnung nicht initialisieren. Ist das Kernelmodul dm_mod geladen? --> is dm_mod really loaded? I tried to manually load dm_mod and get another error message: > modprobe dm_modlibkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/4.1.6-sunxi/modules.dep.bin' This one is a little more helpful... When I navigate to /lib/modules/ I won't find the 4.1.6-sunxi directory but a 4.2.3-sunxi directory (which contains the missing file). This is a little odd, as I am on the 4.1.6 kernel, right...? So what is the correct way of solving this issue? I read that you might use depmod to recreate the missing structures in that missing directory but when I try to invoke depmod there is - of cause - another error: ERROR: could not open directory /lib/modules/4.1.6-sunxi: No such file or directory FATAL: could not search modules: No such file or directory I guess other people here came across this problem in the last couple of weeks as well (though I didn't find a post here) ... Any suggestions are welcome... Regards!
  8. This is something I found on another website when I googled how you reset the hardware clock of the board... You don't have to do this. Maybe this info is even wrong. I don't know... What you need to do: - put the wheezy image with kernel 4.something to the micro sd card - mount the card - edit the file /etc/init.d/armhwinfo - add: # fix for eth0 no brought up if [ "$(hwclock -r)" == "" ]; then echo -e "[\e[0;32m ok \x1B[0m] Fixing RTC and reloading eth0" date -s "2015-01-01 10:00:00" hwclock -w ifup eth0 fi This will fix the problem. The eth0 will be enabled and the ssh key generation succeeds.
  9. Have a look at this post: First run stuck with ssh key generation / Cubietruck RTC bug
  10. Ah, sorry... ... when you use Igor's patch: # fix for eth0 no brought up if [ "$(hwclock -r)" == "" ]; then echo -e "[\e[0;32m ok \x1B[0m] Fixing RTC and reloading eth0" date -s "2015-01-01 10:00:00" hwclock -w service networking restart fi
  11. I can confirm that this works for wheezy. The entire installation procedure succeeded on my cubietruck. Thank you!!
  12. So Vadim and me seem to have the same issue, right? But I have an old but running installation that boots from nand... What would happen when I perform the reset procedure Igor described above within the running installation, shut down and insert the sd card? PS: what does this actually do? hwclock -r --> read time from hardware date -s "2015-01-01 10:10:00" --> set OS system time hwclock -w --> set hardware clock to OS system time?
  13. Not so sure about the webmin. After playing with that one device was børked when I updated things... Creating a simple firewall setting is not that difficult. I like to start with this "everything that is not allowed is denied" setting: #!/bin/bash #reset iptables; drop all rules iptables -F iptables -X #allow loop iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # ALLOW DNS iptables -A INPUT -p udp --sport 53 -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -j ACCEPT # ALLOW ICMP iptables -A INPUT -p icmp -j ACCEPT iptables -A OUTPUT -p icmp -j ACCEPT <-- insert everything you want to allow --> # DROP rest iptables -A INPUT -j REJECT iptables -A OUTPUT -j REJECT The recipe to allow traffic to the device looks like that: # ALLOW incoming SSH from eth0 iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT This just says: - new packets or those belonging to a established session may pass the firewall from outside to inside. - packets related to an established session may exit the device The recipe that allows the device to access the network looks like that: # ALLOW outgoing HTTP/S connection establishment/session (important for apt-get update/upgrade) iptables -A OUTPUT -o eth0 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth0 -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth0 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT Again: - new packets or those related to a established session may exit the device - packets related to an established session may enter the device I know that is not perfect, but it works form me quite well.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines