The firewall appears to be blocking outgoing text messages from my phone ...
-
@JKnott said in The firewall appears to be blocking outgoing text messages from my phone ...:
That doesn't fix the issue, it masks it.
For most people, it results in no difference in functionality. Again, I was just stating that getting a new phone (or phones) was not the only practical solution.
-
@dotdash Disabling IPv6 internally fixed it for me too. I have no use or need for IPv6 on my internal network so it will stay disabled forever or until there is a good reason to use it internally.
-
On my network I have a PC running various servers, pointed to externally by IPv6. While it is, of course, possible to remain mired in the past NAT'ing IPv4 that seemed a backwards approach to my new network installation. You're all free to take the approach you see fit, but seeing that Samsung is clearly a bugged device, I choose not to downgrade my new network to accommodate it. The 10Gb optical switch, running a few cables, and building and setting up pfSense was a serious undertaking. The hell with Samsung.
-
Not letting the companies involved know won't get it fixed either.
-
Having spent most of my career as a tech, it annoys me to see people who just accept a problem, without trying to get it resolved.
-
@JKnott said in The firewall appears to be blocking outgoing text messages from my phone ...:
Having spent most of my career as a tech, it annoys me to see people who just accept a problem, without trying to get it resolved.
You know it's nearly impossible to interact with Samsung as a consumer, and they probably already know anyway. It isn't my job to beta test their crap. From my perspective the problem is resolved - bad device identified and removed. Now, stuff I design? I test it and fix it.
-
As I mentioned, my cell company provides initial support for the phones they sell. If necessary, it then goes to the manufacturer. While Samsung may not listen to individuals, they're likely to pay more attention to major carriers.
However, if you don't try, nothing will happen.
-
@JKnott said in The firewall appears to be blocking outgoing text messages from my phone ...:
As I mentioned, my cell company provides initial support for the phones they sell. If necessary, it then goes to the manufacturer. While Samsung may not listen to individuals, they're likely to pay more attention to major carriers.
However, if you don't try, nothing will happen.
I already used Verizon support. Once you mention wifi they don't care. If it works on the cell tower, and it does, it's not their problem.
Let me tell you something I've learned about software bugs, which you're probably well aware of. When you buy a device with a bug, there is no guarantee when or even if it will be fixed. If you can't live with the bug, don't buy the product based on promises of a future fix. If you already have the device, and the bug is intolerable (which it is, in this case), your only sure solution is to ditch the product.
It may seem like I have a poor attitude towards this, and maybe I do. But my attitude has been shaped by these exact experiences of crap support. You seem pretty optimistic about the whole tech support process.
-
@lifespeed said in The firewall appears to be blocking outgoing text messages from my phone ...:
I already used Verizon support. Once you mention wifi they don't care. If it works on the cell tower, and it does, it's not their problem.
You might not recall but, a year ago, I had a similar sort of problem. IPv6 was failing on my Internet connection. I was able to demonstrate the problem to tier 2 support, but the people responsible for maintaining the network refused to look at it because I was using my own router (pfSense), despite the fact that I could even identify the failing system by name (thanks to Wireshark). Only by constantly pushing, even calling the office of the president, was I able to get them moving. a senior tech showed up at my home, with his own modem, and saw it also failed. He then took his modem to the head end, where it worked on 3 other systems, but failed on the one I was connected to and had identified. The responsible people then accepted it was their problem. So, if you make enough noise, things happen. Since you're clearly not the only one having the issue, make noise about it. Maybe someone in the right place will notice.
Also, isn't Verizon one of those companies that uses WiFi, via customer modems, to provide service to other customers? If so, then it's no longer just your problem. It will likely affect any customer that uses WiFi calling, even when away from home.
BTW, crap support happens because too many people let it happen.
-
From my Ubiquiti Unifi controller monitoring their 10Gb SFP+ switch and wireless access point:
Client Galaxy-Note9 is having trouble resolving a domain name to an IP address (DNS timeout). -
Can you do a packet capture of that? With a managed switch, you should be able to set up port mirroring, so that you can use Wireshark.
-
@JKnott I have a 1Gb Netgear GS716Tv3 (managed) uplinked to a 10Gb Ubiquiti US-16-XG (unmanaged). The WAP could be moved to the Netgear for port mirroring.
Do I plug a Wireshark laptop into the mirrored port and let it capture for a few hours until this event occurs?
-
Yes, you configure the mirror port so that it copies the traffic from the AP to the computer running Wireshark. You can set up filters to narrow down the captures. for example, you could have something like ether host <MAC address> and port 53. This will capture all DNS packets to/from the phone's MAC address, whether IPv4 or IPv6.
You could probably do the same with the pfSense Packet Capture, but I find Wireshark is better to work with.
-
Wireshark is awful. The Samsung Note9 IPv6 ends in 75a0, here is a capture while a wifi call was received (successfully) by Note9.
No. Time Source Destination Protocol Length Info 10262 4.084411 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 104 Standard query 0x9e25 AAAA settings.crashlytics.com 10265 4.101972 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 167 Standard query response 0x9e25 AAAA settings.crashlytics.com CNAME crashlytics.l.google.com AAAA 2607:f8b0:4005:809::2003 10267 4.105301 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 104 Standard query 0x8ebc A settings.crashlytics.com 10277 4.118522 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 155 Standard query response 0x8ebc A settings.crashlytics.com CNAME crashlytics.l.google.com A 172.217.6.35 11872 4.618443 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 97 Standard query 0xc948 AAAA e.crashlytics.com 11943 4.636643 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 273 Standard query response 0xc948 AAAA e.crashlytics.com CNAME events-endpoint-i-1172912053.us-east-1.elb.amazonaws.com SOA ns-1119.awsdns-11.org 11983 4.641550 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 97 Standard query 0x526e A e.crashlytics.com 12011 4.658921 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 292 Standard query response 0x526e A e.crashlytics.com CNAME events-endpoint-i-1172912053.us-east-1.elb.amazonaws.com A 54.227.236.206 A 54.235.102.234 A 54.235.130.173 A 54.235.139.111 A 54.235.145.134 A 54.235.153.229 A 54.225.77.36 A 54.225.80.137 12454 4.789122 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 104 Standard query 0xaf22 AAAA analytics.localytics.com 12457 4.806773 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 225 Standard query response 0xaf22 AAAA analytics.localytics.com CNAME queuer-prod-elb.53.localytics.com SOA ns-1150.awsdns-15.org 12458 4.811377 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 104 Standard query 0x788e A analytics.localytics.com 12485 4.853485 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 265 Standard query response 0x788e A analytics.localytics.com CNAME queuer-prod-elb.53.localytics.com A 52.204.176.87 A 52.204.205.76 A 34.232.55.250 A 34.234.107.175 A 34.234.135.110 A 34.239.78.187 A 52.71.187.57 A 52.72.139.236 31900 18.065314 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 105 Standard query 0xe763 AAAA lh3.googleusercontent.com 31901 18.080418 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 162 Standard query response 0xe763 AAAA lh3.googleusercontent.com CNAME googlehosted.l.googleusercontent.com AAAA 2607:f8b0:4005:807::2001 31903 18.083509 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 2601:646:8c03:52a0:225:90ff:febb:bf0c DNS 105 Standard query 0xf396 A lh3.googleusercontent.com 31905 18.083534 2601:646:8c03:52a0:225:90ff:febb:bf0c 2601:646:8c03:52a0:e0b9:xxxx:xxxx:75a0 DNS 171 Standard query response 0xf396 A lh3.googleusercontent.com CNAME googlehosted.l.googleusercontent.com A 172.217.6.65 -
Wireshark is a very useful tool. However, as it is fairly complex, there is a bit of a learning curve. However, that crashlytics serverr is actually Google.
I just see DNS query response pairs. Are there any failures there?
-
@JKnott said in The firewall appears to be blocking outgoing text messages from my phone ...:
I just see DNS query response pairs. Are there any failures there?
I guess not, will have to wait for it to fail and the spend an hour muddling through wireshark.
-
i just recently posted in 'wifi calling being blocked?' here's a copy paste of my response and how i got not only wifi calling, but all sms, mms as well. hope this helps
edit additional: i believe this would also affect the carrier's video calling feature as well, the baked into android phone app not like google duo or hangouts etc etc.:"ok yea this is almost a year later however:
had this issue - 2.4.5RC packages installed or not didn't matter, wifi calling and MMS would not work
was using solely cloudflare dns. yes dnssec ssl/tls
added google and quad9 dnssec tls/ssl
(i dont think enabling the checkbox for dnssec or all of the other dnssec extras matter as i had the issue before setting it up as well)
success
for me, the problem is the mobile carrier proxy being an RFC 1918 address, pfsense allows this out from what i could tell, even with the rfc 1918 and bogon blocking enabled on the wan not lan (as expected), but i suspect cloudflare might also have these blocked in such a way - which could explain why the return trip would timeout (see next).
for the return trip, it did not return from their internal proxy but rather their external facing 'exit point' (i verified this by running traceroute from my phone while on cell service with hetools to my wan ip address)
added their hostnames to whitelist to be safe.
if i should post this new elsewhere or something, would someone kindly let me know? thanks"
-
@sparkyMcpenguin thanks for sharing. I also had Cloudflare as the sole DNS lookup, but have now added DNSwatch and Quad9. I don't think I'm set up for DNSsec, not sure where that is in pfSense. Will report back if the problem goes away. It is hit or miss so could take a few days.
-
@lifespeed what I did after changing settings was just reload unbound, pfblockerng, dnsbl, and snort. No need to restart or wait too long. Cron update as well is what I did. Hope it works!
Edit additional: I checked my phone APN settings, added their "mmsc" and "proxy" to the whitelist in dnsbl, host name and IP (excessive, but this was only added AFTER verifying it working adding additional DNS servers)
Also, I do not "allow upstream DNS" the forwarding setting. pfsense first, then cloudflare, quad9, Google
Edit: Last "also" I have a feeling the Google DNS is what really did it, at least for me, you know cause android, and I'm sure iPhone works too cause they mostly use Google DNS as well from what I remember
-
@lifespeed as for dnssec uh general setup under system and then the DNS resolver or forwarder had another checkbox I think. Check out dnsprivacy.org
