I'm trying to connect to an Exchange Web Services server which used to work from CFNetwork prior to October 7, but doesn't any more. I don't see any packages that were installed around this time so I'm guessing it was a server change.
I think this is proxied somehow (I don't run the server or have access to it) as some URLs work on this server but some don't. You don't even get prompted for authentication. The server is email dot fahc dot org. You should be able to get an OWA login page, but trying to access an EWS URL (e.g. /ews/Services.wsdl) doesn't work. I have no problems logging into it from Firefox or Chrome, but Safari, Mail, my own apps, etc. are broken.
This is broken on OS X 10.11 and macOS 10.12; OS X 10.10 is fine.
Here's what I get when testing with nscurl with CFNetwork diagnostics enabled. I see it trying to fall back from TLS 1.2 to 1.1 to 1.0, which works elsewhere, but I don't see any more specific errors than 89 (ECANCELED), which is somewhat less than helpful.
Oct 26 14:31:56 nscurl[15026] <Notice>: CFNetwork Diagnostics [3:37] 14:31:56.438 {
Did Fail
Loader: <CFURLRequest 0x7ffbc0502ed0 [0x7fff7552c440]> {url = https://[...]/ews/Services.wsdl, cs = 0x0}
Error: Error Domain=NSPOSIXErrorDomain Code=89 "Operation canceled" UserInfo={NSErrorPeerAddressKey=<CFData 0x7ffbc063a550 [0x7fff7552c440]>{length = 16, capacity = 16, bytes = 0x100201bb0a801e2e0000000000000000}, _kCFStreamErrorCodeKey=89, _kCFStreamErrorDomainKey=1}
init to origin load: 0.00233305s
total time: 0.205145s
total bytes: 0
} [3:37]
Any ideas how I can dig into this further, or should I just file a bug?
Thanks.
This appears to be related to VMware NAT. After switching my VM to bridged networking, this issue disappeared (on both the 10.11 host and 10.12 guest). Thanks to #mikeymikey on Twitter for the suggestion.
Related
I have a Windows application (APP) and Audio Processing Object (APO) loaded by AudioDG.exe that communicate via gRPC:
APP part that is written in C# creates server via Grpc.Core.
APO part creates client via grpc++.
Server is on 127.0.0.1:20000 (I can see it's up and listening with netstat -ano).
I can confirm that APO is loaded into audio device graph by inspecting it with process explorer.
Everything worked like a charm on Windows 8 and 10, but on 11 it cannot communicate at all - I get either Error Code 14, Unavailable, failed to connect to all addresses or 4, Deadline Exceeded.
After enabling debug traces, I now see "socket is null" description for "connect failed" error:
I0207 16:20:59.916447 0 ..\..\..\src\core\ext\filters\client_channel\subchannel.cc:950: subchannel 000001D8B9B01E20 {address=ipv4:127.0.0.1:10000, args=grpc.client_channel_factory=0x1d8bb660460, grpc.default_authority=127.0.0.1:10000, grpc.internal.subchannel_pool=0x1d8b8c291b0, grpc.primary_user_agent=grpc-csharp/2.43.0 (.NET Framework 4.8.4470.0; CLR 4.0.30319.42000; net45; x64), grpc.resource_quota=0x1d8b8c28d90, grpc.server_uri=dns:///127.0.0.1:10000}: connect failed: {"created":"#1644240059.916000000","description":"socket is null","file":"..\..\..\src\core\lib\iomgr\tcp_client_windows.cc","file_line":112}
What I've tried so far:
Updating both parts to the latest grpc versions.
Using "no proxy", "Http2UnencryptedSupport" and other env variables.
Using "localhost" or "0.0.0.0" instead of "127.0.0.1".
Updating connection to use self signed SSL certificates (root CA, server cert + key, client cert + key).
Adding inbound / outbound rules for my port, and then disabling firewall completely.
Creating server on APO side and trying to connect with the client in APP.
Everything works (both insecure and SSL creds) if I create both client and server in C# part, but as soon as it's APP-APO communication it feels blocked or sandboxed.
What has been changed in Windows 11 that can "block" gRPC?
Thanks in advance!
In your input you write:
Server is at 127.0.0.1:20000
Further looking at the logs, you can see that:
The server is located at
grpc.server_uri=dns:///127.0.0.1:10000
Based on the question posed and the amount of data provided, I would check which port the server is really using and which port the client is looking for a connection on.
The easiest way to do this is to use the built-in Resource Monitor application. On the Network tab, in the TCP Connections list, you can find the application and the port it uses.
You can also use the PowerShell command
Test-NetConnection -Port 10000 -InformationLevel "Detailed"
Test-NetConnection -Port 20000 -InformationLevel "Detailed"
At least this is the first thing I would check based on what you described.
Regarding your question about the changes in Windows 11, I do not think that this is something that's causing problems for you. However, Windows 11 has additional security features compared to Windows 10, try disabling the security features completely as a test. Perhaps this will help solve the problem.
As for ASP.NET Core 6.0 itself (if I understood the version correctly), then there is a possibility that the server part, working not in the sandbox of the programming environment, still does not accept the client certificate. At the program level, you can try to fix this by adding the following exception to the code:
// This switch must be set before creating the GrpcChannel/HttpClient.
AppContext.SetSwitch(
"System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
// The port number(5000) must match the port of the gRPC server.
var channel = GrpcChannel.ForAddress("http://localhost:5000");
var client = new Greet.GreeterClient(channel);
More troubleshooting issues with ASP.NET Core 6.0 Microsoft described in detail here.
https://learn.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-6.0
I hope it was useful and at least one of the solutions I suggested will help solve your problem. In any case, if I had more information, I think I could help you more accurately.
When connecting to an ESP32 in softAP mode from an ESP32 client, the client connects and disconnects just fine for a while. Eventually, the AP will show the following error:
dhcps: send_offer>>udp_sendto result ffffffff
The client connects but doesn't get a lease. If I try to connect from another device, like my
iPhone, it doesn't get a lease either. If I set the client as static, it works just fine even after the server stops responding to DHCP request. Stopping and starting the DHCP server doesn't fix it.
I'm using AsyncTCP (me-no-dev Oct 17, 2019 version) on the server. I'm using the 1.12.2 Espressif 32 board library in PlatformIO. (Didn't work with 1.12.1 either)
Any idea why I'm unable to obtain a lease? Rebooting the AP does fix the issue so it doesn't appear to be an issue with the client.
I ran out of heap space. In AsyncTCP you have to explicitly free and delete the point.
https://gitter.im/espressif/arduino-esp32?at=5d6d213329dba2421ceea2c8
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 :)
I am debugging a very odd problem I noticed when testing in my own network. (It doesn't appear to happen on other servers outside my network) where random http requests fail.
I have tried it on two apache servers on my network, and it happens about 1 out of every 100 requests with 2 different apache servers.
I thought it was front-end related, but it appears something to do with my internal network OR configuration. I installed Charles proxy on my machine and used my phone to make the requests in the appellation. (Ajax)
The ajax/http request is being made but it is never making it into my access logs and I am getting the error "Remote Server closed the connection before sending the response header"
How can I debug this further?
NOTE: Also worth noting I can only reproduce problem on mobile iPhone + iPad devices when connecting to the server on the machine. (EVEN when using http proxy...which is very odd)
EDIT:
I did a wireshark capture for port 80 from the server computer and accessing it from iPhone. I am having a hard time interpreting it.
Here is the link to the capture files:
CAPTURE 1 (iOS 8 iPhone):
https://www.dropbox.com/s/1ipruv3wlmgng5o/http%20capture%20bad.pcapng?dl=0
NOTE: The error happens after the LAST post to sales/add_payment
CAPTURE 2 (iOS 8 iPhone):
https://www.dropbox.com/s/4zu3654uh9l6230/http%20capture%20bad%202.pcapng?dl=0
NOTE: The error happens after the LAST post to sales/complete
CAPTURE 3 (Android 4.4):
https://www.dropbox.com/s/8xtwkbewce02psw/http%20capture%20android%201.pcapng?dl=0
FOLLOW UP:
If it is indeed faulty network equipment, how do I determine what is bad? (device, router, modem?)
My company is currently using TortoiseSVN 1.6.16 32-bit on Windows XP to connect via HTTPS to a VisualSVN-Server 2.1.19 running on a Windows Server 2003 residing in the same network (no proxy). We use a self-signed certificate and Kerberos authentication using windows credentials (I suppose this is a VisualSVN-specific feature). In this setup, everything works dandy.
When my company decided to move on to Windows 7, we tried TortoiseSVN 1.7.6 64-bit on Windows 7 64-bit which resulted in the following problem:
Any operation involving the server (repo-browser, checkout, update, checkin, ...) is unbearably slow e.g.
opening the repo-browser (10 projects): 15 min
update on a fresh checkout of 50 files: 1 min
checkin of a single empty file: 30 sec
Tortoise shows alternatively normal transmission speeds and 0 byte/s. Many small files seem to be slower than a few big ones.
The slow connection results in various failures when using neon as http-lib (serf is still slow, but operation finishes successfully without errors)
EasySVN, SmartSVN and the SVN command line client that comes with TortoiseSVN show the same behaviour. Same with TortoiseSVN 1.6.16 64-bit.
Changing the server protocol to HTTP (no SSL) does not improve the situation
On the other hand
TortoiseSVN 1.7.6 32-bit on Windows XP works fine with our server
Access via browser/WebDAV works well even under Windows 7
Server side logs do not show errors or even warnings
I found several posts which also complained about slow behaviour on Windows 7, but they didn't fit my bill because they were local operations or were restricted to TortoiseSVN.
As there is no indication that there is a general problem with Subversion on Windows 7, I suspect that it could be our OS' networking parameters or protocol versions. Are there any parameters which are known to influence Subversion's performance?
I have to admit I am not familiar with how exactly Subversion (or rather neon/serf) relies on the OS and on which parts. Any information on that would be greatly appreciated.
Are there any parameters in the subversion 'servers' file which I should test? How would you consider my chances that Wireshark'ing the connection will help me?
Similar experiences, opinions, hints, help and straws are welcome.
Wireshark shows sporadic gaps of ca. 5 sec in the TCP stream apparently caused by VisualSVN Server.
https: the server acknowledges the client hello then waits for 5 secs before sending its server hello
https: the server acknowledges the client key and than takes 5 secs before supplying its encrypted handshake data
https: even outside the handshake, server sometimes sends an ACK (on TCP level) and then waits for 5 sec before sending something back to the client (the data is encrypted so it's hard to tell whether the break occurs at some point of interest)
http: at both server side transmissions during the NTLM authentication
http: before server sending a FIN flag
A typical fail with Windows 7 against an older server is IPv6 networking.
If your machine does not have an SVN server listening on an IPv6 address Windows 7 might still try to do a TCP6 connect first (you can see it in Process Explorer if you look at the open sockets of the TortoiseSVN process while trying an operation), this has a timeout of a few seconds and then retries with IPv4.
Simple solutions are either upgrade your server to an IPv6 capable one or disable IPv6 for the Windows 7 clients.
Another thing you could verify (the answer above didn't work for us) is the Internet Explorer settings especially if you have IE9. We found that by disabling the option Automatically detect settings in the Internet Options -> Connection tab -> LAN settings, SVN started working normally again.
The issue was never properly cleared up. Most probably, the company internal network path between the client and the server was somehow at fault. The matter became obsolete when we moved the SVN server to another machine. The very same setup of server and clients works fine now, even with Windows 7.
I had the same symptom of a very slow repository browse, slow updates, slow everything.
My SVN server has two Ethernet cards, so it has two Ethernet IP addresses. The SVN server was only listening on one of the IP addresses. So a name resolution via WINS or NetBIOS could resolve to the 'wrong' IP address.
TortoiseSVN would retry, eventually the name resolution would find the 'correct' IP address, and things would work.