IPv6 support using Parse.com - parse-platform

My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.

I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)

Related

random ssl certification failure

I just setup a custom domain for an AWS API Gateway and set up CNAME entries in Google Domains to redirect to my API Gateway. After maybe 30 minutes of waiting I was able to use Chrome to do a simple GET request to my custom domain that properly forwarded to my API Gateway. I tested in Firefox and it worked fine too.
About 3-4 hours later I came back and tried making the same call using Python requests and it worked the first 3 times then failed.
SSLError: HTTPSConnectionPool(host='ids.references.app', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError("hostname '<my_custom_domain>' doesn't match '*.execute-api.us-east-2.amazonaws.com'")))
At first I thought this was a requests problem, but then I opened up Firefox and it didn't work as well. I tried Edge and the call worked. Then I went back to Python and it worked for a bit, then stopped working. I went back to Firefox and it no longer worked. Then I tried Edge and it no longer worked. Sprinkled in there I've tried Chrome and it has worked every time since it started working. (this order of events is from memory and may be slightly off).
Is this a known issue with updating DNS entries that you get some randomness when things first start until the DNS changes have fully propagated. How would I go about even tracking where the error is occurring? I think that's the most frustrating thing about this, it all seems like magic and there's no obvious point where you get something like server 1.2.3.4 says that cert_1 doesn't go with cert_2 and then later you see something like server 4.5.6.7 says cert_2 is all good (so it works). Would I need to install curl for Windows (Is is possible to make a cURL request and get the route that is taken (similar to traceroute)). Would this even matter though? What if curl was like Chrome, it always worked? Does requests have this functionality (bonus points if someone can show a requests solution)? What about Firefox or Chrome? Or could I use something like wireshark (yikes) that could somehow observe the whole system?
I'm using requests 2.25.1 and Python 3.8.5 on Windows 10 and I believe the latest versions of Edge and Firefox.

Windows 10 SNMP service not responding

I'm trying to get my head around SNMP for a project I'm working on. After I failed miserably getting it to work in my company's network, I set up a simple 3-device network to test things on, consisting of two Windows 10 PCs and a manageable switch between them.
I installed the optional feature "SNMP" on both PCs, made sure the service is running correctly and configured both services to accept SNMP queries from each other. I made sure to open up UDP port 161 in both PCs firewalls. Then I got the Net-SNMP binaries in order to use SNMPGET and SNMPWALK. As an alternative, I set up the SNMP extension for PHP through xampp (since I want to use PHP in my project once I get SNMP to work). Finally, I installed wireshark to monitor what exactly is going on and this is what I found:
When I try SNMPGET or SNMPWALK either through cmd or as a PHP command, I always get a timeout message. Wireshark is showing the get-next-request leaving one PC and arriving correctly on the other, so the network connection itself is working fine. But the receiving PC never sends a response. As I said, I'm pretty new to SNMP and I'm at a loss as to why this is happening. As I understand it, the optional feature for Windows 10 comes with its own SNMP agent, correct? If so, what could cause it to simply ignore an incoming request from a valid source IP?
The funny thing is that this even happens when I try to send an SNMP query to 127.0.0.1. I have no idea what I'm doing wrong...
Thanks to the comment of Lex Li, I was able to finally figure out which step I made a mistake with:
When setting up the SNMP service, under the security tab, I had to add 'public' as an accepted community name (with READ-ONLY rights). I figured since 'public' is sort of the standard read-only community, it would be accepted by default, which apparently it is not.
Alternatively, I guess I could have added my own communtiy name, but I didn't try that since I only want to read some values through SNMP anyways and read-only access is all I need for that.
Thank you very much Lex Li, I'm off to continue my project now!

Status read failed: Connection reset by peer at /usr/lib/perl5/site_perl/5.8.8/Net/HTTP/Methods.pm line 265

I am a self-learning in coding never attend a lesson. This issue is quite annoying as i find nothing clue in internet. Recently my website get somethings wrong suddenly when i submit any form with post method. I cannot confirm this is a server problem or coding problem (as laravel can spot the bug i made but nothing wrong).
Status read failed: Connection reset by peer at /usr/lib/perl5/site_perl/5.8.8/Net/HTTP/Methods.pm line 265.
The issue occurred only when using mobile network. I tried:
Together with my computer (boardband) and mobile (mobile network). Only mobile cannot process.
the same mobile first with mobile network -> cannot work.
Change to WIFI signal -> work.
Change back to mobile network -> cannot work again.
Two to three mobiles with different networks. All shows the same above.
Anyway to debug or find out what happen? Many thanks for your help.

