Using Fiddler to debug the Windows Phone 7 emulator - debugging

I recently started using the updated beta tools for Windows Phone 7 and ran into an interesting problem. It seems that with Fiddler running, any Http requests run through the emulator start returning a null result and create a "not found" web exception. This is easy to reproduce with WebClient.DownloadStringAsync(). The old versions of the emulator did work with Fiddler if I remember correctly. Has anyone had luck getting the two to work together? If it's not possible I'd be open to any other tool that could help debug web requests from the WP7 emulator.

It looks like there is a blog post that describes getting fiddler working with Win Phone 7 through some customized rules for setting up Fiddler as a Reverse Proxy.
Here is a little bit of the instructions from the fiddler website, but the blog post seems a little clearer (sorry for wacky format, the block quote is not cooperating):
Option #1: Configure Fiddler as a
Reverse-Proxy Fiddler can be
configured so that any traffic sent to
http://127.0.0.1:8888 is automatically
sent to a different port on the same
machine. To set this configuration:
Start REGEDIT Create a new DWORD named
ReverseProxyForPort inside
HKCU\SOFTWARE\Microsoft\Fiddler
Set the DWORD to the local port you'd like
to re-route inbound traffic to
(generally port 80 for a standard HTTP
server) Restart Fiddler Navigate your
browser to http://127.0.0.1:8888
Option #2: Write a FiddlerScript rule
Alternatively, you can write a rule
that does the same thing.
Say you're running a website on port
80 of a machine named WEBSERVER.
You're connecting to the website using
Internet Explorer Mobile Edition on a
Windows SmartPhone device for which
you cannot configure the web proxy.
You want to capture the traffic from
the phone and the server's response.
Start Fiddler on the WEBSERVER
machine, running on the default port
of 8888. Click Tools | Fiddler
Options, and ensure the "Allow remote
clients to connect" checkbox is
checked. Restart if needed. Choose
Rules | Customize Rules. Inside the
OnBeforeRequest handler, add a new
line of code: if
(oSession.host.toLowerCase() ==
"webserver:8888") oSession.host =
"webserver:80"; On the SmartPhone,
navigate to http://webserver:8888
Requests from the SmartPhone will
appear in Fiddler. The requests are
forwarded from port 8888 to port 80
where the webserver is running. The
responses are sent back through
Fiddler to the SmartPhone, which has
no idea that the content originally
came from port 80.

I'm not able to get Fiddler to monitor the traffic, so I use WireShark, which works fine.

Related

gRPC stopped working with APO on Windows 11

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.

Is there a way to implement captive portal on windows hotspot?

I am looking for a way to implement a captive portal for the windows 10 - mobile hotspot. The idea is to redirect all devices that connect to the hotspot to a webpage.
I was able to find this article which shows how to do it in linux.
But I have been unsuccessful in finding a similar one for windows. Posts like this one proved to be dead ends.
I am okay with using a simple nginx server to give 302 redirect response to clients if needed, but prefer not to use any existing software that implements a captive portal.
UPDATE
I have succeeded in triggering a captive portal on clients (linux laptop, android device etc) using a workaround.
Whenever a device connects to the hotspot it sends a request to some predefined websites to check if the wifi connection has internet access. If it gets a 302 response it generates the captive portal window.
So I added the following entries to the hosts file on windows machine.
127.0.0.1 clients3.google.com #android
127.0.0.1 connectivitycheck.gstatic.com #android
127.0.0.1 nmcheck.gnome.org #ubuntu
These requests will then be resolved locally using the hosts file entries and sent to the nginx server which gives a 302 redirect to all http requests.
The setup I mentioned in the UPDATE above was tweaked finally to get where I wanted. I used dnschef, an open-source dns server that works perfectly as a command line client.
The steps followed.
Start windows mobile hotspot.
Go to Network adapters => Select hotspot adapter => Change IPv4 settings => set 127.0.0.1 as DNS server.
Start dnschef with --fakeip = 192.168.137.1
Start an http server on 192.168.137.1 and give 302 redirect response to all requests.
And that's it! Whenever a device connects to the hotspot, it will attempt to connect to any one of the preset websites used to determine internet connectivity. These requests will be resolved locally by dnschef to our Nginx server. The Nginx server then gives a 302 redirect which triggers captive portal on the client.
I tried a similar approach using dnscrypt-proxy which provides dedicated captive-portal support. Since, this is nothing more than dns cloaking there are several ways to achieve, that requests to certain "connection-checking" domains are directed to a local webserver.
Unlike in the accepted answer, I figured out an even easier and more flexible way by using the windows hosts file without any third-party dns proxy. Instead of associating the connection-checking domains with localhost, I mapped them with the physical wifi accespoint ip address (which is 192.168.137.1). This causes wifi clients to directly send their connection-checking requests to the webserver, that is running on the local pc and listens to all connections on port 80.
hosts file:
192.168.137.1 captive.apple.com
192.168.137.1 clients3.google.com
192.168.137.1 nmcheck.gnome.org
192.168.137.1 connectivitycheck.gstatic.com
192.168.137.1 connectivitycheck.android.com
192.168.137.1 www.msftncsi.com
192.168.137.1 dns.msftncsi.com
192.168.137.1 www.msftconnecttest.com
192.168.137.1 ipv6.msftconnecttest.com
192.168.137.1 ipv4only.arpa
This webserver (in my case asp.net core) redirects clients to a login page, unless they are already registered. In this case the webserver may answer to the calls just like the "real" servers do, that sit behind those connection-checking domains, in order not to redirect clients, that have already been logged in successfully.

