On Thu, 1 May 2008, Stefan Lambrev wrote:
Hi,
I'm little lost in this thread.
Is there a solution for the problem and is it part of RELENG_7?
yes, just update to RELENG_7 and you should be fine.
If yes can someone tell me which version of which files fix this?
ufff.
RELENG_7 as of those
Greetings,
I'm little lost in this thread.
Is there a solution for the problem and is it part of RELENG_7?
If yes can someone tell me which version of which files fix this?
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
___
freebsd-net@freebsd.org maili
On Fri, 11 Apr 2008, Anders Nordby wrote:
Hi,
in case you did not receive a private mail from me please do not go to
any of the mentioned urls or you will make a one week data collection
worthless.
Thank you.
PS: the webservers will go away within a few hours anyway...
Simply open the follo
Hi,
On Wed, Apr 09, 2008 at 08:23:13AM +, Bjoern A. Zeeb wrote:
>> I had the same problem, and temporarily worked around it by disabling
>> SACK:
> ok, here we go...
>
> as I had explained on freebsd-net@ lately there had been 2 changes to
> possibly fix this issue.
>
> I am currently in the
On Wed, 9 Apr 2008, Anders Nordby wrote:
Hi,
I had the same problem, and temporarily worked around it by disabling
SACK:
sysctl net.inet.tcp.sack.enable=0
Which solved my problems. It would be interesting to see if this helps
you also?
This will hide any of the real problems in most cases,
Hi,
I had the same problem, and temporarily worked around it by disabling
SACK:
sysctl net.inet.tcp.sack.enable=0
Which solved my problems. It would be interesting to see if this helps
you also?
If so, it seems this issue is related to SACK and TCP order maybe? Hmm.
On Fri, Apr 04, 2008 at 01:
On Fri, 4 Apr 2008, Steven Hartland wrote:
Hi,
I believe this has already been covered in quite some depth
and iirc its regards the ordering of the new tcp flags
introduced in 7. Best to have a look in the list archives for
the specifics.
so as more users come and see this I am still trying t
I believe this has already been covered in quite some depth
and iirc its regards the ordering of the new tcp flags
introduced in 7. Best to have a look in the list archives for
the specifics.
Regards
Steve
- Original Message -
From: "s3raphi" <[EMAIL PROTECTED]>
I upgraded many
I upgraded many web servers to FreeBSD 7.0-Release several weeks ago. These
servers serve hundreds of thousands of users. Since then, we have had many
users complain that they cannot connect to these servers any more. This was
a very tricky problem to diagnose, but using packet captures on both th
On Thu, Mar 20, 2008 at 7:09 PM, d.s. al coda <[EMAIL PROTECTED]> wrote:
> On 3/12/08, Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
> >
>
> > I'd be very interesting to know the exactly models and their firmware
> > version
> > of the affected routers. If available locally I'd like to obtain a
On 3/12/08, Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
> I'd be very interesting to know the exactly models and their firmware
> version
> of the affected routers. If available locally I'd like to obtain a
> similar
> model myself for future regression tests.
Here are the models we managed to
On Mon, 17 Mar 2008, Mike Silbersack wrote:
On Fri, 14 Mar 2008, Bjoern A. Zeeb wrote:
But I think the "good" case should look like it did before, per POLA.
Ok, I am only printing it in case bad padding happens or one gave -v.
The new patch is here:
http://sources.zabbadoz.net/freebsd/pat
On Fri, 14 Mar 2008, Bjoern A. Zeeb wrote:
But I think the "good" case should look like it did before, per POLA.
Ok, I am only printing it in case bad padding happens or one gave -v.
The new patch is here:
http://sources.zabbadoz.net/freebsd/patchset/20080314-01-tcpdump-print-tcp-option-pad
On 3/12/08, Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
> We've already fixed two issues. The first changes the order of the TCP
> options
> and is in this change:
>
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.160;r2=1.161
>
> It is to solve a problem observed b
On Fri, 14 Mar 2008, Mike Silbersack wrote:
On Thu, 13 Mar 2008, Bjoern A. Zeeb wrote:
It should give you output like this:
19549200,sackOK,eol,0x01[bad padding]>
I like the [bad padding].
:-)
19641135,sackOK,eol,0x00>
But I think the "good" case should look like it did before, per PO
On Thu, 13 Mar 2008, Bjoern A. Zeeb wrote:
It should give you output like this:
19549200,sackOK,eol,0x01[bad padding]>
I like the [bad padding].
But I think the "good" case should look like it did before, per POLA.
-Mike
___
freebsd-net@freeb
On Wed, 12 Mar 2008, Mike Silbersack wrote:
On Wed, 12 Mar 2008, Mike Silbersack wrote:
I think we will need to fix tcpdump before trying to finish diagnosing this
problem. We were missing key information before.
-Mike
Hm, that was far easier than expected. Patch attached.
Here's what
On Wed, 12 Mar 2008, Mike Silbersack wrote:
On Wed, 12 Mar 2008, Bjoern A. Zeeb wrote:
On Tue, 11 Mar 2008, d.s. al coda wrote:
- FreeBSD 7 has (there is of course an aligning
nop
after the eol, which tcpdump skips)
Which is a bug (the nop after the EOL) that I recently fixed in HEAD.
I
On Wed, 12 Mar 2008, Mike Silbersack wrote:
On Wed, 12 Mar 2008, Mike Silbersack wrote:
I think we will need to fix tcpdump before trying to finish diagnosing this
problem. We were missing key information before.
-Mike
Hm, that was far easier than expected. Patch attached.
Here's what
On Wed, 12 Mar 2008, Bjoern A. Zeeb wrote:
On Tue, 11 Mar 2008, d.s. al coda wrote:
- FreeBSD 7 has (there is of course an aligning nop
after the eol, which tcpdump skips)
Which is a bug (the nop after the EOL) that I recently fixed in HEAD.
I am still curious to know if it's only ordering
On Wed, 12 Mar 2008, Mike Silbersack wrote:
I think we will need to fix tcpdump before trying to finish diagnosing this
problem. We were missing key information before.
-Mike
Hm, that was far easier than expected. Patch attached.
Here's what the two tcpdumps show now:
6.3:
IP A > B : S
On Tue, 11 Mar 2008, d.s. al coda wrote:
- FreeBSD 7 has (there is of course an aligning nop
after the eol, which tcpdump skips)
Jake Rizzo sent me some updated tcpdumps comparing 6.3 vs 7.0, and that
aligning NOP that tcpdump (and wireshark) omit seems to be the only
difference.
Here's
d.s. al coda wrote:
Hi,
We recently upgraded one of our webservers to FreeBSD 7, and we started
receiving complaints from some users not able to connect to that server
anymore. On top of that, users were saying that the problem only occurred on
Windows (at least, the ones who had more than on OS
On Wed, Mar 12, 2008 at 1:48 AM, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> Kip Macy wrote:
> > Are you running 7.0-RELEASE? What I believe was this issue was a
> > showstopper for it, so I'm surprised to hear of it now.
>
> No, this is a different issue and not really the fault of TCP but
>
On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> wrote:
> Hi,
> We recently upgraded one of our webservers to FreeBSD 7, and we started
> receiving complaints from some users not able to connect to that server
> anymore. On top of that, users were saying that the problem only oc
On Tue, 11 Mar 2008, d.s. al coda wrote:
- FreeBSD 7 has (there is of course an aligning nop
after the eol, which tcpdump skips)
Which is a bug (the nop after the EOL) that I recently fixed in HEAD.
I am still curious to know if it's only ordering or the invalid padding
or both that keeps cli
On Tue, 11 Mar 2008, d.s. al coda wrote:
Hi,
We recently upgraded one of our webservers to FreeBSD 7, and we started
receiving complaints from some users not able to connect to that server
anymore. On top of that, users were saying that the problem only occurred on
Windows (at least, the ones w
On Wed, 12 Mar 2008, Andre Oppermann wrote:
Kip Macy wrote:
Are you running 7.0-RELEASE? What I believe was this issue was a
showstopper for it, so I'm surprised to hear of it now.
No, this is a different issue and not really the fault of TCP but of certain
cable modem vendors with broken c
Exact same problem that i'm having. I confirmed it exists in 7.0 only since
downgrading one of our servers back to 6.3 stable allowed the same clients
to connect again. This seems to work for us as a workaround:
sysctl net.inet.tcp.sack.enable=0
On 3/12/08, d.s. al coda <[EMAIL PROTECTED]>
Kip Macy wrote:
Are you running 7.0-RELEASE? What I believe was this issue was a
showstopper for it, so I'm surprised to hear of it now.
No, this is a different issue and not really the fault of TCP but
of certain cable modem vendors with broken code in their devices.
FreeBSD is fully compliant
On 3/11/08, Kip Macy <[EMAIL PROTECTED]> wrote:
> Are you running 7.0-RELEASE? What I believe was this issue was a
> showstopper for it, so I'm surprised to hear of it now.
>
> -Kip
Yes, we are running 7.0-RELEASE.
-coda
On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]>
> w
Are you running 7.0-RELEASE? What I believe was this issue was a
showstopper for it, so I'm surprised to hear of it now.
-Kip
On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> wrote:
> Hi,
> We recently upgraded one of our webservers to FreeBSD 7, and we started
> receiving com
Hi,
We recently upgraded one of our webservers to FreeBSD 7, and we started
receiving complaints from some users not able to connect to that server
anymore. On top of that, users were saying that the problem only occurred on
Windows (at least, the ones who had more than on OS to try it out).
After
33 matches
Mail list logo
