NAS542, Link Aggregation and MAC address

Boyanski

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

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:

https://web.archive.org/web/20160827020150/http://downloads.zyxel.nas-central.org/Users/Mijzelf/universal_usb_key_func-2015-10-12.zip

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

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

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

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

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

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

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

~ $ 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

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.