Apns test with ad hoc provisioning

I'm developing an App that works with Apple push notifications but I have some problems testing.
I have tested the app in the sandbox and it all works fine: it can send and receive push notifications, but for one single device (I think that is the correct behavior for an sandbox release).
But when I have create an ad hoc version with his production provisioning I have the same behavior: only one device works fine, it sends and receives the push, but the others devices do not receive any push. All devices can send a push but only the the first one can receive.
After installing 'PersistentConnectionLogging.mobileconfig' on devices that can't receive a push, I can read on the console:
Sep 7 13:17:51 unknown apsd[49] <Warning>: <APSCourier: 0x25a0a0>: Received message for enabled topic 'myapp.name' with payload '(null)'
Sep 7 13:17:51 unknown apsd[49] <Warning>: <APSCourier: 0x25a0a0>: Failed to parse JSON message payload for topic 'myapp.name': The operation couldn’-t -b-e -c-o-m-p-l-e-t-e-d-. -(-C-o-c-o-a -e-r-r-o-r -3-8-4-0-.-)
I can't resolve the issue, I have regenerated the provisioning profile many times and all work fine on server sides connections, the Apple feedback is OK.
I have checked my stored devices token and sandbox and production are different, any suggestions?
Amalgamation of comments posted as an answer, on request: (these helped to break the problem down and identify where the error was occuring)
How/where are you storing your device tokens? How are you generating the message to be pushed?
Your code that connects to the push servers and creates the payload... how is it sending to >1 devices?
I don't know the easyApns code, but either your other device tokens are invalid or the code is not looping correctly to push the message to the other devices. Also, have a browse through Google for the cocoa error 3840 and see if anything helps you to better understand the issue. Else pick some different push code, have a look at [link below] as a starting point.
http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12

Irregular socket errors (10054) on Windows application

I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes
running on different hosts in an intranet.
Processes communicate with each other using TCP/IP. Different processes can be on the
same host or on different hosts (i.e. the communication can be both within the same
host or between different hosts).
We have currently a bug that appears irregularly. The communication seems to work
for a while, then it stops working. Then it works again for some time.
When the communication does not work, we get an error (apparently while a process
was trying to send data). The call looks like this:
send(socket, (char *) data, (int) data_size, 0);
By inspecting the error code we get from
WSAGetLastError()
we see that it is an error 10054. Here is what I found in the Microsoft documentation
(see here):
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
So, as far as I understand, the connection was interrupted by the receiving process.
In some cases this error is (AFAIK) correct: one process has terminated and
is therefore not reachable. In other cases both the sender and receiver are running
and logging activity, but they cannot communicate due to the above error (the error
is reported in the logs).
My questions.
What does the SO_LINGER option mean?
What is a keep-alive activity and how can it break a connection?
How is it possible to avoid this problem or recover from it?
Regarding the last question. The first solution we tried (actually, it is rather a
workaround) was resending the message when the error occurs. Unfortunately, the
same error occurs over and over again for a while (a few minutes). So this is not
a solution.
At the moment we do not understand if we have a software problem or a configuration
issue: maybe we should check something in the windows registry?
One hypothesis was that the OS runs out of ephemeral ports (in case connections are
closed but ports are not released because of TcpTimedWaitDelay), but by analyzing
this issue we think that there should be plenty of them: the problem occurs even
if messages are not sent too frequently between processes. However, we still are not
100% sure that we can exclude this: can ephemeral ports get lost in some way (???)
Another detail that might help is that sending and receiving occurs in each process
concurrently in separate threads: are there any shared data structures in the
TCP/IP libraries that might get corrupted?
What is also very strange is that the problem occurs irregularly: communication works
OK for a few minutes, then it does not work for a few minutes, then it works again.
Thank you for any ideas and suggestions.
EDIT
Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.
That error means that the connection was closed by the
remote site. So you cannot do anything on your programm except to accept that the connection is broken.
I was facing this problem for some days recently and found out that Adobe Acrobat Reader update was the culprit. As soon as you completely uninstall Adobe from the system everything returns back to normal.
I spent a long time debugging a 10054/10053 error in s3 pre-signed uploads
Turns out that the s3 server will reject pre-signed s3 uploads for the first 15 minutes of it's life.
So - If you're debugging s3 check it's not a new bucket.
If you're debugging something else - this is most likely a problem on the server side not client side.

Resources