> > For the others who suggested reducing mss values and such - I'm
> > already doing it. In fact I have mss clamped down to 1312 right now for
> > testing. But, mss clamping doesn't have anything to do with the loss of the
> > lcp-echo frames I was complaining about.
> >
> Janne also suggest
On Thu, 20 Oct 2005, Mike Ireton wrote:
For the others who suggested reducing mss values and such - I'm
already doing it. In fact I have mss clamped down to 1312 right now for
testing. But, mss clamping doesn't have anything to do with the loss of the
lcp-echo frames I was complaining about.
On 10/20/05, Mike Ireton wrote:
> Leonard Isham wrote:
>
> >
> > Merge the encrypted and unencrypted traffic for each side. Look for
> > missing unencrypted packets and then compare encrypted packets that
> > follow and look for a correlation of one or more missing or out of
> > order encrypted
On 10/20/05, Mike Ireton wrote:
> Leonard Isham wrote:
> >
> >>
> >>The problem with this test is that there are many hundreds of OpenVPN
> >>packets per second flying between machine a and machine b - coupla
> >>megabits per second in fact. There is no way to capture just the crypted
> >>ud
On 10/20/05, Mike Ireton wrote:
> James Yonan wrote:
>
> >
> > When you do your 1393 byte ping from A to B, the packet is going to travel
> > 1 -> 2 -> 3 -> 4 -> ICMP echo reply on B -> 4 -> 3 -> 2 -> 1.
> >
> > I need to know exactly where the packet is being dropped in this chain.
>
>
> The prob
