Category Archives: Technical

MikroTik RouterOS ZTE MF90 bug in 6.36 up to 6.43.7, Huawei E5573 & E5673, Movimax MV003 support

I have never installed any USB 3G/4G modem on my MikroTik RouterBOARD devices, despite most of them having a USB port available.  Finally I came across 2 situations where I had to deploy 4G USB modem as primary link at an event venue and as backup Internet connection at home.

I have 2 unused Bolt4G’s MF90 modems in unlocked state so I wanted to use them to save money from buying new modems.  I have many MikroTik RouterBOARD devices at my disposal, 2 hap ac lite, 1 hap ac^2, and 1 RB951Ui-2HnD.  This time I need to plug the modem into the hap ac lite and RB951Ui-2HnD running RouterOS 6.43.4 (the latest OS at the time).  There are tons of materials on MF90 and MikroTik routers because it was such a popular device at its time, which led me to think it should not be difficult to achieve.  It should be a walk in the park, so people say.  Turns out I was wrong.

MF90 drivers would not load on any of the MikroTik RouterBOARD devices I own.  I checked /system resources usb print and I could see the MF90 there.  It was recognised but there was no new interface in the /interfaces lte menu.  I checked the logs, restarted the modem, swapped the 2 MF90s, replaced the USB cable, rebooted the MikroTik devices, still nothing!  I googled further but I couldn’t find why it wouldn’t work, until I came across this and this.  Apparently one person have reported this issue to the MikroTik forum back in September 2016, yes 2016.  More than 2 years ago.  Guess what, nobody from MikroTik team responded to this poor guy (sger on forum.mikrotik.com).  sger mentioned that it had last worked for him on RouterOS 6.35.4 on his CRS125.  I immediately googled for that version of RouterOS (mipsbe package for the hap ac lite that I was using as a testing device) and downgraded the RouterOS.  Voila!  It immediately showed the lte1 interface, so sger is damn right about this.  Typical MikroTik bug I would say, I have seen a couple of times they lose older features to bugs like this.  I reached out to the kind guys at MikroTik support team, this time it went to Antons B.  One thing I like about MikroTik support is most of them know what they are talking about.  Another company who does well at this is cPanel.  Anyway back to topic, I knew I had to report this bug ASAP and they will gladly fix the issue because it was supported then and it should work ever since.

As always MikroTik support asked me to send my supout.rif file.  I had to disable my wireless package since 6.36 was the version where MikroTik introduced the new single wireless package, downgrading to 6.35.x would require me to disable wireless package before I could generate a supout.rif file for MikroTik support.  When it was enabled, the process to generate a supout.rif file would max out the CPU and end up crashing the process.  After sharing my supout.rif files on both the latest RouterOS 6.43.4 and 6.35.4, Antons came back with a new build of RouterOS 6.44beta32.  He told me to test this build and as mentioned above, it solved the problem flawlessly.  It took him only less than 3 days to come up with a new build.  This is why I love MikroTik, responsive and approachable.  If this were Cisco or Juniper, I don’t think I would be able to speak directly to their technical support team and most likely they would direct me to their partner’s support team which probably will never be able to solve the issue.  3 weeks later, MikroTik released 6.43.7 which is the latest stable build with the MF90 fix.

