Source: See http://geekswithblogs.net/mkoerner/archive/2010/12/06/w006.15-isp-or-t-mobile-network-error.aspx
Recommendation: As posted in the link above, turning off "Block Fragmented Packets" on my home router/firewall corrected this problem right away. (You can also witness this problem by enabling and checking your router/firelogs connection log.)
Extent: This problem also seems to exist with several other WiFi access points around my area and other places I have traveled. Note: I suspect some of those WiFi-Calling problems could also be purposefully/unintentionally blocked by being too secure (such as not permitting or enabling UDP ports 4500 and maybe 500?). But many had their router in default configurations, which should have been fine with WiFi-Calling, but was not.
Discussion: It took me numerous hours with T-Mobile support, and several HTC Sensation phones to discover the WiFi Calling UDP incoming packet fragementation problem. This error magically occured after several months of very heavy WiFi calling usage without problems. Then all of a sudden WiFi Calling stopped for several days (untile I disable "Block Fragmented Packets" on my router/firewall). Now WiFi calling works, but I have created a security vulnerability in my firewall.
Problem: Without better network diagnostic equipment, I supsect that the T-Mobile WiFi-Calling server is 1) sending too large of UDP packets so must be fragemented along the way, and/or 2) not properly/adequaetly checking and/or adjusting UDP packet size based on (some offset of) packet MTU sizes (sometimes a problem when traffic is tunneled or constricted along the way with additional overhead (such as ATM, SONET, etc.)) I suspect that the T-Mobile WiFi-Calling server team could fix this on their end if they wanted (or knew) to.
Poor Man's Test: If you happen to also have an old Blackberry that can do WiFi-Calling, and you do not have accees to the router/firewall logs; then if WiFi calling works with the Blackberry and not with your (Android) smart phone, then I would expect UDP Packet Fragementation discussed above to be the problem.
Question: Please let me know if this helps or if you have other WiFi Calling solutions. WiFi Calling is very important to me since I live in a "deadish" cell zone.
Post away my friend. That was great information. Have a great one!
I've always wondered why it sometimes worked at home (and sometimes not), and this is the first time I've seen any sort of explanation as to how finicky it could be.
Personally, it was out for about a month at my home, but mostly fine at the school I go to. When I threw iptraf at my Linux server/router, it would show the first few replies being sent back and forth only using packets of less than 200 bytes, only to fail completely when m015636d0.tmodns.net (or one of the other servers, didn't copy the "bad" one down) would send a 2392 byte packet. Knowing that the average router/switch that connects most every Ethernet system defaults to a 1500 byte packet, there was absolutely nothing I could do to not have such a packet fragment. thus causing my W006.15 error.
Of course, now it's working by sending much smaller packets (though it takes some time to connect), so I'm guessing someone realized what was happening without me having to try to see who to contact to get such a thing fixed.
I am having the same problem on my home wifi. The Android wifi calling works everywhere but home, although it did work at one point and i don't know what changed. I do see packet dropped in the log sometimes but my wifi router is too cheap to have the setting to ignore that.
My UMA phone works from home, which doesn't really help matters.
I did turn on IPSEC and that didn't change anything. Tried enabling PPTP and Gaming Mode, no change.
Hoping someone from the wifi support is looking at this and tweaks it. Regular support rarely knows what wifi calling even is.
It isn't so much a question of IPSec support, but more of a VPN support issue. Outside of running wireshark or some other packet sniffer between your router and whatever service you use to determine what's happening, it becomes incredibly hard to diagnose the issue at hand.
For me, I knew that the initial handshake worked fine, but the response back was that huge packet that was guaranteed to fragment, and UDP packets require a different protocol handle any fragmentation. I have this feeling that it's purely a question of which WiFi Calling server you reach that determines if it sends out big packets or not, and then it becomes a question of if your network hardware can create a VPN IPSec tunnel.
That makes sense, thanks for the insight.
This evening I changed equipment back to the trusty older DSL device and whaddayaknow, wifi calling is up and happy again. Looks like I can pretty much blame the cheapo wifi router. There is a firmware update for it, but I've been avoiding doing it. I found deny errors in the cheapo router's logs with the IPs for the servers at T-mobile, and even after I painstakingly added allow rules for every one of their servers, still I could not get past the error on the phone. I even tried the DMZ trick I read in another thread, and either it just doesn't work or my router doesn't do that right, either. It was frustrating, but at least I could go back to the old modem router combo. I had swapped to the newer one in search of the speed I am supposed to be getting, and besides causing collateral damage to services I need, I also did not get any speed improvement. Tonight the connection speed is good, so who knows.
Best wishes, and good luck getting yours working.
Heh, mine's been working fine for the past few days, with absolutely no effort on my part
Out of curiousity, what device did you replace with what? Personally, I'm using a separate DSL modem that connects to my Linux server/router, which connects to my 16 port Gigabit switch, which then spreads out to everything else, including the DIR-601 that provides wireless access. I just had to make sure that everything supported IPSec properly, followed by making sure the VPN worked fine (which required making sure the firewall didn't explicitly block that stuff).
Now I just get to figure out how to get IPv6 up in my home network for kicks
I actually have 3 DSL devices, a Speedstream 5660, Speedstream 5360 and a Embarq Zyxel 660. I can swap around if I suspect that one has finally reached the EOL. The cheapo wifi router is a Trendnet TEW 432BRP that I got on sale when CompUSA was closing the local store, and I did not get my rebate, btw.
I haven't had a good reason to replace any of it yet, although this episode came close. There is a firmware update for the wifi device, but I never got frustrated enough to apply it.
I think my wifi calling issue was at Centurylink, as it's gone now.
That is strange, how replacing the modem itself seems to have fixed your issue. Right now mine's gone bad again (m2b4a36d0.tmodns.net is sending 2316 byte packets at me), so I might see about forcing a different server on my end somehow...
I encountered this problem after replacing my Vonage VWR router with an Asus RT-N65U wireless router. Thanks to this post I was able to find the solution. In my case I had to enable IPSEC passthrough (Advanced Settings --> WAN, NAT Passthrough tab). WiFi calling is working again! Thank you!
I have this problem too. I disabled dropping fragments on my router but this did not help unfortunately. I've been spending the better part of the day re-flashing my ROM and wiping all sorts of caches to try to get it working until I found this very helpful thread. I did get it working for a short time but I suspect now I was just out of pure luck landing on a better node.
I proved it to myself that it has something to do with the TMO node I landed up on by connecting through my Verizon MiFi card for wireless. Wifi Calling worked first try! Of course I can't use my MiFi card all day for this, I want my regular home wireless to just work.
I'm going to have to do some snooping around with what's going on using wireshark but have to postpone this to when I have the time. I haven't had any equipment or software changes at all to cause this, it's just purely ending up on a bad TMO UMA node.
The thing is there are other elements in play that I don't have full control of how they react to various situations on my home network. I've got several NetGear switches, a Comcast cable modem, a NetGear 802.11n WAP w/dd-wrt running ... I tried dropping all my restrictive firewall rules and no help.
I think this basically just means TMO has to fix their stuff but if I want to enjoy Wifi Calling (which is very important for me as my apartment is a cell dead zone) I may have to investigate a possible workaround on my own end for their broken stuff. Large corporations like TMO work very slowly as far as resolving these sorts of problems. Too much red tape, too many apathetic people...
I've always wondered if doing something like that would work (WIFi Calling through a personal WiFi Hotspot). Personally, I think that the IP address that you connect through plays a role in determining which server you get doled out more than anything, and simply trying to force a server probably won't work, since it would invalidate the VPN handshake at the beginning. Worst part is whenever one of the UMA nodes decide to send out one of those giant packets, they'll more than likely fragment somewhere along the line and thus fail entirely without the server realizing exactly quite why (UDP is like that).
Regardless, best of luck with whatever route you go through to get it somewhat working!
I used Wifi Calling over a personal hotspot in the past. I went Las Vegas once and TMO coverage was so terrible, so I required a personal hot spot just to make calls.
I believe it is some sort of IP affinity thing too. I wish they would just fix their nodes ... I wonder how long the cache TTL on their IP affinity is ... I'm probably going to call and bug them about this.
Retrieving data ...