[nfe] DHCP failure on 8-stable

Recently it became extremely difficult to pass the DHCP discovery step on boot. Now I am using the buggy [nve] instead. Can anyone help? Thank you, Enoch. uname -a FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME

Re: [nfe] DHCP failure on 8-stable

On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > Recently it became extremely difficult to pass the DHCP discovery step > on boot. Now I am using the buggy [nve] instead. > > Can anyone help? > Did you set synchronous_dhclient option in rc.conf? > Thank you, Enoch. > > uname -a >

Re: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load

On 29.03.2012 15:29, Sergey Smitienko wrote: Hello. I've run into a problem with a web server runing FreeBSD 9.0/amd64. What I believe is happening, is what server loses track of correct SEQ/ACK numbers on some connections. Here is an example: 15:20:00.347514 IP (tos 0x68, ttl 123, id 1181, off

Re: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load

Here you go, two sessions, one with win set in Syn/Ack packet and other with separate "windows open" Ack packet. 16:59:47.629750 IP (tos 0x0, ttl 123, id 55648, offset 0, flags [DF], proto TCP (6), length 48) 195.64.148.12.61153 > 193.178.147.113.80: Flags [S], cksum 0x5721 (correct), seq 770

Re: Removing an IPv6 address does not remove NDP entries on that subnet

On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing wrote: >> * In a way this is a good thing as in6_lltable_prefix_free() is >> guaranteed to crash your kernel in two different ways, and that's not >> counting the race conditions that it's subject to. >> > >        Could you please elaborate with some det

Surge 2012 CFP is Open!

Surge 2012, the scalability conference, September 27-28, Baltimore, MD has opened its CFP. Please visit http://omniti.com/surge/2012/cfp for details. -- Katherine Jeschke Director of Marketing and Creative Services OmniTI Computer Consulting, Inc. 7070 Samuel Morse Drive, Ste.150 Columbia, MD 210

FreeBSD TCP ignores zero window size

I've been tracking down some problems with FreeBSD's sending of TCP packets and seem to have come to the conclusion that in FreeBSD 8.2-RELEASE, when the system is working with a TCP connection that has a moderate delay in it, FreeBSD's TCP ignores the other end telling it that the window size is n

Re: [nfe] DHCP failure on 8-stable

On 03/30/2012 19:38, YongHyeon PYUN wrote: > On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> Recently it became extremely difficult to pass the DHCP discovery step >> on boot. Now I am using the buggy [nve] instead. >> >> Can anyone help? >> > > Did you set synchronous_dhclient option in

Re: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load

On 30.03.2012 15:04, Sergey Smitienko wrote: Here you go, two sessions, one with win set in Syn/Ack packet and other with separate "windows open" Ack packet. Thanks for the tcpdumps. The window update issue seems to be separate from the seq#ack# problem. Why do set the recvspace to the very l

Re: FreeBSD TCP ignores zero window size

On Sat, Mar 31, 2012 at 01:22:27AM +1100, Darren Reed wrote: > I've been tracking down some problems with FreeBSD's sending > of TCP packets and seem to have come to the conclusion that > in FreeBSD 8.2-RELEASE, when the system is working with a > TCP connection that has a moderate delay in it, F

Re: FreeBSD TCP ignores zero window size

On 30.03.2012 16:22, Darren Reed wrote: I've been tracking down some problems with FreeBSD's sending of TCP packets and seem to have come to the conclusion that in FreeBSD 8.2-RELEASE, when the system is working with a TCP connection that has a moderate delay in it, FreeBSD's TCP ignores the othe

FreeBSD 9.0 unexpected change of static route

Hi, After upgrade from FreeBSD 8.1 to FreeBSD 9.0-release (amd64) I've observed an unexpected behavior. From time to time, the static route's gateway I have defined in my rc.conf changes to random IP address. In rc.conf I have: static_routes="spp" route_spp="-net 10.0.0.0/16 10.250.0.2" it

Re: FreeBSD 9.0 generates incorrect SEQ/ACK numbers under load

30.03.12 18:13, Andre Oppermann wrote: > On 30.03.2012 15:04, Sergey Smitienko wrote: >> Here you go, two sessions, one with win set in Syn/Ack packet and other >> with separate "windows open" Ack packet. > > Thanks for the tcpdumps. The window update issue seems to be separate > from the seq#ack#

Possible interoperability issue with TCP timestamps between FreeBSD and Linux

So I'm seeing an issue that appears to be caused by the strict TCP timestamp adherence in the Linux kernel when there are connections being initiated by both sides of a Linux and FreeBSD pair of servers. What is looks like is FreeBSD is only tracking the timestamp for the remote host for connection

LACP kernel panics: /* unlocking is safe here */

While investigating a LACP issue, I turned on LACP_DEBUG on a debug kernel. In this configuration it's easy to panic the kernel - just run 'ifconfig lagg0 laggproto lacp' on a lagg that's already in LACP mode and receiving LACP messages. The problem is that lagg_lacp_detach() drops the lagg wl

NFS: rpc.statd/lockd becomes unresponsive

Hello, We've recently setup a FreeBSD 9.0-RELEASE (x64) system to test as an NFS server for "live" network homes for Mac clients (mostly 10.5 and 10.6 clients). We're a public school district and normally have around 150-200 users logged in at a time with network homes. Currently, we're usi

Re: NFS: rpc.statd/lockd becomes unresponsive

On 03/30/2012 05:36 PM, Josh Beard wrote: Hello, snip Whoops, realized freebsd-fs is probably a more appropriate list for this. My apologies. Josh ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To u