Now with the MF90 working, I get to achieve what I wanted to do.  However the MF90 has B08 firmware which is known to be locked to TDD2300 (B40). B05 firmware is said to support FDD2100 but it appears that nobody has done it (or rather share it publicly) so I ended up looking for new USB modems to take advantage of the FDD2100 band (where most of the national telcos operate their 4G services).  I did some research and Huawei’s devices seem to standout.  I considered XL Go Izi’s Movimax MV003 but I couldn’t find any reference stating that it’s usable on MikroTik (turns out it is working well with MikroTik after my colleague lent me hers to test).  Specs-wise it doesn’t say anything other than Qualcomm chip powered.   Since I’m not in a position to gamble right now, I took a safer choice in Huawei E5673.  Some references can be found on Google about it and it looks like a solid modem.  It is suitable for my first use case, however for the second use case I needed a AlwaysOn-like package for the backup Internet connection at home.  I considered Tri, but its performance on both 3G and 4G is just so so.  Telkomsel is expensive and thus is out of the question despite being the strongest candidate since they run both FDD2100 and TDD2300 LTE networks.  Indosat is probably the weakest of the top 3, so naturally it goes back to XL, my previous employer.  XL’s 3G and 4G services prove to be quite fast and reliable at home, but its long-term data package, branded XL Go Izi, requires XL Go-branded modems (E5573, E5577, MV003).  Since the recently purchased E5673 wouldn’t work with it, I ended up buying another one, an XL Go-branded Huawei E5573.  I did not want to risk buying E5577 nor MV003 because nobody has shared their experience getting them to work with MikroTik.  Anyway, after I received the E5573, I immediately started with a speedtest.  I got close to 30Mbps of download in the first attempt, 3X faster than my home FTTH Internet connection.  Now my backup is ready to pick up whenever the FTTH goes down.  Don’t hesitate to buy Huawei E5573, E5673, and Movimax MV003 if you wish to use them on MikroTik devices, I have tested all 3 and confirmed that they play nicely with MikroTik RouterOS!

VMware ESXi on OVH.com’s dedicated server, additional IPv4 subnet, and WORKING native IPv6 connectivity

I have finally migrated my server from LeaseWeb to OVH.  LeaseWeb wouldn’t provide me with a reasonable offer after being a loyal customer for 3 years so I terminated my server there. I came across OVH’s 1-year anniversary for Asia Pacific servers (50% off for annual payment) and their offer was massively appealing so I immediately signed up. I am extremely impressed with their customer control panel. I would say it’s much better than SoftLayer and LeaseWeb if you like to configure things by yourself.  OVH may not have a perfect reputation but it seems to have improved significantly over the years. I’m quite pleased on their automatic provisioning that took minutes and the KVM-over-IP is very easy to use.

It took me a while to get up to speed but once I got a hold of it, things were quite straightforward.  I intend to run a VM-based router (MikroTik’s Cloud Hosted Router) and route the subnet through it and other VMs will be a part of this VM network.  I could “bridge” my VMware ESXi CHR VM to the physical network to take advantage of their very-reasonably-priced one-time-fee additional IPv4 blocks using a FailOver (FO) IP address.  You need 1 individual FO IP to route/”bridge” the additional IPv6 subnet(s).  Apply the OVH-generated VMware-accepted MAC address to your VM host’s virtual ethernet (in my case VMware ESXi) to get the “bridge” to work.  You will need to “bridge” every single IP to the OVH-generated MAC address in the subnet manually.

Once I got everything working as expected, I continued to configure native IPv6 as provided by OVH.  I read the available guides on OVH.com and on Google (they have various guides on IPv6 make sure you read the right one for dedicated server), but I could never get it to work.  I got assigned the IPv6 range of 2402:1f00:8000:3cb::/64 but the guide states that I need to use 2402:1f00:8000:3ff:ff:ff:ff:ff as the gateway IPv6 address, which is unusual because such address is outside the /64 range.  2402:1f00:8000:3cb::/64 means 2402:1f00:8000:3cb:0:0:0:0 – 2402:1f00:8000:3cb:ffff:ffff:ffff:ffff.  Compare this range to the suggested gateway IPv6 address of 2402:1f00:8000:3ff:ff:ff:ff:ff (or 2402:1f00:8000:03ff:00ff:00ff:00ff:00ff), you can clearly see that the suggested IPv6 gateway address is outside the range.  This is the reason why this unusual network setup requires some effort to make it work properly.

I did not really take notice of this initially and wondered for hours why it wouldn’t work.  I opened a support ticket and the response was not helpful, the response only repeated the guide. I eventually used an IPv6 calculator to confirm my suspicion and it proved to be the culprit (because the gateway error was “unreachable” and “no route to host” when ping was used). I immediately tried changing the subnet mask to /56 instead of /64 because the assigned gateway IPv6 address is expected to be overridden with “ff” and changing it to /56 now makes the gateway IPv6 address within the network.  Remember, previously it was outside with the /64 range. Now the OS would accept the gateway IPv6 address and is reachable.  Ping also worked this time and immediately I had native IPv6 connectivity.  However this is not the right setup!

