Jump to content

bonienl

Community Developer
  • Content Count

    7932
  • Joined

  • Last visited

  • Days Won

    47

Everything posted by bonienl

  1. Two main reasons why routers drop packets 1. Bad connection/cabling. Ensure all cables are properly seated and/or replace cables 2. Router overload. Too much traffic for the router to handle Check if your routers provide any statistics about interfaces Here is an example from my router eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 18:e8:29:bd:80:c7 brd ff:ff:ff:ff:ff:ff inet 10.0.101.1/24 brd 10.0.101.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::1ae8:29ff:febd:80c7/64 scope link valid_lft forever preferred_lft forever Description: LAN RX: bytes packets errors dropped overrun mcast 1569109171 11965971 0 337 0 368921 TX: bytes packets errors dropped carrier collisions 27131680121 20486430 0 0 0 0
  2. Why did you configure bonding with LACP while only eth0 is up (eth1 is down)? LACP requires compatible switch support. Does your switch support LACP? Remove bonding and test with a single interface. Your snippet shows the normal sequence when starting docker containers, nothing unusual.
  3. When both clients are in the same network, e.g. 192.168.1.X then they will talke directly to each other via the switch. The router only gets involved if the clients are each in a different network.
  4. This is addressed in version 6.8. Passphrases are no longer stored in a keyfile.
  5. Highly unlikely your system crashes, and the diagnostics seem to confirm that. 1. What exactly did you configure as WireGuard settings? 2. There is something going on with Docker and its virtual interface is going up and down. You can try to test with the Docker service stopped
  6. The file "domain.cfg" has corrupted data. Open the file in a text editor and remove the offending part
  7. I have multiple Pi-hole containers running, one for each dedicated network I have at home. One such dedicated network is for mobile devices.
  8. I made another update, version 2019.11.12c
  9. Yes, you are right. The import parser went wrong on the comment statement(s). I have made an update with the fix. Thanks.
  10. Your network settings show a bonded interface with 4 members and using LACP. This mode requires a switch which supports LACP too. Did you configure your switch properly (assuming it supports LACP)?
  11. /usr/local/sbin/emhttp Is used to start the array and other relevant services. Make this the last command in your go file
  12. The objective is to keep customizations as much as possible. Ideally all, but sometimes this is not possible due to various reasons. You can open a report with details which settings (you XML file) get lost and we can look into how to preserve them, if possible.
  13. You can raise the "network idle threshold" and enter the IP address of your PC under "wait for device inactivity". As long as your PC is online, the server will not go to sleep.
  14. The config files look alright, but in your screenshots there are missing mandatory fields. Did you remove those fields or they are not populated after importing the config file? What happens when all fields are filled in (see also my screenshot)?
  15. There is always hardware error checking done by the hard disks to ensure correct reading and writing from/to disk
  16. I miss a couple of mandatory fields. These should be present in the config file generated by TorGuard Local private key - generated by TorGuard Peer public key - generated by TorGuard Peer endpoint - this is the URL of the TorGuard VPN access Peer allowed IPs - this should be 0.0.0.0/0 Here is a screenshot of my VPN connection
  17. I made an update, please try again.
  18. Disable UPnP, see advanced settings.
  19. Your diagnostics show that the interface is not connected. Settings for eth0: Supported ports: [ TP AUI BNC MII FIBRE ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: no Usually this is a cable problem.
  20. Did you create a new (WG1) tunnel for this connection? In other words do not add this as another peer to an existing tunnel (WG0) Set all other tunnels inactive when using VPN tunneled access
  21. This is not a bug, but as designed. Please make a feature request if you have a more suitable solution
  22. Remove the "ListenPort" in the TorGuard config, it is not needed/used because the peer will always initiate the connection.