I have been investigating various issues that have been nagging our network
for a little while. I recently upgraded the firewall at my office to OpenBSD
3.3 and roughly since then - and some new scrub rules - I have seen a
problem that I cannot see an explanation for.
I use scrub rules like:
scru
On Wed, Jun 11, 2003 at 10:30:45AM +0100, Peter Galbavy wrote:
> 09:12:46.624222 213.155.153.61.39918 > 128.32.18.176.33113: . [tcp sum ok]
> ack 393217 win 62419 (ttl
> 127, id 43371)
Hmm, SACK (RFC 2018, 1072).
I think normalization will ignore the related TCP options and leave them
intact. S
Daniel Hartmeier wrote:
> Can you enable debug logging (pfctl -x m, output in
> /var/log/messages) and tcpdump an entire TCP connection (one that
> stalls). If you get state mismatches, that is likely related to SACK.
Yep. First two lines, of many, are:
Jun 11 10:19:39 cblan-fw /bsd: pf: BAD stat
Daniel Hartmeier wrote:
> If you need a quick
> workaround, you could disable SACK on that client.
(For the archives maybe)
>From http://support.microsoft.com/default.aspx?kbid=224829
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SackOp
ts -> 0
Now it all works. Perfectl
On Wed, Jun 11, 2003 at 11:32:24AM +0100, Peter Galbavy wrote:
> Daniel Hartmeier wrote:
> > If you need a quick
> > workaround, you could disable SACK on that client.
>
> (For the archives maybe)
>
> >From http://support.microsoft.com/default.aspx?kbid=224829
>
> HKEY_LOCAL_MACHINE\SYSTEM\Curre
> > 09:12:46.624222 213.155.153.61.39918 > 128.32.18.176.33113: . [tcp sum ok]
> > ack 393217 win 62419 (ttl
> > 127, id 43371)
> Hmm, SACK (RFC 2018, 1072).
> I think normalization will ignore the related TCP options and leave them
> intact. So does the sequence number tracking code, which might
Mike Frantzen wrote:
> Last time I analyzed it, it looked like SACK would work fine because
> we
> always allow one window backwards in the ack skew check. Lemme think
> about it more after I've been awake for more than five minutes.
>
> If I had to guess, the box is using window scaling. Which w
> Yep, from external interface (me to remote):
> 10:19:22.885036 213.155.153.61.37850 > 128.32.18.176.33186: S [tcp sum ok]
> 1400725148:1400725148(0) win 16960 sackOK> (ttl 127, id 2006)
> This windows XP box (mine, on my desk) was not previously tweaked in anyway.
> All Windows Updates installed
Mike Frantzen wrote:
> Egads. A scale of 4. That is a stack tuned for the TCP benchmarks
> if I
> ever saw one.
Windows XP Professional + updates. Who knows.
> Please apply this diff from -current first. If it doesn't work, then
> ya, the pcap would be useful.
By strange coincidence I am away
Peter Galbavy wrote:
> Now it all works. Perfectly.
May have spoken too soon. Apologies. Now that [EMAIL PROTECTED] tried for the next
package, it hung again. FTPs to alien.ssl.berkeley.edu are now failing
again. All this worked earlier in the day. Sigh.
I will revisit my configuration and tcpdum
10 matches
Mail list logo
