"SMS generic failure" Error - Verizon/CDMA Issue

[fierytechknowhows]

I am having problems too. I can use unstop in the Samsung messages app and txtnet browser and I get a response back from the server. But when I try to go to any website it just says loading and gives an "SMS generic failure" error and I don't receive any SMS messages for the url. I'm wondering if anyone else is getting the same "SMS generic failure" message since I haven't seen it anywhere else on here.

[fierytechknowhows]

It showed more failed characters: (£, ¥, è, Γ, Λ, Ω, Π, Ψ, Σ, Θ, Ξ, Φ) I tested them each and they all still showed 41/3. this is the build number: TP1A.220624.014 Here is the log info:
[character: £ result_code: 1 supplied_error_codeor-1: -1] [character: ¥ result_code: 1 supplied_error_codeor-1: -1] [character: è result_code: 1 supplied_error_codeor-1: -1] [character: Γ result_code: 1 supplied_error_codeor-1: -1] [character: Λ result_code: 1 supplied_error_codeor-1: -1] [character: Ω result_code: 1 supplied_error_codeor-1: -1] [character: Π result_code: 1 supplied_error_codeor-1: -1] [character: @ result_code: -1 supplied_error_codeor-1: -1] [character: Ψ result_code: 1 supplied_error_codeor-1: -1] [character: Σ result_code: 1 supplied_error_codeor-1: -1] [character: Θ result_code: 1 supplied_error_codeor-1: -1] [character: $ result_code: -1 supplied_error_codeor-1: -1] [character: Ξ result_code: 1 supplied_error_codeor-1: -1] [character: Φ result_code: 1 supplied_error_codeor-1: -1]

[lukeaschenbrenner]

@fierytechknowhows Thanks for the reply. That's very valuable information, because although I am not implementing those Greek characters currently in TxtNet Browser, I had plans to add support for them in the future. It looks like your embed ended up as an image and not a video file, is there any way you can upload the video to a cloud storage provider or email me the video directly? Support was specific in mentioning they wanted a video that demonstrated the bug.

[fierytechknowhows]

I actually think the problem is Verizon now because i used Samsung's remote test lab for Developers which allows you to remotely connect to devices for testing and I connected to an S20 FE 5G running android 13 like mine except there wasn't a carrier tied to it. In Samsung messages it showed 0/1 for each character. I also used my old Galaxy Note 5 which is running android 7 and it used to be on verizon until it was deactivated when I upgraded. But it still showed 41/3 on the Note 5 in the default messages app so I actually think it's Verizon now.

[fierytechknowhows]

But here's the video just in case an update from Samsung could still fix it.

https://user-images.githubusercontent.com/19141632/219265898-b1e98ddb-30c5-4a66-b09c-79f6b7561324.mp4

[lukeaschenbrenner]

I actually think the problem is Verizon now because i used Samsung's remote test lab for Developers which allows you to remotely connect to devices for testing and I connected to an S20 FE 5G running android 13 like mine except there wasn't a carrier tied to it. In Samsung messages it showed 0/1 for each character. I also used my old Galaxy Note 5 which is running android 7 and it used to be on verizon until it was deactivated when I upgraded. But it still showed 41/3 on the Note 5 in the default messages app so I actually think it's Verizon now.

That is very interesting, thank you for letting me know. It's quite possible that it is related to the carrier-branded nature of the phones. Either this is a very long-standing OS issue that has existed since at least Android 7, or this issue is somehow present carrier-side on any smartphone, regardless of brand. A surefire way to test this theory would be to insert your SIM into an unlocked smartphone still compatible with Verizon, and checking the character limit there. Of course, it's unreasonable to expect you to have access to one of those to test. I've replied to Samsung with the information you've provided, so hopefully they will be able to track down the issue on their end. I will update you as soon as I receive a substantial response from Samsung. Thank you again for helping me test this issue!

[lukeaschenbrenner]

@fierytechknowhows I have received a message from developer support at Samsung: "We are requesting the complete build number of the device. The user has omitted the last part of the Build Number. Please provide us complete build number of the device. It would be something like TP1A.220624.014.G781VXXXXXXXX." I believe you may have only copied the part of the build number that shows up in the app. That was my mistake, as I did not make it clear that the build number displayed was not the full build number. You can hopefully find the full build number in Settings > About Phone > Software Information > Build Number. Thanks again.

[fierytechknowhows]

Oh ok here's the full build number: TP1A.220624.014.G781VSQS7GWA1

[fierytechknowhows]

So what's the status with Samsung?

[lukeaschenbrenner]

@fierytechknowhows I've been told the issue has been forwarded to the relevant team at Samsung and they are working to reproduce the issue. I'll provide you with more details as soon as they're available!

[lukeaschenbrenner]

@fierytechknowhows I received a response from Samsung support. The software engineer I spoke with said that their team "tested every character you mentioned ( £, ¥, è, Γ, Λ, Ω, Π, Ψ, Σ, Θ, Ξ, Φ ) in message apps (both Samsung and Google messages) and all of them fit into a single 160 character message on the same software version you mentioned (G781VSQS7GWA1)". Because they are unable to reproduce the issue you're experiencing, they are asking you to create a dumpstate log file so that they can analyze your specific case. Here are the steps that support provided me:

