Icmp packet utility
While researching socket programming in C, I stumbled upon a piece of code designed to repetitively send icmp packets to a given target. The concept peaked my interest as a viable stress test for a home router, so i copied and compiled the code to see if and how it worked.... well, it DIDN'T work... The code didn't even compile, let alone run. Still interested and not wanting to let this go, I re-wrote the code. Made it better and made it work. I believe this is an interesting utility to say the least and I encourage anyone reading this to test it (ON YOUR OWN SYSTEMS/NETWORK) and/or give input on how to improve upon it. Depending on the feedback i get on here I might try to make a package build out of it.
Disclaimer!!: The following source code is intended specifically for educational purposes and systems testing only. I take no responsibility, and hold no liability for the misuse of this code.
My source code is listed below.
packetsoup.h
* Packetsoup.h
* Prototype Functions for icmp_pingV2 project
* Written By DeadDingo
* All Rights Reserved 12.21.2013
#ifndef PACK_SOUP_H_
#define PACK_SOUP_H_
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <unistd.h>
#include <arpa/inet.h>
typedef unsigned char u8;
typedef unsigned short int u16;
* Description:
* Calculates the checksum on a packet to packet basis
unsigned short in_cksum(unsigned short *ptr, int nbytes);
* Description:
* Displays Usage Dialog
void Usage( void );
#endif
packetsoup.c
* Packsoup.c
* Written by DeadDingo
* All Rights Reserved 12.21.2013
* Note:
* in_cksum() function written by Silver Moon
#include "packetsoup.h"
unsigned short in_cksum(unsigned short *ptr, int nbytes) {
register long sum;
u_short oddbyte;
register u_short answer;
sum = 0;
while(nbytes > 1) {
sum += *ptr++;
nbytes -= 2;
if(nbytes == 1) {
oddbyte = 0;
*((u_char *) & oddbyte ) = *(u_char *) ptr;
sum += oddbyte;
sum = (sum >> 16) + (sum & 0xffff);
sum += (sum >> 16);
answer = ~sum;
return answer;
void Usage( void ) {
puts("Usage: ");
puts(" -s <source address>");
puts(" -d <destination address>");
puts(" -p <payload size>");
printf("a.out -s <source address> -d <destination address> -p <payload size>\n");
exit(8);
main.c
* icmp_pingV2 project
* ICMP packet utility
* Orriginally Written By Silver Moon
* Version 2 Written By DeadDingo
* Copyright 12.21.2013
* This file is part of the icmp_ping package
* The icmp_pingV2 package is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public Licence as published by
* the Free Software Foundation, either version 3 of the Licence, or
* (at your option) any later version.
* The icmp_pingV2 package is distrubuted in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABLILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public Licence for more details.
* You should have received a copy of the GNU General Public Licence
* along with the DoS package. If not, see <http://www.gnu.org/licences/>.
* ================================================
* Version 2 Channel Log:
* - Better Argument Parsing
* - Better Error Checking
* - Fixed Bad Structure Types (Now runs on BSD, Linux, and OSX)
* - Fixed Bad Member Variables
* - Added Usage Dialog
#include "packetsoup.h"
int main ( int argc, char *argv[ ] ) {
unsigned long daddr;
unsigned long saddr;
int payload_size = 0, sent, sent_size, on, i;
* Argument Parsing...*/
if(argc < 3) {
Usage();
for( i = 1; i < argc; i ++ ) {
if(strncmp(argv[i], "-s", 2) == 0) {
saddr = inet_addr(argv[i+1]);
if(strncmp(argv[i], "-d", 2) == 0) {
daddr = inet_addr(argv[i+1]);
if(strncmp(argv[i], "-p", 2) == 0) {
payload_size = atoi(argv[i+1]);
} //end for loop
//end arg parsing
//Get Raw Socket
int sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
if(sockfd < 0) {
perror("Could not create socket:");
return 0;
puts("Socket Is Live!");
//provide packet headers
if( setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, (const char *)&on, sizeof(on)) == -1 ) {
perror("setsockopt:");
return 0;
//allow socket to send datagrams to broadcast addresses
if( setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, (const char *)&on, sizeof(on)) == -1 ) {
perror("setsockopt");
return 0;
//calc packet size
int packet_size = sizeof(struct ip) + sizeof(struct icmp) + payload_size;
char *packet = (char *)malloc(packet_size);
if(!packet) {
perror("Memory Error");
close(sockfd);
return 0;
//ip header
struct ip *iphdr = (struct ip *)packet;
struct icmp *icmphdr = (struct icmp *) (packet + sizeof(struct ip));
//zero the packet buffer
memset(packet, 0, packet_size);
//set member variables and whatnot
iphdr->ip_v = 4;
iphdr->ip_hl = 5;
iphdr->ip_tos = 0;
iphdr->ip_len = htons(packet_size);
iphdr->ip_id = rand();
iphdr->ip_off = 0;
iphdr->ip_ttl = 255;
iphdr->ip_p = IPPROTO_ICMP;
iphdr->ip_src.s_addr = saddr;
iphdr->ip_dst.s_addr = daddr;
icmphdr->icmp_type = ICMP_ECHO;
icmphdr->icmp_code = 0;
icmphdr->icmp_seq = rand();
icmphdr->icmp_id = rand();
icmphdr->icmp_cksum = 0;
struct sockaddr_in servaddr;
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = daddr;
memset(&servaddr.sin_zero, 0, sizeof(servaddr.sin_zero));
puts("sending to target...");
while(1) {
memset(packet + sizeof(struct ip) + sizeof(struct icmp), rand() % 255, payload_size);
//calculate icmp header checksum
icmphdr->icmp_cksum = 0;
icmphdr->icmp_cksum = in_cksum( (unsigned short *)icmphdr, sizeof(struct icmp) + payload_size );
if( ( sent_size = sendto( sockfd, packet, packet_size, 0, (struct sockaddr *) &servaddr, sizeof(servaddr) ) ) < 1 ) {
perror("Packet Send Failed");
break;
++sent;
printf("%d packets sent\r", sent);
fflush(stdout);
usleep(10000);
free(packet);
close(sockfd);
return 0;
Last edited by DeadDingo (2013-12-27 04:07:24)
Ok sounds good, like I said, it is meant to be a learning tool as some of the demo code available online does not accurately portray the proper ip structures needed for socket communication. I actually had to read through a bunch of C libraries to find the correct structs and member variables.
Similar Messages
-
Hi Guys,
Actually we have two ASA 5520 in active/passive. We are losing random icmp packets between hosts located at different ASA’s interfaces or zones so; random icmp packets are losed when cross the firewalls.
asa# sh interface | i errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 output errors, 0 collisions, 2 interface resets
94 input errors, 0 CRC, 0 frame, 94 overrun, 0 ignored, 0 abort
0 output errors, 0 collisions, 2 interface resets
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 output errors, 0 collisions, 2 interface resets
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 output errors, 0 collisions, 2 interface resets
2 input errors, 0 CRC, 0 frame, 2 overrun, 0 ignored, 0 abort
0 output errors, 0 collisions, 0 interface resets
asa# show conn count
7924 in use, 7934 most used
asa# show resource usage
Resource Current Peak Limit Denied Context
SSH 2 2 5 0 System
ASDM 1 3 5 0 System
Syslogs [rate] 444 1295 N/A 0 System
Conns 7284 8000 280000 0 System
Xlates 2728 3063 N/A 0 System
Hosts 3155 3403 N/A 0 System
Conns [rate] 195 946 N/A 0 System
Inspects [rate] 20 280 N/A 0 System
asa# sh processes cpu-usage non-zero
PC Thread 5Sec 1Min 5Min Process
081a86c4 c91afa08 56.9% 45.1% 37.5% Dispatch Unit
08c15df6 c91a93a8 1.3% 1.3% 1.2% Logger
08190627 c91a4ec0 0.0% 0.1% 0.0% tmatch compile thread
084b6fa1 c91a40f8 0.3% 0.6% 0.6% IKE Daemon
083ccbfc c91a17a0 0.1% 0.1% 0.1% fover_health_monitoring_thread
08405637 c91a13b0 0.0% 0.1% 0.1% ha_trans_data_tx
085345ae c91a09d8 0.5% 0.3% 0.3% ARP Thread
088c038d c918f248 2.3% 2.2% 2.3% Unicorn Admin Handler
08bde96c c9189ba8 0.2% 0.4% 0.2% sshActually I followed your recommendation about capture icmp traffic on ingress and egress interfaces to see how many packets are getting to the ASA and how many are leaving... Dammit!, I saw the same input and output traffic. I can’t see on the ASP capture any icmp packet being dropped by the ASA…
Thxs a lot guys for your help, I really appreciated that.
asa(config)# sh capture
capture capin type raw-data interface franqui [Capturing - 204480 bytes]
match icmp host 192.168.3.130 host 172.31.5.28
capture capout type raw-data interface inside [Capturing - 204480 bytes]
match icmp host 192.168.3.130 host 172.31.5.28
capture asp type asp-drop all buffer 9999999 [Capturing - 9880419 bytes]
asa(config)#
asa(config)# sho cap asp | i 192.168.3.130
1094: 11:15:02.770056 192.168.3.130.80 > 10.150.4.139.52083: . ack 1800180435 win 64240
8427: 11:16:39.131340 192.168.3.130.137 > 192.168.3.255.137: udp 50
8534: 11:16:39.877548 192.168.3.130.137 > 192.168.3.255.137: udp 50
8606: 11:16:40.624982 192.168.3.130.137 > 192.168.3.255.137: udp 50
13257: 11:17:46.657253 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
15450: 11:18:18.148170 192.168.3.130.137 > 192.168.3.255.137: udp 50
23235: 11:20:01.004226 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
24334: 11:20:15.551271 192.168.3.130.138 > 192.168.3.255.138: udp 201
28941: 11:21:21.650265 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
30622: 11:21:47.743842 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
38870: 11:23:44.843721 192.168.3.130.137 > 192.168.3.255.137: udp 50
51315: 11:26:39.053433 192.168.3.130.137 > 192.168.3.255.137: udp 50
51382: 11:26:39.790349 192.168.3.130.137 > 192.168.3.255.137: udp 50
51438: 11:26:40.540285 192.168.3.130.137 > 192.168.3.255.137: udp 50
66736: 11:30:18.165610 192.168.3.130.137 > 192.168.3.255.137: udp 50
75694: 11:32:17.742301 192.168.3.130.138 > 192.168.3.255.138: udp 201
asa(config)# sho cap asp | i 172.31.5.28
458: 11:14:54.353894 172.31.5.28.138 > 172.31.255.255.138: udp 201
9219: 11:16:49.088404 172.31.5.28.63954 > 172.31.5.254.443: F 1216116677:1216116677(0) ack 3105814648 win 65535
9220: 11:16:49.129647 172.31.5.28.63955 > 172.31.5.254.443: F 3311562654:3311562654(0) ack 1788680111 win 65535
9907: 11:16:58.316817 172.31.5.28.63957 > 172.31.5.254.443: F 2372132966:2372132966(0) ack 3446739520 win 65535
9924: 11:16:58.465155 172.31.5.28.63958 > 172.31.5.254.443: F 3052199358:3052199358(0) ack 4060397993 win 65535
9926: 11:16:58.478353 172.31.5.28.63959 > 172.31.5.254.443: F 2416626469:2416626469(0) ack 600987510 win 65535
10207: 11:17:01.425911 172.31.5.28.63960 > 172.31.5.254.443: F 4284764250:4284764250(0) ack 2764360472 win 65535
10209: 11:17:01.462653 172.31.5.28.63962 > 172.31.5.254.443: F 2897853406:2897853406(0) ack 36732653 win 65535
10562: 11:17:06.392862 172.31.5.28.63963 > 172.31.5.254.443: F 3418331111:3418331111(0) ack 4106159305 win 65535
10566: 11:17:06.437782 172.31.5.28.63965 > 172.31.5.254.443: F 351951743:351951743(0) ack 3852846382 win 65535
10570: 11:17:06.491109 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) ack 2036124283 win 0
10571: 11:17:06.491322 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) win 0
10605: 11:17:06.990885 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) ack 1444481707 win 0
10606: 11:17:06.991113 172.31.5.28.63966 > 172.31.5.254.443: F 4291895411:4291895411(0) ack 1869758408 win 65535
10607: 11:17:06.991205 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) win 0
10716: 11:17:09.033506 172.31.5.28.63968 > 172.31.5.254.443: F 1213337051:1213337051(0) ack 2793080200 win 65535
28699: 11:21:18.048444 172.31.5.28.63978 > 172.31.5.254.443: F 3516588597:3516588597(0) ack 4082523455 win 65535
28702: 11:21:18.082530 172.31.5.28.63979 > 172.31.5.254.443: F 2624860618:2624860618(0) ack 1229240024 win 65535
29157: 11:21:25.289917 172.31.5.28.63980 > 172.31.5.254.443: F 1840304766:1840304766(0) ack 3822990521 win 65535
29159: 11:21:25.369808 172.31.5.28.63983 > 172.31.5.254.443: F 879930713:879930713(0) ack 1786169064 win 65535
29160: 11:21:25.381587 172.31.5.28.63984 > 172.31.5.254.443: F 427260469:427260469(0) ack 341330867 win 65535
29321: 11:21:28.067242 172.31.5.28.63985 > 172.31.5.254.443: F 2238218183:2238218183(0) ack 2288210469 win 65535
29325: 11:21:28.098902 172.31.5.28.63986 > 172.31.5.254.443: F 118474273:118474273(0) ack 4277263123 win 65535
29665: 11:21:33.143074 172.31.5.28.63987 > 172.31.5.254.443: F 1353084768:1353084768(0) ack 2091147977 win 65535
29667: 11:21:33.174566 172.31.5.28.63989 > 172.31.5.254.443: F 3477322977:3477322977(0) ack 2198309559 win 65535
29701: 11:21:33.621763 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) ack 2966254164 win 0
29702: 11:21:33.622007 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) ack 2362014837 win 0
29703: 11:21:33.622282 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) win 0
29704: 11:21:33.622328 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) win 0
29767: 11:21:34.860764 172.31.5.28.63992 > 172.31.5.254.443: F 4226212155:4226212155(0) ack 2230361367 win 65535
52256: 11:26:52.323835 172.31.5.28.138 > 172.31.255.255.138: udp 201
asa(config)# sho cap asp | i 192.168.3.130
1094: 11:15:02.770056 192.168.3.130.80 > 10.150.4.139.52083: . ack 1800180435 win 64240
8427: 11:16:39.131340 192.168.3.130.137 > 192.168.3.255.137: udp 50
8534: 11:16:39.877548 192.168.3.130.137 > 192.168.3.255.137: udp 50
8606: 11:16:40.624982 192.168.3.130.137 > 192.168.3.255.137: udp 50
13257: 11:17:46.657253 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
15450: 11:18:18.148170 192.168.3.130.137 > 192.168.3.255.137: udp 50
23235: 11:20:01.004226 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
24334: 11:20:15.551271 192.168.3.130.138 > 192.168.3.255.138: udp 201
28941: 11:21:21.650265 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
30622: 11:21:47.743842 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137: udp 50
38870: 11:23:44.843721 192.168.3.130.137 > 192.168.3.255.137: udp 50
51315: 11:26:39.053433 192.168.3.130.137 > 192.168.3.255.137: udp 50
51382: 11:26:39.790349 192.168.3.130.137 > 192.168.3.255.137: udp 50
51438: 11:26:40.540285 192.168.3.130.137 > 192.168.3.255.137: udp 50
66736: 11:30:18.165610 192.168.3.130.137 > 192.168.3.255.137: udp 50
75694: 11:32:17.742301 192.168.3.130.138 > 192.168.3.255.138: udp 201
asa(config)# sho cap asp | i 172.31.5.28
458: 11:14:54.353894 172.31.5.28.138 > 172.31.255.255.138: udp 201
9219: 11:16:49.088404 172.31.5.28.63954 > 172.31.5.254.443: F 1216116677:1216116677(0) ack 3105814648 win 65535
9220: 11:16:49.129647 172.31.5.28.63955 > 172.31.5.254.443: F 3311562654:3311562654(0) ack 1788680111 win 65535
9907: 11:16:58.316817 172.31.5.28.63957 > 172.31.5.254.443: F 2372132966:2372132966(0) ack 3446739520 win 65535
9924: 11:16:58.465155 172.31.5.28.63958 > 172.31.5.254.443: F 3052199358:3052199358(0) ack 4060397993 win 65535
9926: 11:16:58.478353 172.31.5.28.63959 > 172.31.5.254.443: F 2416626469:2416626469(0) ack 600987510 win 65535
10207: 11:17:01.425911 172.31.5.28.63960 > 172.31.5.254.443: F 4284764250:4284764250(0) ack 2764360472 win 65535
10209: 11:17:01.462653 172.31.5.28.63962 > 172.31.5.254.443: F 2897853406:2897853406(0) ack 36732653 win 65535
10562: 11:17:06.392862 172.31.5.28.63963 > 172.31.5.254.443: F 3418331111:3418331111(0) ack 4106159305 win 65535
10566: 11:17:06.437782 172.31.5.28.63965 > 172.31.5.254.443: F 351951743:351951743(0) ack 3852846382 win 65535
10570: 11:17:06.491109 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) ack 2036124283 win 0
10571: 11:17:06.491322 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) win 0
10605: 11:17:06.990885 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) ack 1444481707 win 0
10606: 11:17:06.991113 172.31.5.28.63966 > 172.31.5.254.443: F 4291895411:4291895411(0) ack 1869758408 win 65535
10607: 11:17:06.991205 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) win 0
10716: 11:17:09.033506 172.31.5.28.63968 > 172.31.5.254.443: F 1213337051:1213337051(0) ack 2793080200 win 65535
28699: 11:21:18.048444 172.31.5.28.63978 > 172.31.5.254.443: F 3516588597:3516588597(0) ack 4082523455 win 65535
28702: 11:21:18.082530 172.31.5.28.63979 > 172.31.5.254.443: F 2624860618:2624860618(0) ack 1229240024 win 65535
29157: 11:21:25.289917 172.31.5.28.63980 > 172.31.5.254.443: F 1840304766:1840304766(0) ack 3822990521 win 65535
29159: 11:21:25.369808 172.31.5.28.63983 > 172.31.5.254.443: F 879930713:879930713(0) ack 1786169064 win 65535
29160: 11:21:25.381587 172.31.5.28.63984 > 172.31.5.254.443: F 427260469:427260469(0) ack 341330867 win 65535
29321: 11:21:28.067242 172.31.5.28.63985 > 172.31.5.254.443: F 2238218183:2238218183(0) ack 2288210469 win 65535
29325: 11:21:28.098902 172.31.5.28.63986 > 172.31.5.254.443: F 118474273:118474273(0) ack 4277263123 win 65535
29665: 11:21:33.143074 172.31.5.28.63987 > 172.31.5.254.443: F 1353084768:1353084768(0) ack 2091147977 win 65535
29667: 11:21:33.174566 172.31.5.28.63989 > 172.31.5.254.443: F 3477322977:3477322977(0) ack 2198309559 win 65535
29701: 11:21:33.621763 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) ack 2966254164 win 0
29702: 11:21:33.622007 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) ack 2362014837 win 0
29703: 11:21:33.622282 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) win 0
29704: 11:21:33.622328 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) win 0
29767: 11:21:34.860764 172.31.5.28.63992 > 172.31.5.254.443: F 4226212155:4226212155(0) ack 2230361367 win 65535
52256: 11:26:52.323835 172.31.5.28.138 > 172.31.255.255.138: udp 201 -
Regarding ICMP "Packet Too Big" message in 6PE RFC 4798
Dear All,
The penultimate para in Section 3, Page 6 of 6PE RFC 4798 states the following:
"Otherwise, routers in the IPv4 MPLS network have the option to generate an ICMP "Packet Too Big" message using mechanisms as described in Section 2.3.2 .... of [RFC3032]"
As per RFC3032, the routers in the IPv4 MPLS network can generate ICMP "Time Exceeded" message or "Destination Unreachable because fragmentation needed and DF set" message.
Can someone please explain, how a IPv4 MPLS router will generate an ICMP "Packet Too Big"? This requires that the router in IPv4 MPLS network be a dual stack router to understand the IPv6 header under the label stack. Is my understanding correct?
If the router is an intermediate LSR, how will it know the path to the IPv6 destination even if it is dual stack router?
Thanks in advance.
Cheers,
SriramSriram,
The IPv4 core router does need to have code to understand IPv6 and create the "Packet too big" message and so on. It does not need to be configured for IPv6 though (dual stack).
The forwarding will be done based on the incoming label stack for that IPv6 packet, which means that the ICMPv6 message will be constructed with the source of the original packet as the destination IPv6 address, the top label for the incoming IPv6 packet will be swapped, prepended to the ICMPv6 message and forwarded through the egress interface. The egress PE will received this ICMPv6 message and forwarding appropriately.
The same mechanism is used when performing traceroutes in an L3VPN context, as the core routers have no knowledge of the address space being used by the L3VPN customers and couldn't otherwise forward ICMP messages to the proper source.
Regards -
Windows Firewall indound icmp packets drop
Hi, we have enabled icmpv4 traffic with a local firewall inbound rule in a gpo and we still having ping drops. Is there another value somewhere that we could disable in our setup. It seems like a protection coming from the windows
server 2008 and for no specific reason it blocks the traffic.
The ping comes from a load balancer linux base machine. We have created another test rule that is opening all ports and all protocol coming from that ip address and we get the same behaviour.
We know if we restart the server it will let the ping go through again with no problem but for a relatively short period of time.
Carl R.
ThanksHi Carl,
>>we have enabled icmpv4 traffic with a local firewall inbound rule in a gpo and we still having ping drops.
Before going further, we can cmd command gpresult/h gpreport.html with admin privileges to collect group policy result to check if the policy setting was applied successfully.
Regarding how to allow inbound Internet Control Message Protocol (ICMP) network traffic, the following article can be referred for more information.
Create an Inbound ICMP Rule on Windows 7, Windows Vista, Windows Server 2008, or Windows Server 2008 R2
http://technet.microsoft.com/en-us/library/cc972926(v=ws.10).aspx
Besides, for this is related to network, in order to get more and better help, we can also ask for suggestions in the following network forum.
Network Access Protection
https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverNAP
Best regards,
Frank Shen -
HOW TO FIND THE PATH TRAVELLED BY THE CLIENT'S REQUEST PACKET
Hi,
I want to know is there any way by which we can know the entire path or the hops travelled by the client request packet to reach the web-server.Say suppose the client machine is part of a large network in a corparate where there is a a personlaized WAN. I want to know whther i can achive this using the servlets.
and i even want to know some information about the client's NIC Card Physical Address.If at all i use the HttpServletRequest.inetAddress() gives the public IP of the Client which is shared in the network.
Please suggest me a way by which i can do this.
Thanks in Advance!!!
Regards,
RAHULhey i m back
import java.net.Inet4Address;
import java.net.InetAddress;
import java.net.URL;
import java.util.Arrays;
import jpcap.JpcapCaptor;
import jpcap.JpcapSender;
import jpcap.NetworkInterface;
import jpcap.NetworkInterfaceAddress;
import jpcap.packet.EthernetPacket;
import jpcap.packet.ICMPPacket;
import jpcap.packet.IPPacket;
import jpcap.packet.Packet;
public class Traceroute {
public static void main(String[] args) throws Exception{
if(args.length<2){
System.out.println("Usage: java Traceroute <device index (e.g., 0, 1..)> <target host address>");
System.exit(0);
//initialize Jpcap
NetworkInterface device=JpcapCaptor.getDeviceList()[Integer.parseInt(args[0])];
JpcapCaptor captor=JpcapCaptor.openDevice(device,2000,false,5000);
InetAddress thisIP=null;
for(NetworkInterfaceAddress addr:device.addresses)
if(addr.address instanceof Inet4Address){
thisIP=addr.address;
break;
//obtain MAC address of the default gateway
InetAddress pingAddr=InetAddress.getByName("www.microsoft.com");
captor.setFilter("tcp and dst host "+pingAddr.getHostAddress(),true);
byte[] gwmac=null;
while(true){
new URL("http://www.microsoft.com").openStream().close();
Packet ping=captor.getPacket();
if(ping==null){
System.out.println("cannot obtain MAC address of default gateway.");
System.exit(-1);
}else if(Arrays.equals(((EthernetPacket)ping.datalink).dst_mac,device.mac_address))
continue;
gwmac=((EthernetPacket)ping.datalink).dst_mac;
break;
//create ICMP packet
ICMPPacket icmp=new ICMPPacket();
icmp.type=ICMPPacket.ICMP_ECHO;
icmp.seq=100;
icmp.id=0;
icmp.setIPv4Parameter(0,false,false,false,0,false,false,false,0,0,0,IPPacket.IPPROTO_ICMP,
thisIP,InetAddress.getByName(args[1]));
icmp.data="data".getBytes();
EthernetPacket ether=new EthernetPacket();
ether.frametype=EthernetPacket.ETHERTYPE_IP;
ether.src_mac=device.mac_address;
ether.dst_mac=gwmac;
icmp.datalink=ether;
captor.setFilter("icmp and dst host "+thisIP.getHostAddress(),true);
JpcapSender sender=captor.getJpcapSenderInstance();
//JpcapSender sender=JpcapSender.openDevice(device);
sender.sendPacket(icmp);
while(true){
ICMPPacket p=(ICMPPacket) captor.getPacket();
//System.out.println("received "+p);
if(p==null){
System.out.println("Timeout");
}else if(p.type==ICMPPacket.ICMP_TIMXCEED){
p.src_ip.getHostName();
System.out.println(icmp.hop_limit+": "+p.src_ip);
icmp.hop_limit++;
}else if(p.type==ICMPPacket.ICMP_UNREACH){
p.src_ip.getHostName();
System.out.println(icmp.hop_limit+": "+p.src_ip);
System.exit(0);
}else if(p.type==ICMPPacket.ICMP_ECHOREPLY){
p.src_ip.getHostName();
System.out.println(icmp.hop_limit+": "+p.src_ip);
System.exit(0);
}else continue;
sender.sendPacket(icmp);
} -
What is the -k option for of the Ping utility in OS X?
Hi,
May I know what is the -k option for of the Ping utility in OS X? It doesn't seem to be a ICMP protocol standards-relates.
Below is the description of this option copied from Yosemite.
-k trafficlass
Specifies the traffic class to use for sending ICMP packets. The
supported traffic classes are BK_SYS, BK, BE, RD, OAM, AV, RV,
VI, VO and CTL. By default ping uses the control traffic class
(CTL).
Thank you!These are low-level bits defined in the kernel's IPv6 support code.
Here is the first reference I could find that actually says what some of them are: https://github.com/darwin-on-arm/xnu/blob/master/bsd/sys/kpi_mbuf.h
Search for "MBUF_TC_BE" -
ICMP Inspection and Extended Access-List
I need a little help clarifying the need for an Extended Access-list when ICMP Inspect is enabled on an ASA. From reading various documents such as the following (http://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/15246-31.html), I CAN allow ICMP through my ASA using an extended access-list or enabling ICMP Inspection in the Modular Policy Framework. Is that true? I only NEED an Extended Access-list or enable ICMP Inspection? I do not need both? Or is it best practice to do both?
What does the ASA do to a PING from a host on the inside interface (Security 100) to host on the outside interface (Security 0) when ICMP Inspection is enabled with the following commands:
policy-map global_policy
class inspection_default
inspect_icmp
However, the following commands are NOT placed on the inbound Extended Access-list of the outside interface:
access-list inbound permit icmp any any echo-reply
access-list inbound permit icmp any any source-quench
access-list inbound permit icmp any any unreachable
access-list inbound permit icmp any any time-exceeded
access-group inbound in interface outside
Will the PING complete?
Thank you,
T.J.Hi, T.J.
If problem is still actual, I can answer you this question.
Let's see situation without ICMP inspection enabled:
The Cisco ASA will allow ICMP packets only in case if ACL entry exist on interface, where packet goes in. If we're speaking about ping, then ACL rules must allow packets in both directions.
In case with ICMP inspection, with ACL entry you should allow only request packets, replies will be allowed based on ICMP inspection created connection.
Speaking about your particular example with different security levels - with default ACL rule, that allow traffic from higher interface to lower - NO, you can do not enter that rules you described, and as you'll have successful ping.
If you deleted this rule and administrate allowed traffic manually, then YES, you must allow ICMP requests to have successful ping.
P.S. It's not a good practice to leave that default rule, which allow traffic from higher sec.lvl. to lower. -
Hi,
I have a strange behavior on a ACE blade :
The blade is configured in bridge mode, when a configured reals server, if they are on the same site, the probe is ok, if they are on another site, the probe is failed.
What I found is that the echo reply on the PO of the blade is padded with 23 bytes of "0" only for the probe.
This is really strange...
the version of the blade and ios:
blade : 3.0(0)A1(4a)
Sup (720): 12.2(18)SXF8
I found on the forum that it could be related to the PFC3b but I don't see how I could try to bypass it.
Thanks for your help ;-)I understand the reply will come on some ethernet module and be forwarded into the ACE PO.
So, what is the the ethernet hardware module type ? 'show mod'.
Could you also give us the trace so we can look at the icmp packet.
Thanks,
Gilles. -
Excessive ICMP traffic on server
Hello,
I am experiencing excessive ICMP traffic on all my Netware 6.5 SP6
servers. This ICMP traffic originates at the server; not from a
workstation. Tried to search KB but no luck. I want to know if any
netware products rely on ICMP communication and if I can disable ICMP at
the server console. Currently we have ACLs on all core switches denying
ICMP traffic. However, all the traffic on the network itself is causing
congestion.
To give you an idea of the problem, this AM I tried to download a 1MB file
from a remote site and it took an ave. of 5 min. I then, powered off the
NW server, checked the logs on core switch, ICMP traffic literally
disappeared, and tried the same download again; this time only taking 40
sec.
Please help! This is affecting my network drastically!!!There are different scenarios in which ICMP packets copuld be generated.
You should really capture the ICMP packets to see what is really going on.
Some possible cases are:
- ICMP packets used for costing (e.g. determinining the distance of other
servers to see which server might be the best to talk to)
- ICMP replies in case of error conditions (can't fragmnet and no such
protocol replies)
while filtering ICMP traffic in itself is a good idea, blankly turning it
off completely is generally a very bad idea as some communications really
need ICMP and perform badly without out (for instance MTU detection will
not work without ICMP)
Marcel Cox (using XanaNews 1.18.1.6) -
Hello,
I configured icmp inspection on the ACE module [system:Version A2(3.3) [build 3.0(0)A2(3.3)] but I'm not able to see any packets in counters with show service-policy name, all counters are empty. How would I see if icmp packet inspection is operational and show stats.
thanks
ACE-1/non-prod# sh service-policy ICMP_INSPECT_POLICY
Status : ACTIVE
Interface: vlan 65
service-policy: ICMP_INSPECT_POLICY
class: ICMP_INSPECT_CLASS
inspect icmp:
icmp error: DISABLED
curr conns : 0 , hit count : 0
dropped conns : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
config :
access-list icmp line 8 extended permit icmp any any
access-list ANYONE line 1 extended permit ip any any
class-map match-any ICMP_INSPECT_CLASS
description Class for ICMP Inspection
2 match access-list icmp
policy-map multi-match ICMP_INSPECT_POLICY
class ICMP_INSPECT_CLASS
inspect icmp
interface vlan 65
ip address 172.16.128.8 255.255.255.0
mac-sticky enable
access-group input ANYONE
access-group output ANYONE
nat-pool 1 172.16.128.252 172.16.128.254 netmask 255.255.255.255 pat
service-policy input VIPS
service-policy input REMOTE_MGMT_POLICY
service-policy input ICMP_INSPECT_POLICY
no shutdownHello Jorge,
thanks for your reply...to clarify a bit, from a client PC I can ping servers and VIPs but I want to have stats on ICMP inspect to be sure that ICMP packets are being inspected.
the command show conn | in ICMP shows ICMP sessions even if icmp inspection and icmp-guard are not applied on the interface.
the line "access-group input icmp" does not apply on interface because access-list ANYONE is already applied (Error: An access-list of the same type has been already activated on the interface).
I applied also the "no normalization" but the output for ICMP_INSPECT and VIPS policies are still the same
here they are :
ACE-1/non-prod# show service-policy VIPS
Status : ACTIVE
Interface: vlan 65
service-policy: VIPS
class: MAX_L4VIP_HTTP
loadbalance:
L7 loadbalance policy: REDIRECT_L7PLB_HTTP
VIP Route Metric : 77
VIP Route Advertise : ENABLED-WHEN-ACTIVE
VIP ICMP Reply : ENABLED-WHEN-ACTIVE
VIP State: INSERVICE
curr conns : 0 , hit count : 0
dropped conns : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
class: MAX_L4VIP_HTTPS
ssl-proxy server: MAX_SSL_PROXY_SERVER
nat:
nat dynamic 1 vlan 65
curr conns : 0 , hit count : 0
dropped conns : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
loadbalance:
L7 loadbalance policy: MAX_L7PLB_HTTPS
Regex dnld status : SUCCESSFUL
VIP Route Metric : 77
VIP Route Advertise : ENABLED-WHEN-ACTIVE
VIP ICMP Reply : ENABLED-WHEN-ACTIVE
VIP State: INSERVICE
curr conns : 0 , hit count : 4
dropped conns : 0
client pkt count : 34 , client byte count: 4129
server pkt count : 9 , server byte count: 1928
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
Parameter-map(s):
HTTP_PARAM_MAP
class: class-default
Parameter-map(s):
TCP_PARAM_MAP
ACE-1/non-prod#
ACE-1/non-prod# sh service-policy ICMP_INSPECT_POLICY
Status : ACTIVE
Interface: vlan 65
service-policy: ICMP_INSPECT_POLICY
class: ICMP_INSPECT_CLASS
inspect icmp:
icmp error: DISABLED
curr conns : 0 , hit count : 0
dropped conns : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0 -
Experiencing high packet loss.
Hello, I am experiencing relatively high packet loss, in particular when connected to my teamspeak server which is at andesite.typefrag.com.
Here is my tracert
Tracing route to andesite.typefrag.com [54.209.243.18]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1]
2 8 ms 6 ms 7 ms L100.NWRKNJ-VFTTP-83.verizon-gni.net [173.70.104.1]
3 8 ms 12 ms 9 ms G0-13-0-2.NWRKNJ-LCR-21.verizon-gni.net [130.81.216.128]
4 6 ms 7 ms 6 ms ae3-0.NWRK-BB-RTR1.verizon-gni.net [130.81.199.186]
5 13 ms 18 ms 11 ms 0.xe-3-0-1.BR1.NYC1.ALTER.NET [152.63.5.149]
6 11 ms 59 ms 10 ms jfk-brdr-04.inet.qwest.net [63.235.40.53]
7 * 20 ms * dca2-edge-01.inet.qwest.net [67.14.36.10]
8 18 ms 19 ms 19 ms 65.120.78.82
9 19 ms 19 ms 19 ms 72.21.220.149
10 20 ms 19 ms 21 ms 72.21.222.129
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 22 ms 19 ms 19 ms ec2-54-209-243-18.compute-1.amazonaws.com [54.209.243.18]
Trace complete.
I am not exactly sure what to make of this or where to go at this point in resolving the issue, any help would be greatly appreciated.
Thanks.Where are you experiencing packet loss? I see ICMP de-priortization at 1 hop and 100% dropping of ICMP at 3 of the 4 last hops but otherwise no packet loss. What sort of issues are you having? It's packet loss at the destination that is the issue, not in between. It's not uncommon for hops between source and destination to drop some or all ICMP packets as they're more concerned with legitimate data.
WinMTR statistics
Host
Sent
Recv
Best
Avrg
Wrst
Last
L100.PITBPA-VFTTP-33.verizon-gni.net
0
219
219
2
4
42
2
G0-1-0-5.PITBPA-LCR-22.verizon-gni.net
1
215
214
2
5
11
5
xe-0-1-0-0.PHIL-BB-RTR2.verizon-gni.net
0
219
219
10
19
163
10
0.xe-7-3-0.BR1.IAD8.ALTER.NET
0
219
219
15
18
72
16
dcp-brdr-03.inet.qwest.net
0
219
219
15
17
82
17
dca2-edge-01.inet.qwest.net
1
215
214
15
17
69
15
65.120.78.82
0
219
219
15
17
83
16
72.21.220.149
0
219
219
17
18
26
18
205.251.245.63
0
219
219
17
24
56
41
No response from host
100
43
0
0
0
0
0
No response from host
100
43
0
0
0
0
0
No response from host
100
43
0
0
0
0
0
ec2-54-209-243-18.compute-1.amazonaws.com
0
219
219
15
16
26
17 -
CSMARS reporting ICMP traffic between hosts and Exchange Server
We recently added a CSMARS box to our infrastructure so it could correlate and report on our 4260's alerts. I've noticed that CSMARS is reporting on ICMP's from multiple hosts within our network sending ICMP packets to our Exchange server. The total amounts of packets are between 15 and 30 and then the ICMP's from the specific clients stop.
I know that Windows XP clients will send ICMP traffic to domain controllers in order to test connectivity and I'm wondering if we're seeing the same occurrence with our Exchange clients.
Thanks,
JavierHi, the signature that is firing is ICMP Flood
Signature ID: 2152/0. According to Cisco's site this signature should not fire under normal circumstances. However, when we first setup the IPS sensor it would deny all vpn users' access to our exchange server as the Win Nuke signature kept firing. Of course this was a false positive.
However, once I tweaked the CSMARS rule a bit the noise calmed down and it reported on two hosts that were trying to send ICMP floods to Google. -
how does PAT/NAT perform on ICMP packets if there are not ports like udp/tcp ?
best regards
francescoHave a look at these documents
http://tools.ietf.org/wg/behave/draft-ietf-behave-nat-icmp/draft-ietf-behave-nat-icmp-01-from-00.wdiff.html
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080093f96.shtml
Both would help you understand
HTH
Hoogen
Do rate if this helps :) -
Cisco 3750 --- Mark TCP packets from port 80 with DSCP ef
Good afternoon,
I am trying to mark outgoing traffic from a web server with value of DSCP ef
When I am doing a traffic capture all TCP packets have tos 0x0
If I marked UDP packets, or icmp packets, I can see it with in trafic capture, but not TCP traffic.
This is my config,
mls qos
ip access-list extended MARK-HTTP-ACL
permit tcp host 10.10.10.10 eq www any
class-map match-any HTTP-CM
match access-group name MARK-HTTP-ACL
policy-map PRIORITY-PM
class HTTP-CM
set dscp ef
interface GigabitEthernet1/0/11
switchport access vlan 20
switchport mode access
spanning-tree portfast
mls qos trust dscp
service-policy input PRIORITY-PM
Can anybody can help me to understand, why I cannot mark TCP packets?
Thank youYes. You need to eliminate the things I've said to eliminate with the other side. Ensure your configs are matching exactly. They probably are, whatever, just make sure of it because it's easy. You both need to run packet captures on your interfaces both in and out to even begin to have an idea of where to look.
The more info you can have just one person responsible for the better. What I mean by that is, it's typically a nice step for the 'bigger end' to have the 'smaller end's' config file to look at.
If you are seeing packets come in your inside, leave your outside, and never make it to his inside, then take it a step at a time.
If you're seeing them come in his interface and never come back out, you know where to look.
Set your caps to a single host to single host if need be, and generate traffic accordingly.
You need to narrow down where NOT to look so that you know where TO look. I would say then, and only then, do you get the ISP involved. Once you're sure the problem exists between his edge device and your edge device.
I do exactly this for a living on a daily basis...day after day after day. I'm responsible for over 200 IPSec s2s connections and thousands of SSL VPN sessions. I always start the exact same way...from the very bottom. -
BGP PROCESSES AND ICMP TREATMENT
Hi everybody
I hope you guys are doing fine.
http://www.cisco.com/c/en/us/support/do
cs/ip/border-gateway-protocol-bgp/107615-highcpu-bgp.html#understandbgp
From the above link:
While BGP scanner runs, low priority processes need to wait a longer time to access the CPU. One low priority process controls Internet Control Message Protocol (ICMP) packets such as pings. Packets destined to or originated from the router may experience higher than expected latency since the ICMP process must wait behind BGP scanner. The cycle is that BGP scanner runs for some time and suspends itself, and then ICMP runs. In contrast, pings sent through a router should be switched via Cisco Express Forwarding (CEF) and should not experience any additional latency.
1)Are we saying the pings sourced from the router will be switched using CEF above? Just want to confirm that.
Please consider the following example:
CE----------R1-----ISP CORE---
Above CE is customer router connected to R1 for internet connectivity. R1 carries Internet routes in a service provider network
So If we issue pings sourced from R1 to CE, will this pings be CEF switched? will the ping replies from CE destined to R1,given lowest ICMP priority, even though CE is responding to R1 pings?
ThanksHello Sarah,
I hope you are well
ICMP packets originated by the router or destinated to the router are processed by main cpu not by CEF, they are actually placed in an internal queue waiting to be process switched by the main cpu and this may expose them to some delay as explained in the link about BGP scanner. (this is called punting to the main cpu the packets are punted). The same happens for protocol messsages.
The reason is that the packet needs to be examined to prepare the appropriate answer.
So going to your example, the CE node will process switch the ICMP echo request coming from R1 and will process switch the ICMP echo reply to R1, the same happens for R1, that has a full internet table, it process switches its own requests and CE's replies.
So it is R1 the more likely device to introduce delay variation.
in other words the RTT of ICMP packets may vary depending on when they are issued.
Traffic going through the router is CEF switched and far less impacted by BGP scan process.
Hope to help
Giuseppe
Maybe you are looking for
-
How do I determine the number of plots on a waveform graph?
How do I determine the number of plots that have previously been plotted on a waveform graph? I am loading dynamic data from a file. If I convert to an array and size it and there is only one plot, I get the number of data points and I don't know how
-
Hi, I've a table having customer code, customer name, dr_cr, amount fields SELECT a.CUCODE, a.cuname, a.DR_CR, decode(a.DR_CR,'D',a.AMOUNT) Debit, decode(a.DR_CR,'C',a.AMOUNT) Credit, nvl(decode(a.DR_CR,'D',a.AMOUNT),0)-nvl(decode(a.DR_CR,'C',a.AMOUN
-
struts:action vs go Questions
Hello, Can someone help me a little with the functional differences between <struts:action> and <go> in an event handler? In the �Complete ADF UIX Application�� tutorial a forward link is always created and then the <go> element is used. In looking a
-
Whats a duplicate file name?
OKay so since I tried last night to sync my ipod I am having the worst two days! Everything that can possibly go wrong is. After gettting an error on almost every song in my library, and my ipod being wiped of every file on it, its now telling me it
-
My 6th generation ipod quit working.
My 6th generation ipod quit working. The battery was low, but I plugged it into a charger immediately. I've tried a car charger, wall outlet and iTunes does not recognize it to charge or reset. What should I do?