bonienl

Community Developer
  • Posts

    10232
  • Joined

  • Last visited

  • Days Won

    65

Report Comments posted by bonienl

  1. The included diagnostics are from 6.12.2 and for some unknown reason show an incomplete boot up sequence.

     

    The diagnostics are missing the driver for the ethernet controller and hence interfaces are not created. This results obviously in no IP address assignments.

     

    According to these diagnostics 6.12.2 doesn't have any interfaces at all, this contradicts your statement about reverting. It is impossible the system has connectivity

     

    Install version 6.12.3 and include diagnostics of this version.

     

    You are looking at a hardware or driver problem, not a bug.

     

  2. 6 hours ago, SpaceInvader said:

    After updating to 6.12.3 I thought I could enable IPv6 again, but after only a few minutes the webui crashed again.

     

    Can you disable the nginx proxy and test with a plain connection.

     

    Jul 16 01:28:17 NAS rc.docker: container Nginx-Proxy-Manager has an additional network that will be restored: none;

     

    There is also something wrong with your router and IPv6 assignment. You need to check router configuration.

     

    Jul 16 02:06:21 [1123]: br0: part of a Router Advertisement expired
    Jul 16 02:06:21 [1123]: route socket overflowed (rcvbuflen 106496) - learning interface state
    Jul 16 02:06:21 [1123]: drained 279 messages

     

  3. I see what is happening

    When you create a static IP address + gateway without explicitely setting a metric value, then a default route with metric 0 is created for br0. This is indeed wrongly displayed in the GUI as value 1 (a display error).

     

    When creating the interface shim-br0, another default route with metric 0 is added, but this fails because two times the same metric is not allowed and hence there is a missing default route for the shim-br0 interface as a result, and this causes communication loss to the outside world whenever the shim-interface is used.

     

    The solution is indeed to set a metric value other then zero for the br0 gateway when a static IP assignment is used and "host access" is enabled. Btw this is not Unraid 6.12 specific but is true for earlier versions too.

     

    Need to think of a way to make this clear to the user and avoid this situation.

     

    Thanks for all the testing.

     

    • Thanks 1
  4. Quote

    After reboot now I noticed two changes:

    1. br0 interface metric changed from 1 to 1006

    2. broadcast address for br0 changed from 0.0.0.0 to 192.168.x.255

     

    This information comes from your DHCP server

     

    macvlan / ipvlan setting is for docker, it doesn't change network settings.

     

    Quote

    For now I did not succeed to reproduce the incomplete arp,

     

    An incomplete ARP occurs when the target host (your router in this case) is no longer responding to arp requests from the server.

     

  5. 32 minutes ago, thecode said:

    What is the meaning of this parameter?

     

    It tells how many interfaces are present and need to be configured

    When this line is not present, it is assumed the network.cfg file holds a legacy configuration (pre V6) and it results in a basic network configuration without all the extras which is supported in V6 and later.

     

    When modifying the network settings using the GUI, it will automatically add the SYSNICS setting.

     

  6. The wireguard log shows a duplicate network address in your wg0 configuration and it doesn't look complete

     

    wg-quick up wg0 (autostart)
    [#] ip link add wg0 type wireguard
    [#] wg setconf wg0 /dev/fd/63
    [#] ip -4 address add 192.168.126.1 dev wg0
    [#] ip link set mtu 1420 up dev wg0
    [#] ip -4 route add 192.168.126.4/32 dev wg0
    [#] ip -4 route add 192.168.126.3/32 dev wg0
    [#] ip -4 route add 192.168.126.2/32 dev wg0
    [#] ip -4 route add 192.168.128.0/24 dev wg0
    RTNETLINK answers: File exists
    [#] ip link delete dev wg0

     

    Can you delete the wg0 tunnel and re-create?

     

    wg1 is correct and has the expected entries

     

    wg-quick up wg1 (autostart)
    [#] ip link add wg1 type wireguard
    [#] wg setconf wg1 /dev/fd/63
    [#] ip -4 address add 10.253.1.1 dev wg1
    [#] ip link set mtu 1420 up dev wg1
    [#] ip -4 route add 10.253.1.2/32 dev wg1
    [#] logger -t wireguard 'Tunnel WireGuard-wg1 started';/usr/local/emhttp/webGui/scripts/update_services
    [#] iptables -t nat -A POSTROUTING -s 10.253.1.0/24 -o br0 -j MASQUERADE
    [#] ip -4 route flush table 201
    [#] ip -4 route add default via 10.253.1.1 dev wg1 table 201
    [#] ip -4 route add 192.168.128.0/24 via 192.168.128.1 dev br0 table 201

     

  7. IPvlan operates in a mode which shares the same MAC address amongst multiple IP addresses.

    It seems to me that the Fritzbox can not handle that, it apparently wants to act on unique MAC addresses when doing port forwarding. Can the Fritzbox act on IP address instead?

     

    A couple of workarounds:

     

    1. If you don't use VMs then the 'bridge' function is not needed on eth0 and you can use MACvlan directly on the interface, which doesn't cause call traces in my testing.

     

    2. Use docker containers on a dedicated interface (eth1) with no IP addresses assigned and again no bridging enabled for this interface. This separates docker communication completely from system communication.