As the feature code try removing just the ‘#’ as I believe that is the issue.
Andrew, I did that (tried just *0) and it corrected the issue. But it can’t stay like that.
Astbox, I’ll try that, but I’m betting it won’t work as well, because there’s something about the *0# it has magically stopped liking.
I did a test on another system - that I had recently Yum Updated, and it now has the issue - so I’m starting to think this is an asterisk flaw in a recent update. I may submit something there as well if the extensions_custom doesn’t do the trick…
It’s the “#”. Asterisk is interpreting it as an include statement. I can’t recall if feature code admin allows “” but you can try *0\#
That is so strange that it’s worked for years across different versions, but I see what you’re saying. And you’re right (as is usually the case) 
Feature Code Admin doesn’t like the slash. Manually edited the file and did a core reload to grab the new config - same deal, didn’t like it.
I’m not sure if there’s a way for me to see the last time asterisk itself was updated, but I’m thinking that’s where the problem started. Also not sure if I can roll it back to the previous release or not… That would certainly pinpoint where the issue was.
So as it stands now, any codes that contain # but have other digits after them , work. It’s only the code that ends with a #, and it only started after this weekend…
OK now this is interesting, I think that it is “feature not a bug” situation. 
Consider changing your feature codes, you will spent less time.
I can’t justify doing that on hundreds of systems - makes more sense to fix what is likely a bug (since it’s worked for so many years on so many releases).
I thought we were talking for your pbx, please open a ticket as tm1000 suggested.
1 Like
We were, but with all this testing, it has proven to start happening when I update to the latest Asterisk version, so now that it appears to possibly be a more widespread issue, I opened a thread over on the Asterisk forum (thought I’d do that before submitting a bug).
Thx. folks…
There are some other places I have noticed this as well. Specifically conferences when I put a # into the file to be used as an operator (Admin Menu) it gets upset about that unless I put a \ on it. Which is what we’ve been doing for a while in the code base to work around it
Actually try upgrading timeconditions to 13.0.29. See if it resolves your issue or not.
No such luck. When new modules are downloaded, I’m assuming that causes a regeneration of the configs, correct? Or should I make a change to a time condition to force a rewrite?
You have me intrigued - what were you thinking was up? I ask because when I first detected this issue, I also couldn’t dial our direct to VM codes (##+ext). After a couple module updates on Tuesday or Wednesday, now those started working (though *0# still failed).
Incorrect. You need to actually run “Apply Changes” this is why it comes up when you install a module.
Well, yeah. I knew that. But that does indeed regenerate everything. Good. That’s what I hoped.
Also, a test system that had a dozen or so pending module updates, I tested and it worked. After I ran the updates, it then failed. So whatever you were thinking, you may be on the right track.
the bug was that it would break any voicemail hint. You said it worked when you took pound off. so nevermind. This is not the issue and I don’t think freepbx is the issue
I just checked a fully up to date FreePBX 13 system on Asterisk 13.8.2.
I added *0# as “My Voicemail” worked fine.
I added “##” to direct dial voicemail. Worked fine.
I added “#0*” as “Dial Voicemail” worked fine.
I switched them all around. Worked fine.
I believe you have an external issue here.
No work on system over the weekend. Still failing this morning (as expected). Latest module updates today, and it is now fixed. 
Not sure which module caused it, but it’s been taken care of, so… sweet!!!