So, if you are an OVH customer and you cannot get IPv6 to work on MikroTik after reading their knowledge base articles , here is how:
The kind guy at MikroTik support (Martins S.) helped me to get this to work on my MikroTik setup.  The solution is actually very simple.  Basically once you have set up the IPv6 address on MikroTik, use multicast ping command: /ping FF02::2%ether1.  ether1 is the interface name connected to OVH.  Write down link-local addresses responding to the ping and expect to see a few replies for every ping request, including the device’s own link-local interface.  In my case I received 3 replies from 3 link-local addresses per ping, after eliminating my own device’s link-local address, I ended up with 2 link-local addresses.  These should be the link-local address of the actual router.  You can use this command to set up the IPv6 default route: /ip6 route add dst-address=”2000::/3″ gateway=”%ether1″. The new default route should immediately become active and you can use /tool trace ipv6.google.com to confirm your IPv6 connectivity on OVH’s network (assuming you have a working resolver configuration in place ;).

Good luck!

CentOS / CloudLinux 6 locale issue

When you use Terminal to ssh into a freshly installed CentOS / CloudLinux 6, you would encounter this:

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

There are a few solution out there, but the best and simplest is this:

echo ‘LC_CTYPE=”en_US.UTF-8″‘ >> /etc/sysconfig/i18n

Done.

References:
http://serverfault.com/questions/320971/centos-6-and-locale-error

Dynamic DNS + tunnelbroker MikroTik script for HE.net (Hurricane Electric)

 

Note: Tested on MikroTik 6.2

/system script
add name=he-dns policy=ftp,read,write,policy,test,winbox,api source=”# Update Hurricane Electric DDNS IPv4 address\r\
\n\r\
\n#make sure previousip is initialized with a value (0.0.0.0) before the script is first run\r\
\n:global previousip\r\
\n\r\
\n:local ddnshost \”DYNAMIC_HOSTNAME\”\r\
\n:local key \”KEY\”\r\
\n:local updatehost \”dyn.dns.he.net\”\r\
\n:local WANinterface \”WAN_INTERFACE_NAME\”\r\
\n:local outputfile \”he-dns.txt\”\r\
\n\r\
\n# Internal processing below…\r\
\n# ———————————-\r\
\n:local currentip\r\
\n\r\
\n# Get WAN interface IP address\r\
\n:set currentip [/ip address get [/ip address find interface=\$WANinterface] address]\r\
\n:set currentip [:pick [:tostr \$currentip] 0 [:find [:tostr \$currentip] \”/\”]]\r\
\n:log info (\”previous ip = \”.\$previousip.\”, current ip = \”.\$currentip)\r\
\n\r\
\n:if ([:len \$currentip] = 0) do={\r\
\n :log error (\”Could not get IP for interface \” . \$WANinterface)\r\
\n :error (\”Could not get IP for interface \” . \$WANinterface)\r\
\n}\r\
\n\r\
\n:if (\$currentip != \$previousip) do={\r\
\n :log info (\”Updating DDNS IPv4 address\” . \” Client IPv4 address to new IP \” . \$currentip . \”…\”)\r\
\n\r\
\n /tool fetch mode=http user=\$ddnshost password=\$key url=\”http://\$updatehost/nic/update\\\?hostname=\$ddnshost&myip=\$currentip\” \\\r\
\ndst-path=\$outputfile\r\
\n\r\
\n :log info ([/file get \$outputfile contents])\r\
\n /file remove \$outputfile\r\
\n :set previousip \$currentip\r\
\n} else={\r\
\n :log info (\”IP has not changed, no update necessary\”)\r\
\n}”
add name=he-tunnelbroker policy=ftp,read,write,policy,test,winbox,api source=”# Update Hurricane Electric tunnelbroker IPv4 address\r\
\n\r\
\n#make sure previousip is initialized with a value (0.0.0.0) before the script is first run\r\
\n:global previousip\r\
\n\r\
\n:local tunnelid \”TUNNEL_ID\”\r\
\n:local tunnelinterface \”TUN_INTERFACE_NAME\”\r\
\n:local user \”USERNAME_TUNNELBROKER\”\r\
\n:local pass \”PASSWORD_TUNNELBROKER\”\r\
\n:local updatehost \”ipv4.tunnelbroker.net\”\r\
\n:local WANinterface \”WAN_INTERFACE_NAME\”\r\
\n:local outputfile \”he-tunnelbroker.txt\”\r\
\n\r\
\n# Internal processing below…\r\
\n# ———————————-\r\
\n:local currentip\r\
\n\r\
\n# Get WAN interface IP address\r\
\n:set currentip [/ip address get [/ip address find interface=\$WANinterface] address]\r\
\n:set currentip [:pick [:tostr \$currentip] 0 [:find [:tostr \$currentip] \”/\”]]\r\
\n:log info (\”previous ip = \”.\$previousip.\”, current ip = \”.\$currentip)\r\
\n\r\
\n:if ([:len \$currentip] = 0) do={\r\
\n :log error (\”Could not get IP for interface \” . \$WANinterface)\r\
\n :error (\”Could not get IP for interface \” . \$WANinterface)\r\
\n}\r\
\n\r\
\n:if (\$currentip != \$previousip) do={\r\
\n :log info (\”Updating tunnelbroker client IPv4 address to new IP \” . \$currentip . \”…\”)\r\
\n\r\
\n /tool fetch mode=https user=\$user password=\$pass url=\”https://\$updatehost/nic/update\\\?hostname=\$tunnelid&myip=\$currentip\” \\\r\
\ndst-path=\$outputfile\r\
\n\r\
\n /interface 6to4 set \$tunnelinterface local-address=\$currentip\r\
\n\r\
\n :log info ([/file get \$outputfile contents])\r\
\n /file remove \$outputfile\r\
\n :set previousip \$currentip\r\
\n} else={\r\
\n :log info (\”IP has not changed, no update necessary\”)\r\
\n}”

