How to monitor send/receive bytes


 
Thread Tools Search this Thread
Top Forums Shell Programming and Scripting How to monitor send/receive bytes
# 15  
Old 12-07-2010
ok you are right "ifconfig -a" says lo0 and e1000g0 plus some other stuff..
Now when I try to run "kstat - n e1000g0 | grep s64" it gives me "obytes64" which I assume are sent bytes and "rbytes64" which I assume are received bytes..and yes there are also ipakets and opakets.
Login or Register to Ask a Question

Previous Thread | Next Thread

9 More Discussions You Might Find Interesting

1. IP Networking

Can not send files bigger than 1350 bytes

I am sending files over WAN from Ubuntu 8 to OSR 5.07 on regular basis without a problem using ftp and rsync. Today I can not send anything bigger than ~1350 bytes, tried ftp, rsync, scp, it becomes frozen and I have to kill the process. Smaller files are sent without issue. Telnet and ssh... (1 Reply)
Discussion started by: migurus
1 Replies

2. Shell Programming and Scripting

Send/receive file through serial using minicom

i have connected with my board through serial interface using minicom and i am running a bash script, which should test ethernet (ping test), USB read/write, RS232 .. I have managed to test ethernet and USB read/write. I test ethernet with ping. I test USB read/write, using dd and verifying... (10 Replies)
Discussion started by: linuxmember
10 Replies

3. Solaris

zfs send receive performance issues

I 'm trying to clone a zfs file system pool/u01 to a new file system called newpool/u01 using following commands zfs list zfs snapshot pool/u01@new zfs send pool/u01@new | zfs -F receive newpool/u01 Its a 100G file system snapshot and copied to same server on different pool and... (9 Replies)
Discussion started by: fugitive
9 Replies

4. Shell Programming and Scripting

Script to monitor for new file with ext .err and size > 0 bytes and perform a action or command

Hi All, I need to create a script to monitor a dir for new files with ext .err and also it should b a non empty files. and perform a action or command . We have a new ETL application that runs on a linux server, every times a etl fails it creates a .err file or updates the existing .err... (4 Replies)
Discussion started by: MAKHAN
4 Replies

5. Shell Programming and Scripting

Send Receive Mails

Hi All, I am writing one script to automate one long process. In this process we need to upload some input files and download some output files. So , I want to automate this upload and download by using mail functionality. I want to trigger this script when I am sending mail to server. I know... (0 Replies)
Discussion started by: NirajThakar
0 Replies

6. Programming

Send/Receive buffer size??

Dear friends, How do I find the TCP send and receive buffer size? (1 Reply)
Discussion started by: nagalenoj
1 Replies

7. UNIX for Dummies Questions & Answers

Can send but not receive email

Hi, One of the users in our company can send but not receive email. We are using SENDMAIL in conjunction with procmail. The funny thing is that all his sent email is in his /var/spool/mail but the email client does not pick anything up! He is using IMAP. Anyone see have any ideas? (2 Replies)
Discussion started by: mojoman
2 Replies

8. UNIX for Dummies Questions & Answers

I can send but cannot receive mail with unix?

Hi all, First post! I have just discovered that I can use unix to send mail to a mail address. I normally use entourage for my mail. This unix mail is very intriguing to me, but something is not working... I tried the search, but could not find the answer... This works: (in terminal)... (1 Reply)
Discussion started by: bjorn
1 Replies

9. IP Networking

Tcp Ip Send Receive Server Program

Requirements: A server program should read a file and send the message to the client . if the file is not there, then switch to the receive part of the same program and receive any messages from the socket. If no messages to receive then switch to send part of the program to... (2 Replies)
Discussion started by: Rajeshsu
2 Replies
Login or Register to Ask a Question
nifftmt(7)						 Miscellaneous Information Manual						nifftmt(7)

