On Wed, Feb 6, 2013 at 6:32 AM, shilpa kondawar
<shilpa.konda...@gmail.com> wrote:
> Hi,
>    Thanks for your response.But we are not understanding why the count of
> snmp mib variable - ' TCPPASSIVEOPENS ' ( which keeps track of the number of
> times server state changes from listen state to syn_rcv state)

I think there's a subtle wording in the description of tcpPassiveOpens
which could explain what you're seeing.  It says "The number of times
that TCP *connections* have made a direct transition to the SYN-SENT
state from the CLOSED state".  It's possible that the implementation
doesn't count something as a *connection* until it makes it to
ESTABLISHED, which syn-attacks don't.

In any case, all net-snmp is reporting is the value reported by your
OS kernel for this attribute, so your question about how the value is
calculated is better addressed to your operating system vendor.

  Bill

> does not
> change even though we attack (syn flood - flooding with tcp syn packets )
> the server using netwox tool.
>
> OS - Ubuntu 12.04
> net-snmp - 5.4.3
>
> On Wed, Feb 6, 2013 at 2:37 PM, Jatin Bodarya <jatin.boda...@elitecore.com>
> wrote:
>>
>> give forum your code, your net-snmp version your OS details and all...
>> then only they will reply you.
>>
>>
>>
>> I have checked both  using “net-snmp-5.7.1-rc2 ” version. In linux red-hat
>> machine. (in my case its a NAS-RADIUS scenario  and also I have a LAN with
>> many machines ,without restrictions of tcp-firewalls  )  check your firewall
>> and try  to communicate using tcp connection(u can use simple C or java
>> socket prog.).  If alls okk  you can check following MIBS.
>>
>> If your snmp-version below 5.1 you need a patch I hink there was a issue
>> of these MIBS  before these versions.
>>
>>
>>
>>
>>
>> Bdw read following : May you get the idea when the value of RST is
>> increasing.
>>
>>
>>
>> A TCP connection may terminate in two ways: (1) the normal
>>
>>             TCP close sequence using a FIN handshake, and (2) an "abort"
>>
>>             in which one or more RST segments are sent and the
>>
>>             connection state is immediately discarded.  If a TCP
>>
>>             connection is closed by the remote site, the local
>>
>>             application MUST be informed whether it closed normally or
>>
>>             was aborted.
>>
>>
>>
>>             The normal TCP close sequence delivers buffered data
>>
>>             reliably in both directions.  Since the two directions of a
>>
>>             TCP connection are closed independently, it is possible for
>>
>>             a connection to be "half closed," i.e., closed in only one
>>
>>             direction, and a host is permitted to continue sending data
>>
>>             in the open direction on a half-closed connection.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------++++++++++++++++++++-----------------------
>>
>>
>>
>> When an application closes a connection in such a way that it can
>>
>>       no longer read any received data, the TCP SHOULD
>>
>>  send a RST if there is any unread received
>>
>>       data, or if any new data is received. A TCP that fails to do so
>>
>>       exhibits "Failure to RST on close with data pending".
>>
>>
>>
>>       Note that, for some TCPs, this situation can be caused by an
>>
>>       application "crashing" while a peer is sending data.
>>
>>
>>
>>
>>
>> From: shilpa kondawar [mailto:shilpa.konda...@gmail.com]
>> Sent: 05 February 2013 21:36
>> To: Jatin Bodarya
>> Subject: Re: Regarding mib values
>>
>>
>>
>> Hi,
>>    Thanks for the responding.But our query is regarding why there is  no
>> change in snmp mib variable TCPPASSIVEOPEN or TCPOURSTS though it is sending
>> syn_ack followed by reset packet as per our observation in wireshark.
>>
>> On Tue, Feb 5, 2013 at 5:30 PM, Jatin Bodarya
>> <jatin.boda...@elitecore.com> wrote:
>>
>> TCPOUTRSTS
>>
>> RFC 2525 section 2.17 right it says that if a local server (used
>> connection) is closed down it will need to send RSTs to the remote client if
>> that client is still sending data or if received data is not (no longer)
>> read.
>>
>>
>>
>> From: shilpa kondawar [mailto:shilpa.konda...@gmail.com]
>> Sent: 05 February 2013 16:55
>> To: net-snmp-users@lists.sourceforge.net
>> Subject: Regarding mib values
>>
>>
>>
>> Hello everyone,
>>
>>
>>       We are currently working on final year project.We need snmp mib
>> variables value.We have set up of two nodes , one is sending syn packets
>> using hping3 .We observed the behaviour of network packets through wireshark
>> at other node.Its showing syn-ack packets and reset packets.But  mib
>> variables corresponding to it TCPPASSIVEOPEN and TCPOUTRSTS are not getting
>> changed.
>> We are not getting why this mib variable values not changing in this
>> scenario?
>>
>> Are these correct mib variables that we have assumed for half open
>> connections or should we consider other mib variables?
>> Any help will be appreciated.
>>
>> --
>> Shilpa Kondawar,
>>
>>
>>
>>
>> --
>> Shilpa Kondawar,
>>
>> B.Tech IT,
>>
>> College of Engineering, Pune.
>
>
>
>
> --
> Shilpa Kondawar,
> B.Tech IT,
> College of Engineering, Pune.
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Net-snmp-users mailing list
> Net-snmp-users@lists.sourceforge.net
> Please see the following page to unsubscribe or change other options:
> https://lists.sourceforge.net/lists/listinfo/net-snmp-users
>

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to