When I use wireshark to track tcp packet, it works fine. But when I use wget command, it can't track. What's the problem ?
○ → wget http://superuser.com/questions/674605/what-is-type-of-icmp-packets-tcp-or-udp
--2016-10-01 10:50:36-- http://superuser.com/questions/674605/what-is-type-of-icmp-packets-tcp-or-udp
Resolving superuser.com... 151.101.193.69, 151.101.1.69, 151.101.65.69, ...
Connecting to superuser.com|151.101.193.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 74235 (72K) [text/html]
Saving to: ‘what-is-type-of-icmp-packets-tcp-or-udp’
what-is-type-of-icmp-packets-tcp-or-udp 100%[==============================================================================================>] 72.50K 37.3KB/s in 1.9s
2016-10-01 10:50:39 (37.3 KB/s) - ‘what-is-type-of-icmp-packets-tcp-or-udp’ saved [74235/74235]
And wireshark gets nothing:
I got it, because I use VPN which causes the dest ip changed to VPN address .
Related
I'm having problems using SSL certificate pinning in SIM800L. I can successfully make GET requests using both AT+HTTPSSL=0 and AT+HTTPSSL=1. However, the module doesn't check whether the offered server certificate is valid. According to this thread I have uploaded the certificate to the module's filesystem. I can successfully set the cert using an AT command:
AT+SSLSETCERT=cert.cer
AT+SSLSETCERT=cert.cer
OK
+SSLSETCERT: 0
However, doing this only doesn't seem to block other certificates from being used, e. g. I have tried with google.com and mywebsite.com (for which I have imported the certificate). So I dig a little deeper and find the SSLOPT command, which should (according to SSL docs) block invalid certificates. Setting the flag with AT+SSLOPT=0,0 and then executing the HTTPS request gets me a 605 error:
+HTTPACTION: 0,605,0
Documentation says this means "SSL failed to establish channels". My understanding of this is that the server offered an invalid certificate (so, something different from the one loaded with AT+SSLSETCERT). If I understand this correctly, I would expect this error to come when doing a request to, let's say, google.com or selfsigned.badssl.com. The problem is that I get this even if I do the request to mywebsite.com, for which I loaded the certificate into the storage.
I have tried a similar procedure with two different modules (SIM800L and SIM808) and got a similar result. Am I doing something wrong?
Here's the full list of commands and their replies for the request to mywebsite.com:
AT+CREG?
+CREG: 0,5
OK
AT+SAPBR=1,1
AT+SAPBR=1,1
OK
AT+HTTPINIT
AT+HTTPINIT
OK
AT+HTTPPARA="URL","mywebsite.com"
AT+HTTPPARA="URL","mywebsite.com"
OK
AT+HTTPPARA="CID",1
AT+HTTPPARA="CID",1
OK
AT+HTTPSSL=1
AT+HTTPSSL=1
OK
AT+SSLSETCERT=cert.cer
AT+SSLSETCERT=cert.cer
OK
+SSLSETCERT: 0
AT+SSLOPT=0,0
AT+SSLOPT=0,0
OK
AT+HTTPACTION=0
AT+HTTPACTION=0
OK
AT+HTTPREAD
AT+HTTPREAD
OK
+HTTPACTION: 0,605,0 <<<-------This shouldn't be 605
AT+HTTPTERM
AT+HTTPTERM
OK
AT+SAPBR=0,1
AT+SAPBR=0,1
OK
I found simcom 's document about ssl here,and i see a example in it. (page. 19)
4.5 HTTPS Get Method with HTTPS
// Use HTTPS download data
AT+HTTPINIT
OK
//Init HTTP service
AT+HTTPPARA="CID",1
OK
AT+HTTPPARA="URL","www.gmail.com" OK
AT+HTTPPARA="REDIR",1
OK
//Set parameters for HTTP session
AT+HTTPSSL=1
OK
//Enable HTTPS function
AT+HTTPACTION=0
OK
+HTTPACTION: 0,200,84200
//GET session start
//GET successfully
AT+HTTPREAD
+HTTPREAD: 84200 …. OK
//Read the data of HTTP server
AT+HTTPTERM
OK
I also suffered for a long time with this problem. The solution turned out to be the following - the https port should be specified in the site address. That is not so:
AT + HTTPPARA = "URL", "mywebsite.com"
and so:
AT + HTTPPARA = "URL", "mywebsite.com:443"
Using a Commodore 64 with a GLINK LT RS-232 adapter connected to a Digi-Connect SP configured to send RAW TCP to a static IP/port on my home network. Destination is a socat process passing traffic elsewhere with verbose logging.
Testing hitting socat from a bash shell on an OS X machine, issuing curl http://192.168.1.91:1234 I get a valid response and the socat log shows
> 2018/12/29 22:06:50.168550 length=81 from=0 to=80
GET / HTTP/1.1\r
Host: 192.168.1.91:1234\r
User-Agent: curl/7.54.0\r
Accept: */*\r
\r
< 2018/12/29 22:06:50.169509 length=144 from=0 to=143
(followed by http response)
But when I run the following on the C64 BASIC code SNIPPET:
100 OPEN 2,2,3,CHR$(6)+CHR$(0)
110 GET#2,A$: REM TOSS NULL TO OPEN RCVR CHANNEL
120 PRINT#2,"GET /"
...
the socat log shows:
> 2018/12/29 22:11:38.952005 length=1 from=167 to=167
G> 2018/12/29 22:11:38.983674 length=1 from=168 to=168
E> 2018/12/29 22:11:39.015464 length=1 from=169 to=169
T> 2018/12/29 22:11:39.051758 length=1 from=170 to=170
> 2018/12/29 22:11:39.084476 length=1 from=171 to=171
/> 2018/12/29 22:11:39.117131 length=1 from=172 to=172
I'm not sure if I'm doing something wrong on the C64 side to cause the individual char's to be sent or if it's an incorrect Digi-Connect setting.
Digi serial settings are:
TCP Client Settings:
Automatically establish TCP connections
Always connect and maintain connection
Establish connection to the following network service:
Server: 192.168.1.91
Service: Raw TCP
TCP Port: 1234
Enable TCP Keep-Alive: On
Basic Serial Settings
Baud: 300
Data bits: 8
Parity: None
Stop Bits: 0
Flow Control: Hardware
Advanced Serial Settings
(nothing configured here)
The individual characters was a red herring, the fix is simply to add a LF (ASCII 10) to the end of the message so the downstream web service understands that the message is finished.
Working example:
100 OPEN 2,2,3,CHR$(6)+CHR$(0)
110 PRINT#2,"GET /"
120 PRINT#2,CHR$(10)
(also of note - anything requiring correct upper/lower case will need PETSCII <-> ASCII conversions)
I have a service that redirects users to temporary pre-signed AWS downloads. These are large files, often 5-10gb. To prevent download sharing, we have a relatively short (30 seconds) valid lifespan.
Everything is working except that on slow internet connections, they tend to fail or get interrupted. wget has a feature that automatically retries the download. However, instead of retrying the original URL (eg: http://service.com/download/file.zip), wget retries the redirected pre-signed URL (eg: http://service.s3.amazonaws.com/file.zip?AWSAccessKeyId=XXXX&Signature=XXXX&Expires=1468000000)
Since these are large files, and the pre-signed lifespan is so short, that temporary url is no longer valid and the user gets a 403 Forbidden result.
Originally, when we noticed the problem, we were using 302 Found temporary redirects. A little research seemed to indicate we SHOULD have been using 307 Temporary Redirect. However, that didn't resolve the problem with wget. For grins and giggles, we tried 303 See Other, but that didn't work either.
Does anyone have any idea how get wget to retry the original URL instead of the redirected URL?
below is a wget example log:
--2016-07-06 10:29:51-- https://service.com/download/file.zip
Connecting to service.com (service.com)|10.0.0.1|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location:
https://service.s3.amazonaws.com/file.zip?AWSAccessKeyId=XXXX&Signature=XXXX&Expires=1468000000
[following]
--2016-07-06 10:29:52-- https://service.s3.amazonaws.com/file.zip?AWSAccessKeyId=XXXX&Signature=XXXX&Expires=1468000000
Resolving service.s3.amazonaws.com (service.s3.amazonaws.com)...
54.231.12.129
Connecting to service.s3.amazonaws.com
(service.s3.amazonaws.com)|54.231.12.129|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2070666907 (1.9G) [application/zip]
Saving to: ‘file.zip’
file.zip 53%[=========> ] 1.03G --.-KB/s in 18m 7s
2016-07-06 10:47:59 (995 KB/s) - Read error at byte
1107205784/2070666907 (The specified session has been invalidated for
some reason.). Retrying.
--2016-07-06 10:48:00-- (try: 2) https://service.s3.amazonaws.com/file.zip?AWSAccessKeyId=XXXX&Signature=XXXX&Expires=1468000000
Connecting to service.s3.amazonaws.com
(service.s3.amazonaws.com)|54.231.12.129|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2016-07-06 10:48:01 ERROR 403: Forbidden.
I had a similar issue, and a similar answer as #panzerito, but broke it up into a script i called loopdone
#!/bin/bash
until `$1`; do sleep 1; echo restarting; done
then I can just do loopdone "wget -c http://my.url/" (incl quotes) to force it to run again and again (and resume, unless server does not support it) until exit code is 0. (meaning no error)
Bash-code:
initial_error_EXIT_STATUS; until [ "$?" -eq "0" ]; do wget https://example.com/download/file.zip -c; done
OK, we all know how to use PING to test connectivity to an IP address. What I need to do is something similar but test if my outbound request to a given IP Address as well as a specif port (in the present case 1775) is successful. The test should be performed preferably from the command prompt.
Here is a small site I made allowing to test any outgoing port. The server listens on all TCP ports available.
http://portquiz.net
telnet portquiz.net XXXX
If there is a server running on the target IP/port, you could use Telnet. Any response other than "can't connect" would indicate that you were able to connect.
To automate the awesome service portquiz.net, I did write a bash script :
NB_CONNECTION=10
PORT_START=1
PORT_END=1000
for (( i=$PORT_START; i<=$PORT_END; i=i+NB_CONNECTION ))
do
iEnd=$((i + NB_CONNECTION))
for (( j=$i; j<$iEnd; j++ ))
do
#(curl --connect-timeout 1 "portquiz.net:$j" &> /dev/null && echo "> $j") &
(nc -w 1 -z portquiz.net "$j" &> /dev/null && echo "> $j") &
done
wait
done
If you're testing TCP/IP, a cheap way to test remote addr/port is to telnet to it and see if it connects. For protocols like HTTP (port 80), you can even type HTTP commands and get HTTP responses.
eg
Command IP Port
Telnet 192.168.1.1 80
The fastest / most efficient way I found to to this is with nmap and portquiz.net described here: http://thomasmullaly.com/2013/04/13/outgoing-port-tester/ This scans to top 1000 most used ports:
# nmap -Pn --top-ports 1000 portquiz.net
Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-02 22:28 CDT
Nmap scan report for portquiz.net (178.33.250.62)
Host is up (0.072s latency).
rDNS record for 178.33.250.62: electron.positon.org
Not shown: 996 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
8080/tcp open http-proxy
Nmap done: 1 IP address (1 host up) scanned in 4.78 seconds
To scan them all (took 6 sec instead of 5):
# nmap -Pn -p1-65535 portquiz.net
The bash script example of #benjarobin for testing a sequence of ports did not work for me so I created this minimal not-really-one-line (command-line) example which writes the output of the open ports from a sequence of 1-65535 (all applicable communication ports) to a local file and suppresses all other output:
for p in $(seq 1 65535); do curl -s --connect-timeout 1 portquiz.net:$p >> ports.txt; done
Unfortunately, this takes 18.2 hours to run, because the minimum amount of connection timeout allowed integer seconds by my older version of curl is 1. If you have a curl version >=7.32.0 (type "curl -V"), you might try smaller decimal values, depending on how fast you can connect to the service. Or try a smaller port range to minimise the duration.
Furthermore, it will append to the output file ports.txt so if run multiple times, you might want to remove the file first.
Wordpress not using direct linking for the download links (looks like enterprise software developer who generate links dynamically to track installation).
Use wget http://wordpress.org/latest.tar.gz is not getting the right file name.
I dont want save in desktop and upload to server because I'm running slow internet connection.
I fail to see what the problem is:
marc#panic:~$ wget http://wordpress.org/latest.tar.gz
--2011-04-01 11:19:27-- http://wordpress.org/latest.tar.gz
Resolving wordpress.org... 72.233.56.139, 72.233.56.138
Connecting to wordpress.org|72.233.56.139|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: `latest.tar.gz'
[ <=> ] 2,365,766 1.09M/s