Changing web to https

I am trying to change my site to https (port 443). Everything works correctly except for one thing, on my site i'm using a service call Yawcam which allows to stream a webcam (I'm using port 8081 to that end).
It is working when I use for my Apache server port 80 (http://myip:8081), but when using port 443 it doesn't respond (https://myip:8081).
All ports mentioned are opened to Public (80,443,8081) through my Windows Server firewall.
I'm out of ideas, do you have any?
This is nothing to do with your firewall, this is to do with the fact that you are using mixed content.
Chances are you are using http:// for the external service and this will be blocked by browsers as they do not like it when you try to load a less secure resource than the loaded page.
Try changing your external content URLs to https:// if possible.
You can see here for a little more info on what you could try: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content/How_to_fix_website_with_mixed_content

websocket will not connect from remote server

I have a web page to control a thermostat on a raspberry pi, and I'm running into difficulties when trying to get websockets to work from a remote client. It seems to work fine when on LAN however. I'm obviously missing something (and likely something basic), but I can't seem to figure out what it is.
The pi's local ip is 192.168.1.134. The web page (served from apache server) has the URL http://192.168.1.134:8010/thermostat.html. The page starts up some javascript, which then tries to connect to the pi's main program using websockets via ws://192.168.1.134:9000. (the server on the pi is running libwebsockets). The websocket comes up, and it seems to work fine. I then tried to connect via a remote client (a cell phone, where wifi was turned off) from http:\\23.239.99.99:8010\thermostat.html. The html/js files load fine, but the web socket attempts to connect to uri ws:\\23.239.99.99:9000, and this fials.
As far as I can tell, the NAT seems to be configured properly:
name ext ext protocol int int ip addr interface
port port port port
start end start end
Thermostat3 8010 8010 TCP 8010 8010 192.168.1.134 eth3.1
Thermostat5 8000 8000 TCP/UDP 80 80 192.168.1.134 eth3.1
Thermostat_ws 9000 9000 TCP/UDP 9000 9000 192.168.1.134 eth3.1
I checked, and the router does not have any firewalls set up, neither does my modem. I didn't install a firewall on the pi (I checked, and there's no odd iptables rule). Does anyone know what I'm missing?
--- EDIT ---
I'm still stuck on this. I called my ISP and they assure me there are no firewalls on their servers. Is there any way to tell if port 9000 is being blocked, and by who?
Bind your apache server to 0.0.0.0 address to make it accessible from remote machines
Try this tool to determine if the port is inaccessible (use the custom port): http://www.whatsmyip.org/port-scanner/
Everything else looks fine. As a sanity check I would try putting the ws port to 8010 to see if that works. I would also recommend using a tool like Advanced Web Client to isolate networking issues.
This is interesting. I once had a similar problem. I set up a WebSocket (I was using a nodejs ws) and once I tried to access it from remote client I was not able to reach it with ws://yourip:port but instead I had to use http://yourip:port. I don't know if you have the same problem, mine was due to a proxy I was using.
I still have an advice for you how you might be able to solve your problem. I don't know how concerned you are about security but as far as I understood your idea you basically connect to your raspberry pi through a WebSocket and tell it to change the temperature.
Back when did a similar project I found it rather hard to secure my WebSocket connection. I was basically sending a password plus command through the WebSocket to my server which then checks wether the password is correct. Otherwise everyone on the internet could heat your house. Not cool...
But therefore, I had to tunnel the connection through https to prevent a middleware attack.
I quickly threw the towel and decided to go with a completely different solution. Basically I set up a nodejs express server (can easily be configured with a self signed certificate to use https or used behind a nginx/apache https server) and authenticated with username and password. When someone made a POST request to /api/thermostats?id=0 with a temperature request, the server checks if the user is authenticated and then executes a terminal command from within node.
Maybe this idea also fits your demands.

JMeter recording for browser less application

My web application doesn't uses browser. It is a MS Word plugin and uses port 80.
When I try to record on port 80, Jmeter says 'port already in use'
And if i set other port in my app, app doesn't work properly.
What to do in this case??
Thanks
If your MS Word Plugin has proxy settings - configure it to use JMeter's Proxy.
If it doesn't have its own proxy settings - it should respect system proxy configuration (usually it can be configured via Internet Explorer proxy settings)
You can use 3rd-party tool like Wireshark or Fiddler to capture the traffic and convert it to JMeter .jmx script.
The only way you can do it as I see it is not through script recording but by setting requests in jMeter manually and build whole test plan like this. It's not so hard anyway if you know how your plugin works and requests you send. Some short info can be find here:
http://jmeter.apache.org/usermanual/build-web-test-plan.html
Error message 'port already in use' means that port 80 was assinged to some other service. You can't assign that port to Jmeter proxy server to start. (Jmeter has to start its own service on some unused port)
a. Just start Jmeter on its default port 8080 (or some other unused port).
b. Redirect required traffic to Jmeter proxy port (i.e, 8080). MS office will honor System proxy settings, so change the IE proxy setting to server '127.0.0.1' port '8080', it should automatically apply to office.
c. Now all the HTTP requests trigger from Office should visible in Jmeter Proxy recorder. After that you can move them to required location in Test Plan.
As Dmitri Said, you can also use Fiddler to track the requests (Prefer Fiddler over Wireshark, for its ease of use).
Good Luck!

Resources