I am using following filter expression to sniff IPv4/IPv6 SYN/ACK/FIN/RST packets. This works fine using tcpdump for IPv4 however for IPv6 I dont see any thing coming
tcp port 80 and (tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-fin|tcp-rst) != 0)
Currently, TCPDump (and Wireshark) do not support embedded protocol BPF filters under IPv6. In order to find these packets, you would have to use BPF offsets and masks.
For example:
ip6 proto tcp and ip6[13+40]&0x17!=0
Here we are checking to see if TCP is the embedded protocol in the IPv6 header. From there, we are going 13 bytes into the TCP header and adding 40 bytes since we are referencing it from the start of the ip6 header. I'm assuming that you know already that 0x17 would be the mask to match what you have written (SYN|ACK|FIN|RST).
While there is a protochain option which can find TCP anywhere in the protocol chain, it really isn't practical to use BPF to track down which "Next Header" contains TCP (it should be the last one).
To add the port to the above, you would just add:
and ip6[(40+2):2]=80
Related
While understanding SMTP PIPELINING RFC 2920 Section 3.2 indicates that a server supporting pipelining MUST NOT buffer responses to unrecognized commands. Is the ideal response to expect an SMTP Protocol Violation Error?
For example, here's a transcript without pipelining but when using an UNKNOWNCOMMAND:
C: EHLO domain
S: 250-ServerName ..... 250-PIPELINING
C: UNKNOWNCOMMAND
S: 500 Unrecognized Command
C: EHLO domain
S: 250-ServerName ..... 250-PIPELINING
With pipelining
C: EHLO domain
S: 250-ServerName ..... 250-PIPELINING
C: UNKNOWNCOMMAND\r\nEHLO domain
S: 500 Unrecognized Command
S: 250-ServerName ..... 250-PIPELINING
Is this the expected behavior or should the SMTP server not buffer responses to unknown commands and to specific commands like EHLO | DATA | NOOP (RFC 2920 Section 3.2 Point 5)? So for the pipelined UNKNOWNCOMMAND\r\nEHLO domain, should the server send only one 500 Unrecognized Command response and flush the TCP input buffer? Are the servers which exhibit this behavior adhering to a stricter constraints?
The relevant points of section 3.2 are:
(6) [The server] MUST NOT buffer responses to unrecognized commands.
(9) [The server] MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
I interpret these two points as follows: If you send an unknown command followed by a known command in a "single" TCP packet, the server has to send its response to the unknown command immediately before it reads from its input again. In other words, you receive "two" TCP packets instead of one. Unless you monitor your network traffic (or measure the precise timing programmatically), you won't be able to notice the difference. As indicated by the point 9 above, the server may not reset its input buffer.
As a client, you can usually also send commands after EHLO and DATA immediately without any issues because most server don't look ahead in their input buffers. However, such a client violates the pipelining extension. Detecting this can be used as an anti-spam technique (see invalid pipelining in this Wikipedia article).
I'm trying to scan list of IP addresses using below command
nmap -v -n -sP -iL <IP-list-file.txt>
here I'm looking retry option with nmap command for the failed probe retransmission. Above command will do a single ICMP probe for each IP/hosts. Even I tried with --max-retries no result. So I'm looking a similiar option like { ping -c<2> IP > along with this nmap.
Even tried "-A -T5" no result
Note:- My purpose is to check only whether the host/IP is alive or dead that's it. Preferably nmap utility.
Nmap uses a lot of different methods for host discovery. The options that you used will do one of two things depending on whether you have root privileges:
If you do run Nmap as root, it will send four probes: ICMP Echo Request, TCP SYN to port 443, TCP ACK to port 80, and ICMP Timestamp Request. Only if all four fail to get a response will it mark the target as down.
If you do not run Nmap as root, it will attempt to make a TCP connection to port 80 and port 443. If both of these time out, it will mark the target as down.
So this method is already more robust than simply using /bin/ping. Nmap also retries probes a certain number of times depending on how reliable the network seems. For host discovery, this starts out at 2 retransmits per probe. There doesn't really seem to be a way to increase this without Nmap detecting network problems, so the best way to increase confidence in a "down" determination is to add more host discovery probes using the various -P* options.
The -A and -T5 options will not help at all. -A turns on extra features, none of which will run if the target is considered down, and -T5 simply tells Nmap to assume a very fast and reliable network. It will never retransmit more than 2 times, and will time out probes very quickly. This is almost certainly the opposite of what you want.
I'm trying to capture MySQL activities through my web application and MySQL Server by using Wireshark on Windows. I've seen that most of questions about capturing packets related to MySQL return MySQL Protocol and the possibility of seeing the queries sent and their responses. Yet, when running Wireshark and using my application, I see only TCP packets coming and going, as can be seen in the pictures in the links below.
TCP Packet -> Src - Dst
Inside TCP Packet
It's important to note that I've used tools like tshark and WinDump to collect packets through the network, but nothing worked.
Am I doing something wrong or it's a Wireshark bug?
Thanks for the answers!
I did what was suggested by Christopher following Edit -> Preferences -> Protocols -> MySQL. There was nothing like "Port Number", but the issue was that "Show SQL Query string in INFO column" was not selected.
The image provided indicates that the port in use is 3307, but the MySQL dissector registers by default on port 3306, which is the IANA-registered port for mysql traffic. So, when a non-standard port is used, you must make use of the "Decode As" feature of Wireshark, as nnovich-OK has already mentioned.
Another option in many cases, which unfortunately is not yet available in this case, is to change the port number that the dissector registers for. The MySQL dissector does not offer a port preference though, but you could open a Wireshark bug report asking for such a preference to be added - even better if you submit a patch that actually implements it. Once a preference is available, then you could set it as desired via Edit -> Preferences -> Protocols -> MySQL -> Port Number, similar to how many other dissectors allow a configurable port.
Wireshark has some logic which automatically determines type of traffic observed. I don't know the reason for it to fail in your case, but you can always manually point to the desired protocol. Right click on one of your TCP packets, click on "decode as" and choose "MySQL" in the last column.
I am using tcpdump to collect packet data through wlan0. But I find many packets with length of 0 like following picture shows. Well, length 0 packets... Is tcpdump reliable or I have missed something?
OK, those are TCP packets, and that's the TCP payload length. That can be zero, if a TCP packet is just acknowledging data sent by the other side of the connection, and not sending any data.
For example, the next to the last packet is from 121.186.151.61.dial.xw.sh.dynamic.163data.com.cn, port 80 (that's the ".http" at the end - it's not part of the domain name, it's an indication that it's from port 80) to android-1b46862a4910306b, port 53876, with 16 bytes of data. The last packet is android-1b46862a4910306b sending an ACK to 121.186.151.61.dial.xw.sh.dynamic.163data.com, probably acknowledging the previous 16 bytes.
The other zero-length packets in your sample output are TCP FIN packets, which don't have to have data in them (the host sending it is just saying "I don't have any more data to send you, and never will have any more data to send you on this connection - I'm done"), and TCP RST packets, which are just forcibly shutting down the connection and also don't have to have data in them.
I want to send emails using gmail's smtp with the PHP script posted below using Swiftmailer. Now this works fine on my own webserver. But when I used it on the webserver of the people I'm creating this for, I get an exception:
Fatal error: Uncaught exception 'Swift_TransportException' with message 'Connection could not be established with host smtp.gmail.com [Connection timed out #110]' in ...
What could be the problem?
I'm assuming its got to do with the difference in server settings, because the code works on my own webserver. I've checked with phpinfo() the following:
- Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
- OpenSSL support enabled
- OpenSSL Library Version OpenSSL 1.0.1e-fips 11 Feb 2013
This is my PHP code:
$emailname = MY_GMAIL_ACCOUNT_USERNAME;
$emailpass = MY_GMAIL_ACCOUNT_PASSWORD;
$transport = Swift_SmtpTransport::newInstance('smtp.gmail.com', 465, "ssl")
->setUsername($emailname)
->setPassword($emailpass);
$mailer = Swift_Mailer::newInstance($transport);
$message = Swift_Message::newInstance($emailtitle)
->setFrom(array($emailname.'#gmail.com' => $emailsender))
->setTo(array($emailrecp))
->setBody($emailbody,'text/html');
$result = $mailer->send($message);
I had the same issue on a Digital Ocean server. Turns out they're blocking SMTP by default on IPv6. Here's the fix:
nano /etc/gai.conf
precedence ::ffff:0:0/96 100
as per:
https://www.digitalocean.com/community/questions/outgoing-connections-on-port-25-587-143-blocked-over-ipv6
My easy solution to avoid the problem of dynamic IP (every time i ping smtp.gmail.com I see a slight difference in the last 3digit chunk), is to simply use php built-in gethostbyname() to read the IP in real-time.
$smtp_host_ip = gethostbyname('smtp.gmail.com');
$transport = Swift_SmtpTransport::newInstance($smtp_host_ip,465,'ssl')
->setUsername('username')->setPassword('pwd');
Im not advanced in php and streams but it seems that IPv6 DNS resolution depends on the router and/or ISPs. I changed my provider, got a new router and the smtp connection always timed out.
To use IPv6 you should either add your own IPv6 or force stream_context_create to use IPv4. You can call setSourceIp() on a swiftmailer object or directly change the Swift_SmtpTransport class (i.e. in the constructor).
Use IPv6:
// replace IP with your own IPv6
$this->setSourceIp('2aaa:8a8:fc0:230:fds:4fd:faa:24ae');
Use IPv4 (mentioned at https://github.com/phergie/phergie/issues/195):
$this->setSourceIp('0.0.0.0');
just add
74.125.130.108 smtp.gmail.com
to server's hosts file
I've just been doing battle with exactly the same problem. Mine worked locally too, but as soon as it got on a real server ... no. It just would not work even though all the settings were the same.
After many hours, I've think I've found out why.
What seems to happen is that on a server with IPv4 and IPv6 support, IPv6 takes precedence. Which makes sense, given that it's newer. But in the case of smtp.gmail.com, it appears to only listen on IPv4. So when the server resolved smtp.gmail.com, it got its IPv6 address back and so PHP tried to connect to it. That eventually gives up with a "Connection timed out" exception. Now you would think that fsockopen, presumably, would detect the connection wasn't working and so try IPv4, but seemingly it doesn't.
If you find out what smtp.gmail.com's IPv4 address is (ping smtp.gmail.com) and simply put that IP in place of the hostname in the code - it works :)
It's not ideal coding in an IP address - given that Google could change it at any minute - but at least you will get some emails sent
The answer for me was that my server was blocking the outbound connection. It could be your firewall or your host.
The way to test this is to try connecting yourself. I used telnet on two different machines to compare and it became obvious that this was my issue. There may be a way to test this with curl directly.