NAS542, Link Aggregation and MAC address

24

All Replies

  • Boyanski
    Boyanski Posts: 33  Freshman Member
    First Anniversary
    Maybe I'm missing something else too. Here is what I tried:

    As super user 
    mv /sbin/dhcpcd /sbin/dhcpcd.old
    cd /sbin
    cat > dhcpcd
    Then I entered the code you gave me with the desired MAC in the console
    Ctrl + Z to save and exit
    chmod a+x dhcpcd
    I restarted the NAS and it changed the MAC again. As I checked the /sbin directory - dhcpcd.old was gone and dhcpcd file exist, but it's not the one I created, I guess the original what it should be.

    You said it's on a ram drive. Is it the "black magic" that I didn't understand?
  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited September 2018
    Apparently. As many embedded linux devices, this box has it's root filesystem embedded in the kernel, which is extracted to a ramdrive on boot. A big advantage of this is that in the early boot stage Linux doesn't need access to any storage system, as all needed binaries and scripts are already available. Consequence is that any change made to the rootfs will be reset on reboot. That can be a disadvantage, but also an advantage, as it's harder to brick the device.

    The black magic is that it's possible to have a script on an USB stick, which is called rather early in the boot process. Before the nic bonding is made, and so before the dhcp client is started.

    That script could be:
    #!/bin/sh<br><br>mv /sbin/dhcpcd /sbin/dhcpcd.old<br><br>cat >/sbin/dhcpcd <<__EOF__<br>#!/bin/sh<br>ifconfig bond0 hw ether 00:11:22:33:44:55<br>exec /sbin/dhcpcd.old "\$@"<br>__EOF__<br><br>chmod a+x /sbin/dhcpcd<br><br>exit 1<br>
    nas-central.org is down, at the moment, but fortunately archive.org has archived the needed zipfile:

    I'd test first if it's possible to change the bond0 mac address this way. Maybe you'll have to bring it down first, or something like that.

  • Boyanski
    Boyanski Posts: 33  Freshman Member
    First Anniversary
    OK, I did it, the script works now. But...

    Now something else happened. As it injects the given MAC, now my router assigns a random IP address, not the one I set in the DHCP. At first I couldn't understand why this is happening, but as I thought it later I think I realized what's going on, since I triple checked the entries there.

    The iSCSI is not the only problem I had with the changing MACs. Zyxel Drive is the other thing that works only on the MAC of LAN2 (let's call it M2 for short).

    When I first configured the NAS, it was connected to LAN2, maybe that matters. When I log in to Zyxel Drive from my phone's mobile network, if the NAS uses M2, I have access. When it has M1, it just says "Connecting..." forever. Now I set the script to inject M2, but I can no longer access it through ZDrive.

    So back to the router. I think what's happening is that when I restart the NAS, first it alternates the MAC. Since it's on M2, it changes to M1, the router detects it on the network and assigns a random IP (M1 is not in the DHCP list). After that (maybe milliseconds later) the script changes M1 to M2 and maybe this causes some kind of a mess.

    I don't know if my assumptions are correct, it's the only possible thing that came to my mind.

    When I log in to MyCloud there it shows M1. When I click the down arrow, where it shows the status (disk usage, temperature, etc..), it cannot now, just closes it after a few seconds of trying.

    Why is it so complicated? Did I make a big mess?
  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    I can imagine the box first brings up both nic's, before bonding them. You can expand the script to do some logging, to see if that is the case:
    #!/bin/sh<br>date >>/tmp/dhcpcd.log<br>echo "\$0 \$@" >>/tmp/dhcpcd.log<br>ifconfig bond0 hw ether 00:11:22:33:44:55<br>exec /sbin/dhcpcd.old "\$@"<br>__EOF__cat >/sbin/dhcpcd <<__EOF__<br>
    This will log all starts of dhcpcd.log, with it's command line arguments. (If invoked after usb_key_func.sh is invoked). If indeed the single nic is brought up first, you can filter it, and simply not start dhcpcd.




  • Boyanski
    Boyanski Posts: 33  Freshman Member
    First Anniversary
    If I have understood correctly, this is the log file:

    ~ $ cat /tmp/dhcpcd.log
    Sun Sep 16 17:22:16 UTC 2018
    /sbin/dhcpcd -k egiga1
    Sun Sep 16 17:22:19 UTC 2018
    /sbin/dhcpcd -k egiga0
    Sun Sep 16 17:22:21 UTC 2018
    /sbin/dhcpcd -k bond0
    Sun Sep 16 17:22:22 UTC 2018
    /sbin/dhcpcd -k egiga1
    Sun Sep 16 17:22:22 UTC 2018
    /sbin/dhcpcd -R -G -N -h NAS542 -m 6 bond0
    Sun Sep 16 17:22:24 UTC 2018
    /sbin/dhcpcd -k egiga0

  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited September 2018
    Yes, you understood correctly.

    This logging looks normal. According to the manual -k means release. I tested it on my '520, if dhcpcd is not running on that interface, it simply generates an error:
    root@NAS520:/etc/init.d# /sbin/dhcpcd -k egiga1<br>****&nbsp; /sbin/dhcpcd: not running<br>root@NAS520:/etc/init.d# /sbin/dhcpcd -k egiga0<br>root@NAS520:/etc/init.d# <br>
    I have only egiga0 connected. So the only 'real' call to dhcpcd is '/sbin/dhcpcd -R -G -N -h NAS542 -m 6 bond0'. Here it's a bit strange that -G is provided. The manual says:
    Prevents dhcpcd from installing default routes provided by DHCP server. If optional gateway ip address parameter is supplied then use it for default route.
    So the gateway is applied another way. The daemon creates a file /etc/dhcpc/dhcpcd-interface.info, which contains all info provided by the dhcp server. Knowing the addiction of ZyXEL for python scripts, I guess some script reads this file, and applies it.
    You can have a look in this info file, and look at 'route' to see if it's applied right.

    So back to the router. I think what's happening is that when I restart the NAS, first it alternates the MAC. Since it's on M2, it changes to M1, the router detects it on the network and assigns a random IP (M1 is not in the DHCP list). After that (maybe milliseconds later) the script changes M1 to M2 and maybe this causes some kind of a mess.
    That shouldn't matter. From the dhcp server point of view M1 and M2 are unrelated. So it should simply handle them as two unrelated devices. Maybe it becomes different if first egiga1 with M2 asks for an IP address, and then bond0 with the same M2. For the dhcp server that's the same device, but for the NAS firmware it isn't. According to your log that doesn't happen.
    Do you have access to the internal logging of your dhcp server?

    BTW, you are aware that bonding needs a corresponding setup in the switch?

  • Boyanski
    Boyanski Posts: 33  Freshman Member
    First Anniversary
    You can have a look in this info file, and look at 'route' to see if it's applied right.
    ~ $ ls /etc/dhcpc
    dhcpcd-bond0.cache  dhcpcd-bond0.info   dhcpcd-bond0.pid    resolv.conf.meta
    ~ $ cat /etc/dhcpc/dhcpcd-bond0.info
    IPADDR=192.168.0.5
    NETMASK=255.255.255.0
    NETWORK=192.168.0.0
    BROADCAST=192.168.0.255
    GATEWAY=192.168.0.1
    HOSTNAME='NAS542'
    DNS=192.168.0.1,192.168.0.1
    DHCPSID=192.168.0.1
    DHCPGIADDR=0.0.0.0
    DHCPSIADDR=192.168.0.1
    DHCPCHADDR=5C:F4:AB:8C:1D:B9
    DHCPSHADDR=AC:84:C6:2D:C9:FC
    DHCPSNAME=''
    LEASETIME=7200
    RENEWALTIME=3600
    REBINDTIME=6300
    INTERFACE='bond0'
    CLASSID='Linux 3.2.54 armv7l'
    CLIENTID=5C:F4:AB:8C:1D:B9
    
    Do you have access to the internal logging of your dhcp server?
    If you mean the router's log, I checked it and it only contains some logs from 1.1.2016 and none of them is DHCP related. Looks like my router is not logging and I can't find a setting about it.
    BTW, you are aware that bonding needs a corresponding setup in the switch?
    I have enabled the Link Aggregation. There are not much settings there:
    Mode - Static LAG, the only option, no dynamic. According to Zyxel Knowledge Base static is preferred;
    Hash Algorithm: SRC MAC+DST MAC, which I guess stands for Source MAC and Destination MAC and is the recommended choice, however it's possible to choose one or the other;

  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    According to Wikipedia that hash is used to choose which cable/port to use, dependent on some ethernet header value (source+dest MAC, in your case). Don't know if it matters that both sides use the same mechanism. On my 520 it defaults to round-robin, when I load the bonding kernel module.
    You can see yours by executing<br>

    <code>cat /proc/net/bonding/bond0

    About /etc/dhcpc/dhcpcd-bond0.info, you have to compare it to the output of the command 'route' or 'route -n', to see if the gateway is set to 192.168.0.1 correctly. If not, that could explain why MyCloud doesn't work. Without gateway access from or to the internet is impossible.

    Further it might be an idea to assign bond0 an independent MAC address, (for instance ..:BA) to make sure there can be no dhcp issues (although I don't see how that could be. The box gets an IP address or not. After that ARP is responsible for IP/MAC translations.)
  • Boyanski
    Boyanski Posts: 33  Freshman Member
    First Anniversary
    ~ $ route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    192.168.0.0     *               255.255.255.0   U     0      0        0 bond0
    </code>~ $ cat /proc/net/bonding/bond0
    Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
    
    Bonding Mode: load balancing (xor)
    </pre><div>I guess this matches the router's?</div><pre class="CodeBlock"><code>
    ~ # route add default gw 192.168.0.1 bond0
    ~ # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 bond0
    192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 bond0
    </code>~ $ route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 bond0
    </pre><div>You are right, the gateway is not 192.168.0.1<br><br>Is this correct?<br><pre class="CodeBlock"><code>
    It doesn't match the destination now.
  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    I guess this matches the router's?
    You mean the switch? xor vs 'source and destination hash'? I don't think so. Xor is not a hashing algorithm. But I can be wrong. What are the other choices in the switch? Does the NAS have any settings for bonding?

    Is this correct?

    Yes.

    It doesn't match the destination now.
    Yes it does. You should also take the netmask into account. The routing algorithm always chooses for the netmask with the most bits. So your table can be read as:
    all traffic for 192.168.0.0/255.255.255.0 should go to 0.0.0.0, which is no address, so it is handled on ethernet level.
    Else all traffic for 0.0.0.0/0.0.0.0, which matches everything, should go to 192.168.0.1. Which is correct.
    On my nas the default gateway has a metric of 6, but equal metrics for both routes should also work in this case.

    Does MyCloud work with the added default gateway?

    A bit depressing, that the firmware says to dhcpcd 'don't apply the default gateway, I'll do it myself', and then it doesn't. Sigh.

Consumer Product Help Center