Initialize previousip with the following command in the Terminal:

:global previous “0.0.0.0”

References:

Recipient MX-based dnslookup routing for cPanel’s Exim

I host a few websites and emails for my friends and relatives on my cPanel server.  I need to ensure that their emails don’t end up in Spam/Junk folder when they send to email addresses hosted on Google/Yahoo/Hotmail (common problem with small webhosting companies).  I can easily forward/relay every single remote delivery via an ESP’s smarthost, but that would be too costly for me since ESPs charge by the amount of emails relayed.  Getting certified by ReturnPath is also expensive and takes some time.  I just need at least the major ones to be relayed, so I needed a recipient MX-based routing for my Exim.  It doesn’t look proper, but it works great!  I’m sure many small cPanel hosts will face this similar problem.

authenticators:

esp_relay_login:
driver = plaintext
public_name = LOGIN
client_send = : ${extract{user}{${lookup{${lookup{$sender_address_domain}lsearch*{/etc/mail_relay_mapping}{$value}}}lsearch{/etc/mail_relay_secret}{$value}}}} : ${extract{pass}{${lookup{${lookup{$sender_address_domain}lsearch*{/etc/mail_relay_mapping}{$value}}}lsearch{/etc/mail_relay_secret}{$value}}}}

routers:

smarthost_dkim:
driver = dnslookup
domains = !+local_domains : ! /etc/mail_domain_excluded_from_using_relay
require_files = “+/var/cpanel/domain_keys/private/${sender_address_domain}”
transport = remote_smtp_smart_dkim
ignore_target_hosts = ! /etc/mail_ips_of_domains_to_be_relayed
senders = ! /etc/mail_exclude_from_relay

