* Sonic sonicsm...@gmail.com [2014-09-05 17:12]:
On Fri, Sep 5, 2014 at 4:42 AM, Kapetanakis Giannis
bil...@edu.physics.uoc.gr wrote:
yeah, don't use reassemble tcp. it's not perfect.
Isn't that default behavior?
hell, no.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web
* Kapetanakis Giannis bil...@edu.physics.uoc.gr [2014-09-06 00:50]:
I'm asking about reassemble tcp.
According to some 2010's threads in misc@ it used to cause problems to some
users.
I'm wondering what's the status now.
unchanged.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS
On 13/09/14 11:55, Henning Brauer wrote:
* Kapetanakis Giannis bil...@edu.physics.uoc.gr [2014-09-06 00:50]:
I'm asking about reassemble tcp.
According to some 2010's threads in misc@ it used to cause problems to some
users.
I'm wondering what's the status now.
unchanged.
Thanks
I've found the following in the archives. Is the situation still the
same with
reassemble tcp?
My only scrub rule (in firewall/router) is
match in all scrub (no-df random-id reassemble tcp max-mss 1440)
Should I be worried?
Thanks
G
List: openbsd-misc
Subject:Re: pf: reassemble
On Fri, Sep 5, 2014 at 4:42 AM, Kapetanakis Giannis
bil...@edu.physics.uoc.gr wrote:
yeah, don't use reassemble tcp. it's not perfect.
Isn't that default behavior?
Is it recommended to disable this feature?
On 05/09/14 18:10, Sonic wrote:
On Fri, Sep 5, 2014 at 4:42 AM, Kapetanakis Giannis
bil...@edu.physics.uoc.gr wrote:
yeah, don't use reassemble tcp. it's not perfect.
Isn't that default behavior?
Is it recommended to disable this feature?
I'm not asking about set reassemble for fragmented
There has been 2 recent threads mentioning problems with reassemble tcp:
pf: reassemble tcp
problems with emails through pf
For info here is another. We solved the problem by removing this scrub.
We went from 4.3 with
scrub in all
to the latest 4.6 stable with
match in all scrub
There has been 2 recent threads mentioning problems with reassemble tcp:
pf: reassemble tcp
problems with emails through pf
For info here is another. We solved the problem by removing this scrub.
We went from 4.3 with
scrub in all
to the latest 4.6 stable with
match in all scrub (reassemble
On 2010-01-15, Alastair Johnson att...@googlemail.com wrote:
We went from 4.3 with
scrub in all
to the latest 4.6 stable with
match in all scrub (reassemble tcp)
'scrub in all' on 4.3 is the same as 'scrub in all fragment reassemble'
which is now done by default.
If you had done
no - only ftp to ftp.ibes.com and ftp to www.chi-x.com which are not public.
it seems to have failed after login just before or just as data started to
flow.
the strange thing is that data download works about half the time with
reassemble tcp switched on and all the time with it off.
appologies
snip
It may be an irrelevant coincidence but each
FTP site that this happened with was Microsoft FTP. It never happened (ie
FTP always worked fine) with other server types.
snip
I don't know if this matters, but I had some problems recently with
people downloading from external FTP servers
Hi there. I've a problem with pf on OpenBSD 4.6
After different test, I've been reduced my pf.conf to those rules:
macros
set block-policy drop
match all scrub (no-df, random-id, reassemble tcp, max-mss 1440)
nat on $ext from $int:network - $ext:0
block log all
pass in on $int from any
On Fri, Jan 15, 2010 at 3:33 PM, Alessandro Baggi
alessandro.ba...@gmail.com wrote:
If I remove reassemble tcp It works fine.
I've tried also with a pass all rules...but with the same result. It's
possible that a scrub with reassemble tcp option, blocks some packet?
What is the reason
Ted Unangst wrote:
On Fri, Jan 15, 2010 at 3:33 PM, Alessandro Baggi
alessandro.ba...@gmail.com wrote:
If I remove reassemble tcp It works fine.
I've tried also with a pass all rules...but with the same result. It's
possible that a scrub with reassemble tcp option, blocks some packet?
What
There has been 2 recent threads mentioning problems with reassemble tcp:
pf: reassemble tcp
problems with emails through pf
For info here is another. We solved the problem by removing this scrub.
We went from 4.3 with
scrub in all
to the latest 4.6 stable with
match in all scrub (reassemble tcp
There has been 2 recent threads mentioning problems with reassemble tcp:
pf: reassemble tcp
problems with emails through pf
For info here is another. We solved the problem by removing this scrub.
We went from 4.3 with
scrub in all
to the latest 4.6 stable with
match in all scrub (reassemble tcp
Hi.
I have
match in all scrub (tcp reassemble no-df random-id max-mss 1440)
in my pf.conf (-current)
Unless I remove 'tcp reassemble', one of the web sites (it's a
Windows/IIS) site cannot communicate with me - it hangs loading a
page.
Any ideas?
a
page.
Any ideas?
yeah, don't use reassemble tcp. it's not perfect.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
On Thu, Jan 14, 2010 at 12:46 PM, Henning Brauer lists-open...@bsws.dewrote:
I have
match in all scrub (tcp reassemble no-df random-id max-mss 1440)
in my pf.conf (-current)
yeah, don't use reassemble tcp. it's not perfect.
How about fragment reassemble?
I'm using it on my
* Ted t...@pobox.com [2010-01-14 05:03]:
On Thu, Jan 14, 2010 at 12:46 PM, Henning Brauer lists-open...@bsws.dewrote:
I have
match in all scrub (tcp reassemble no-df random-id max-mss 1440)
in my pf.conf (-current)
yeah, don't use reassemble tcp. it's not perfect
Get tcpdumps on both router interfaces with and without the reassemble
tcp option. Do this for a similar file on both a working website and
broken (ebay) website.
On both router interfaces? Wouldn't the external if be enough?
You're probably right. But my theory is that if you're going
of your posts.
It's a filtering bridge then.
Would be interesting if bridging has something to do with
our reassemble tcp problem...
Perhaps because the if is in promiscuous mode?
However, as I've mentioned earlier, everything works _on_ the gateway
_without_ NAT. But regardless of NAT, all packets
On Thu, 20 Jul 2006, Steve Welham wrote:
Get tcpdumps on both router interfaces with and without the reassemble
tcp option. Do this for a similar file on both a working website and
broken (ebay) website.
I have now. Got a dump of the following request (all on a single line):
wget -nd -O /dev
On Thu, 20 Jul 2006, Daniel E. Hassler wrote:
I was hoping he could try 'set debug loud' in his pf.conf and check his
/var/log/messages file after testing a problem site.
If he sees messages similar to the one's I've seen maybe we both know a little
more.
Unfortunately not. When I set debug
Sorry, 'modulate tcp' was a thinko. I had been meaning to move
'modulate state' into the scrubber for a long time.
Reassemble TCP does aggressive TCP PAWs checks on the TCP timestamps.
It does the usual PAWs check to make sure a timestamp is not older than
the last echoed value - which
On Fri, 21 Jul 2006, Mike Frantzen wrote:
Reassemble TCP does aggressive TCP PAWs checks on the TCP timestamps.
It does the usual PAWs check to make sure a timestamp is not older than
the last echoed value - which is in theory a wrapped sequence number.
It also does its aggressive check
On Friday 21 July 2006 18:38, Walter Haidinger wrote:
On Fri, 21 Jul 2006, Mike Frantzen wrote:
Reassemble TCP does aggressive TCP PAWs checks on the TCP timestamps.
It does the usual PAWs check to make sure a timestamp is not older than
the last echoed value - which is in theory a wrapped
as DMZ. IP's on the $lanif side
are considered LAN.
WAN---PIX/NAT---DMZ---TPF---LAN---OS X
Whenever I put a scrub rule with reassemble tcp on $wanif and/or $lanif
I have trouble with some sites. (e.g. Apple's Software Update).
setting debug to loud I get the messages I mention below.
-Dan
Daniel
and scrub with reassemble tcp trying to run OS X's Software Update.
Jul 19 19:42:37 obsd38 /bsd: pf_normalize_tcp_stateful: Did not receive
expected RFC1323 timestamp
Jul 19 19:42:37 obsd38 /bsd: TCP 192.168.1.14:65108 192.168.1.14:65108
17.250.248.95:80 [lo=4276925920 high=4276942304 win
It's a stab in the dark but I would start with the assumption that some
sites are using server load balancing and that reassemble tcp is
breaking this somehow.
Could be. Lets suspect poor load balancing because other big sites,
which most likely do load balancing too, work. eBay is just
What is 'modulate tcp'?
modulate state works fine.
I get these errors only with scrub's reassemble tcp option
I originally assumed it was an Apple problem since I only had trouble
with the OS X Software Update feature.
Going back to the beginning of this thread - Walter Haidinger appears
Hi!
I'm running OpenBSD 3.9 GENERIC as a NAT router.
If I add the reassemble tcp option to my scrub rule in pf.conf,
I have trouble connecting to some sites, particulary ebay (ebay.de,
ebay.at and ebay.com as well as e.g. kaufen.ebay.de) and
some other few sites, from a machine behind the NAT
Walter Haidinger([EMAIL PROTECTED]) on 2006.07.19 12:28:52 +:
Hi!
I'm running OpenBSD 3.9 GENERIC as a NAT router.
If I add the reassemble tcp option to my scrub rule in pf.conf,
I have trouble connecting to some sites, particulary ebay (ebay.de,
ebay.at and ebay.com as well as e.g
reassemble tcp breaks things, but why?
- set the correct MTU
- check pf.conf for scrub max-mss [...]
No changes necessary, IMHO.
- google
Have done this, of course. Turned up e.g.:
http://www.benzedrine.cx/pf/msg07352.html
http://monkey.org/openbsd/archive/bugs/0312/msg00059.html
Similar
and that reassemble tcp is
breaking this somehow. Then I'd try and prove that assumption by looking
at the tcpdumps specifically for how reassemble tcp changes may be
interfering.
Get tcpdumps on both router interfaces with and without the reassemble
tcp option. Do this for a similar file on both a working
to access problem sites.
# NORMALIZATION: reduce/resolve ambiguities.
#
scrub on $admif all random-id reassemble tcp
#scrub on $lanif all random-id reassemble tcp
#scrub on $wanif all random-id reassemble tcp
#
# Problem
More info - I ran a test scenario.
Here is a sample of the messages I get via syslog with set debug loud
and scrub with reassemble tcp trying to run OS X's Software Update.
Jul 19 19:42:37 obsd38 /bsd: pf_normalize_tcp_stateful: Did not receive
expected RFC1323 timestamp
Jul 19 19:42:37
37 matches
Mail list logo
