I'm facing an issue with my MT7601U network adapter on Linux. Although I've successfully entered monitor mode, I'm encountering difficulties capturing handshakes and discovering devices in the network/s. Strangely, only WPS attacks seem to work reliably. Here are the key details: - **Adapter:** Ralink MT7601U - **Distribution:** parrotOS 6.0 (lorikeet) 64-bit Kernel 6.8.0-xxxxx - **Problem Summary:** - Monitor mode is enabled. - Unable to capture handshakes or detect devices in the network, except for WPS attacks which is very different kind of wifi attack. - **Attempts to Resolve:** - Successfully entered monitor mode using the iw command (sudo iw dev set monitor control). - Tried various tools like Aircrack-ng, Wireshark, and tcpdump for packet capture, but no success in capturing handshakes. - Even after ensuring monitor mode is active, no devices are being discovered in the network, except during WPS attacks. - **Observations:** - Checked system logs (dmesg, /var/log/syslog) but found no relevant error messages. - Updated drivers through the package manager and also tried downloading from the manufacturer's website, but the issue persists. I'm reaching out to the community for guidance on troubleshooting steps or potential solutions to this problem. Any advice or insights from users familiar with the MT7601U adapter or similar issues with other adapters would be greatly appreciated. Thank you for your assistance!

I have a question about nginx. I created a reverse proxy by nginx. Activated SSL encryption with Letsencrypt. All is ok and all requests from client are sent to origin server specified in upstream. Sometimes I have error > 502 Bad Gateway nginx/1.16.1 in chrome browser. Checked nginx error.log and this is the error: > peer closed connection in SSL handshake 104: Connection reset by peer while SSL handshaking to upstream. I searched and tested all suggestions. Still sometimes this error occurs. example.com.conf: upstream example_com { server 50.90.20.70:443 max_fails=10 fail_timeout=60s; } server { server_name *.example_com; location / { #proxy_ssl_server_name on; proxy_pass https://example_com ; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_set_header Accept-Encoding ""; proxy_set_header Host "example.com"; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; add_header Front-End-Https on; add_header 'host' "$host"; add_header Strict-Transport-Security "max-age=31536000"; proxy_redirect off; proxy_buffering on; proxy_cache off; proxy_cache_valid 200 4h; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504; #proxy_ssl_verify on; #proxy_ssl_trusted_certificate /etc/letsencrypt/live/example.com/fullchain.pem; proxy_ssl_server_name on; proxy_ssl_session_reuse off; } listen 443 ssl; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; #ssl_ecdh_curve secp384r1:prime256v1; } server { if ($host = example.com) { return 301 https://$host$request_uri ; } server_name example.com; listen 80; return 404; } nginx.conf: user nginx; worker_processes 6; worker_rlimit_nofile 5000; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1000; multi_accept on; } http { include /etc/nginx/mime.types; default_type application/octet-stream; proxy_cache_path /etc/nginx/cache levels=1:2 keys_zone=STATIC:10m inactive=1h max_size=950g; log_format main '$host' access_log /var/log/nginx/access.log main; sendfile off; tcp_nopush on; #server_names_hash_max_size: 512; server_names_hash_bucket_size 128; keepalive_timeout 65; large_client_header_buffers 4 32k; client_max_body_size 100M; proxy_no_cache $cookie_nocache $arg_nocache$arg_comment $http_x_no_cache; proxy_no_cache $http_pragma $http_authorization; proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment; proxy_cache_bypass $http_pragma $http_authorization $http_x_no_cache ; proxy_ssl_server_name on; #gzip on; gzip on; gzip_buffers 16 8k; gzip_comp_level 6; gzip_http_version 1.1; gzip_min_length 256; gzip_proxied any; gzip_vary on; gzip_types text/xml application/xml application/atom+xml application/rss+xml applicati$ text/javascript application/javascript application/x-javascript text/x-json application/json application/x-web-app-manifest+json text/css text/plain text/x-component font/opentype application/x-font-ttf application/vnd.ms-fontobject image/x-icon; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; # include /etc/nginx/conf.d/*.conf; server { error_page 500 502 503 504 /error503.html; location = /error503.html { root /usr/share/nginx/html; internal; } } include /etc/nginx/conf.d/*.conf; }

When I execute the following command in Ubuntu: curl -v --insecure -XGET 'https://user:pass@IP_ADDR:PORT/SOME_FILE.php ' I get this output: * Hostname was NOT found in DNS cache * Trying IP_ADDR... * Connected to IP_ADDR (IP_ADDR) port PORT (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): And after several minutes I get this: * Unknown SSL protocol error in connection to IP_ADDR:PORT * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to IP_ADDR:PORT When I try the same thing in CentOS I still get stuck in Client Hello, but in the end I get this: curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received Does anyone knows what can cause it and how can I fix it?

I was using few times Parrot OS live booted from RAM or USB as well. I have started the learning path with the basics, so I tried to **grab handshake of my own wifi networks**. **I succeded few times**, but now I am in problem. I am choosing the network that handshake would be taken of and then the method of taking handshake (no matter which one of the three I choose) the result is always same. The small window is opened in the top right screen. **After several seconds appears the string ][WPA handshake: BSSID]. This normally was the success** and I was prompted to give the path for the handshake. I am doing completely **same steps on same parrot os usb and for the same network as before** and now it doesn't give me handshake. Insted there is a failure like below. **What is going on and how to fix it?** If I choosed wrong stack-exchange please point me where should I post my question. Regards

I have a shared hosted server with FTPS access, and I can connect it trough Filezilla with the following configuration: ftp.idrissi.co 21 4 0 user@idrissi.co 2 0 MODE_DEFAULT 0 Auto 0 ftp.idrissi.co 0ftp.idrissi.co With ncftp is more simple, I just use the following command ncftp -u user@idrissi.co -P 21 ftp://ftp.idrissi.co. But, when I try to access with the [lftp](https://lftp.tech/) tool it fail. With lftp, I use the following configuration: 1d [fauve:~/lftptest] % openssl s_client -starttls ftp -crlf -connect ftp.idrissi.co:21 > ftp-idrissi-temp.cert 1d [fauve:~/lftptest] 130 % cat ftp-idrissi-temp.cert | pcregrep -M '\-----BEGIN CERTIFICATE-----(.*\n)*.*-----END CERTIFICATE-----' > ftp-idrissi.cert 1d [fauve:~/lftptest] % vim ftp-idrissi.cert 1d [fauve:~/lftptest] % cat lftp-script set ftps:initial-prot P set ftp:ssl-force true set ftp:ssl-protect-data true set ssl:cert-file ./ftp-idrissi.cert ls 1d [fauve:~/lftptest] % lftp -e "cat lftp-script| sed 's/\n/; /'" -p 21 -u user@idrissi.co ftps://ftp.idrissi.co ls: Erreur fatale: gnutls_handshake: An unexpected TLS packet was received. 1d [fauve:~/lftptest] 1 % lftp -e "cat lftp-script| sed 's/\n/; /'" -p 21 -u user@idrissi.co ftp://ftp.idrissi.co ls: Erreur fatale: Certificate verification: certificate common name doesn't match requested host name « ftp.idrissi.co » I try many variations on the lftp-script but it doesn’t work. And I don’t understand how Fillezilla could do it with a minimalist config. So, how can I connect to my FTP account?

I am running the following command: curl --tlsv1.2 -v --cacert ./mycert.crt --key ./key.pem --cert ./mycert.crt https://thirdparty.url I received the certificate from the third party I am working with after generating CSR and key files with openssl. My server IP is whitelisted on the third party's firewall and they can see my requests coming in but the handshake always fails. This is the response I receive: * Trying X.X.X.X... * Connected to thirdparty.url (X.X.X.X) port 443 (#0) * found 1 certificates in ./nonprod.crt * found 596 certificates in /etc/ssl/certs * ALPN, offering http/1.1 * gnutls_handshake() failed: Handshake failed * Closing connection 0 curl: (35) gnutls_handshake() failed: Handshake failed How can I debug this issue? Some info: I am running curl 7.47.0 on Ubuntu 16.04.4 I try running this command: openssl s_client -connect server.url:443 -tls1_2 -cert ./mycert.crt -key key.pem BUT I have to exclude the link URI to make it work. The response does include this however: 140593823835800:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1487:SSL alert number 40 140593823835800:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656: But it also says: SSL handshake has read 3378 bytes and written 1702 bytes New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: CE2294E9B415FB8B9850DB28F64FEF17390A46D5A38F12E62E31F614DA4199CF50C0AFA5F62401C4964105AFC4F1B095 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1528299660 Timeout : 7200 (sec) Verify return code: 0 (ok)

I'm trying open a website with cURL like this: $ curl -vH "Accept: application/json" https://www.rocketleaguereplays.com/api/replays/-1/ The output is: * Trying 104.24.114.83... * Connected to www.rocketleaguereplays.com (104.24.114.83) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Unknown (21): * TLSv1.2 (IN), TLS alert, Server hello (2): * error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure * Closing connection 0 * TLSv1.2 (OUT), TLS alert, Client hello (1): curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure I have Linux kernel 4.4.0 and the newest cURL version installed: $ curl -V curl 7.47.1 (x86_64-pc-linux-gnu) libcurl/7.47.1 OpenSSL/1.0.2f zlib/1.2.8 c-ares/1.10.0 nghttp2/1.6.0 Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp Features: AsynchDNS IPv6 Largefile NTLM SSL libz TLS-SRP HTTP2 UnixSockets How can I fix this? On Ubuntu it works fine with cURL and same URL.

While debugging some strange behaviour with an Azure load-balancer, I noticed that my local Debian Stretch TCP stack was only establishing TCP connections with an even-numbered port. I do not start a single TCP handshake with an odd source port. Is that intended?

I have a problem with one of our clients trying to initiate a TCP connection to our server but it fails. In tcpdumpI see, that the client's device sends a SYN packet to which our server correctly replies with a SYN ACK. Immediately after that, our server receives a RST packet. After a few seconds the procedure repeats. Strangely enough, the connection is correctly established from time to time (about every 2 days around 8:30 am). I have tried redirecting the packets to another server but get the same problem with that server. Today I tried connecting the other way round. Our client currently does not have a port opened in his firewall, but I tried connecting anyways to see what happens. I used ssh to try the connection from different machines, here is what I discovered: From my personal computer (Mac OS X 10.10): ssh: connect to host x.x.x.x port 22: Connection refused From the server that is receiving the SYNpackets (Debian 8): ssh: connect to host x.x.x.x port 22: No route to host From another server in a different hosting center (Debian 7): ssh: connect to host x.x.x.x port 22: No route to host From another server in a larger company (Debian 7): ssh: connect to host x.x.x.x port 22: Operation timed out The response I get from my personal computer at home is what I expect if the port is not opened in the firewall, but I am confused by the different outputs I get from the different servers. Pinging the client's IP from any of these machines works fine. Could I be looking at a routing problem here, where my SYN-ACK packages are routed incorrectly and therefor (almost) never reach the client? Do you have any suggestions on how to tackle the problem? Should I contact the client's ISP, or maybe my server provider? Thank you for your help. **UPDATE 1:** I did some further research on Jeff's Questions. Here are my results:

IP TTL SYN: 55
IP TTL RST: 59

I am currently waiting on the client to grant me access to his network, so I cannot currently see if he receives the SYN-ACK or if he sends the RST Traceroute:

1  x.x.x.x  25.793 ms  5.516 ms  5.516 ms
 2  x.x.x.x  4.140 ms  4.172 ms  4.166 ms
 3  x.x.x.x  4.158 ms  4.147 ms  4.139 ms
 4  x.x.x.x  9.855 ms  9.877 ms  9.874 ms
 5  x.x.x.x  15.506 ms !X  15.753 ms !X  15.970 ms !X

The traceroute from my computer at home ist the same on the last two hops. Both traceroutes have 5 hops. There is no firewall or load balancer at the server end. The routing tables look good on the servers receiving the no route to host. They mainly consist of the default route and the local subnet route both working without a problem on all other occasions.

If I have the following rule in the nat-table in the prerouting chain: 0 0 REDIRECT tcp -- eth5 any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN redir ports 20000 My intention is to DNAT to the incoming interface (hence the redirect target) and I want to redirect only packets where the SYN-Flag is set and all others flags are unset. I am wondering if this rule is correct. What happens if there is a packet, with only the SYN and the URG Flag set? Or with only the SYN and the PUSH flag set? As far as I know that wouldn't be a match to the above rule. In this case the packet just wouldn't get redirected. As far as I understand I should change the --tcp-flags rule to: --tcp-flags ALL SYN In this case even if the PUSH and the URG flags are set it would (Edit: NOT!!) get redirected and that's what I want. So that's why I think that that would be correct. Is my reasoning right? Edit: As I am thinking about this I'm getting more and more confused. Reflecting on what I have just written, it just doesn't matter whether to include the PUSH or the URG flag because it seems that in both cases it just wouldn't get redirected. So logically it seems that FIN,SYN,RST,ACK/SYN is equal to --tcp-flags ALL SYN