1. Dial *#9900#, Delete Dumpstate/logcat
2. Dial *#9900#, and Select Debug Level to MID. This restarts the device
3. Reproduce the issue (open the Test SMS Sender app and attempt to run the tests)
4. Again dial *#9900# and press “Run Dumpstate/logcat”
5. When it is finished press “Copy To SD Card (include CP Ramdump)
6. Now, use a file explorer to find the "log" folder on the root of the user filesystem. That directory should contain the dumpstate log file generated, having the name format: dumpState\<DEVICE MODEL>\<TIMESTAMP>

Please upload this log file to a file hosting service like Google Drive so that I am able to download it and forward it to the support team (or simply create a temporary GitHub repo and place the file in there).

[fierytechknowhows]

there was a .zip file and .log file with that name so I put both in there just in case but I'm guessing that only the .log file is needed. https://drive.google.com/drive/folders/1HvjUwL_wNk1c4dtE_yZo0DTTIYBCS71_?usp=share_link

[lukeaschenbrenner]

@fierytechknowhows Thanks for the help. I have finally received a response back from Samsung. They believe, like you suggested, that this is because of the network and that this is working as intended, because CDMA networks using CDMA2000 technologies somehow only support ASCII encoding, and not the GSM-7 alphabet. According to Wikipedia, Verizon, US Cellular, and Cellcom are the only US carriers still in operation that originated/support CDMA technology. Because of this, any smartphone using one of these carriers would not be able to run TxtNet Browser in its current state. Even though this is the same number of bits, because ASCII has 33 control characters, they go entirely wasted and are not representable without falling back to UCS-2 encoding. However, of course, this only applies to CDMA2000 (and by extension cdmaOne) technology, which was designed for 3G and 2G networks. According to Verizon's open development 4G SMS requirements (section 5.1.2.2.3), all smartphones using SMS over 4G should support message formats in both 3GPP2 and 3GPP standards. So, it seems that since Verizon has entirely shut down its CDMA network, the only reason that messages are encoding as ASCII is because Android queries the IMS to see if it supports 3GPP2, and if it does, defaults to CDMA encoding. If Verizon also does support 3GPP GSM-7 alphabet like they say in their document when messaging over 4G, then it might actually be a "bug" in Android to encode any control code ASCII character as whitespace. I have messaged Samsung back to see if they can test this theory and possibly fix the bug.

In the meantime, can you download the newest build of SMS Test Sender and run it again? Ideally, please try it twice, once using the default phone number, and another time using a phone number you know is subscribed to Verizon. Please copy both results to clipboard and share them! (If they are too long, you might want to consider just putting them into pastebin and sending a pastebin link over.) Thanks again.

[fierytechknowhows]

It gave the same for both times [character: £ result_code: 1 supplied_error_codeor-1: -1] [character: @ result_code: -1 supplied_error_codeor-1: -1] [character: ¥ result_code: 1 supplied_error_codeor-1: -1] [character: $ result_code: -1 supplied_error_codeor-1: -1] [character: è result_code: 1 supplied_error_codeor-1: -1] [character: Γ result_code: 1 supplied_error_codeor-1: -1] [character: Λ result_code: 1 supplied_error_codeor-1: -1] [character: Ω result_code: 1 supplied_error_codeor-1: -1] [character: Π result_code: 1 supplied_error_codeor-1: -1] [character: Ψ result_code: 1 supplied_error_codeor-1: -1] [character: Σ result_code: 1 supplied_error_codeor-1: -1] [character: Θ result_code: 1 supplied_error_codeor-1: -1] [character: Ξ result_code: 1 supplied_error_codeor-1: -1] [character: Φ result_code: 1 supplied_error_codeor-1: -1]

[lukeaschenbrenner]

Hmm... That's not what I would have expected the output to be. There should be more logs inside {{ }} brackets, for every message that sent successfully (just the @ and the $). If you haven't before can you try uninstalling and reinstalling the app? It's possible that maybe I uploaded an old version, but I'm pretty sure I didn't. If that doesn't work, I'll try more troubleshooting tomorrow.

[lukeaschenbrenner]

