I have a problem on one of my machines.
I connect to some IMAP server and do ". CAPABILITY" request:
* OK IMAP4 ready
. CAPABILITY
* CAPABILITY IMAP4REV1 UIDPLUS
. OK completed
But if I inspect response in Wireshark I get
* CAPABILITY IMAP4 IMAP4rev1 UIDPLUS STARTTLS LOGINDISABLED which is the expected result.
And it works just fine on other machines.
What can be wrong?
Actually I have similar problem with openssl connection on that machine: Didn't find STARTTLS in server response, trying anyway..., but I think it has the same root cause.
Unfortunately, I didn't have enough time to dig deep into the problem. After some fiddling with updates, software reinstallation, changing IPs and so on I gave up, formatted C and made clean Windows installation.
It helped, as it usually is with such weird behaviors.
Related
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!
I use HTTP protocol for send binary data to server (PUT request and Content-Type: application/octet-stream). Until recently time this worked fine.
But now I getting 504 http error on Windows (I try it on several Windows mashines).
I try do all what imagine, so correct this behavior. When I catch request through Fiddler. I see what full request has sended to server, but server not respond.
I send absolutly same request from Linux machine, so it still works fine as a before.
In addition I notice, what Windows mashine works correctly (PUT request and Content-Type: application/octet-stream) when in the body request contains only literal characters.
Any idea, what I do with this? Is it known issue?
I solve this issue. Problem wasn't on Windows.
This has came with server kernel version (kernel 3.0.23).
When I update kernel (Ubuntu server from 3.0.23 to 3.0.24 version), it was working again.
That most likely problem in recognizing TCP packages.
We are attempting to connect to a WebDAV server using net use over SSL. On some servers we're seeing an issue in which this connection only succeeds if we specify port 443 in the URL.
Does Map
net use * "https://example.com:443/folder"
net use * "\\example.com#SSL#443\folder"
and, bizarrely, so does this:
net use * "\\example.com#SSLasdf\folder"
Does Not Map
net use * "https://example.com/folder"
net use * "\\example.com#SSL\folder"
In the non-working cases we consistently receive the following error:
System error 67 has occured.
The network name cannot be found.
We have noticed some things that might be useful information:
We have a test server that's configured the same way as the prod server and it works as expected.
In the non-working cases, no incoming requests are ever seen at the prod server from the failing host.
All clients are based on the same image.
The problem does not manifest uniformly on all clients -- some work, some don't.
There is an existing, valid entry for example.com in the client DNS cache.
Flushing the client DNS cache of the affected servers does not resolve the problem.
Once the problem appears, it seems to stick. That is, if I execute one of the working mappings, delete it, and then immediately execute one of the non-working mappings, the problem persists.
We are utterly stumped. Any theories?
You are seeing different behaviors because you are connecting using different names. Once a name has been attempted and failed, the WebClient (this is the service that enables WebDAV) will cache the response for a period. To clear the cache, locate the WebClient service in the Services console and restart it. Or from an administrative command prompt execute the following command:
net.exe stop webclient && net.exe start webclient
We ultimately determined that we were mis-interpreting the System Error 67 that net use was returning. We discovered two interesting things:
In the event that the WebDAV returns a 404 or a 50x on the initial, root folder PROPFIND, net use will (rightly) interpret this as the root folder being unavailable. The fact that it says the network name could not be found let us to believe that the problem was with the name resolution, but it was really just saying, 'hey, I couldn't find anything at this path.'
If 'net use' fails due to a 404/50x, it appears that for a brief period of time it will automatically fail any additional mappings for that same host without issuing a request. For example, if net use http://me.com/foo returns a 404, then net use http://me.com/bar will instantly fail if made in rapid succession to that first call, and no request record will be seen in the WebDAV server logs.
My best guess is that appending the #443 port didn't make any real difference. What it perhaps did do was to trick net use into thinking it was talking to a different host, at least for the purposes of its 'auto-fail' feature. But that's just a guess.
Am trying to upload a file using libcurl in C. Data transmission is getting failed. Below is the log message.
How to fix this issue?
< 250 CWD command successful.
EPSV
Connect data stream passively
< 500 'EPSV': command not understood
disabling EPSV usage
PASV
< 227 Entering Passive Mode (x,x,x,x,193,152).
Trying x.x.x.x... * No route to host
couldn't connect to host
Closing connection #0
Couldn't connect to server
This means that when the FTP server opens a second port for your client to connect to, your client (libcurl) fails to reach it. It is most likely due to a firewall or other network equipment somewhere along the way that blocks your ability to do the request operation.
Alternative reasons could be a wrongly configured ftp server, but if it works for other users, that seems less likely.
Another reason for failure may be that you have an active firewall that doesn't know EPSV and thus gets confused by it and ruins it for you. Try without it by setting CURLOPT_FTP_USE_EPSV to 0.
You can try to the active approach instead (which is what most older style FTP clients do by default), which makes the client ask the server to connect back to you instead. You activate that in libcurl with CURLOPT_FTPPORT. (See the docs for exact details on how to use it.)
I'm trying to use Putty 0.60 to log in to an OpenSSH 5.3 server. Connections with openssh from another Linux server are possible, but Putty fails. Putty's event log tells me "software caused connection abort" right after the DH key exchange, the server log doesn't report anything (set to INFO). I analyzed the traffic with Wireshark and got a whole bunch of "TCP retransmission" and "TCP DUP ACK" after said key exchange.
Sometimes I was able to log in, but at some point (usually < 2 min.) the connection froze without any logged messages. Sadly, I didn't capture a trace.
The server is my own (Funtoo with genkernel and gentoo-sources 2.6.34), so I may tweak it, but I'd still like to know what causes the error. Any suggestions? Thank you!
Ok, that was weird.
The problems cause was a network BIOS setting: a specified static IP and NIC = shared (Broadcom Extreme II) - system in question is a Dell Blade. By these settings, I somehow ended up with multiple MAC addresses for the IP - which killed my SSH connections. I honestly hope this helps somebody else...