I have a pcap file, captured with Wireshark,with 2690 packets
I use tcpreplay to replay it on an interface, but the problem is that the number of Attempted packets in tcpreplay is different(less) with number of packets showing in wireshark
#tcpreplay -i eth1 test.pcap
sending out eth1
processing file: /tmp/reloadtest4.pcap
Actual: 1826 packets (1634597 bytes) sent in 58.06 seconds.
Rated: 28153.6 bps, 0.21 Mbps, 31.45 pps
Statistics for network device: eth1
Attempted packets: 1826
Successful packets: 1826
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
It may be a bug in Tcpreplay, or it may be an issue with your capture. I suggest logging the issue here. Include the output of tcpreplay -V. Also rename the packet capture with a suffix of .txt and you will be able to upload it to the issue.
Related
From the beginning of the new year, i cannot extract jobs info from my Jenkins, using the classic example that can be found here: https://jenkinsapi.readthedocs.io/en/latest/using_jenkinsapi.html#example-2-get-details-of-jobs-running-on-jenkins-server. In replace of them, i get the following error:
requests.exceptions.ConnectionError: HTTPSConnectionPool(host=,
port=): Max retries exceeded with url:
/job/<JOB_NAME>/api/python?tree=allBuilds%5Bnumber%2Curl%5D (Caused by
ReadTimeoutError("HTTPSConnectionPool(host=, port=): Read
timed out. (read timeout=10)"))
Thanks for any advice.
You will get this error if the host you are connecting to is not available.
I would suggest trying a few network tests to ensure the host is visible:
where:
ReadTimeoutError("HTTPSConnectionPool(host='myhost.something.com', port=1234)
try netcat or tracepath:
-> nc -w 5 -vz myhost.something.com 1234
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.11.12.13:1234.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
-> tracepath -p 33434 myhost.something.com
I've got a build of the OpenVPN3 client library (https://github.com/OpenVPN/openvpn3) connecting to an OpenVPN 2 server (2.4.4). This is working for my mac and windows builds, but failing when the client is iOS.
The iOS client appears to connect, in the sense that I get my custom up script invoked and I can see what I assume are keepalive/heartbeat packets going back and forth between client and server. The client doesn't time out as long as these packets are allowed to continue. However, as soon as the client attempts to access any web page over the tunnel, I get packets dropped on the server side with errors like the following:
Fri Mar 15 20:08:27 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=10 seenFri Mar 15 20:08:28 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=7 seen
Fri Mar 15 20:08:29 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=5 seen
Fri Mar 15 20:08:30 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=9 seen
Fri Mar 15 20:08:31 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=8 seen
Fri Mar 15 20:08:32 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=2 seen
Fri Mar 15 20:08:34 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=13 seen
Fri Mar 15 20:08:38 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=7 seen
I'm using the same server and client configs for iOS as I was using when the client was Mac and Windows.
Server configs:
port 1194
proto udp
dev tun
ca /opt/certs/ca-cert.pem
cert /opt/certs/server.pem
key /opt/certs/server-key.pem
dh /opt/certs/dh2048.pem
tls-auth /opt/certs/ta.key 0
server 10.8.0.0 255.255.0.0
keepalive 5 15
verb 3
script-security 3
client-connect "/usr/local/bin/sdp-updown"
client-disconnect "/usr/local/bin/sdp-updown"
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
comp-lzo
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
Client configs:
dev tun
proto udp
remote ... server and port omitted
remote-cert-tls server
key-direction 1
server-poll-timeout 5
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
comp-lzo
... routes omitted
<ca>
... CA omitted
</ca>
<cert>
... cert omitted
</cert>
<key>
... private key omitted
</key>
<tls-auth>
... OpenVPN static key omitted
</tls-auth>
I've tried a number of different settings for cipher and tls-cipher. When those settings are set to values that are supported on both sides I can get connected, but get the same IP packet with unknown IP version error. Obviously when either cipher or tls-cipher isn't supported on either server or client we fail to negotiate TLS and don't get connected at all.
I found a number of troubleshooting forum posts regarding this error and most of them are resolved by setting the compression settings to the same value on both ends. My iOS client build seems to think that it has no ability to perform compression, even though I think I've linked successfully against the LZ4 library. I compiled the LZ4 library for iOS, and included the LZ4=1 when building a dylib for OpenVPN itself. However, when the iOS client connects it reports settings like:
ENV[IV_AUTO_SESS] = 1
ENV[IV_COMP_STUBv2] = 1
ENV[IV_COMP_STUB] = 1
ENV[IV_LZO_STUB] = 1
ENV[IV_PROTO] = 2
ENV[IV_TCPNL] = 1
ENV[IV_NCP] = 2
ENV[IV_PLAT] = ios
ENV[IV_VER] = 3.1.2
I notice that this does not include IV_LZ4, which I take to mean that the client thinks it can't perform compression. That said, even when my configs include disabled compression I get the same results. I tried omitting any compression setting at all, comp-lzo no, compress stub, and compress stub-v2. None of these resulted in any different behavior.
My questions are thus:
What could be the cause of my IP packet with unknown IP version errors when actually sending packets over the data channel?
If what I'm seeing is actually a compression setting error, how do I convince OpenVPN to disable compression entirely? Alternatively, what have I done wrong to link LZ4 into my iOS OpenVPN dylib?
I have an fluentd, elasticsearch, graylog setup and I'm getting below error intermittently in td-agent log
[warn]: temporarily failed to flush the buffer. next_retry=2019-01-27
19:00:14 -0500 error_class="ArgumentError" error="Data too big (189382
bytes), would create more than 128 chunks!"
plugin_id="object:3fee25617fbc"
Because of this cache memory increases and td-agent fails to send messages to graylog
I have tried setting the buffer_chunk_limit to 8m and flush_interval time to 5sec
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 used the -R and -K option but it doesnt seem to be working as I captured the pumped traffic using tcpdump and the number of packets that I see there dont seem to match the number of packets that I expect in the time frame.
First of all make sure you are using the latest version, available here. You will want to use the -K and --mbps (or -M) options, for example:
# tcpreplay -i eth7 -K --mbps 1000 smallFlows.pcap
File Cache is enabled
Actual: 14261 packets (9216531 bytes) sent in 0.073761 seconds.
Rated: 124951275.0 Bps, 999.61 Mbps, 193340.65 pps
Flows: 1209 flows, 16390.77 fps, 14243 flow packets, 18 non-flow
Statistics for network device: eth7
Attempted packets: 14261
Successful packets: 14261
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
When you attempt to move to higher speeds (e.g. 10GigE) you may need to generate a bigger block of data by using the --loop option. Also with Tcpreplay version 4.0 there are the more advanced --netmap and --unique-ip options which on a properly set up system, will achieve near wire rate and very high flows/sec. More information available at Tcpreplay How To. Here is an example:
# tcpreplay -i eth7 -K --mbps 9500 --loop 100 --netmap --unique-ip smallFlows.pcap
Switching network driver for eth7 to netmap bypass mode... done!
File Cache is enabled
Actual: 1426100 packets (921653100 bytes) sent in 0.776133 seconds.
Rated: 1187493767.1 Bps, 9499.95 Mbps, 1837442.80 pps
Flows: 120900 flows, 155772.27 fps, 1424300 flow packets, 1800 non-flow
Statistics for network device: eth7
Attempted packets: 1426100
Successful packets: 1426100
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
Switching network driver for eth7 to normal mode... done!