On Sat, Jan 18, 2003 at 01:57:17PM +, Steve Schmitz wrote:
> If you consider gigabit/copper a fast network and can suggest
> experiments/meassurements, I'll be happy to conduct them.
TCP window scaling support has been commited to -current (pf.c 1.306).
If you have a spare box to install -cu
> >We could add a "strip-wscale" option to scrub. It doesn't solve
> >the state pickup issue, but could prevent clients communicating
> >through the firewall from negotiating this option.
> Does the Linux NAT code already do this?
Linux's stock state code doesn't track sequence numbers.
.mike
Maybe someone with experience in fast networks can comment on how
average packet loss and latency affect the maximum TCP window you might
want to use. With an MTU of 1500 or lower, over the Internet, do your
windows actually go beyond 65535 bytes, even if you enable scaling?
We have a (partly) gi
Another problem with very large window sizes is that it becomes more
easy for an attacker to guess valid sequence numbers.
With window scaling, the maximum shift is 14 (as per RFC 1323), so the
window might become as large as 65535*2^14=1GB. Sequence numbers are
32-bit unsigned integers, so if bot
On Sat, Jan 18, 2003 at 08:42:04AM +, Steve Schmitz wrote:
> Does the Linux NAT code already do this?
Possibly, but I'll have to check the source code to verify. It could
either strip the option or set any scale factors inside the option to
zero. But doing that is not much simpler than actual
We could add a "strip-wscale" option to scrub. It doesn't solve
the state pickup issue, but could prevent clients communicating
through the firewall from negotiating this option.
Does the Linux NAT code already do this?
We tried and temporarily split up our combined firewall/NAT machine into
tw
> Return-Path: [EMAIL PROTECTED]
> Delivery-Date: Fri Jan 17 14:46:14 2003
> If the client supports the extention, it will add a TCP option to its
> initial SYN packet, indicating its support (and supplying its own scale
> factor). If the peer also supports the extention, it will add its own
> TCP
Daniel Hartmeier wrote/schrieb/scripsit:
> I guess we could add support for the case where pf does see the
> handshake, but this is the first time I see this problem reported, maybe
> RFC 1323 adoption isn't that broad.
Let's not do the ECN mistake again.
-Stefan
Hi Daniel, hi Mike, and the others.
Thank you very very much for your help!
Now I know what caused the problem (TCP Window Scaling) and how
to fix it ("echo 0 > /proc/sys/net/ipv4/tcp_window_scaling" on
the clients), all without requiring access to the Oracle server
machine, and without measure
On Fri, Jan 17, 2003 at 02:01:39PM +, Steve Schmitz wrote:
> Any idea why they do this?
The TCP header has only space to hold a 16-bit unsigned number to hold
the window value, so windows are traditionally limited to 65535 bytes,
which can limit performance on fast networks.
RFC 1323 (http:/
You mentioned the behavior depends on the OS (and application) of the
server. When Oracle runs on Solaris, it works. And when you connect to the
Linux Oracle to another service (ssh, etc.), it works, too?
I am not allowed to log into Linux/Oracle server. I tried with netcat on a
sister machine
> You mentioned the behavior depends on the OS (and application) of the
> server. When Oracle runs on Solaris, it works. And when you connect to
> the Linux Oracle to another service (ssh, etc.), it works, too? If
> that's the case, I wonder whether the Oracle on Linux is configured to
> use any TC
On Fri, Jan 17, 2003 at 07:51:29AM +, Steve Schmitz wrote:
> The firewall is running not quite the newest version of OpenBSD/PF (a 3.2
> beta). Is it advisable to upgrade, given the interruption in service?
I doubt it will make a difference, as that part of the code (the
sequence number trac
Could be fragments. Can you try with
scrub in on $ext_if all no-df
scrub out on $ext_if all no-df
If you run pfctl -si, do you see any of the 'Counters' at the bottom
increase when you get a stalled connection?
Also, can you enable debug loggin (pfctl -x m) and check
/var/log/messages for re
On Thu, Jan 16, 2003 at 02:54:29PM +, Steve Schmitz wrote:
> Any ideas?
Could be fragments. Can you try with
scrub in on $ext_if all no-df
scrub out on $ext_if all no-df
If you run pfctl -si, do you see any of the 'Counters' at the bottom
increase when you get a stalled connection?
Als
Hi,
I have a problem with access to an Oracle database over
an OpenBSD PF NAT setup.
We (a particle physics institute) have a Linux cluster for
our computations; the nodes have private IP addresses and
contact the outside world via an OpenBSD/PF NAT machine.
The NAT machine works perfectly fine
16 matches
Mail list logo