smarthost_regular:
driver = dnslookup
domains = !+local_domains : ! /etc/mail_domain_excluded_from_using_relay
transport = remote_smtp_smart_regular
ignore_target_hosts = ! /etc/mail_ips_of_domains_to_be_relayed
senders = ! /etc/mail_exclude_from_relay

transports:

remote_smtp_smart_dkim:
driver = smtp
hosts_require_tls = *
interface = ${if exists {/etc/mailips}{${lookup{$original_domain}lsearch{/etc/mailips}{$value}{${lookup{$sender_address_domain}lsearch{/etc/mailips}{$value}{${lookup{${perl{get_sender_from_uid}}}lsearch*{/etc/mailips}{$value}{}}}}}}}}
helo_data = ${if exists {/etc/mailhelo}{${lookup{$original_domain}lsearch{/etc/mailhelo}{$value}{${lookup{$sender_address_domain}lsearch{/etc/mailhelo}{$value}{${lookup{${perl{get_sender_from_uid}}}lsearch*{/etc/mailhelo}{$value}{$primary_hostname}}}}}}}{$primary_hostname}}
dkim_domain = $sender_address_domain
dkim_selector = default
dkim_private_key = “/var/cpanel/domain_keys/private/${dkim_domain}”
dkim_canon = relaxed
hosts_require_auth = *
hosts = ${lookup{$sender_address_domain}lsearch*{/etc/mail_relay_mapping}{$value}}::587
hosts_override = yes

remote_smtp_smart_regular:
driver = smtp
hosts_require_tls = *
interface = ${if exists {/etc/mailips}{${lookup{$original_domain}lsearch{/etc/mailips}{$value}{${lookup{$sender_address_domain}lsearch*{/etc/mailips}{$value}{${lookup{${perl{get_sender_from_uid}}}lsearch*{/etc/mailips}{$value}{}}}}}}}}
helo_data = ${if exists {/etc/mailhelo}{${lookup{$original_domain}lsearch{/etc/mailhelo}{$value}{${lookup{$sender_address_domain}lsearch{/etc/mailhelo}{$value}{${lookup{${perl{get_sender_from_uid}}}lsearch*{/etc/mailhelo}{$value}{$primary_hostname}}}}}}}{$primary_hostname}}
hosts_require_auth = *
hosts = ${lookup{$sender_address_domain}lsearch*{/etc/mail_relay_mapping}{$value}}::587
hosts_override = yes

 

Files needed:

/etc/mail_domain_excluded_from_using_relay: (exclude emails sent to these domains from being relayed to smarthost)
abc.com
cde.com

/etc/mail_exclude_from_relay: (exclude emails sent from these domains from being relayed to smarthost, this should be your customers’ domains hosted on your server)
def.com
ghi.com
jkl.com
mno.com

/etc/mail_ips_of_domains_to_be_relayed: (MX IPs of domains which Exim will relay via smarthost)
#Google
74.125.0.0/16
173.194.0.0/16
#Hotmail
65.52.0.0/14
#Yahoo APAC
106.10.128.0/18
#Yahoo EU
188.125.64.0/21
#Yahoo US
68.180.128.0/17
98.136.0.0/14
66.196.64.0/18
63.250.192.0/19

/etc/mail_relay_secret: (list of credentials for smarthosts, list down all smarthosts that you will use in /etc/mail_relay_mapping below)
smtp.example.com: user=postusername pass=password
smtp.example.net: user=postuser pass=pass123
smtp.example.org: user=boo pass=hoo

/etc/mail_relay_mapping: (list of domains to explicitly map to certain smarthost, last entry is default smarthost)
ghi.com: smtp.example.org
def.com: smtp.example.net
jkl: smtp.example.org
*: smtp.example.com

Thus if mno.com sends an email to Gmail/Hotmail/Yahoo, it will be relayed via smtp.example.com.

How do you check if it works?  Test by sending an email to certain domain like Yahoo and watch Exim’s log.  For domains that should be relayed, it should say remote_smtp_smart_regular or remote_smtp_smart_dkim transport (T) in the logs:

