NAS542, Link Aggregation and MAC address
All Replies
-
Maybe I'm missing something else too. Here is what I tried:
As super usermv /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 exitchmod 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?0 -
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.
1 -
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?0 -
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:
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.#!/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>
1 -
If I have understood correctly, this is the log file:~ $ cat /tmp/dhcpcd.logSun Sep 16 17:22:16 UTC 2018/sbin/dhcpcd -k egiga1Sun Sep 16 17:22:19 UTC 2018/sbin/dhcpcd -k egiga0Sun Sep 16 17:22:21 UTC 2018/sbin/dhcpcd -k bond0Sun Sep 16 17:22:22 UTC 2018/sbin/dhcpcd -k egiga1Sun Sep 16 17:22:22 UTC 2018/sbin/dhcpcd -R -G -N -h NAS542 -m 6 bond0Sun Sep 16 17:22:24 UTC 2018/sbin/dhcpcd -k egiga00
-
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>**** /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?
1 -
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;
0 -
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.)
1 -
~ $ 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.0 -
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.
1
Freshman Member
Guru Member
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 144 Nebula Ideas
- 94 Nebula Status and Incidents
- 5.6K Security
- 237 USG FLEX H Series
- 267 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.3K Consumer Product
- 247 Service & License
- 384 News and Release
- 83 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.2K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 83 About Community
- 71 Security Highlight
