What's new

[Feature Request] Letsencrypt DNS-01 challenge/AC86U geoip module support

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Sylphia

Regular Contributor
Our ISP blocked port 80/443 for home users, so I have to use dns-01 challenge to get a let's encrypt certificate, and I've been using geoip module to implement simple vpn rules, sadly it's not working on ac86u.
 
Let's Encrypt implementation is closed source and outside of my control.
 
Let's Encrypt implementation is closed source and outside of my control.

Indeed, I saw letsencrypt.so binary yesterday after I started this thread.

I'm trying to modify some code to make geoip working with my 86u, maybe only 4 files that I need to make change to (ac86u only):
linux kernel 4.1 xt_geoip.c xt_geoip.h, iptables-1.4.x libipt_geoip.c and linux headers in hnd toolchain (xt_geoip.h)

But for safety I have to ask, does ac86u hard to brick, I mean, the cfe restore stuff...
 
Last edited:
But for safety I have to ask, does ac86u hard to brick, I mean, the cfe restore stuff...

Not 100% sure, just for safety I recommend you do your tests using the ubi.w image rather than the cfe_ubi.w image. The RT-AC86U shares the same ftpd/mini web interface as other models.

If your kernel changes are in a module, you should be safe, any crash would only happen when modprobing the module.
 
Not 100% sure, just for safety I recommend you do your tests using the ubi.w image rather than the cfe_ubi.w image. The RT-AC86U shares the same ftpd/mini web interface as other models.

If your kernel changes are in a module, you should be safe, any crash would only happen when modprobing the module.

Modified the 4 files I mentioned above, but still got 'invalid size 160 (kernel) != (user) 96' error. When building iptables-1.4.x, we're using linux header from toolchain (arm-buildroot) right? I changed pointers in xt_geoip.h to aligned_u64 type, why still 96 bits in user space? Am I missing something?
 
Modified the 4 files I mentioned above, but still got 'invalid size 160 (kernel) != (user) 96' error. When building iptables-1.4.x, we're using linux header from toolchain (arm-buildroot) right? I changed pointers in xt_geoip.h to aligned_u64 type, why still 96 bits in user space? Am I missing something?

I don't know. I have never looked at geoip since it was never used by the firmware, it's just some leftover code that Asus put in there at some point, but never actually used it.
 
My bad. I didn't noticed that I flashed original merlin firmware again.
Confirmed working.
Should this patch being merged into repo?
 
My bad. I didn't noticed that I flashed original merlin firmware again.
Confirmed working.
Should this patch being merged into repo?

I'm willing to merge it, provided it doesn't break other platforms.
 
I'm willing to merge it, provided it doesn't break other platforms.

Since seems only ac86u was built with kernel 4.1, changes to kernel header and geoip kernel module should be safe to merge, and changes to kernel header file inside hnd toolchain should be safe to merge, too.

But changes to iptables-1.4.x will break other models, so it needed to be patched only when building iptables-1.4.x for ac86u, but I'm not familiar with makefiles (not using C/Make for over ten years), so I uploaded diff files here.
 

Attachments

  • ac86u-geoip-fix-patch.diff.txt
    9.4 KB · Views: 250
  • ac86u-geoip-fix-toolchain-patch.diff.txt
    1.7 KB · Views: 296
Since seems only ac86u was built with kernel 4.1, changes to kernel header and geoip kernel module should be safe to merge, and changes to kernel header file inside hnd toolchain should be safe to merge, too.

But changes to iptables-1.4.x will break other models, so it needed to be patched only when building iptables-1.4.x for ac86u, but I'm not familiar with makefiles (not using C/Make for over ten years), so I uploaded diff files here.

That wouldn't work too well, since Asuswrt does not rely of buildtime patching (unlike OpenWRT). This would have to be implemented with the use of ifdef blocks.
 
That wouldn't work too well, since Asuswrt does not rely of buildtime patching (unlike OpenWRT). This would have to be implemented with the use of ifdef blocks.
How about we change xt_geoip.c xt_geoip.h in all kernels? Except slightly memory usage change, I don't think it will break any other function, as you said, ASUS didn't make use of it.
I'll submit a merge request if you're ok with these changes.
 
And, for let's encrypt DNS-01 challenge, I'm going to give dehydrated (dehydrated.io) script a try, but seems it is not compatible with bash provided by busybox, I have to use bash from EntWare.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top