ERORR：
Feb 14 14:09:04 es1 postfix/smtp[16443]: connect to mx3.hotmail.com[65.54.188.94]:25: Connection timed out
Feb 14 14:09:34 es1 postfix/smtp[16443]: connect to mx1.hotmail.com[104.44.194.231]:25: Connection timed out
Feb 14 14:10:04 es1 postfix/smtp[16443]: connect to mx1.hotmail.com[207.46.8.167]:25: Connection timed out
Feb 14 14:10:34 es1 postfix/smtp[16443]: connect to mx2.hotmail.com[65.55.37.104]:25: Connection timed out
Feb 14 14:11:04 es1 postfix/smtp[16443]: connect to mx1.hotmail.com[65.55.92.136]:25: Connection timed out
Feb 14 14:11:04 es1 postfix/smtp[16443]: 228D519C06D: to=<xxxx#hotmail.com>, relay=none, delay=395818, delays=395668/0.01/150/0, dsn=4.4.1, status=deferred (connect to mx1.hotmail.com[65.55.92.136]:25: Connection timed out)
I've host Mail Server on CentOS 6 with Postfix/Dovecot, I can receive mail from outside, but can't not sending mail to outside.
Things I've done:
Add spf record to dns, also validate successfully from http://www.kitterman.com/spf/validate.html?
v=spf1 ip4:x.x.x.x -all
Note:
I've change the default port 25 to 26 due to ISP block issue by adding etc/postfix/master.cf
26 inet n - n - - smtpd
Your ISP is probably blocking outbound port 25. Its very common. Your SPF record and inbound SMTP port makes no difference. I suggest you contact your ISP.
PC can be very good to achieve the video upload and download, but there are two problems in the use of IOS devices:
1、In the IOS7.0 devices can not upload the video, the following is log:
[DEBUG] Did open connection on socket 17
[DEBUG] Did connect
[DEBUG] Did start background task
[DEBUG] Connection received 528 bytes on socket 17
[DEBUG] Connection received 234 bytes on socket 17
[DEBUG] Connection received 46 bytes on socket 17
[DEBUG] Connection on socket 17 preflighting request "POST /upload" with 808 bytes body
[DEBUG] Connection on socket 17 processing request "POST /upload" with 808 bytes body
2015-12-14 10:58:34.523 GCDWebServer[1701:403846] [UPLOAD] /var/mobile/Containers/Data/Application/5F45B407-9DA8-43D1-AADF-07CF22B1C4B2/Documents/IMG_9675.mp4
[DEBUG] Connection sent 175 bytes on socket 17
[DEBUG] Connection sent 2 bytes on socket 17
[DEBUG] Did close connection on socket 17
[VERBOSE] [my localhost:80] iPad2(7.0) client:50692 200 "POST /upload" (808 | 177)
[DEBUG] Did open connection on socket 17
2015-12-14 10:58:34.577 GCDWebServer[1701:403846] album’s name == GCDWebServer
[DEBUG] Connection received 400 bytes on socket 17
[DEBUG] Connection on socket 17 preflighting request "GET /list" with 400 bytes body
[DEBUG] Connection on socket 17 processing request "GET /list" with 400 bytes body
[DEBUG] Connection sent 177 bytes on socket 17
[DEBUG] Connection sent 213 bytes on socket 17
[DEBUG] Did close connection on socket 17
[VERBOSE] [my localhost:80] iPad2(7.0) client's IP:50693 200 "GET /list" (400 | 390)
[DEBUG] Did open connection on socket 17
[DEBUG] Connection received 453 bytes on socket 17
[DEBUG] Connection on socket 17 preflighting request "GET /download" with 453 bytes body
[DEBUG] Connection on socket 17 processing request "GET /download" with 453 bytes body
[DEBUG] Connection sent 182 bytes on socket 17
[DEBUG] Did close connection on socket 17
[VERBOSE] [my localhost:80] iPad2(7.0) client's IP:50694 304 "GET /download" (453 | 182)
[DEBUG] Did disconnect
[DEBUG] Did end background task
2、In the IPAD device can not download the video, the following is log:
[DEBUG] Did open connection on socket 17
[DEBUG] Did connect
[DEBUG] Did start background task
[DEBUG] Connection received 427 bytes on socket 17
[DEBUG] Connection on socket 17 preflighting request "GET /download" with 427 bytes body
[DEBUG] Connection on socket 17 processing request "GET /download" with 427 bytes body
[DEBUG] Connection sent 398 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[ERROR] Error while writing to socket 17: Broken pipe (32)
[DEBUG] Did close connection on socket 17
[VERBOSE] [my localhost:80] iPad2(7.0) client's IP:50690 200 "GET /download" (427 | 197006)
[DEBUG] Did open connection on socket 17
[DEBUG] Connection received 346 bytes on socket 17
[DEBUG] Connection on socket 17 preflighting request "GET /download" with 346 bytes body
[DEBUG] Connection on socket 17 processing request "GET /download" with 346 bytes body
[DEBUG] Connection sent 398 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[DEBUG] Connection sent 32768 bytes on socket 17
[ERROR] Error while writing to socket 17: Broken pipe (32)
[DEBUG] Did close connection on socket 17
[VERBOSE] [my localhost:80] iPad2(7.0) client's IP:50691 200 "GET /download" (346 | 131470)
[DEBUG] Did disconnect
[DEBUG] Did end background task
Do you know why? Thank you very much!
Sorry for my ignorance.
I am trying to play a MP4 video on a LG TV using the Connect SDK 1.4.1. We have a working implementation with Chromecast and Apple TV.
When first starting our app, we are able to successfully connect to the LG TV. When trying to play one of our own videos the first time, we receive no response from the Connect SDK, nor do we see the video play on the TV. In the console output, it appears that the TV disconnects from the app. The console output can be seen in the Console Output below.
However, we are able to successfully play the Sintel video provided in your demo. After playing that video, any future attempt to play a video from my app results in the Sintel video being played instead.
I used Charles to redirect the path to the Sintel video, to a video used in my app, and found that the video played fine. This appears to be a communication issue between the App and the TV causing this unintended behavior.
Am I doing something wrong that is specific to the LG platform? Is there any additional information I can provide to solve this problem?
Thank you!
Specs:
ConnectSDK 1.4.1 (installed using Cocoa Pods)
Platform: iOS 8.1.2 (12B440)
LG TV Model #: 47LA6200 (January 2014)
Stream Format: MP4; H.264#1280x720; AAC 44100 Hz Stereo
Console Output.
[DEBUG] Did open connection on socket 27
[DEBUG] Did connect
[DEBUG] Did start background task
[DEBUG] Did open connection on socket 29
[DEBUG] Connection received 909 bytes on socket 29
[DEBUG] Connection received 350 bytes on socket 27
[DEBUG] Connection on socket 29 preflighting request "NOTIFY /RenderingControl/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" with 909 bytes body
[DEBUG] Connection on socket 29 processing request "NOTIFY /RenderingControl/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" with 909 bytes body
[DEBUG] Connection received 2379 bytes on socket 27
[DEBUG] Connection on socket 27 preflighting request "NOTIFY /ConnectionManager/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" with 2729 bytes body
[DEBUG] Connection on socket 27 processing request "NOTIFY /ConnectionManager/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" with 2729 bytes body
[DEBUG] Did open connection on socket 32
[DEBUG] Connection sent 122 bytes on socket 29
[DEBUG] Did close connection on socket 29
[VERBOSE] [192.168.1.121:49291] 192.168.1.144:38356 200 "NOTIFY /RenderingControl/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" (909 | 122)
[DEBUG] Connection received 1724 bytes on socket 32
[DEBUG] Connection on socket 32 preflighting request "NOTIFY /AVTransport/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" with 1724 bytes body
[DEBUG] Connection on socket 32 processing request "NOTIFY /AVTransport/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" with 1724 bytes body
[DEBUG] Connection sent 122 bytes on socket 27
[DEBUG] Did close connection on socket 27
[VERBOSE] [192.168.1.121:49291] 192.168.1.144:38355 200 "NOTIFY /ConnectionManager/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" (2729 | 122)
[DEBUG] Connection sent 122 bytes on socket 32
[DEBUG] Did close connection on socket 32
[VERBOSE] [192.168.1.121:49291] 192.168.1.144:38357 200 "NOTIFY /AVTransport/45d7f4f5-ebfc-4d0b-f5bd-79e51d2b2006/event.xml" (1724 | 122)
2015-01-13 16:47:32.843 Connect-Demo[1853:1424495] TeamStreamConnectVideo downloaded manifest...
[DEBUG] Did disconnect
[DEBUG] Did end background task
I need to connect, let's say a script, from an IP to a website and I can't, because:
wget: domain.com…
--2014-11-10 11:20:53-- domain.com…
recognized: domain.com... <IP>
Connecting with: domain.com|<IP>... error: Connection Timeout.
Connect again
I asked the admin of the server I host the domain on to give me ping and tracert to that IP and here it is:
pat#daz:/# ping 188.127.246.50
PING 188.127.246.50 (188.127.246.50) 56(84) bytes of data.
^C
--- 188.127.246.50 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms
pat#daz:/# traceroute 188.127.246.50
traceroute to 188.127.246.50 (188.127.246.50), 30 hops max, 40 byte packets
1 79.133.193.65 (79.133.193.65) 1.348 ms 0.994 ms 0.796 ms
2 ae1-JunM10.etop.pl (79.133.201.129) 72.054 ms 56.309 ms 52.532 ms
3 frm-k90-cr1.rascom.ru (80.81.192.166) 20.489 ms 20.356 ms 20.388 ms
4 * * *
5 oversun.w-ix.net (193.106.112.195) 63.164 ms 59.526 ms 124.898 ms
6 * * *
7 * *^C
The website's .htaccess is clean, robots.txt too, hosting's admin says there's nothing from their side (firewall, blacklist etc) that could be blocking that IP from connecting.
What could it be then? How can I check it?
I'm trying to use curl 7.23.1 to POST some data to my server (which runs an nginx server). When this nginx is queried using http://, it redirects to https:// if it can (if it has keys and all the mambo-jumbo)
It looks like curl is doing something... odd. For compatibility reasons, my script (the thing that runs curl) is sending its requests to http://, but when it hits a server that has https:// available (and therefore, gets redirected), the body in the POST request disappears.
I'm trying to upload a bunch of text using --data-urlencode name#filename option. Basically, I run an script, dump its output in the file /tmp/checkin/cmd_result, and I want to upload that as the "data" attribute of the request:
curl --max-time 30 --silent --location-trusted \
--insecure --write-out "%{http_code}" --request POST \
--data-urlencode "data#/tmp/checkin/cmd_result" \
"http:/myserver/command_reply?command_id=524729ce93bc63292c1c9831" \
--trace-ascii /tmp/command_response_trace.log \
--output /tmp/checkin/cmd_res_resp --connect-timeout 10
But the redirection seems to strip the body. If I send my data directly to https://, everything works like a charm. Adding -L (--location) or --location-trusted to the curl instruction doesn't seem to fix the issue.
Has someone experienced the same issue? Any help will be deeply appreciated.
PS:
This is the trace curl outputs (I've cleaned it a bit):
=> Send header, 300 bytes (0x12c)
0000: POST /command_reply?&command_id=52
0040: 4729ce93bc63292c1c9831 HTTP/1.1
0061: User-Agent: curl/7.23.1 (mips-openwrt-linux-gnu) libcurl/7.23.1
00a1: OpenSSL/1.0.1c zlib/1.2.7
00e4: Content-Length: 356
00f9: Content-Type: application/x-www-form-urlencoded
012a:
=> Send data, 356 bytes (0x164)
0000: data=PING%20google.coms%0A
<= Recv header, 32 bytes (0x20)
0000: HTTP/1.1 302 Moved Temporarily
<= Recv header, 22 bytes (0x16)
0000: Server: nginx/1.1.19
<= Recv header, 37 bytes (0x25)
0000: Date: Sat, 28 Sep 2013 19:11:27 GMT
<= Recv header, 25 bytes (0x19)
0000: Content-Type: text/html
<= Recv header, 21 bytes (0x15)
0000: Content-Length: 161
<= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
<= Recv header, 120 bytes (0x78)
0000: Location: https://myserver/sensor/command_reply?command_id
0040: =524729ce93bc63292c1c9831
<= Recv header, 2 bytes (0x2)
0000:
<= Recv data, 161 bytes (0xa1)
0000: <html>
0008: <head><title>302 Found</title></head>
002f: <body bgcolor="white">
0047: <center><h1>302 Found</h1></center>
006c: <hr><center>nginx/1.1.19</center>
008f: </body>
0098: </html>
== Info: SSLv3, TLS handshake, Client hello (1):
=> Send SSL data, 189 bytes (0xbd)
0000: .....
== Info: SSLv3, TLS handshake, Server hello (2):
<= Recv SSL data, 90 bytes (0x5a)
0000: .....
== Info: SSLv3, TLS handshake, CERT (11):
<= Recv SSL data, 3227 bytes (0xc9b)
0000: .....?.
== Info: SSLv3, TLS handshake, Server key exchange (12):
<= Recv SSL data, 525 bytes (0x20d)
0000: .^~...
== Info: SSLv3, TLS handshake, Server finished (14):
<= Recv SSL data, 4 bytes (0x4)
0000: ....
== Info: SSLv3, TLS handshake, Client key exchange (16):
=> Send SSL data, 134 bytes (0x86)
0000: ...'
== Info: SSLv3, TLS change cipher, Client hello (1):
=> Send SSL data, 1 bytes (0x1)
0000: .
== Info: SSLv3, TLS handshake, Finished (20):
=> Send SSL data, 16 bytes (0x10)
0000: ....
== Info: SSLv3, TLS change cipher, Client hello (1):
<= Recv SSL data, 1 bytes (0x1)
0000: .
== Info: SSLv3, TLS handshake, Finished (20):
<= Recv SSL data, 16 bytes (0x10)
0000: ...
=> Send header, 230 bytes (0xe6)
0000: POST /sensor/command_reply?command_id=52
0040: 4729ce93bc63292c1c9831 HTTP/1.1
0061: User-Agent: curl/7.23.1 (mips-openwrt-linux-gnu) libcurl/7.23.1
00a1: OpenSSL/1.0.1c zlib/1.2.7
00bc: Host: myserver
00d7: Accept: */*
00e4:
<= Recv header, 17 bytes (0x11)
0000: HTTP/1.1 200 OK
<= Recv header, 22 bytes (0x16)
0000: Server: nginx/1.1.19
<= Recv header, 37 bytes (0x25)
0000: Date: Sat, 28 Sep 2013 19:11:27 GMT
<= Recv header, 47 bytes (0x2f)
0000: Content-Type: application/json; charset=UTF-8
<= Recv header, 20 bytes (0x14)
0000: Content-Length: 22
<= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
<= Recv header, 2 bytes (0x2)
0000:
<= Recv data, 22 bytes (0x16)
0000: {"r": 200, "data": {}}
== Info: SSLv3, TLS alert, Client hello (1):
=> Send SSL data, 2 bytes (0x2)
0000: ..
Looks like your nginx does a 302 redirect from http to https. Based on RFC2616 standard, you should use 301 or 307 redirect in your nginx config. See more information from the link below.
Note that some user agents (chrome, firefox, IE) went further and treat a 302 redirect as a GET request even though the original request could be a POST.
Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
Update
301 might not work as well. Find this in curl manual. Looks like curl violates RFC2616 as well. So you might want to try 307 first.
When curl follows a redirect and the request is not a plain GET
(for example POST or PUT), it will do the following request with
a GET if the HTTP response was 301, 302, or 303. If the response
code was any other 3xx code, curl will re-send the following
request using the same unmodified method.