For reference, this is what it looks like when I run it (granted, I have no errors since all my messages send successfully).

 [character: @ result_code: -1 supplied_error_code_or_-1: -1]
 {{format: 3gpp}}
 {{delivery status for ID#1: [0], protocol identifier: [0], SMSC number: +12063130055}}
 [character: £ result_code: -1 supplied_error_code_or_-1: -1]
 [character: $ result_code: -1 supplied_error_code_or_-1: -1]
 [character: ¥ result_code: -1 supplied_error_code_or_-1: -1]
 {{format: 3gpp}}
 {{delivery status for ID#2: [0], protocol identifier: [0], SMSC number: +14054720057}}
 [character: è result_code: -1 supplied_error_code_or_-1: -1]
 [character: Γ result_code: -1 supplied_error_code_or_-1: -1]
 [character: Λ result_code: -1 supplied_error_code_or_-1: -1]
 {{format: 3gpp}}
 {{delivery status for ID#3: [0], protocol identifier: [0], SMSC number: +14054720105}}
 [character: Ω result_code: -1 supplied_error_code_or_-1: -1]
 [character: Π result_code: -1 supplied_error_code_or_-1: -1]
 [character: Ψ result_code: -1 supplied_error_code_or_-1: -1]
 {{format: 3gpp}}
 {{delivery status for ID#4: [0], protocol identifier: [0], SMSC number: +12063130078}}
 [character: Σ result_code: -1 supplied_error_code_or_-1: -1]
 {{format: 3gpp}}
 {{delivery status for ID#5: [0], protocol identifier: [0], SMSC number: +14054720105}}
 [character: Θ result_code: -1 supplied_error_code_or_-1: -1]
 [character: Ξ result_code: -1 supplied_error_code_or_-1: -1]
 [character: Φ result_code: -1 supplied_error_code_or_-1: -1]
 {{format: 3gpp}}
 {{delivery status for ID#6: [0], protocol identifier: [0], SMSC number: +12063130079}}
...

[fierytechknowhows]

[character: £ result_code: 1 supplied_error_codeor-1: -1] [character: @ result_code: -1 supplied_error_codeor-1: -1] [character: ¥ result_code: 1 supplied_error_codeor-1: -1] [character: $ result_code: -1 supplied_error_codeor-1: -1] [character: è result_code: 1 supplied_error_codeor-1: -1] {{format: 3gpp2}} {{delivery status for ID#1: [131072], protocol identifier: [0], SMSC number: +17632692641}} [character: Γ result_code: 1 supplied_error_codeor-1: -1] [character: Λ result_code: 1 supplied_error_codeor-1: -1] {{format: 3gpp2}} {{delivery status for ID#2: [131072], protocol identifier: [0], SMSC number: +17632692641}} [character: Ω result_code: 1 supplied_error_codeor-1: -1] [character: Π result_code: 1 supplied_error_codeor-1: -1] [character: Ψ result_code: 1 supplied_error_codeor-1: -1] [character: Σ result_code: 1 supplied_error_codeor-1: -1] [character: Θ result_code: 1 supplied_error_codeor-1: -1] [character: Ξ result_code: 1 supplied_error_codeor-1: -1] [character: Φ result_code: 1 supplied_error_codeor-1: -1]

[lukeaschenbrenner]

@fierytechknowhows Thanks for the info. Unfortunately Samsung Support has reached out to me and said that they are no longer pursuing this issue as it is considered intended behavior. I may have luck in contacting Google to review the CDMA SMS implementation of AOSP, but other than that, there is little else that can be done. I have been informed that all newer Samsung smartphones such as the Galaxy S23 no longer support CDMA provisioning and should work fine with Version using TxtNet. Because of this, I will be closing this issue for now. It only affects a small subset of users on a few carriers, so it's not an immediate priority. The one thing you can still try is to call Verizon and ask for your mobile service to be provisioned as "CDMA-less". It's a setting on their end that disables legacy 3G/2G CDMA support which is what causes this bug. This may be all it takes to disable the weird behavior caused by a query to support 3GPP2. If you do end up doing that, please let me know because then there will at least be a confirmed solution to this issue. Thanks for all your support throughout this entire process.

[lukeaschenbrenner]

Just to follow up, it looks like according to this Reddit thread the provisioning as CDMA-less method is almost definitely what you need to fix this issue. If you can, please try to do it, reboot your phone, and test again.

[fierytechknowhows]

They said they didn't have a cdma-less setting on their end

[lukeaschenbrenner]

@fierytechknowhows Thanks for checking. According to online forums you have to ask to talk with Network Tech. If they aren't familiar with CDMA-less, you need to ask to be transferred to the "direct tech". Ask them to add the CDMA-less feature to your account. Some Verizon representatives aren't familiar with the feature. I've done this personally when I still had Verizon a few years back, but it took talking with 3 reps before someone knew what I was talking about. Sorry for the troubles but I appreciate you looking into this.

[fierytechknowhows]

Could you try making it send messages as mms messages

[fierytechknowhows]

They knew what i was talking about but they still didn't have an option enable cdma-less saying its supposed to be enabled automatically.

[lukeaschenbrenner]

Okay, thanks for letting me know. Sadly there isn't anything else I can do right now. Like I said I will try to contact Google to see if they can look into possibly fixing that part of AOSP, but otherwise my only alternative would be to enable an ASCII-only backup mode in the app. I'm trying to avoid MMS because that essentially works through data as well, even though it's originally sent through SMS channels. If anyone else has Verizon service and could comment if they are able to send messages using the SMS Test Sender app, that would be very useful. I'm sorry that you won't be able to use TxtNet Browser right now and I want to enable as wide of compatibility as possible, so I will update this issue if an ASCII-only mode is released or if the issue is fixed on AOSP. Thanks again for all the help, I appreciate the time you've dedicated to tracking down this issue.