1VFjpE-0002oA-Tb => xxxxx@yahoo.com R=smarthost_regular T=remote_smtp_smart_regular H=smtp.example.com [123.123.123.123] X=TLSv1:DHE-RSA-AES256-SHA:256
1VFjFr-0007hX-QJ => xxxxx@gmail.com R=smarthost_dkim T=remote_smtp_smart_dkim H=smtp.example.org [124.124.124.124] X=TLSv1:DHE-RSA-AES256-SHA:256

Normal route would be remote_smtp or dkim_remote_smtp:

1VDN3n-00088z-46 => yyyyy@gmail.com R=lookuphost T=remote_smtp H=gmail-smtp-in.l.google.com [173.194.79.26] X=TLSv1:RC4-SHA:128
1VDWNC-0002Zo-OB => zzzzzz@hotmail.com R=dkim_lookuphost T=dkim_remote_smtp H=mx2.hotmail.com [65.55.92.152]

Thanks to Chris Siebenmann!

References:
http://www.gossamer-threads.com/lists/exim/users/97299
http://www.tgunkel.de/docs/exim_smarthosts.en

Noteworthy links:
http://serverfault.com/questions/347285/exim-redirect-to-smart-host-based-on-mx-record
http://www.gossamer-threads.com/lists/exim/users/97056

Facebook Page fan photos

In case you wonder why “Add Photos” link on your Facebook Page is no longer working as expected (directs you back to your Facebook Home), I believe it’s because they have changed the way fan photos work on Facebook Pages (without informing users).

Like usual, Facebook developers are changing and implementing things quickly without updating all necessary help information to guide users with these changes.  These days bugs are easily spotted on Facebook.  It’s understandable to have bugs at their current size, but implementing changes before/without communicating these changes to users is a very stupid move.  Not to mention they never reply to (real) bug reports.

Two weeks ago, for 1 day, no one could write a comment to wall posts of the Facebook Pages.  Only comments for photos were normal.  I think I’m starting to hate Facebook, plus the fact that they have removed Profile’s boxes and tabs.  Someone should really make a good copy of Facebook when it had all the cool features.

These past 3 days I have waited for a reply from Facebook to fix or at least address fan’s “Add Photos” link issue, but I got nothing.  I need this feature to work ASAP for my marketing team, so I looked around and found a discussion link on Facebook.  Basically these people complain about the same thing, apparently this feature has been buggy since last year.

Abbey Butler‘s post on page 7 of the thread is the answer.  Thanks, Abbey! 🙂

Areca RAID cards and WDC desktop-class HDDs (non-RE)

First of all, avoid any green drives (including WDC RE-GP drives) at all cost for RAID setups.

I have Areca’s ARC-1210 and ARC-1220 RAID cards installed on my Tyan servers (with S5397 and S5211 motherboards).  Some of these servers are using WDC GP drives (my vendor ordered the GP drives), despite having TLER-enabled, they will drop from the RAID sets within days or weeks.  Enabling TLER does help, but don’t count too much on it.  This is caused by the IntelliPower feature that limits its RPM to 5400.  RAID drives are supposed to be fast, GP drives are slow.

Few weeks ago I tried to get a pair of WDC WD2500AAJS-22VTA0 to run Windows Server 2003 R2 Standard Edition.  The installation went well until few days of uptime, the server rebooted itself after showing this error message:

The instruction at “0x76946203” referenced memory at “0x76946203”. The required data was not placed into memory because of an I/O error status of “0xc000000e”. Click on OK to terminate the program.

Prior to this error message, it showed a yellow popup (like the low disk space popup) on the systray but I couldn’t get a screenshot as it happened really fast.  It states (IIRC) that files are missing/corrupted in the RECYCLER folder.

I tried disabling write cache on the RAID card and Windows, but no luck.  Tried to enable TLER (it wasn’t on before), also no luck.  Finally I consulted Google and found out that disabling NCQ help on some hard drives.  I disabled NCQ and rebooted the server, so far it has been up for almost a month.  Before this, it couldn’t even reach a week of uptime.

Now I use the WDC RE3 drives (WD5002ABYS) to replace the GP drives.  The temperature of the RE3 drives are much lower (8-10C lower) than the desktop drives, despite having less cooling in the room.

