Packet_vlad's profile - activity

I need to take a closer look on it but actually it looks like micro-bursting with 1Gbit interface speed hitting a buffer

I need to take a closer look on it but actually it looks like micro-bursting with 1Gbit interface speed hitting a buffer

I need to take a closer look on it but actually it looks like micro-bursting with 1Gbit interface speed hitting hard a b

I need to take a closer look on it but actually it looks like micro-bursting with 1Gbit interface speed hardly hitting a

I need to take a closer look on it but actually it looks like micro-bursting with 1Gbit interface speed hitting a buffer

I need to take a closer look on it but actually it looks like micro-bursting with 1Gbit interface speed hitting a buffer

I need to take a closer look on it but actually it looks like micro-bursting with 1Gbit interface speed hitting a buffer

I need to take a closer look on it but actually it looks like micro-bursting on 1Gbit interface rate hitting a buffer or

I need to dive deeper but actually it looks like micro-bursting on 1Gbit interface rate hitting a buffer or policer.

Hi @ille , the latest question Q1: I think the server didn't increase it's window because it didn't observe incoming tra

Hi @ille , the latest question Q1: I think the server didn't increase it's window because it didn't observe incoming tra

Could you please enable SACK on both endpoints and do the capture again? An absence of SACK option makes loss recovery v

Could you please enable SACK on both endpoints and do the capture again? An absence of SACK option makes loss recovery v

Could you please enable SACK on both endpoints and do the capture again? An absence of SACK option makes loss recovery v

Could you please enable SACK ob both endpoints and do the capture again? An absence of SACK option makes loss recovery v

Chris Greer recently recorded nice introductory video on the subject.

By clicking on the packet you define a source for the filter argument. Otherwise if you have for example 100 different p

By clicking on the packet you define a source for the filter argument. Otherwise if you have for example 100 different p

By clicking on the packet you define a source for the filter argument. Otherwise if you have for example 100 different p

Have you tried the next format? ip.addr==${gtp.user_ipv4}

Keep in mind you have to select a packet containing gtp.user_ipv4 field first and then type the filter expression.

Have you tried the next format? ip.addr==${gtp.user_ipv4}

From the captures you have provided I don't see any serious problem. FIN, ACK and RST This is quite usual way to s

From the captures you have provided I don't see any serious problem. FIN, ACK and RST This is quite usual way to s

@Christian_R: good observations! Interesting thing is - the second retransmission was not necessary because: a) it was

@Christian_R: good observations! Interesting thing is - the second retransmission was not necessary because: a) it was

Below are some observations / thoughts about the case Receiver Window size was not "negotiated down from 8192 to 513"

Below are some observations / thoughts about the case Receiver Window size was not "negotiated down from 8192 to 513"

Below are some observations / thoughts about the case Receiver Window size was not "negotiated down from 8192 to 513"

Below are some observations / thoughts about the case Receiver Window size was not "negotiated down from 8192 to 513"

Try to use packet slicing option: Choose a size (snaplen) in Bytes to capture only headers data therefore a payload w

Try to use packet slicing option: Choose a size (snaplen) in Bytes to capture only headers data therefore a payload w

Try to use packet slicing option: Choose a size (snaplen) in Bytes to fit only headers data therefore a payload will

Could you show the picture to look at? And which part is confusing you.

Hello, Doing such kind of analysis (TCP performance issues) demands looking at PCAPs, highly preferably sender-side on

Hello, Doing such kind of analysis (TCP performance issues) demands looking at PCAPs, highly preferably sender-side one

Hello, Doing such kind of analysis (TCP performance issues) demands looking at PCAPs, highly preferably sender-side ones

Hello, Doing such kind of analysis (TCP performance issues) demands looking at PCAPs, highly preferably sender-side ones

Just checked some of my traces. So I found the next. Among the packets with wrong checksum: All TCP checksums I've s

@vsharker The statistics I wrote about in my answer was regarding packets that ALL have "Incorrect checkum" warning. Ju

@vsharker The statistics I wrote about in my answer was regarding packets that ALL have "Incorrect checkum" warning. Ju

@vsharker The statistics I wrote about in my answer was regarding packets that ALL have "Incorrect checkum" warning. Ju

@vsharker The statistics I wrote about in my answer was regarding packets that ALL have "Incorrect checkum" warning. Ju

@vsharker The statistics I wrote about in my answer was regarding packets that ALL have "Incorrect checkum" warning. Ju