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
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
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
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
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
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 TCP
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
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
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
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
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
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?
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
13 matches
Mail list logo