Hopefully this post can help others to avoid the issues I encountered.

Issues with NTP

If you wonder why your VPS or specifically OpenVZ VE’s ntpd is stuck at stratum 16 or stratum 0 while ntpq -p shows no abnormality (use ntpq -c rv to check state, it should say state=3 when abnormal), then try executing ntpdate manually. If it says “ntpdate: step-systime: Operation not permitted”, then you need to reconfigure your OpenVZ VE or ask your host to do it for you: vzctl set 123 –capability sys_time:on –save

If everything is fine but this message “ntpdate: no server suitable for synchronization found” keeps coming up, then it could be your ISP blocking UDP port 123. Use ntpdate -u to verify, this option should circumvent the firewall.

References:
http://blog.haite.ch/2009/05/22/1242984900000.html

iptables mangle and NAT notes, etc.

PREROUTING in nat table: DNAT, REDIRECT
POSTROUTING in nat table: SNAT/MASQUERADE

PREROUTING in mangle table: alter routing (e.g. source-based routing)
FORWARD in mangle table: traffic shaping for tc (flowid)

In MikroTik RouterOS, /ip firewall nat:
srcnat chain = PREROUTING
dstnat chain = POSTROUTING

/ip firewall mangle:
prerouting chain = global-in
forward chain = global-out (support NAT traffic shaping, higher load on router)

Update: I used to think that global-in literally means global input, while global-out literally means global output.  Apparently I was mistaken.  The parent queues MUST be matched to the right parent, either global-in, global-out, global-total, or one of the network interfaces depending on the mangle rules.  Top-most queue parent (global-in, global-out, global-total) doesn’t decide whether it’s up/down.  The mangle rules do the direction decision trick, whether a packet is incoming/download or outgoing/upload.  This makes perfect sense now! (doh)  I kept wondering why half of my queues (download queues’ top-most parent was global-in) weren’t working, when all my mangle rules were in forward chain.  Obviously they wouldn’t, because global-in marks both direction in prerouting chain.

Update 2: mangle: download rules first then upload rules. global-in, connection mark: prerouting; packet mark: prerouting. global-out, connection mark: forward, packet mark: postrouting.

 

This didn’t make sense until I read the URL listed below under References.  Silly me!  Assumption is the root of most, if not all, problems indeed.

References:
http://wiki.ispadmin.eu/index.php/Documentation/Mikrotik_guide#.22Global-in.22_vs._.22global-out.22_setup

MikroTik simple script to update ZoneEdit Dynamic DNS

I have a MikroTik router (RouterOS v4.x) with an ADSL connection at work, unfortunately it comes with dynamic public IP address.  I need to connect to my office workstation or simply the MikroTik router from home or elsewhere but I need to know its latest IP address all the time, so I decided to use ZoneEdit’s Dynamic DNS service.

Add a new script to the MikroTik router (replace those in bold):

  • /system script add name=zoneedit-dyndns source=”/tool fetch url=\”http://dynamic.zoneedit.com/auth/dynamic.html\?host=dyndns.example.com&dnsto=127.0.0.1\” user=ZEUser password=ZEPass keep-result=no\r\n/delay 30\r\n/tool fetch url=\”http://dynamic.zoneedit.com/auth/dynamic.html\?host=dyndns.example.com\” user=ZEUser password=ZEPass keep-result=no” policy=read

Test the script by running it manually:

  • /system script run zoneedit-dyndns

If it shows 2 lines of “status: finished”, then the script works properly.

Schedule the script to run regularly (in this case, every 10 minutes):

  • /system scheduler add name=”zoneedit-dyndns” interval=10m on-event=”/system script run zoneedit-dyndns” policy=read,test

Why does it require 2 “fetch” commands to update?  I think there is a bug in ZoneEdit’s Dynamic DNS updater, so it needs to be forced. The new dynamic DNS change entry has to be significantly different from the previous dynamic DNS entry before the ZoneEdit backend would really update it.

Thanks, ZoneEdit!