NAME
nifftmt - Traffic monitoring for the Network Interface Failure Finder (NIFF) SYNOPSIS
#include <net/if.h> #include <sys/ioctl.h> DESCRIPTION
The NIFF traffic monitor thread checks the connectivity of network interfaces and issues events when it detects a change in an interface's connectivity. It does this by monitoring the interface's data counters and using the event management (EVM) framework to inform interested subscribers of connectivity-related events. Typically, the traffic monitor looks at a network interface's counters once every several seconds and issues an event based on what it determines from their value. There are two basic types of events. The first type occurs when an interface is added to the list of events already being monitored. In this case, the traffic monitor sends an event to indicate the interface is up and running. The other type of event occurs when the traffic monitor does not see any traffic coming into the interface for a period of time. The traffic monitor thread uses timing parameters to determine when to issue an event. TIMING PARAMETERS The timing parameters for the traffic monitor are passed to the NIFF traffic monitor thread using the ioctl(2) system call and the moni- tored_interface structure defined in the <net/if.h> file. See ioctl(2) for further information. The following lists the NIFF traffic monitor thread timing parameters: The name of an interface that is to be monitored. For example, tu0 and fta0. Specifies the time period, in seconds, that the traffic monitor thread delays between reads of the interface counters when the network is running normally. The traffic monitor thread issues a yellow alert when there is no change in the received byte count for a period of t1 seconds. By default, niffconfig sets this time period to 20 seconds. This corresponds to the niffconfig -t option. Speci- fies the time period, in seconds, that the traffic monitor thread delays between reads of the interface counters when it suspects there is a connectivity problem. This number must be smaller than the number given for the t1 option. The traffic monitor thread issues an orange alert when there is no change in the received byte count for t1 plus dt seconds. If another dt seconds goes by with no change in the received byte count, the traffic monitor thread issues a red alert. By default, niffconfig sets this time period to 5 seconds. This cor- responds to the niffconfig -d option. The total number of traffic-free seconds that must pass before the traffic monitor thread declares the interface to be dead. After t2 seconds with no change in the interface's received byte count, the traffic monitor thread issues a dead event. This number must be equal to at least the sum of t1 and two times t2. By default, niffconfig sets this time period to 60 seconds. This corresponds to the niffconfig -o option. The interface continues to be monitored every dt seconds in case it comes back on-line. The traffic monitor thread enforces the following restriction between the timing parameters: t2 > t1 + 2dt, and dt < t1 It is up to the subscribers to take action based on the events that the traffic monitor reports. For example, the niffd daemon attempts to generate traffic that the suspect interface's receiver will pick up. Other subscribers may want to take action such as to migrate applica- tions to another node or to activate another network interface to replace the suspect interface. The traffic monitor responds to the following ioctl(2) commands: #include <net/if.h> mif_t arg; ioctl(fd, command, arg); As shown in the previous example, mif_t is a monitored interface structure. Most commands require the name field of the mif_t structure to be filled in. The applicable commands are: Adds the named interface to the list of interfaces being monitored. The timing parameters must be filled in as noted in the TIMING PARAMETERS section. If this is the first interface to be added, the SIOCTMTADD command also starts the thread. Removes the named interface from the list of monitored interfaces. If the last interface in the list of those being monitored is removed, the thread is stopped. Modifies the timing parameters for the named interface. The rela- tionship between the timing parameters must be as noted in the TIMING PARAMETERS section. Returns the number of bytes required to store a complete status dump of the interfaces currently being monitored. See SIOCTMTDUMP. This command does not require a third argument to ioctl. Fills in the mif_t structure for the named interface, thereby sending its status back to the caller. Fills in the user-supplied buffer with the status of each interface being monitored. Used for debugging. Causes the kernel to print the status of each interface that is currently being monitored. EVENTS The traffic monitor posts the following events: This event is posted when the traffic monitor thread declares an interface to be dead. This event is posted when the traffic monitor thread has not seen traffic on an interface for t1 seconds. This event is also posted every dt seconds until either traffic is detected or the traffic monitor determines that the interface is dead. RETURN CODES An SIOCTMTADD was attempted on an interface that is already being monitored. The kernel could not allocate memory to copy in the user's buffer. The relationship between the timing parameters is not correct, or an invalid command was given to the traffic monitor. An SIOCTM- TADD, SIOCTMTSTATUS, or SIOCTMTMODIFY command was attempted on an interface that is not currently being monitored. EXAMPLES
The following example illustrates the use of a few NIFF ioctl functions: #include <stdio.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/ioctl.h> #include <sys/param.h> #include <net/if.h> #include <errno.h> /* these strings map to the "state" enum */ char *state[] = {"INIT", "GREEN", "YELLOW", "ORANGE", "RED", "DEAD"}; /* usage: niff_example tu0 tu1 tu2... * must supply the name of at least one * network interface */ main(int ac, char **av) { int t1 = 20, t2 = 60, dt = 5; char **oldav; mif_t mif; int s; oldav = ++av; s = socket(AF_INET, SOCK_DGRAM, 0); /* tell the traffic monitor to start watching these interfaces */ while (*av) { printf("Adding interface %s to the traffic monitor0, *av); bzero(&mif, sizeof (mif)); bcopy(*av, &mif.name[0], MIN(strlen(*av) + 1, sizeof (mif.name - 1))); mif.current_interval = mif.next_time = mif.t1 = t1; mif.t2 = t2; mif.dt = dt; mif.time_to_dead = mif.t2 - mif.t1 + 2 * mif.dt; mif.flags = 0; if (ioctl(s, SIOCTMTADD, &mif) < 0) { perror("couldn't add interface"); break; } ++av; } av = oldav; /* get the status of the interfaces - NB will probably always * be in the "init" state */ while (*av) { printf("checking the status of interface %s0, *av); bzero(&mif, sizeof (mif)); bcopy(*av, &mif.name[0], MIN(strlen(*av) + 1, sizeof (mif.name - 1))); if (ioctl(s, SIOCTMTSTATUS, &mif) < 0) { perror("couldn't get status for interface"); break; } else printf("Interface: %05s, state: %s, t1: %d, dt: %d, t2: %d, time to dead: %d, current_interval:%d, next time: %d0, mif.name, state[mif.current_state], mif.t1, mif.dt, mif.t2, mif.time_to_dead, mif.current_interval, mif.next_time); ++av; } av = oldav; /* tell the traffic monitor to stop watching */ while (*av) { printf("deleting interface %s from the traffic monitor0, *av); bzero(&mif, sizeof (mif)); bcopy(*av, &mif.name[0], MIN(strlen(*av) + 1, sizeof (mif.name - 1))); if (ioctl(s, SIOCTMTREMOVE, &mif) < 0) { perror("couldn't remove interface"); } ++av; } exit(0); } RELATED INFORMATION
ioctl(2), EVM(5), niffconfig(8), niffd(8) delim off nifftmt(7)