^{Originally posted by APCCV February 22, 2025}
Hit a weird issue. Looking for ideas of what may be wrong so I poke around. Tried figuring out what's not working but I've got nothing.

Issue:

• I have two OpenWrt devices, two different architectures (kirkwood, ipq806x) running Netatalk v4.1.1 (I know .2 is out) that even though the afp.conf file has appletalk = yes they don't register and show up on an nbplkup.
• Those devices can register a printer with papd, or run timelord, or a2boot and that shows up on nbplkup, so the issue is not that AppleTalk is not functional or registration overall is not working.
• To further baffle me, I have an identical ipq806x running the same binaries v4.1.1 and that one works. The overall OS configuration is slightly different and that's where I've been focusing on without success, but it's the same version of OpenWrt on all, same version or Netatalk for all, same afp.conf and same atalkd.conf
• Configuration files are being read alright, as atalkd is running, and afpd service is available via TCP.
• The issue might be in the code parsing afp.conf (although I have no explanation on why one of the ipq806x works and the other doesn't). If I force the code to consider appletalk='yes' with patch below, then everything works as expected.

--- a/libatalk/util/netatalk_conf.c
+++ b/libatalk/util/netatalk_conf.c
@@ -2101,7 +2101,7 @@ int afp_config_parse(AFPObj *AFPObj, char *processname)
         options->passwdbits |= PASSWD_SET;
     if (atalk_iniparser_getboolean(config, INISEC_GLOBAL, "spotlight expr", 1))
         options->flags |= OPTION_SPOTLIGHT_EXPR;
-    if (atalk_iniparser_getboolean(config, INISEC_GLOBAL, "appletalk", 0))
+    if (atalk_iniparser_getboolean(config, INISEC_GLOBAL, "appletalk", 1))
         options->flags |= OPTION_DDP;

     /* figure out options w values */

The question... is there anything at OS level (missing library, ubus config, whatever) that would influence the behaviour of atalk_iniparser_getboolean so it misses the config line?

PS: I can see that v4.2 will use a different config parser... I can wait for that to be out and try it when it's part of a release... but still would like to know why I'm having this issue.