From owner-freebsd-net@FreeBSD.ORG Sun Jun 1 07:48:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81D4D106564A for ; Sun, 1 Jun 2008 07:48:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 5C35B8FC19 for ; Sun, 1 Jun 2008 07:48:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so552161rvf.43 for ; Sun, 01 Jun 2008 00:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=HE1ZVOlfP2olc0+5q8UG4aKOk2xIVV0HTbDbaoN1fCs=; b=Nt/jH8l1GY0ObngN/i7NvXH80axpgeR6whzmkPkEjW/XAUC4Q9x8xjfYreatSTPFyubdv4oKB+V8/8CVBv1lo6QQztLEGcYQqSxXCiRFM/X5Knr/KhtZjgF7ULM6QAwkFOD+xIzWw/rEL/BcZP/nUtv8OU5EvovFcyt9tquR3Rs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=wSGo19HWxEadYOIKKSdbOf3lCbMdW401XZNZybSO2UE+TvgkcHeNydjd6xxNkP/GNZHUoAjJbTEB4IkFxD1b8Fs8cwHGmNDcTzJOgtrf1yb/6ZZs/5pdb+VEXKTchAM1Xtkda4fx2WQpEWeX5uoas3CCkyzfhc4kJd9n8hJL/pQ= Received: by 10.141.128.19 with SMTP id f19mr4173333rvn.45.1212306520660; Sun, 01 Jun 2008 00:48:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id b8sm3285673rvf.9.2008.06.01.00.48.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Jun 2008 00:48:39 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m517mXTS081364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2008 16:48:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m517mWTl081363; Sun, 1 Jun 2008 16:48:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sun, 1 Jun 2008 16:48:32 +0900 From: Pyun YongHyeon To: "Fuchs, Martin" Message-ID: <20080601074832.GA80963@cdnetworks.co.kr> References: <20080528003526.GB63696@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, jfvogel@gmail.com Subject: Re: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 07:48:41 -0000 On Sat, May 31, 2008 at 01:40:47PM +0200, Fuchs, Martin wrote: > Ok, back again... sorry for letting you wait so long, but i had a lot to do... > > Since there's no possibility to copy via putty i'm copying by hand... hopefully there are not too many errors :-) > > ----- > pciconf -lcv > > ... > fxp0@pci0:1:4:0: class=0x020000 card=0x00708086 chip=0x12298086 rev=x010 > hdr=0x00 > class = network > subclass = ethernet > cap01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > > fxp1@pci0:1:5:0: class=0x020000 card=0x00708086 chip=0x12298086 rev=x010 > hdr=0x00 > class = network > subclass = ethernet > cap01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > > fxp2@pci0:1:8:0: class=0x020000 card=0x30118086 chip=0x103a8086 rev=x010 > hdr=0x00 > class = network > subclass = ethernet > cap01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > It looks like fxp0/fxp1 is 82551 Pro and fxp2 is 82801 DB(ICH4). > ----- > dmesg shows for example: > > fxp0: link state changed to down > fxp1: link state changed to down > fxp2: link state changed to down > fxp1: link state changed to up <- when I attach a network cable to a switch That's normal. All ethernet drivers should detect link up event. > > ----- > devinfo does not work... does not find the command (it's the freebsd under pfSense) > Hmm, I don't know layout of pfSense but I guess it's not good idea to remove such a small/good program. > ----- > vmstat -i > > interrupt total rate > irq0: clk 1348688 999 > irq5: ehci0 9043 6 > irq8: rtc 172621 127 > irq10: fxp1 91 0 > irq12: fxp0 86 0 > irq14: uhci0 ata0 792 0 > irq15: ata1 2738 2 > Total 1534059 1137 > > ----- > > Hope you can use this information ? > This looks odd, where is fxp2? Therere is no '+' mark in vmstat output so I think there should be at least an entry for fxp2. Because you have two differnet kinds of NICs would you let me know which one is not working? Also full dmesg output would be helpful, I guess. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sun Jun 1 18:25:33 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F19651065672; Sun, 1 Jun 2008 18:25:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A15648FC2E; Sun, 1 Jun 2008 18:25:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m51INlxD032469; Sun, 1 Jun 2008 12:23:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Jun 2008 12:25:24 -0600 (MDT) Message-Id: <20080601.122524.114765121.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <20080526162427.X26343@fledge.watson.org> References: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> <20080526162427.X26343@fledge.watson.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, bms@freebsd.org, current@freebsd.org, ade@freebsd.org, net@freebsd.org Subject: Re: HEAD UP: non-MPSAFE network drivers to be disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 18:25:33 -0000 In message: <20080526162427.X26343@fledge.watson.org> Robert Watson writes: : : On Mon, 26 May 2008, Bruce M. Simpson wrote: : : >> Given that this is (a) 2008 and (b) 8.x we're talking about, are there : >> really that many consumers of SLIP to warrant it being carried forward at : >> all? : > : > It's kind of a basic. [C]SLIP has been historically handy to have around for : > situations which warrant it. Mind you, given that we have had tun(4) in the : > tree for years now, a userland implementation of SLIP is possible. : > : > As with all of these things it's down to someone sitting down and doing it. : > : > I'm not volunteering to support any of this as I don't use it myself (got : > enough on my plate), merely pointing out that support for SLIP in a system : > is something many people have taken for granted over the years, and for : > prototyping something or providing IP over a simple serial link without the : > configuration overhead of PPP, SLIP is something someone might be using. : > : > P.S. ahc(4) is commodity hardware, I think it can stay right where it is : > thank-you. : : My suspicion is that getting SLIP basically working in userspace is fairly : straight forward, SLiRP and friends have been doing this for years. I made my living for about a year working on TIA, which was a portable, userland implementation of PPP and SLIP/CSLIP. This was in about 1995 or so. It isn't that hard... : SLIP has its subtleties, but the current implementation is relatively : straight-forward, well-documented, etc. Yes, especially CSLIP. But frankly, they are a whole lot easier than PPP to get up and going... Warner From owner-freebsd-net@FreeBSD.ORG Sun Jun 1 18:34:44 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5FA106566C; Sun, 1 Jun 2008 18:34:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCAE8FC0C; Sun, 1 Jun 2008 18:34:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m51IWDPD032548; Sun, 1 Jun 2008 12:32:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Jun 2008 12:33:51 -0600 (MDT) Message-Id: <20080601.123351.-950433793.imp@bsdimp.com> To: bms@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <483C2666.7010608@FreeBSD.org> References: <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ed@80386.nl, current@FreeBSD.org, arch@FreeBSD.org, phk@phk.freebsd.dk, rwatson@FreeBSD.org, ade@FreeBSD.org, net@FreeBSD.org Subject: Re: HEAD UP: non-MPSAFE network drivers to be disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 18:34:45 -0000 In message: <483C2666.7010608@FreeBSD.org> "Bruce M. Simpson" writes: : Other than that, line disciplines can go away. In the past I've uesd line disciplines to implement a keyboard driver for the Apple Newton Keyboard (serial protocol) so I could use it at any point after the loader (the system didn't run X11, so I couldn't use the X11 driver I wrote there). This system has been retired, and I don't think I ever forward ported them past about 3.mumble, if even that far. This code is badly decayed, and I have no requirement that it continues to work. But I know similar techniques are used in some embedded systems. Expect some delayed complaining if they go away entirely. But that may be OK given we're ridding tty of Giant. Now, if we could only sort out the syscons/keyboard/mouse mess... Warner From owner-freebsd-net@FreeBSD.ORG Sun Jun 1 21:01:24 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D898B106567D; Sun, 1 Jun 2008 21:01:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 868EE8FC16; Sun, 1 Jun 2008 21:01:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8DE77170E3; Sun, 1 Jun 2008 21:01:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m51L1KOg002205; Sun, 1 Jun 2008 21:01:21 GMT (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 01 Jun 2008 12:33:51 CST." <20080601.123351.-950433793.imp@bsdimp.com> Date: Sun, 01 Jun 2008 21:01:20 +0000 Message-ID: <2204.1212354080@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: ed@80386.nl, current@FreeBSD.org, arch@FreeBSD.org, rwatson@FreeBSD.org, ade@FreeBSD.org, net@FreeBSD.org, bms@FreeBSD.org Subject: Re: HEAD UP: non-MPSAFE network drivers to be disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 21:01:25 -0000 In message <20080601.123351.-950433793.imp@bsdimp.com>, "M. Warner Losh" writes : >In the past I've uesd line disciplines to implement a keyboard driver >for the Apple Newton Keyboard (serial protocol) [...] But shouldn't you have used uart(4) for that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 01:51:08 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2037106567B for ; Mon, 2 Jun 2008 01:51:08 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id A7D0E8FC17 for ; Mon, 2 Jun 2008 01:51:08 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by an-out-0708.google.com with SMTP id b33so745743ana.13 for ; Sun, 01 Jun 2008 18:51:08 -0700 (PDT) Received: by 10.101.68.10 with SMTP id v10mr13846156ank.45.1212371466602; Sun, 01 Jun 2008 18:51:06 -0700 (PDT) Received: by 10.100.216.6 with HTTP; Sun, 1 Jun 2008 18:51:06 -0700 (PDT) Message-ID: Date: Sun, 1 Jun 2008 22:51:06 -0300 From: "Victor Hugo Bilouro" To: "Andre Oppermann" In-Reply-To: <48430A59.5090604@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> Cc: net@freebsd.org Subject: Re: establish connection without tcp options X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 01:51:09 -0000 On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: > Victor Hugo Bilouro wrote: >> >> On Sun, Jun 1, 2008 at 8:00 AM, Andre Oppermann wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> On Thu, May 29, 2008 at 5:01 AM, Andre Oppermann >>>> wrote: >>>>> >>>>> Victor Hugo Bilouro wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm working into establish manually a tcp connection. >>>>>> >>>>>> Does anyone knows if freebsd 7.0 stable agree, a connection >>>>>> establishment without TCP options set? >>>>> >>>>> Yes, certainly it does. If you send a SYN w/o any options it >>>>> won't use any. If you establish a connection from FreeBSD you >>>>> may ignore any options in SYN and in your SYN-ACK not send any. >>>>> If you want FreeBSD not to send any options you can set the >>>>> socket option TCP_NOOPT before you do the connect. >>>>> >>>>> -- >>>>> Andre >>>>> >>>> Hello, >>>> >>>> First thanks Andre! >>>> >>>> So, as I told before, I'm trying to connect manually, but, something >>>> wrong is occurring, after accomplish 3way-handshake, the server >>>> (passive open) is sending a RESET. >>>> You can see by tcpdump dump, that everything is OK. >>>> >>>> tcpdump -ied0 -S -vv tcp >>>> >>>> 08:58:21.302052 IP (tos 0x0, ttl 64, id 55136, offset 0, flags [none], >>>> proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: S, >>>> cksum 0x2a4d (correct), 3204258715:3204258715(0) win 65535 >>>> >>>> 08:58:21.302125 IP (tos 0x0, ttl 64, id 411, offset 0, flags [DF], >>>> proto TCP (6), length 44) 192.168.1.20.22022 > 192.168.1.10.53639: S, >>>> cksum 0xba99 (correct), 400703492:400703492(0) ack 3204258716 win >>>> 65535 >>>> >>>> 08:58:21.697561 IP (tos 0x0, ttl 64, id 55137, offset 0, flags [none], >>>> proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: ., >>>> cksum 0xacf0 (correct), 0:0(0) ack 400703493 win 65535 >>>> >>>> 08:58:21.697632 IP (tos 0x0, ttl 64, id 412, offset 0, flags [DF], >>>> proto TCP (6), length 40) 192.168.1.20.22022 > 192.168.1.10.53639: R, >>>> cksum 0xacfc (correct), 400703493:400703493(0) win 0 >>>> >>>> >>>> Any suggestions? >>> >>> Enable net.inet.tcp.log_debug=1 and watch the log output. It will >>> tell you where it stumbled. >>> >>> -- >>> Andre >>> >>>> BTW, I'm GSoC student, doing TCP/IP Regression Test Suite. >>>> This code at bilouro_tcptest client at perfoce. >>>> (//depot/projects/soc2008/bilouro_tcptest/) >>>> This script: >>>> //depot/projects/soc2008/bilouro_tcptest/src/scripts/tcpconnect.py >>>> >>>> Best >>> >> >> cool I didn't know this... >> >> I'm seeing /var/log/debug.log and actually something is wrong.... >> >> syn--------------------------------- >> sport 56054 >> dport 22022 >> sequence 2992965889 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 16400 >> urg_pointer 0 >> --------------------------------- >> >> syn+ack----------------------------- >> sport 22022 >> dport 56054 >> sequence 2079194755 >> ack_number 2992965890 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 65535 >> checksum 44497 >> urg_pointer 0 >> --------------------------------- >> >> ack--------------------------------- >> sport 56054 >> dport 22022 >> sequence 0 > > ^^^^^^^^^^^^^ should be 2992965890 > >> ack_number 2079194756 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 33014 >> urg_pointer 0 >> --------------------------------- >> >> /var/log/debug.log: >> TCP [192.168.1.10]:56054 to [192.168.1.20]:22022 tcpflags 0x10; >> syncache_expand: SEQ 0 != IRS+1 2992965889, segment rejected. > > The sequence number of your segment is neither the previous value > not is incremented by one to account for the SYN. > >> Even though I know in step #3 of 3way-handshake I don't need pass the >> sequence, I sent a sequence... > > You do have to pass the sequence number at any time. And it has > to be correct all the time. > >> syn--------------------------------- >> sport 59966 >> dport 22022 >> sequence 874312230 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 50667 >> urg_pointer 0 >> >> --------------------------------- >> >> syn+ack----------------------------- >> sport 22022 >> dport 59966 >> sequence 2755934977 >> ack_number 874312231 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 65535 >> checksum 52952 >> urg_pointer 0 >> >> --------------------------------- >> >> ack--------------------------------- >> sport 59966 >> dport 22022 >> sequence 874312230 > > ^^^^^^^^^^^^^^ increment by one for SYN you sent. > See also the ACK you got back above. > >> ack_number 2755934978 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 59030 >> urg_pointer 0 >> --------------------------------- >> >> ...and the log showed: >> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >> >> I'm still working... > > You should familiarize yourself some more with the sequence number > system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 > are very good for that. > > -- > Andre > PS.: I forgot to copy the list in the previous email exchanging, so I'm doing now.... Andre, thank you SO VERY MUCH. It's working fine! As every book show tcpdump examples of connection establishment , and when the SYN flag is 0(as step #3 of three way handshake), sequence number(SN) are omitted of dump, BUT, it's present. The thing is, the SN is present but it isn't consumed. So, packets that don't consumes the SN, must have the last consumed SN + 1. Only for curiosity, linux and windows 2k accomplished without problems the three way handshake without Sequence Number filled on step #3. More one time, thanks! -- Victor Hugo Bilouro FreeBSD! From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 07:49:42 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4A14106564A for ; Mon, 2 Jun 2008 07:49:42 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8F48FC15 for ; Mon, 2 Jun 2008 07:49:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 64263 invoked from network); 2 Jun 2008 06:46:43 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jun 2008 06:46:43 -0000 Message-ID: <4843A615.90809@freebsd.org> Date: Mon, 02 Jun 2008 09:49:41 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Victor Hugo Bilouro References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: establish connection without tcp options X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 07:49:42 -0000 Victor Hugo Bilouro wrote: > On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: >> Victor Hugo Bilouro wrote: >>> syn--------------------------------- >>> sport 59966 >>> dport 22022 >>> sequence 874312230 >>> ack_number 0 >>> offset 5 >>> reserved 0 >>> urgent 0 >>> ack 0 >>> push 0 >>> reset 0 >>> syn 1 >>> fin 0 >>> window 65535 >>> checksum 50667 >>> urg_pointer 0 >>> >>> --------------------------------- >>> >>> syn+ack----------------------------- >>> sport 22022 >>> dport 59966 >>> sequence 2755934977 >>> ack_number 874312231 >>> offset 6 >>> reserved 0 >>> urgent 0 >>> ack 1 >>> push 2 >>> reset 4 >>> syn 9 >>> fin 0 >>> window 65535 >>> checksum 52952 >>> urg_pointer 0 >>> >>> --------------------------------- >>> >>> ack--------------------------------- >>> sport 59966 >>> dport 22022 >>> sequence 874312230 >> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >> See also the ACK you got back above. >> >>> ack_number 2755934978 >>> offset 5 >>> reserved 0 >>> urgent 0 >>> ack 1 >>> push 0 >>> reset 0 >>> syn 0 >>> fin 0 >>> window 65535 >>> checksum 59030 >>> urg_pointer 0 >>> --------------------------------- >>> >>> ...and the log showed: >>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>> >>> I'm still working... >> You should familiarize yourself some more with the sequence number >> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >> are very good for that. >> >> -- >> Andre >> > > PS.: I forgot to copy the list in the previous email exchanging, so > I'm doing now.... > > > Andre, thank you SO VERY MUCH. It's working fine! > > As every book show tcpdump examples of connection establishment , and > when the SYN flag is 0(as step #3 of three way handshake), sequence > number(SN) are omitted of dump, BUT, it's present. You should use the "-S" option to tcpdump. It will show absolute sequence number instead of relative ones (as guessed by tcpdump). > The thing is, the SN is present but it isn't consumed. So, packets > that don't consumes the SN, must have the last consumed SN + 1. > > Only for curiosity, linux and windows 2k accomplished without > problems the three way handshake without Sequence Number filled on > step #3. I have a hard time believing that. At most they may have sent you a retransmit or a challenge-ACK. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 09:58:07 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6994D1065675 for ; Mon, 2 Jun 2008 09:58:07 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 35B3E8FC1A for ; Mon, 2 Jun 2008 09:58:07 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by an-out-0708.google.com with SMTP id b33so800686ana.13 for ; Mon, 02 Jun 2008 02:58:06 -0700 (PDT) Received: by 10.100.34.16 with SMTP id h16mr14628893anh.46.1212400686336; Mon, 02 Jun 2008 02:58:06 -0700 (PDT) Received: by 10.100.216.6 with HTTP; Mon, 2 Jun 2008 02:58:06 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2008 06:58:06 -0300 From: "Victor Hugo Bilouro" Sender: bilouro@bilouro.com To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: c00a727c2c36122f Cc: Subject: [GSoC - tcptest] Weekly Status Report X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 09:58:07 -0000 Hi, I posted the tcptest** weekly status report at freebsd wiki. Links: http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite http://wiki.freebsd.org/VictorBilouro/Following_tcptest http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_1 Thank you! cheers -- Victor Hugo Bilouro FreeBSD! **tcptest** --> tcptest is a GSoC (Google Summer of Code) project, it's a TCP/IP Regression Test Suite implementation. As a testing tool, it can perform regression, protocol conformance, and fuzz tests. The tool may also be employed as an aid to protocol developers and both testing and debugging of firewalls/routers. It's was built on top of pcs.sf.net of gnn at freebsd. ps: I will keep the nomenclature used at subject. From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 10:36:54 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16A2A1065672 for ; Mon, 2 Jun 2008 10:36:54 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id D31BB8FC17 for ; Mon, 2 Jun 2008 10:36:53 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by an-out-0708.google.com with SMTP id b33so805085ana.13 for ; Mon, 02 Jun 2008 03:36:53 -0700 (PDT) Received: by 10.101.67.15 with SMTP id u15mr14629504ank.66.1212403012901; Mon, 02 Jun 2008 03:36:52 -0700 (PDT) Received: by 10.100.216.6 with HTTP; Mon, 2 Jun 2008 03:36:52 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2008 07:36:52 -0300 From: "Victor Hugo Bilouro" To: "Andre Oppermann" In-Reply-To: <4843A615.90809@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> <4843A615.90809@freebsd.org> Cc: net@freebsd.org Subject: Re: establish connection without tcp options X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 10:36:54 -0000 On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann wrote: > Victor Hugo Bilouro wrote: >> >> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> syn--------------------------------- >>>> sport 59966 >>>> dport 22022 >>>> sequence 874312230 >>>> ack_number 0 >>>> offset 5 >>>> reserved 0 >>>> urgent 0 >>>> ack 0 >>>> push 0 >>>> reset 0 >>>> syn 1 >>>> fin 0 >>>> window 65535 >>>> checksum 50667 >>>> urg_pointer 0 >>>> >>>> --------------------------------- >>>> >>>> syn+ack----------------------------- >>>> sport 22022 >>>> dport 59966 >>>> sequence 2755934977 >>>> ack_number 874312231 >>>> offset 6 >>>> reserved 0 >>>> urgent 0 >>>> ack 1 >>>> push 2 >>>> reset 4 >>>> syn 9 >>>> fin 0 >>>> window 65535 >>>> checksum 52952 >>>> urg_pointer 0 >>>> >>>> --------------------------------- >>>> >>>> ack--------------------------------- >>>> sport 59966 >>>> dport 22022 >>>> sequence 874312230 >>> >>> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >>> See also the ACK you got back above. >>> >>>> ack_number 2755934978 >>>> offset 5 >>>> reserved 0 >>>> urgent 0 >>>> ack 1 >>>> push 0 >>>> reset 0 >>>> syn 0 >>>> fin 0 >>>> window 65535 >>>> checksum 59030 >>>> urg_pointer 0 >>>> --------------------------------- >>>> >>>> ...and the log showed: >>>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>>> >>>> I'm still working... >>> >>> You should familiarize yourself some more with the sequence number >>> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >>> are very good for that. >>> >>> -- >>> Andre >>> >> >> PS.: I forgot to copy the list in the previous email exchanging, so >> I'm doing now.... >> >> >> Andre, thank you SO VERY MUCH. It's working fine! >> >> As every book show tcpdump examples of connection establishment , and >> when the SYN flag is 0(as step #3 of three way handshake), sequence >> number(SN) are omitted of dump, BUT, it's present. > > You should use the "-S" option to tcpdump. It will show absolute > sequence number instead of relative ones (as guessed by tcpdump). > >> The thing is, the SN is present but it isn't consumed. So, packets >> that don't consumes the SN, must have the last consumed SN + 1. >> >> Only for curiosity, linux and windows 2k accomplished without >> problems the three way handshake without Sequence Number filled on >> step #3. > > I have a hard time believing that. At most they may have sent you > a retransmit or a challenge-ACK. > > -- > Andre > I will post here the tcpdump and tcptest dumps for both windows and linux with ACK with sequence 0. windows tcpdump: (tcpdump -i ed0 -S tcp) 17:01:46.420016 IP 192.168.1.10.59537 > 192.168.1.101.http: S 770272892:770272892(0) win 65535 17:01:46.421835 IP 192.168.1.101.http > 192.168.1.10.59537: S 1681202755:1681202755(0) ack 770272893 win 64240 17:01:46.834808 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack 1681202756 win 65535 17:01:46.839584 IP 192.168.1.10.59537 > 192.168.1.101.http: F 770272893:770272893(0) ack 1681202756 win 65535 17:01:46.840613 IP 192.168.1.101.http > 192.168.1.10.59537: . ack 770272894 win 64240 17:01:46.840675 IP 192.168.1.101.http > 192.168.1.10.59537: F 1681202756:1681202756(0) ack 770272894 win 64240 17:01:47.297816 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack 1681202757 win 65535 windows dump of tcptest (every packet of connection establishment and finalization) SYN--------------------------------- sport 56121 dport 80 sequence 1046947043 ack_number 0 offset 5 reserved 0 urgent 0 ack 0 push 0 reset 0 syn 1 fin 0 window 65535 checksum 60750 urg_pointer 0 --------------------------------- SYN+ACK--------------------------------- sport 80 dport 56121 sequence 1494256296 ack_number 1046947044 offset 6 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 9 fin 0 window 64240 checksum 63191 urg_pointer 0 --------------------------------- ACK (SYN)--------------------------------- sport 56121 dport 80 sequence 0 ack_number 1494256297 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 27857 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 56121 dport 80 sequence 1046947044 ack_number 1494256297 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 1 window 65535 checksum 2437 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 80 dport 56121 sequence 1494256297 ack_number 1046947045 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 0 window 64240 checksum 3732 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 80 dport 56121 sequence 1494256297 ack_number 1046947045 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 1 window 64240 checksum 3731 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 56121 dport 80 sequence 1046947045 ack_number 1494256298 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 2436 urg_pointer 0 --------------------------------- linux tcpdump: (tcpdump -i ed0 -S tcp) 17:06:12.493737 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: S 501941873:501941873(0) win 65535 17:06:12.934559 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: S 1436097196:1436097196(0) ack 501941874 win 5840 17:06:13.313919 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . ack 1436097197 win 65535 17:06:13.320533 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: F 501941874:501941874(0) ack 1436097197 win 65535 17:06:13.331289 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: . ack 501941874 win 5840 17:06:13.337751 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: F 1436097197:1436097197(0) ack 501941875 win 5840 17:06:13.762246 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . ack 1436097198 win 65535 linux dump of tcptest (every packet of connection establishment and finalization) SYN--------------------------------- sport 54458 dport 80 sequence 501941873 ack_number 0 offset 5 reserved 0 urgent 0 ack 0 push 0 reset 0 syn 1 fin 0 window 65535 checksum 25507 urg_pointer 0 --------------------------------- SYN+ACK--------------------------------- sport 80 dport 54458 sequence 1436097196 ack_number 501941874 offset 6 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 9 fin 0 window 5840 checksum 50368 urg_pointer 0 --------------------------------- ACK (SYN)--------------------------------- sport 54458 dport 80 sequence 0 ack_number 1436097197 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 6059 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 54458 dport 80 sequence 501941874 ack_number 1436097197 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 1 window 65535 checksum 62284 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 80 dport 54458 sequence 1436097197 ack_number 501941874 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 0 window 5840 checksum 56445 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 80 dport 54458 sequence 1436097197 ack_number 501941875 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 1 window 5840 checksum 56443 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 54458 dport 80 sequence 501941875 ack_number 1436097198 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 62283 urg_pointer 0 --------------------------------- It was the first test conformance result of tcptest! cheers -- Victor Hugo Bilouro FreeBSD! From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 11:06:57 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91DA010656DF for ; Mon, 2 Jun 2008 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 86CCD8FC0A for ; Mon, 2 Jun 2008 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m52B6vq2093247 for ; Mon, 2 Jun 2008 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m52B6uZF093243 for freebsd-net@FreeBSD.org; Mon, 2 Jun 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Jun 2008 11:06:56 GMT Message-Id: <200806021106.m52B6uZF093243@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 11:06:57 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(1): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one p kern/123741 net [netgraph] [panic] kernel panic due to netgraph mpd o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123950 net [tcp] TH_RST packet sended if received out-of-order da o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov 91 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available o kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres 51 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 11:27:36 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528671065670 for ; Mon, 2 Jun 2008 11:27:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 525138FC1E for ; Mon, 2 Jun 2008 11:27:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 67136 invoked from network); 2 Jun 2008 10:24:34 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jun 2008 10:24:34 -0000 Message-ID: <4843D926.8010402@freebsd.org> Date: Mon, 02 Jun 2008 13:27:34 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Victor Hugo Bilouro References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> <4843A615.90809@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: establish connection without tcp options X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 11:27:36 -0000 Victor Hugo Bilouro wrote: > On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann wrote: >> Victor Hugo Bilouro wrote: >>> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: >>>> Victor Hugo Bilouro wrote: >>>>> syn--------------------------------- >>>>> sport 59966 >>>>> dport 22022 >>>>> sequence 874312230 >>>>> ack_number 0 >>>>> offset 5 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 0 >>>>> push 0 >>>>> reset 0 >>>>> syn 1 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 50667 >>>>> urg_pointer 0 >>>>> >>>>> --------------------------------- >>>>> >>>>> syn+ack----------------------------- >>>>> sport 22022 >>>>> dport 59966 >>>>> sequence 2755934977 >>>>> ack_number 874312231 >>>>> offset 6 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 1 >>>>> push 2 >>>>> reset 4 >>>>> syn 9 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 52952 >>>>> urg_pointer 0 >>>>> >>>>> --------------------------------- >>>>> >>>>> ack--------------------------------- >>>>> sport 59966 >>>>> dport 22022 >>>>> sequence 874312230 >>>> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >>>> See also the ACK you got back above. >>>> >>>>> ack_number 2755934978 >>>>> offset 5 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 1 >>>>> push 0 >>>>> reset 0 >>>>> syn 0 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 59030 >>>>> urg_pointer 0 >>>>> --------------------------------- >>>>> >>>>> ...and the log showed: >>>>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>>>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>>>> >>>>> I'm still working... >>>> You should familiarize yourself some more with the sequence number >>>> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >>>> are very good for that. >>>> >>>> -- >>>> Andre >>>> >>> PS.: I forgot to copy the list in the previous email exchanging, so >>> I'm doing now.... >>> >>> >>> Andre, thank you SO VERY MUCH. It's working fine! >>> >>> As every book show tcpdump examples of connection establishment , and >>> when the SYN flag is 0(as step #3 of three way handshake), sequence >>> number(SN) are omitted of dump, BUT, it's present. >> You should use the "-S" option to tcpdump. It will show absolute >> sequence number instead of relative ones (as guessed by tcpdump). >> >>> The thing is, the SN is present but it isn't consumed. So, packets >>> that don't consumes the SN, must have the last consumed SN + 1. >>> >>> Only for curiosity, linux and windows 2k accomplished without >>> problems the three way handshake without Sequence Number filled on >>> step #3. >> I have a hard time believing that. At most they may have sent you >> a retransmit or a challenge-ACK. >> >> -- >> Andre >> > > I will post here the tcpdump and tcptest dumps for both windows and > linux with ACK with sequence 0. > > windows tcpdump: (tcpdump -i ed0 -S tcp) > 17:01:46.420016 IP 192.168.1.10.59537 > 192.168.1.101.http: S > 770272892:770272892(0) win 65535 > 17:01:46.421835 IP 192.168.1.101.http > 192.168.1.10.59537: S > 1681202755:1681202755(0) ack 770272893 win 64240 > 17:01:46.834808 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack > 1681202756 win 65535 > 17:01:46.839584 IP 192.168.1.10.59537 > 192.168.1.101.http: F > 770272893:770272893(0) ack 1681202756 win 65535 > 17:01:46.840613 IP 192.168.1.101.http > 192.168.1.10.59537: . ack > 770272894 win 64240 > 17:01:46.840675 IP 192.168.1.101.http > 192.168.1.10.59537: F > 1681202756:1681202756(0) ack 770272894 win 64240 > 17:01:47.297816 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack > 1681202757 win 65535 That's interesting. I don't see any rationale why that should be acceptable. We enforce the sequence number to be present and valid in the ACK. This hasn't caused any complaints or incompatibilities so far. What version/service-pack of Windows and Linux (kernel) are you testing against? According to RFC793, Section 3.9, Page 69 the first check is actually testing the SEG.SEQ as follows: RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND. RCV.NXT is obviously the SEG.SEQ you sent with your SYN segment. It seems that Windows and Linux are ignoring this test because you didn't send any data with the ACK. Or they are simply ignoring the segment as invalid and your FIN packet (with the correct SEG.SEQ and SEG.ACK) causes the internal state transition. One may discuss which response, none (just ignore segment) or sending a RST (as we do currently) is better. I tend to argue the latter as it makes problems/bugs much more evident as we've witnessed with your test. -- Andre > windows dump of tcptest (every packet of connection establishment and > finalization) > SYN--------------------------------- > sport 56121 > dport 80 > sequence 1046947043 > ack_number 0 > offset 5 > reserved 0 > urgent 0 > ack 0 > push 0 > reset 0 > syn 1 > fin 0 > window 65535 > checksum 60750 > urg_pointer 0 > > --------------------------------- > > SYN+ACK--------------------------------- > sport 80 > dport 56121 > sequence 1494256296 > ack_number 1046947044 > offset 6 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 9 > fin 0 > window 64240 > checksum 63191 > urg_pointer 0 > > --------------------------------- > > ACK (SYN)--------------------------------- > sport 56121 > dport 80 > sequence 0 > ack_number 1494256297 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 27857 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 56121 > dport 80 > sequence 1046947044 > ack_number 1494256297 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 1 > window 65535 > checksum 2437 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 80 > dport 56121 > sequence 1494256297 > ack_number 1046947045 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 0 > window 64240 > checksum 3732 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 80 > dport 56121 > sequence 1494256297 > ack_number 1046947045 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 1 > window 64240 > checksum 3731 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 56121 > dport 80 > sequence 1046947045 > ack_number 1494256298 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 2436 > urg_pointer 0 > > --------------------------------- > > > > > > > > > linux tcpdump: (tcpdump -i ed0 -S tcp) > 17:06:12.493737 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: S > 501941873:501941873(0) win 65535 > 17:06:12.934559 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: S > 1436097196:1436097196(0) ack 501941874 win 5840 > 17:06:13.313919 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . > ack 1436097197 win 65535 > 17:06:13.320533 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: F > 501941874:501941874(0) ack 1436097197 win 65535 > 17:06:13.331289 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: . > ack 501941874 win 5840 > 17:06:13.337751 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: F > 1436097197:1436097197(0) ack 501941875 win 5840 > 17:06:13.762246 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . > ack 1436097198 win 65535 > > > > > linux dump of tcptest (every packet of connection establishment and > finalization) > SYN--------------------------------- > sport 54458 > dport 80 > sequence 501941873 > ack_number 0 > offset 5 > reserved 0 > urgent 0 > ack 0 > push 0 > reset 0 > syn 1 > fin 0 > window 65535 > checksum 25507 > urg_pointer 0 > > --------------------------------- > > SYN+ACK--------------------------------- > sport 80 > dport 54458 > sequence 1436097196 > ack_number 501941874 > offset 6 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 9 > fin 0 > window 5840 > checksum 50368 > urg_pointer 0 > > --------------------------------- > > ACK (SYN)--------------------------------- > sport 54458 > dport 80 > sequence 0 > ack_number 1436097197 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 6059 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 54458 > dport 80 > sequence 501941874 > ack_number 1436097197 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 1 > window 65535 > checksum 62284 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 80 > dport 54458 > sequence 1436097197 > ack_number 501941874 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 0 > window 5840 > checksum 56445 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 80 > dport 54458 > sequence 1436097197 > ack_number 501941875 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 1 > window 5840 > checksum 56443 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 54458 > dport 80 > sequence 501941875 > ack_number 1436097198 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 62283 > urg_pointer 0 > > --------------------------------- > > It was the first test conformance result of tcptest! > > > cheers From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 16:44:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 149DE1065676 for ; Mon, 2 Jun 2008 16:44:54 +0000 (UTC) (envelope-from crapsh@MonkeyBrains.NET) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id 14F148FC18 for ; Mon, 2 Jun 2008 16:44:54 +0000 (UTC) (envelope-from crapsh@MonkeyBrains.NET) Received: from Penelope-Thomas-Computer.local (adsl-76-199-98-156.dsl.pltn13.sbcglobal.net [76.199.98.156]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id m52Giq8o047758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jun 2008 09:44:53 -0700 (PDT) (envelope-from crapsh@MonkeyBrains.NET) Message-ID: <48442389.9000602@MonkeyBrains.NET> Date: Mon, 02 Jun 2008 09:44:57 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on pita.monkeybrains.net X-Virus-Status: Clean Subject: carpdev? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 16:44:54 -0000 Any plans for carpdev in FreeBSD? I'd be happy to poke around the OpenBSD source and try to get it working on FreeBSD. (Emphasis on the _try_) http://lists.freebsd.org/pipermail/freebsd-pf/2006-July/002429.html http://www.openbsd.org/faq/faq6.html#CARP Quick question: I notice the IP in carp examples is always a /24. If there is already a /24 IP on the 'host' interface for the carp device, why is it not a /32 (like when an alias is issued)? hostname="hosta.example.org" ifconfig_fxp0="inet 192.168.1.3 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 1 pass testpass 192.168.1.50/24" Carpdev would get rid fo the 192.168.1.3 requirement and have something similar to vlandev. Rudy From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 16:57:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82179106564A for ; Mon, 2 Jun 2008 16:57:00 +0000 (UTC) (envelope-from crapsh@MonkeyBrains.NET) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id 80B1D8FC18 for ; Mon, 2 Jun 2008 16:57:00 +0000 (UTC) (envelope-from crapsh@MonkeyBrains.NET) Received: from Penelope-Thomas-Computer.local (adsl-76-199-98-156.dsl.pltn13.sbcglobal.net [76.199.98.156]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id m52GuwWb053087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jun 2008 09:56:59 -0700 (PDT) (envelope-from crapsh@MonkeyBrains.NET) Message-ID: <4844265F.4000405@MonkeyBrains.NET> Date: Mon, 02 Jun 2008 09:57:03 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <48442389.9000602@MonkeyBrains.NET> In-Reply-To: <48442389.9000602@MonkeyBrains.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on pita.monkeybrains.net X-Virus-Status: Clean Subject: Re: carpdev? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 16:57:00 -0000 Ah, someone already asked for this...http://lists.freebsd.org/pipermail/freebsd-pf/2007-July/003624.html Would this work? (I will test later today...) routerA ifconfig em0 10.0.0.8/24 ifconfig carp0 create ifconfig carp0 vhid 1 pass mekmitasdigoat 10.0.0.2/24 ifconfig carp0 1.2.3.4/30 <--- my "real" ip for my router routerB ifconfig em0 10.0.0.9/24 ifconfig carp0 create ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat 10.0.0.2/24 ifconfig carp0 1.2.3.4/30 <--- my "real" ip for my router if so, would rc.conf be something like this: /cloned/*_*/interfaces="carp 0"/ ifconfig_carp0="vhid 1 pass mekmitasdigoat 10.0.0.2/24" ifconfig_carp0_alias0="1.2.3.4/30" Rudy From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 17:04:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE3BD106567A for ; Mon, 2 Jun 2008 17:04:11 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id B25078FC22 for ; Mon, 2 Jun 2008 17:04:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-016-249.pools.arcor-ip.net [88.66.16.249]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1K3DS33PbK-0004vl; Mon, 02 Jun 2008 19:04:09 +0200 Received: (qmail 27495 invoked from network); 2 Jun 2008 17:02:13 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 2 Jun 2008 17:02:13 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Mon, 2 Jun 2008 19:03:48 +0200 User-Agent: KMail/1.9.9 References: <48442389.9000602@MonkeyBrains.NET> <4844265F.4000405@MonkeyBrains.NET> In-Reply-To: <4844265F.4000405@MonkeyBrains.NET> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_0fCRIvDhAIxj+va" Message-Id: <200806021903.48986.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19iiQUzBatiPd7bdznZ6kUIhLkLlyxd/Uhm6SV 3csnTUX/nm65ZwzUIru50qkJt3qKGbiRUYXtJOa0M0IsgUEYbe QODOBKOhtUAq8KF9qeV8A== Cc: Rudy Subject: Re: carpdev? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:04:11 -0000 --Boundary-00=_0fCRIvDhAIxj+va Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline I did the attached patch some time ago, but didn't find sufficient testers and when I did - I didn't have time. This should work. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-00=_0fCRIvDhAIxj+va Content-Type: text/x-diff; charset="iso-8859-1"; name="carpdev.BETA2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="carpdev.BETA2.diff" diff --git a/sbin/ifconfig/ifcarp.c b/sbin/ifconfig/ifcarp.c index 9c961b7..82dbd50 100644 --- a/sbin/ifconfig/ifcarp.c +++ b/sbin/ifconfig/ifcarp.c @@ -52,13 +52,7 @@ static const char *carp_states[] = { CARP_STATES }; -void carp_status(int s); -void setcarp_advbase(const char *,int, int, const struct afswtch *rafp); -void setcarp_advskew(const char *, int, int, const struct afswtch *rafp); -void setcarp_passwd(const char *, int, int, const struct afswtch *rafp); -void setcarp_vhid(const char *, int, int, const struct afswtch *rafp); - -void +static void carp_status(int s) { const char *state; @@ -76,17 +70,17 @@ carp_status(int s) else state = carp_states[carpr.carpr_state]; - printf("\tcarp: %s vhid %d advbase %d advskew %d\n", - state, carpr.carpr_vhid, carpr.carpr_advbase, - carpr.carpr_advskew); + printf("\tcarp: %s carpdev %s vhid %d advbase %d advskew %d\n", + state, carpr.carpr_carpdev, carpr.carpr_vhid, + carpr.carpr_advbase, carpr.carpr_advskew); } return; } -void -setcarp_passwd(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_passwd, val, d) { struct carpreq carpr; @@ -105,8 +99,8 @@ setcarp_passwd(const char *val, int d, int s, const struct afswtch *afp) return; } -void -setcarp_vhid(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_vhid, val, d) { int vhid; struct carpreq carpr; @@ -130,8 +124,8 @@ setcarp_vhid(const char *val, int d, int s, const struct afswtch *afp) return; } -void -setcarp_advskew(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_advskew, val, d) { int advskew; struct carpreq carpr; @@ -152,8 +146,8 @@ setcarp_advskew(const char *val, int d, int s, const struct afswtch *afp) return; } -void -setcarp_advbase(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_advbase, val, d) { int advbase; struct carpreq carpr; @@ -174,11 +168,51 @@ setcarp_advbase(const char *val, int d, int s, const struct afswtch *afp) return; } +static +DECL_CMD_FUNC(setcarp_carpdev, val, d) +{ + struct carpreq carpr; + + memset((char *)&carpr, 0, sizeof(struct carpreq)); + ifr.ifr_data = (caddr_t)&carpr; + + if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1) + err(1, "SIOCGVH"); + + strlcpy(carpr.carpr_carpdev, val, sizeof(carpr.carpr_carpdev)); + + if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1) + err(1, "SIOCSVH"); + + return; +} + +static +DECL_CMD_FUNC(setcarp_unsetcarpdev, val, d) +{ + struct carpreq carpr; + + memset((char *)&carpr, 0, sizeof(struct carpreq)); + ifr.ifr_data = (caddr_t)&carpr; + + if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1) + err(1, "SIOCGVH"); + + memset(carpr.carpr_carpdev, 0, sizeof(carpr.carpr_carpdev)); + + if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1) + err(1, "SIOCSVH"); + + return; +} + static struct cmd carp_cmds[] = { DEF_CMD_ARG("advbase", setcarp_advbase), DEF_CMD_ARG("advskew", setcarp_advskew), DEF_CMD_ARG("pass", setcarp_passwd), DEF_CMD_ARG("vhid", setcarp_vhid), + DEF_CMD_ARG("carpdev", setcarp_carpdev), + DEF_CMD_OPTARG("-carpdev", setcarp_unsetcarpdev), }; static struct afswtch af_carp = { .af_name = "af_carp", diff --git a/sys/amd64/conf/CARP b/sys/amd64/conf/CARP new file mode 100644 index 0000000..710a970 --- /dev/null +++ b/sys/amd64/conf/CARP @@ -0,0 +1,4 @@ +include GENERIC +ident CARP + +device carp diff --git a/sys/net/ethernet.h b/sys/net/ethernet.h index 7d45ce3..e7a3450 100644 --- a/sys/net/ethernet.h +++ b/sys/net/ethernet.h @@ -380,6 +380,7 @@ extern void ether_demux(struct ifnet *, struct mbuf *); extern void ether_ifattach(struct ifnet *, const u_int8_t *); extern void ether_ifdetach(struct ifnet *); extern int ether_ioctl(struct ifnet *, u_long, caddr_t); +extern void ether_input(struct ifnet *, struct mbuf *); extern int ether_output(struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *); extern int ether_output_frame(struct ifnet *, struct mbuf *); diff --git a/sys/net/if.c b/sys/net/if.c index 9db8935..9178a3d 100644 --- a/sys/net/if.c +++ b/sys/net/if.c @@ -1309,8 +1309,7 @@ if_unroute(struct ifnet *ifp, int flag, int fam) pfctlinput(PRC_IFDOWN, ifa->ifa_addr); if_qflush(&ifp->if_snd); #ifdef DEV_CARP - if (ifp->if_carp) - carp_carpdev_state(ifp->if_carp); + carp_carpdev_state(ifp); #endif rt_ifmsg(ifp); } @@ -1333,8 +1332,7 @@ if_route(struct ifnet *ifp, int flag, int fam) if (fam == PF_UNSPEC || (fam == ifa->ifa_addr->sa_family)) pfctlinput(PRC_IFUP, ifa->ifa_addr); #ifdef DEV_CARP - if (ifp->if_carp) - carp_carpdev_state(ifp->if_carp); + carp_carpdev_state(ifp); #endif rt_ifmsg(ifp); #ifdef INET6 @@ -1386,8 +1384,7 @@ do_link_state_change(void *arg, int pending) IFP2AC(ifp)->ac_netgraph != NULL) (*ng_ether_link_state_p)(ifp, link_state); #ifdef DEV_CARP - if (ifp->if_carp) - carp_carpdev_state(ifp->if_carp); + carp_carpdev_state(ifp); #endif if (ifp->if_bridge) { KASSERT(bstp_linkstate_p != NULL,("if_bridge bstp not loaded!")); diff --git a/sys/net/if_ethersubr.c b/sys/net/if_ethersubr.c index 7023e9c..170bcc7 100644 --- a/sys/net/if_ethersubr.c +++ b/sys/net/if_ethersubr.c @@ -153,6 +153,9 @@ ether_output(struct ifnet *ifp, struct mbuf *m, u_char esrc[ETHER_ADDR_LEN], edst[ETHER_ADDR_LEN]; struct ether_header *eh; struct pf_mtag *t; +#ifdef DEV_CARP + struct ifnet *ifp0 = ifp; +#endif int loop_copy = 1; int hlen; /* link layer header length */ @@ -162,6 +165,19 @@ ether_output(struct ifnet *ifp, struct mbuf *m, senderr(error); #endif +#ifdef DEV_CARP + if (ifp->if_type == IFT_CARP) { + struct ifaddr *ifa; + + if (dst != NULL && ifp->if_link_state == LINK_STATE_UP && + (ifa = ifa_ifwithaddr(dst)) != NULL && + ifa->ifa_ifp == ifp) + return (looutput(ifp, m, dst, rt0)); + + ifp = ifp->if_carpdev; + } +#endif + if (ifp->if_flags & IFF_MONITOR) senderr(ENETDOWN); if (!((ifp->if_flags & IFF_UP) && @@ -172,7 +188,11 @@ ether_output(struct ifnet *ifp, struct mbuf *m, switch (dst->sa_family) { #ifdef INET case AF_INET: +#ifdef DEV_CARP + error = arpresolve(ifp0, rt0, m, dst, edst); +#else error = arpresolve(ifp, rt0, m, dst, edst); +#endif if (error) return (error == EWOULDBLOCK ? 0 : error); type = htons(ETHERTYPE_IP); @@ -293,6 +313,14 @@ ether_output(struct ifnet *ifp, struct mbuf *m, (void)memcpy(eh->ether_shost, IF_LLADDR(ifp), sizeof(eh->ether_shost)); +#ifdef DEV_CARP + if (ifp0 != ifp && ifp0->if_type == IFT_CARP) { + /* XXX: LINK1 */ + (void)memcpy(eh->ether_shost, IF_LLADDR(ifp0), + sizeof(eh->ether_shost)); + } +#endif + /* * If a simplex interface, and the packet is being sent to our * Ethernet address or a broadcast address, loopback a copy. @@ -351,12 +379,6 @@ ether_output(struct ifnet *ifp, struct mbuf *m, return (error); } -#ifdef DEV_CARP - if (ifp->if_carp && - (error = carp_output(ifp, m, dst, NULL))) - goto bad; -#endif - /* Handle ng_ether(4) processing, if any */ if (IFP2AC(ifp)->ac_netgraph != NULL) { KASSERT(ng_ether_output_p != NULL, @@ -506,7 +528,7 @@ ether_ipfw_chk(struct mbuf **m0, struct ifnet *dst, * Process a received Ethernet packet; the packet is in the * mbuf chain m with the ethernet header at the front. */ -static void +void ether_input(struct ifnet *ifp, struct mbuf *m) { struct ether_header *eh; @@ -658,19 +680,15 @@ ether_input(struct ifnet *ifp, struct mbuf *m) } #ifdef DEV_CARP - /* - * Clear M_PROMISC on frame so that carp(4) will see it when the - * mbuf flows up to Layer 3. - * FreeBSD's implementation of carp(4) uses the inprotosw - * to dispatch IPPROTO_CARP. carp(4) also allocates its own - * Ethernet addresses of the form 00:00:5e:00:01:xx, which - * is outside the scope of the M_PROMISC test below. - * TODO: Maintain a hash table of ethernet addresses other than - * ether_dhost which may be active on this ifp. - */ - if (ifp->if_carp && carp_forus(ifp->if_carp, eh->ether_dhost)) { - m->m_flags &= ~M_PROMISC; - } else + if (ifp->if_carp) { + if (ifp->if_type != IFT_CARP && (carp_input(m) == 0)) + return; + else if (ifp->if_type == IFT_CARP && + /* XXX: LINK2 */ + m->m_flags & (M_BCAST | M_MCAST) && + !bcmp(IFP2AC(ifp), eh->ether_dhost, ETHER_ADDR_LEN)) + m->m_flags &= ~(M_BCAST | M_MCAST); + } #endif { /* diff --git a/sys/net/if_loop.c b/sys/net/if_loop.c index bd15bdf..1706f58 100644 --- a/sys/net/if_loop.c +++ b/sys/net/if_loop.c @@ -98,8 +98,6 @@ struct lo_softc { int loioctl(struct ifnet *, u_long, caddr_t); static void lortrequest(int, struct rtentry *, struct rt_addrinfo *); -int looutput(struct ifnet *ifp, struct mbuf *m, - struct sockaddr *dst, struct rtentry *rt); static int lo_clone_create(struct if_clone *, int, caddr_t); static void lo_clone_destroy(struct ifnet *); diff --git a/sys/net/if_var.h b/sys/net/if_var.h index 44a297e..b0da599 100644 --- a/sys/net/if_var.h +++ b/sys/net/if_var.h @@ -131,7 +131,12 @@ struct ifnet { */ struct knlist if_klist; /* events attached to this if */ int if_pcount; /* number of promiscuous listeners */ - struct carp_if *if_carp; /* carp interface structure */ + union { + struct carp_if *carp_s; + struct ifnet *carp_d; + } if_carp_ptr; +#define if_carp if_carp_ptr.carp_s +#define if_carpdev if_carp_ptr.carp_d struct bpf_if *if_bpf; /* packet filter structure */ u_short if_index; /* numeric abbreviation for this if */ short if_timer; /* time 'til if_watchdog called */ @@ -692,6 +697,8 @@ struct ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr *); struct ifaddr *ifaof_ifpforaddr(struct sockaddr *, struct ifnet *); int if_simloop(struct ifnet *ifp, struct mbuf *m, int af, int hlen); +int looutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, + struct rtentry *rt); typedef void *if_com_alloc_t(u_char type, struct ifnet *ifp); typedef void if_com_free_t(void *com, u_char type); diff --git a/sys/netinet/if_ether.c b/sys/netinet/if_ether.c index 13f2c06..b4f667d 100644 --- a/sys/netinet/if_ether.c +++ b/sys/netinet/if_ether.c @@ -110,7 +110,6 @@ SYSCTL_INT(_net_link_ether_inet, OID_AUTO, proxyall, CTLFLAG_RW, &arp_proxyall, 0, "Enable proxy ARP for all suitable requests"); static void arp_init(void); -static void arp_rtrequest(int, struct rtentry *, struct rt_addrinfo *); static void arprequest(struct ifnet *, struct in_addr *, struct in_addr *, u_char *); static void arpintr(struct mbuf *); @@ -144,7 +143,7 @@ arptimer(void *arg) /* * Parallel to llc_rtrequest. */ -static void +void arp_rtrequest(int req, struct rtentry *rt, struct rt_addrinfo *info) { struct sockaddr *gate; @@ -575,9 +574,6 @@ in_arpinput(struct mbuf *m) int op, rif_len; int req_len; int bridged = 0; -#ifdef DEV_CARP - int carp_match = 0; -#endif if (ifp->if_bridge) bridged = 1; @@ -608,12 +604,11 @@ in_arpinput(struct mbuf *m) itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) goto match; #ifdef DEV_CARP - if (ifp->if_carp != NULL && + if (ifp->if_type != IFT_CARP && ifp->if_carp != NULL && + ia->ia_ifp->if_type == IFT_CARP && carp_iamatch(ifp->if_carp, ia, &isaddr, &enaddr) && - itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) { - carp_match = 1; + itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) goto match; - } #endif } LIST_FOREACH(ia, INADDR_HASH(isaddr.s_addr), ia_hash) @@ -676,7 +671,9 @@ match: /* The following is not an error when doing bridging. */ if (!bridged && rt->rt_ifp != ifp #ifdef DEV_CARP - && (ifp->if_type != IFT_CARP || !carp_match) + && !(rt->rt_ifp->if_type == IFT_CARP && + rt->rt_ifp->if_carpdev == ifp) && + !(ifp->if_type == IFT_CARP && ifp->if_carpdev == rt->rt_ifp) #endif ) { if (log_arp_wrong_iface) diff --git a/sys/netinet/if_ether.h b/sys/netinet/if_ether.h index 9bc6b7b..8c36e02 100644 --- a/sys/netinet/if_ether.h +++ b/sys/netinet/if_ether.h @@ -113,6 +113,7 @@ int arpresolve(struct ifnet *ifp, struct rtentry *rt, struct mbuf *m, struct sockaddr *dst, u_char *desten); void arp_ifinit(struct ifnet *, struct ifaddr *); void arp_ifinit2(struct ifnet *, struct ifaddr *, u_char *); +void arp_rtrequest(int, struct rtentry *, struct rt_addrinfo *); #endif #endif diff --git a/sys/netinet/in_proto.c b/sys/netinet/in_proto.c index 5239805..f642bb9 100644 --- a/sys/netinet/in_proto.c +++ b/sys/netinet/in_proto.c @@ -318,7 +318,7 @@ struct protosw inetsw[] = { .pr_domain = &inetdomain, .pr_protocol = IPPROTO_CARP, .pr_flags = PR_ATOMIC|PR_ADDR, - .pr_input = carp_input, + .pr_input = carp_proto_input, .pr_output = (pr_output_t*)rip_output, .pr_ctloutput = rip_ctloutput, .pr_usrreqs = &rip_usrreqs diff --git a/sys/netinet/ip_carp.c b/sys/netinet/ip_carp.c index c08d39f..aea3518 100644 --- a/sys/netinet/ip_carp.c +++ b/sys/netinet/ip_carp.c @@ -92,11 +92,9 @@ SYSCTL_DECL(_net_inet_carp); struct carp_softc { struct ifnet *sc_ifp; /* Interface clue */ - struct ifnet *sc_carpdev; /* Pointer to parent interface */ - struct in_ifaddr *sc_ia; /* primary iface address */ +#define sc_carpdev sc_ifp->if_carpdev struct ip_moptions sc_imo; #ifdef INET6 - struct in6_ifaddr *sc_ia6; /* primary iface address v6 */ struct ip6_moptions sc_im6o; #endif /* INET6 */ TAILQ_ENTRY(carp_softc) sc_list; @@ -159,7 +157,7 @@ struct carp_if { struct mtx vhif_mtx; }; -/* Get carp_if from softc. Valid after carp_set_addr{,6}. */ +/* Get carp_if from softc. Valid after carp_set_{addr[6],ifp}. */ #define SC2CIF(sc) ((struct carp_if *)(sc)->sc_carpdev->if_carp) /* lock per carp_if queue */ @@ -190,7 +188,7 @@ static void carp_hmac_generate(struct carp_softc *, u_int32_t *, static int carp_hmac_verify(struct carp_softc *, u_int32_t *, unsigned char *); static void carp_setroute(struct carp_softc *, int); -static void carp_input_c(struct mbuf *, struct carp_header *, sa_family_t); +static void carp_proto_input_c(struct mbuf *, struct carp_header *, sa_family_t); static int carp_clone_create(struct if_clone *, int, caddr_t); static void carp_clone_destroy(struct ifnet *); static void carpdetach(struct carp_softc *, int); @@ -203,7 +201,7 @@ static void carp_send_arp(struct carp_softc *); static void carp_master_down(void *); static void carp_master_down_locked(struct carp_softc *); static int carp_ioctl(struct ifnet *, u_long, caddr_t); -static int carp_looutput(struct ifnet *, struct mbuf *, struct sockaddr *, +static int carp_output(struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *); static void carp_start(struct ifnet *); static void carp_setrun(struct carp_softc *, sa_family_t); @@ -212,13 +210,16 @@ static int carp_addrcount(struct carp_if *, struct in_ifaddr *, int); enum { CARP_COUNT_MASTER, CARP_COUNT_RUNNING }; static void carp_multicast_cleanup(struct carp_softc *); +static int carp_set_ifp(struct carp_softc *, struct ifnet *); static int carp_set_addr(struct carp_softc *, struct sockaddr_in *); +static int carp_join_multicast(struct carp_softc *); static int carp_del_addr(struct carp_softc *, struct sockaddr_in *); static void carp_carpdev_state_locked(struct carp_if *); static void carp_sc_state_locked(struct carp_softc *); #ifdef INET6 static void carp_send_na(struct carp_softc *); static int carp_set_addr6(struct carp_softc *, struct sockaddr_in6 *); +static int carp_join_multicast6(struct carp_softc *); static int carp_del_addr6(struct carp_softc *, struct sockaddr_in6 *); static void carp_multicast6_cleanup(struct carp_softc *); #endif @@ -247,9 +248,9 @@ carp_hmac_prepare(struct carp_softc *sc) #endif if (sc->sc_carpdev) - CARP_SCLOCK(sc); + CARP_SCLOCK_ASSERT(sc); - /* XXX: possible race here */ + /* XXX: possible race here - really? */ /* compute ipad from key */ bzero(sc->sc_pad, sizeof(sc->sc_pad)); @@ -285,8 +286,6 @@ carp_hmac_prepare(struct carp_softc *sc) for (i = 0; i < sizeof(sc->sc_pad); i++) sc->sc_pad[i] ^= 0x36 ^ 0x5c; - if (sc->sc_carpdev) - CARP_SCUNLOCK(sc); } static void @@ -334,13 +333,106 @@ carp_setroute(struct carp_softc *sc, int cmd) TAILQ_FOREACH(ifa, &SC2IFP(sc)->if_addrlist, ifa_list) { if (ifa->ifa_addr->sa_family == AF_INET && sc->sc_carpdev != NULL) { - int count = carp_addrcount( - (struct carp_if *)sc->sc_carpdev->if_carp, - ifatoia(ifa), CARP_COUNT_MASTER); + int count = 0, error; + struct sockaddr sa; + struct rtentry *rt; + struct radix_node_head *rnh; + struct radix_node *rn; + struct rt_addrinfo info; + int hr_otherif, nr_ourif; + + /* + * Avoid screwing with the routes if there are other + * carp interfaces which are master and have the same + * address. + */ + if (sc->sc_carpdev != NULL && + sc->sc_carpdev->if_carp != NULL) { + count = carp_addrcount( + (struct carp_if *)sc->sc_carpdev->if_carp, + ifatoia(ifa), CARP_COUNT_MASTER); + if ((cmd == RTM_ADD && count != 1) || + (cmd == RTM_DELETE && count != 0)) + continue; + } - if ((cmd == RTM_ADD && count == 1) || - (cmd == RTM_DELETE && count == 0)) - rtinit(ifa, cmd, RTF_UP | RTF_HOST); + /* Remove the existing host route, if any */ + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = ifa->ifa_addr; + info.rti_flags = RTF_HOST; + error = rtrequest1(RTM_DELETE, &info, NULL); + rt_missmsg(RTM_DELETE, &info, info.rti_flags, error); + + /* Check for our address on another interface */ + /* XXX cries for proper API */ + rnh = rt_tables[ifa->ifa_addr->sa_family]; + RADIX_NODE_HEAD_LOCK(rnh); + rn = rnh->rnh_matchaddr(ifa->ifa_addr, rnh); + rt = (struct rtentry *)rn; + hr_otherif = (rt && rt->rt_ifp != sc->sc_ifp && + rt->rt_flags & (RTF_CLONING|RTF_WASCLONED)); + + /* Check for a network route on our interface */ + bcopy(ifa->ifa_addr, &sa, sizeof(sa)); + satosin(&sa)->sin_addr.s_addr = satosin(ifa->ifa_netmask + )->sin_addr.s_addr & satosin(&sa)->sin_addr.s_addr; + rn = rnh->rnh_lookup(&sa, ifa->ifa_netmask, rnh); + rt = (struct rtentry *)rn; + nr_ourif = (rt && rt->rt_ifp == sc->sc_ifp); + RADIX_NODE_HEAD_UNLOCK(rnh); + + switch (cmd) { + case RTM_ADD: + if (hr_otherif) { + ifa->ifa_rtrequest = NULL; + ifa->ifa_flags &= ~RTF_CLONING; + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = + ifa->ifa_addr; + info.rti_info[RTAX_GATEWAY] = + ifa->ifa_addr; + info.rti_flags = RTF_UP | RTF_HOST; + error = rtrequest1(RTM_ADD, &info, + NULL); + rt_missmsg(RTM_ADD, &info, + info.rti_flags, error); + } + if (!hr_otherif || nr_ourif || !rt) { + if (nr_ourif && !(rt->rt_flags & + RTF_CLONING)) { + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = &sa; + info.rti_info[RTAX_NETMASK] = + ifa->ifa_netmask; + error = rtrequest1(RTM_DELETE, + &info, NULL); + rt_missmsg(RTM_DELETE, &info, + info.rti_flags, error); + } + + ifa->ifa_rtrequest = arp_rtrequest; + ifa->ifa_flags |= RTF_CLONING; + + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = &sa; + info.rti_info[RTAX_GATEWAY] = + ifa->ifa_addr; + info.rti_info[RTAX_NETMASK] = + ifa->ifa_netmask; + error = rtrequest1(RTM_ADD, &info, + NULL); + if (error == 0) + ifa->ifa_flags |= IFA_ROUTE; + rt_missmsg(RTM_ADD, &info, + info.rti_flags, error); + } + break; + case RTM_DELETE: + break; + default: + break; + } + break; } #ifdef INET6 if (ifa->ifa_addr->sa_family == AF_INET6) { @@ -360,6 +452,7 @@ carp_clone_create(struct if_clone *ifc, int unit, caddr_t params) struct carp_softc *sc; struct ifnet *ifp; + static const u_char eaddr[ETHER_ADDR_LEN]; /* 00:00:00:00:00:00 */ MALLOC(sc, struct carp_softc *, sizeof(*sc), M_CARP, M_WAITOK|M_ZERO); ifp = SC2IFP(sc) = if_alloc(IFT_ETHER); @@ -391,16 +484,13 @@ carp_clone_create(struct if_clone *ifc, int unit, caddr_t params) ifp->if_softc = sc; if_initname(ifp, CARP_IFNAME, unit); - ifp->if_mtu = ETHERMTU; - ifp->if_flags = IFF_LOOPBACK; + ether_ifattach(ifp, eaddr); + ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = carp_ioctl; - ifp->if_output = carp_looutput; + ifp->if_output = carp_output; ifp->if_start = carp_start; ifp->if_type = IFT_CARP; ifp->if_snd.ifq_maxlen = ifqmaxlen; - ifp->if_hdrlen = 0; - if_attach(ifp); - bpfattach(SC2IFP(sc), DLT_NULL, sizeof(u_int32_t)); mtx_lock(&carp_mtx); LIST_INSERT_HEAD(&carpif_list, sc, sc_next); mtx_unlock(&carp_mtx); @@ -503,7 +593,7 @@ carp_ifdetach(void *arg __unused, struct ifnet *ifp) * but it seems more efficient this way or not possible otherwise. */ void -carp_input(struct mbuf *m, int hlen) +carp_proto_input(struct mbuf *m, int hlen) { struct ip *ip = mtod(m, struct ip *); struct carp_header *ch; @@ -517,9 +607,9 @@ carp_input(struct mbuf *m, int hlen) } /* check if received on a valid carp interface */ - if (m->m_pkthdr.rcvif->if_carp == NULL) { + if (m->m_pkthdr.rcvif->if_type != IFT_CARP) { carpstats.carps_badif++; - CARP_LOG("carp_input: packet received on non-carp " + CARP_LOG("carp_proto_input: packet received on non-carp " "interface: %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -529,7 +619,7 @@ carp_input(struct mbuf *m, int hlen) /* verify that the IP TTL is 255. */ if (ip->ip_ttl != CARP_DFLTTL) { carpstats.carps_badttl++; - CARP_LOG("carp_input: received ttl %d != 255i on %s\n", + CARP_LOG("carp_proto_input: received ttl %d != 255i on %s\n", ip->ip_ttl, m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -540,7 +630,7 @@ carp_input(struct mbuf *m, int hlen) if (m->m_pkthdr.len < iplen + sizeof(*ch)) { carpstats.carps_badlen++; - CARP_LOG("carp_input: received len %zd < " + CARP_LOG("carp_proto_input: received len %zd < " "sizeof(struct carp_header)\n", m->m_len - sizeof(struct ip)); m_freem(m); @@ -550,7 +640,7 @@ carp_input(struct mbuf *m, int hlen) if (iplen + sizeof(*ch) < m->m_len) { if ((m = m_pullup(m, iplen + sizeof(*ch))) == NULL) { carpstats.carps_hdrops++; - CARP_LOG("carp_input: pullup failed\n"); + CARP_LOG("carp_proto_input: pullup failed\n"); return; } ip = mtod(m, struct ip *); @@ -564,7 +654,7 @@ carp_input(struct mbuf *m, int hlen) len = iplen + sizeof(*ch); if (len > m->m_pkthdr.len) { carpstats.carps_badlen++; - CARP_LOG("carp_input: packet too short %d on %s\n", + CARP_LOG("carp_proto_input: packet too short %d on %s\n", m->m_pkthdr.len, m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -582,19 +672,19 @@ carp_input(struct mbuf *m, int hlen) m->m_data += iplen; if (carp_cksum(m, len - iplen)) { carpstats.carps_badsum++; - CARP_LOG("carp_input: checksum failed on %s\n", + CARP_LOG("carp_proto_input: checksum failed on %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); return; } m->m_data -= iplen; - carp_input_c(m, ch, AF_INET); + carp_proto_input_c(m, ch, AF_INET); } #ifdef INET6 int -carp6_input(struct mbuf **mp, int *offp, int proto) +carp6_proto_input(struct mbuf **mp, int *offp, int proto) { struct mbuf *m = *mp; struct ip6_hdr *ip6 = mtod(m, struct ip6_hdr *); @@ -609,9 +699,9 @@ carp6_input(struct mbuf **mp, int *offp, int proto) } /* check if received on a valid carp interface */ - if (m->m_pkthdr.rcvif->if_carp == NULL) { + if (m->m_pkthdr.rcvif->if_type != IFT_CARP) { carpstats.carps_badif++; - CARP_LOG("carp6_input: packet received on non-carp " + CARP_LOG("carp6_proto_input: packet received on non-carp " "interface: %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -621,7 +711,7 @@ carp6_input(struct mbuf **mp, int *offp, int proto) /* verify that the IP TTL is 255 */ if (ip6->ip6_hlim != CARP_DFLTTL) { carpstats.carps_badttl++; - CARP_LOG("carp6_input: received ttl %d != 255 on %s\n", + CARP_LOG("carp6_proto_input: received ttl %d != 255 on %s\n", ip6->ip6_hlim, m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -633,7 +723,7 @@ carp6_input(struct mbuf **mp, int *offp, int proto) IP6_EXTHDR_GET(ch, struct carp_header *, m, *offp, sizeof(*ch)); if (ch == NULL) { carpstats.carps_badlen++; - CARP_LOG("carp6_input: packet size %u too small\n", len); + CARP_LOG("carp6_proto_input: packet size %u too small\n", len); return (IPPROTO_DONE); } @@ -642,22 +732,22 @@ carp6_input(struct mbuf **mp, int *offp, int proto) m->m_data += *offp; if (carp_cksum(m, sizeof(*ch))) { carpstats.carps_badsum++; - CARP_LOG("carp6_input: checksum failed, on %s\n", + CARP_LOG("carp6_proto_input: checksum failed, on %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); return (IPPROTO_DONE); } m->m_data -= *offp; - carp_input_c(m, ch, AF_INET6); + carp_proto_input_c(m, ch, AF_INET6); return (IPPROTO_DONE); } #endif /* INET6 */ static void -carp_input_c(struct mbuf *m, struct carp_header *ch, sa_family_t af) +carp_proto_input_c(struct mbuf *m, struct carp_header *ch, sa_family_t af) { - struct ifnet *ifp = m->m_pkthdr.rcvif; + struct ifnet *ifp = m->m_pkthdr.rcvif->if_carpdev; struct carp_softc *sc; u_int64_t tmp_counter; struct timeval sc_tv, ch_tv; @@ -793,9 +883,6 @@ carp_input_c(struct mbuf *m, struct carp_header *ch, sa_family_t af) static int carp_prepare_ad(struct mbuf *m, struct carp_softc *sc, struct carp_header *ch) { - struct m_tag *mtag; - struct ifnet *ifp = SC2IFP(sc); - if (sc->sc_init_counter) { /* this could also be seconds since unix epoch */ sc->sc_counter = arc4random(); @@ -809,16 +896,6 @@ carp_prepare_ad(struct mbuf *m, struct carp_softc *sc, struct carp_header *ch) carp_hmac_generate(sc, ch->carp_counter, ch->carp_md); - /* Tag packet for carp_output */ - mtag = m_tag_get(PACKET_TAG_CARP, sizeof(struct ifnet *), M_NOWAIT); - if (mtag == NULL) { - m_freem(m); - SC2IFP(sc)->if_oerrors++; - return (ENOMEM); - } - bcopy(&ifp, (caddr_t)(mtag + 1), sizeof(struct ifnet *)); - m_tag_prepend(m, mtag); - return (0); } @@ -859,6 +936,8 @@ carp_send_ad_locked(struct carp_softc *sc) struct carp_header *ch_ptr; struct mbuf *m; int len, advbase, advskew; + struct ifaddr *ifa; + struct sockaddr sa; CARP_SCLOCK_ASSERT(sc); @@ -887,7 +966,7 @@ carp_send_ad_locked(struct carp_softc *sc) ch.carp_cksum = 0; #ifdef INET - if (sc->sc_ia) { + if (sc->sc_naddrs) { struct ip *ip; MGETHDR(m, M_DONTWAIT, MT_HEADER); @@ -916,7 +995,15 @@ carp_send_ad_locked(struct carp_softc *sc) ip->ip_ttl = CARP_DFLTTL; ip->ip_p = IPPROTO_CARP; ip->ip_sum = 0; - ip->ip_src.s_addr = sc->sc_ia->ia_addr.sin_addr.s_addr; + + bzero(&sa, sizeof(sa)); + sa.sa_family = AF_INET; + ifa = ifaof_ifpforaddr(&sa, SC2IFP(sc)); + if (ifa == NULL) + ip->ip_src.s_addr = 0; + else + ip->ip_src.s_addr = + ifatoia(ifa)->ia_addr.sin_addr.s_addr; ip->ip_dst.s_addr = htonl(INADDR_CARP_GROUP); ch_ptr = (struct carp_header *)(&ip[1]); @@ -959,7 +1046,7 @@ carp_send_ad_locked(struct carp_softc *sc) } #endif /* INET */ #ifdef INET6 - if (sc->sc_ia6) { + if (sc->sc_naddrs6) { struct ip6_hdr *ip6; MGETHDR(m, M_DONTWAIT, MT_HEADER); @@ -983,8 +1070,15 @@ carp_send_ad_locked(struct carp_softc *sc) ip6->ip6_vfc |= IPV6_VERSION; ip6->ip6_hlim = CARP_DFLTTL; ip6->ip6_nxt = IPPROTO_CARP; - bcopy(&sc->sc_ia6->ia_addr.sin6_addr, &ip6->ip6_src, - sizeof(struct in6_addr)); + + bzero(&sa, sizeof(sa)); + sa.sa_family = AF_INET6; + ifa = ifaof_ifpforaddr(&sa, SC2IFP(sc)); + if (ifa == NULL) + bzero(&ip6->ip6_src, sizeof(struct in6_addr)); + else + bcopy(ifatoia6(ifa)->ia_addr.sin6_addr.s6_addr, + &ip6->ip6_src, sizeof(struct in6_addr)); /* set the multicast destination */ ip6->ip6_dst.s6_addr16[0] = htons(0xff02); @@ -1058,7 +1152,7 @@ carp_send_arp(struct carp_softc *sc) continue; /* arprequest(sc->sc_carpdev, &in, &in, IF_LLADDR(sc->sc_ifp)); */ - arp_ifinit2(sc->sc_carpdev, ifa, IF_LLADDR(sc->sc_ifp)); + arp_ifinit2(SC2IFP(sc), ifa, IF_LLADDR(sc->sc_ifp)); DELAY(1000); /* XXX */ } @@ -1211,7 +1305,6 @@ carp_iamatch6(void *v, struct in6_addr *taddr) void * carp_macmatch6(void *v, struct mbuf *m, const struct in6_addr *taddr) { - struct m_tag *mtag; struct carp_if *cif = v; struct carp_softc *sc; struct ifaddr *ifa; @@ -1223,18 +1316,6 @@ carp_macmatch6(void *v, struct mbuf *m, const struct in6_addr *taddr) &ifatoia6(ifa)->ia_addr.sin6_addr) && (SC2IFP(sc)->if_flags & IFF_UP) && (SC2IFP(sc)->if_drv_flags & IFF_DRV_RUNNING)) { - struct ifnet *ifp = SC2IFP(sc); - mtag = m_tag_get(PACKET_TAG_CARP, - sizeof(struct ifnet *), M_NOWAIT); - if (mtag == NULL) { - /* better a bit than nothing */ - CARP_UNLOCK(cif); - return (IF_LLADDR(sc->sc_ifp)); - } - bcopy(&ifp, (caddr_t)(mtag + 1), - sizeof(struct ifnet *)); - m_tag_prepend(m, mtag); - CARP_UNLOCK(cif); return (IF_LLADDR(sc->sc_ifp)); } @@ -1423,15 +1504,116 @@ carp_multicast6_cleanup(struct carp_softc *sc) #endif static int +carp_set_ifp(struct carp_softc *sc, struct ifnet *ifp) +{ + struct carp_if *cif = NULL, *ncif = NULL; + struct carp_softc *vr, *after = NULL; + int myself = 0, error = 0; + + if (ifp == sc->sc_carpdev) + return (0); + + if (ifp != NULL) { + if ((ifp->if_flags & IFF_MULTICAST) == 0) + return (ENODEV); + if (ifp->if_type == IFT_CARP) + return (EINVAL); + + if (ifp->if_carp == NULL) { + MALLOC(ncif, struct carp_if *, sizeof(*ncif), M_CARP, + M_WAITOK|M_ZERO); + if (!ncif) + return (ENOBUFS); + if ((error = ifpromisc(ifp, 1))) { + FREE(ncif, M_CARP); + return (error); + } + } else { + cif = (struct carp_if *)ifp->if_carp; + CARP_LOCK(cif); + TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) + if (vr != sc && vr->sc_vhid == sc->sc_vhid) { + CARP_UNLOCK(cif); + return (EINVAL); + } + } + + /* detach from old interface */ + if (sc->sc_carpdev != NULL) { + CARP_SCLOCK(sc); + carpdetach(sc, 1); + } + + if (sc->sc_naddrs != 0 && + (error = carp_join_multicast(sc)) != 0) + goto cleanup; +#ifdef INET6 + if (sc->sc_naddrs6 != 0 && + (error = carp_join_multicast6(sc)) != 0) { + carp_multicast_cleanup(sc); + goto cleanup; + } +#endif + + /* attach carp glue to physical interface */ + if (ncif != NULL) { + CARP_LOCK_INIT(ncif); + CARP_LOCK(ncif); + ncif->vhif_ifp = ifp; + TAILQ_INIT(&ncif->vhif_vrs); + TAILQ_INSERT_HEAD(&ncif->vhif_vrs, sc, sc_list); + ncif->vhif_nvrs++; + ifp->if_carp = ncif; + CARP_UNLOCK(ncif); + } else { + cif = (struct carp_if *)ifp->if_carp; + TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) { + if (vr == sc) + myself = 1; + if (vr->sc_vhid < sc->sc_vhid) + after = vr; + } + if (!myself) { + if (after == NULL) { + TAILQ_INSERT_TAIL(&cif->vhif_vrs, sc, + sc_list); + } else { + TAILQ_INSERT_AFTER(&cif->vhif_vrs, + after, sc, sc_list); + } + cif->vhif_nvrs++; + } + CARP_UNLOCK(cif); + } + + sc->sc_carpdev = ifp; + if (sc->sc_naddrs || sc->sc_naddrs6) + sc->sc_ifp->if_flags |= IFF_UP; + carp_carpdev_state(ifp); + } else { + CARP_SCLOCK(sc); + carpdetach(sc, 1); + SC2IFP(sc)->if_flags &= ~IFF_UP; + SC2IFP(sc)->if_drv_flags &= ~IFF_DRV_RUNNING; + } + + return (0); +cleanup: + if (ncif) + FREE(ncif, M_CARP); + else + CARP_UNLOCK(cif); + + return (error); +} + +static int carp_set_addr(struct carp_softc *sc, struct sockaddr_in *sin) { - struct ifnet *ifp; - struct carp_if *cif; + struct ifnet *ifp = sc->sc_carpdev; struct in_ifaddr *ia, *ia_if; - struct ip_moptions *imo = &sc->sc_imo; - struct in_addr addr; u_long iaddr = htonl(sin->sin_addr.s_addr); - int own, error; + int error; if (sin->sin_addr.s_addr == 0) { if (!(SC2IFP(sc)->if_flags & IFF_UP)) @@ -1443,7 +1625,7 @@ carp_set_addr(struct carp_softc *sc, struct sockaddr_in *sin) } /* we have to do it by hands to check we won't match on us */ - ia_if = NULL; own = 0; + ia_if = NULL; TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { /* and, yeah, we need a multicast-capable iface too */ if (ia->ia_ifp != SC2IFP(sc) && @@ -1451,106 +1633,65 @@ carp_set_addr(struct carp_softc *sc, struct sockaddr_in *sin) (iaddr & ia->ia_subnetmask) == ia->ia_subnet) { if (!ia_if) ia_if = ia; - if (sin->sin_addr.s_addr == - ia->ia_addr.sin_addr.s_addr) - own++; } } - if (!ia_if) - return (EADDRNOTAVAIL); - - ia = ia_if; - ifp = ia->ia_ifp; - - if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0 || - (imo->imo_multicast_ifp && imo->imo_multicast_ifp != ifp)) - return (EADDRNOTAVAIL); - - if (imo->imo_num_memberships == 0) { - addr.s_addr = htonl(INADDR_CARP_GROUP); - if ((imo->imo_membership[0] = in_addmulti(&addr, ifp)) == NULL) - return (ENOBUFS); - imo->imo_num_memberships++; - imo->imo_multicast_ifp = ifp; - imo->imo_multicast_ttl = CARP_DFLTTL; - imo->imo_multicast_loop = 0; - } - - if (!ifp->if_carp) { - - MALLOC(cif, struct carp_if *, sizeof(*cif), M_CARP, - M_WAITOK|M_ZERO); - if (!cif) { - error = ENOBUFS; - goto cleanup; - } - if ((error = ifpromisc(ifp, 1))) { - FREE(cif, M_CARP); - goto cleanup; + if (ia_if) { + ia = ia_if; + if (ifp) { + if (ifp != ia->ia_ifp) + return (EADDRNOTAVAIL); + } else { + ifp = ia->ia_ifp; } - - CARP_LOCK_INIT(cif); - CARP_LOCK(cif); - cif->vhif_ifp = ifp; - TAILQ_INIT(&cif->vhif_vrs); - ifp->if_carp = cif; - - } else { - struct carp_softc *vr; - - cif = (struct carp_if *)ifp->if_carp; - CARP_LOCK(cif); - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) - if (vr != sc && vr->sc_vhid == sc->sc_vhid) { - CARP_UNLOCK(cif); - error = EINVAL; - goto cleanup; - } } - sc->sc_ia = ia; - sc->sc_carpdev = ifp; - { /* XXX prevent endless loop if already in queue */ - struct carp_softc *vr, *after = NULL; - int myself = 0; - cif = (struct carp_if *)ifp->if_carp; + if ((error = carp_set_ifp(sc, ifp))) + return (error); - /* XXX: cif should not change, right? So we still hold the lock */ - CARP_LOCK_ASSERT(cif); - - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) { - if (vr == sc) - myself = 1; - if (vr->sc_vhid < sc->sc_vhid) - after = vr; - } + if (sc->sc_carpdev == NULL) + return (EADDRNOTAVAIL); - if (!myself) { - /* We're trying to keep things in order */ - if (after == NULL) { - TAILQ_INSERT_TAIL(&cif->vhif_vrs, sc, sc_list); - } else { - TAILQ_INSERT_AFTER(&cif->vhif_vrs, after, sc, sc_list); - } - cif->vhif_nvrs++; - } + CARP_SCLOCK(sc); + if (sc->sc_naddrs == 0 && (error = carp_join_multicast(sc)) != 0) { + CARP_SCUNLOCK(sc); + return (error); } sc->sc_naddrs++; SC2IFP(sc)->if_flags |= IFF_UP; - if (own) - sc->sc_advskew = 0; carp_sc_state_locked(sc); carp_setrun(sc, 0); - - CARP_UNLOCK(cif); + CARP_SCUNLOCK(sc); return (0); -cleanup: - in_delmulti(imo->imo_membership[--imo->imo_num_memberships]); - return (error); +/* + * XXX: cleanup multi? + * cleanup: + * return (error); + */ +} + +static int +carp_join_multicast(struct carp_softc *sc) +{ + struct ip_moptions *imo = &sc->sc_imo; + struct in_addr addr; + + KASSERT(imo->imo_num_memberships == 0, + ("carp_join_multicast: leftover multicast memberships")); + + addr.s_addr = htonl(INADDR_CARP_GROUP); + if ((imo->imo_membership[0] = + in_addmulti(&addr, SC2IFP(sc))) == NULL) + return (ENOBUFS); + imo->imo_num_memberships++; + imo->imo_multicast_ifp = SC2IFP(sc); + imo->imo_multicast_ttl = CARP_DFLTTL; + imo->imo_multicast_loop = 0; + + return (0); } static int @@ -1587,12 +1728,8 @@ static int carp_set_addr6(struct carp_softc *sc, struct sockaddr_in6 *sin6) { struct ifnet *ifp; - struct carp_if *cif; struct in6_ifaddr *ia, *ia_if; - struct ip6_moptions *im6o = &sc->sc_im6o; - struct in6_multi_mship *imm; - struct in6_addr in6; - int own, error; + int own; if (IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr)) { if (!(SC2IFP(sc)->if_flags & IFF_UP)) @@ -1633,93 +1770,12 @@ carp_set_addr6(struct carp_softc *sc, struct sockaddr_in6 *sin6) ifp = ia->ia_ifp; if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0 || - (im6o->im6o_multicast_ifp && im6o->im6o_multicast_ifp != ifp)) + (sc->sc_im6o.im6o_multicast_ifp && + sc->sc_im6o.im6o_multicast_ifp != ifp)) return (EADDRNOTAVAIL); - if (!sc->sc_naddrs6) { - im6o->im6o_multicast_ifp = ifp; - - /* join CARP multicast address */ - bzero(&in6, sizeof(in6)); - in6.s6_addr16[0] = htons(0xff02); - in6.s6_addr8[15] = 0x12; - if (in6_setscope(&in6, ifp, NULL) != 0) - goto cleanup; - if ((imm = in6_joingroup(ifp, &in6, &error, 0)) == NULL) - goto cleanup; - LIST_INSERT_HEAD(&im6o->im6o_memberships, imm, i6mm_chain); - - /* join solicited multicast address */ - bzero(&in6, sizeof(in6)); - in6.s6_addr16[0] = htons(0xff02); - in6.s6_addr32[1] = 0; - in6.s6_addr32[2] = htonl(1); - in6.s6_addr32[3] = sin6->sin6_addr.s6_addr32[3]; - in6.s6_addr8[12] = 0xff; - if (in6_setscope(&in6, ifp, NULL) != 0) - goto cleanup; - if ((imm = in6_joingroup(ifp, &in6, &error, 0)) == NULL) - goto cleanup; - LIST_INSERT_HEAD(&im6o->im6o_memberships, imm, i6mm_chain); - } - - if (!ifp->if_carp) { - MALLOC(cif, struct carp_if *, sizeof(*cif), M_CARP, - M_WAITOK|M_ZERO); - if (!cif) { - error = ENOBUFS; - goto cleanup; - } - if ((error = ifpromisc(ifp, 1))) { - FREE(cif, M_CARP); - goto cleanup; - } - - CARP_LOCK_INIT(cif); - CARP_LOCK(cif); - cif->vhif_ifp = ifp; - TAILQ_INIT(&cif->vhif_vrs); - ifp->if_carp = cif; - - } else { - struct carp_softc *vr; - - cif = (struct carp_if *)ifp->if_carp; - CARP_LOCK(cif); - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) - if (vr != sc && vr->sc_vhid == sc->sc_vhid) { - CARP_UNLOCK(cif); - error = EINVAL; - goto cleanup; - } - } - sc->sc_ia6 = ia; sc->sc_carpdev = ifp; - { /* XXX prevent endless loop if already in queue */ - struct carp_softc *vr, *after = NULL; - int myself = 0; - cif = (struct carp_if *)ifp->if_carp; - CARP_LOCK_ASSERT(cif); - - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) { - if (vr == sc) - myself = 1; - if (vr->sc_vhid < sc->sc_vhid) - after = vr; - } - - if (!myself) { - /* We're trying to keep things in order */ - if (after == NULL) { - TAILQ_INSERT_TAIL(&cif->vhif_vrs, sc, sc_list); - } else { - TAILQ_INSERT_AFTER(&cif->vhif_vrs, after, sc, sc_list); - } - cif->vhif_nvrs++; - } - } - sc->sc_naddrs6++; SC2IFP(sc)->if_flags |= IFF_UP; if (own) @@ -1727,20 +1783,61 @@ carp_set_addr6(struct carp_softc *sc, struct sockaddr_in6 *sin6) carp_sc_state_locked(sc); carp_setrun(sc, 0); - CARP_UNLOCK(cif); - return (0); -cleanup: - /* clean up multicast memberships */ - if (!sc->sc_naddrs6) { - while (!LIST_EMPTY(&im6o->im6o_memberships)) { - imm = LIST_FIRST(&im6o->im6o_memberships); - LIST_REMOVE(imm, i6mm_chain); - in6_leavegroup(imm); - } +/* XXX: + * cleanup: + * * clean up multicast memberships * + * if (!sc->sc_naddrs6) { + * while (!LIST_EMPTY(&im6o->im6o_memberships)) { + * imm = LIST_FIRST(&im6o->im6o_memberships); + * LIST_REMOVE(imm, i6mm_chain); + * in6_leavegroup(imm); + * } + * } + * return (error); + */ +} + +static int +carp_join_multicast6(struct carp_softc *sc) +{ + struct ip6_moptions *im6o = &sc->sc_im6o; + struct in6_multi_mship *imm, *imm2; + struct in6_addr in6; + int error = 0; + + /* join CARP multicast address */ + bzero(&in6, sizeof(in6)); + in6.s6_addr16[0] = htons(0xff02); + in6.s6_addr8[15] = 0x12; + if ((error = in6_setscope(&in6, sc->sc_carpdev, NULL)) != 0) + return (error); + if ((imm = in6_joingroup(sc->sc_carpdev, &in6, &error, 0)) == NULL) + return (error); + + /* join solicited multicast address */ + bzero(&in6, sizeof(in6)); + in6.s6_addr16[0] = htons(0xff02); + in6.s6_addr32[1] = 0; + in6.s6_addr32[2] = htonl(1); + in6.s6_addr32[3] = 0; /* XXX: sin6->sin6_addr.s6_addr32[3]; */ + in6.s6_addr8[12] = 0xff; + if ((error = in6_setscope(&in6, sc->sc_carpdev, NULL)) != 0) { + in6_leavegroup(imm); + return (error); } - return (error); + if ((imm2 = in6_joingroup(sc->sc_carpdev, &in6, &error, 0)) == NULL) { + in6_leavegroup(imm); + return (error); + } + + im6o->im6o_multicast_ifp = sc->sc_carpdev; + + LIST_INSERT_HEAD(&im6o->im6o_memberships, imm, i6mm_chain); + LIST_INSERT_HEAD(&im6o->im6o_memberships, imm2, i6mm_chain); + + return (0); } static int @@ -1786,7 +1883,8 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) struct ifaddr *ifa; struct ifreq *ifr; struct ifaliasreq *ifra; - int locked = 0, error = 0; + struct ifnet *cdev = NULL; + int locked = 0, error = 0, changed = 0; ifa = (struct ifaddr *)addr; ifra = (struct ifaliasreq *)addr; @@ -1794,12 +1892,12 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) switch (cmd) { case SIOCSIFADDR: + case SIOCAIFADDR: + changed++; switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: SC2IFP(sc)->if_flags |= IFF_UP; - bcopy(ifa->ifa_addr, ifa->ifa_dstaddr, - sizeof(struct sockaddr)); error = carp_set_addr(sc, satosin(ifa->ifa_addr)); break; #endif /* INET */ @@ -1815,29 +1913,8 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) } break; - case SIOCAIFADDR: - switch (ifa->ifa_addr->sa_family) { -#ifdef INET - case AF_INET: - SC2IFP(sc)->if_flags |= IFF_UP; - bcopy(ifa->ifa_addr, ifa->ifa_dstaddr, - sizeof(struct sockaddr)); - error = carp_set_addr(sc, satosin(&ifra->ifra_addr)); - break; -#endif /* INET */ -#ifdef INET6 - case AF_INET6: - SC2IFP(sc)->if_flags |= IFF_UP; - error = carp_set_addr6(sc, satosin6(&ifra->ifra_addr)); - break; -#endif /* INET6 */ - default: - error = EAFNOSUPPORT; - break; - } - break; - case SIOCDIFADDR: + changed++; switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: @@ -1881,6 +1958,14 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) if ((error = copyin(ifr->ifr_data, &carpr, sizeof carpr))) break; error = 1; + changed++; + if (carpr.carpr_carpdev[0] != '\0' && + (cdev = ifunit(carpr.carpr_carpdev)) == NULL) { + error = EINVAL; + break; + } + if ((error = carp_set_ifp(sc, cdev))) + break; if (sc->sc_carpdev) { locked = 1; CARP_SCLOCK(sc); @@ -1959,64 +2044,37 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) if (error == 0) bcopy(sc->sc_key, carpr.carpr_key, sizeof(carpr.carpr_key)); + if (sc->sc_carpdev != NULL) + strlcpy(carpr.carpr_carpdev, sc->sc_carpdev->if_xname, + CARPDEVNAMSIZ); error = copyout(&carpr, ifr->ifr_data, sizeof(carpr)); break; + case SIOCADDMULTI: + case SIOCDELMULTI: + /* TODO: tell carpdev */ + break; + default: error = EINVAL; } + if (changed) { + if (!locked && sc->sc_carpdev) { + /* XXX: This really shouldn't happen */ + CARP_SCLOCK(sc); + locked = 1; + } + carp_hmac_prepare(sc); + } + if (locked) CARP_SCUNLOCK(sc); - carp_hmac_prepare(sc); - return (error); } /* - * XXX: this is looutput. We should eventually use it from there. - */ -static int -carp_looutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, - struct rtentry *rt) -{ - u_int32_t af; - - M_ASSERTPKTHDR(m); /* check if we have the packet header */ - - if (rt && rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE)) { - m_freem(m); - return (rt->rt_flags & RTF_BLACKHOLE ? 0 : - rt->rt_flags & RTF_HOST ? EHOSTUNREACH : ENETUNREACH); - } - - ifp->if_opackets++; - ifp->if_obytes += m->m_pkthdr.len; - - /* BPF writes need to be handled specially. */ - if (dst->sa_family == AF_UNSPEC) { - bcopy(dst->sa_data, &af, sizeof(af)); - dst->sa_family = af; - } - -#if 1 /* XXX */ - switch (dst->sa_family) { - case AF_INET: - case AF_INET6: - case AF_IPX: - case AF_APPLETALK: - break; - default: - printf("carp_looutput: af=%d unexpected\n", dst->sa_family); - m_freem(m); - return (EAFNOSUPPORT); - } -#endif - return(if_simloop(ifp, m, dst->sa_family, 0)); -} - -/* * Start output on carp interface. This function should never be called. */ static void @@ -2027,81 +2085,84 @@ carp_start(struct ifnet *ifp) #endif } -int +static int carp_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *sa, struct rtentry *rt) { - struct m_tag *mtag; - struct carp_softc *sc; - struct ifnet *carp_ifp; + struct carp_softc *sc = ifp->if_softc; - if (!sa) - return (0); + if (sc->sc_carpdev != NULL && sc->sc_state == MASTER) + return (sc->sc_carpdev->if_output(ifp, m, sa, rt)); + else { + m_freem(m); + return (ENETUNREACH); + } +} - switch (sa->sa_family) { -#ifdef INET - case AF_INET: - break; -#endif /* INET */ -#ifdef INET6 - case AF_INET6: - break; -#endif /* INET6 */ - default: - return (0); +struct ifnet * +carp_ourether(void *v, struct ether_header *eh, u_char iftype, int src) +{ + struct carp_if *cif = (struct carp_if *)v; + struct carp_softc *vh; + u_int8_t *ena; + + if (src) + ena = (u_int8_t *)&eh->ether_shost; + else + ena = (u_int8_t *)&eh->ether_dhost; + + TAILQ_FOREACH(vh, &cif->vhif_vrs, sc_list) { + if ((vh->sc_ifp->if_flags & (IFF_UP)) != (IFF_UP)) + continue; + if ((vh->sc_state == MASTER /* || vh->sc_ifp->if_flags & IFF_LINK0 */) + && !bcmp(ena, IF_LLADDR(vh->sc_ifp), ETHER_ADDR_LEN)) + return (vh->sc_ifp); } + return (NULL); +} - mtag = m_tag_find(m, PACKET_TAG_CARP, NULL); - if (mtag == NULL) - return (0); +int +carp_input(struct mbuf *m) +{ + struct ether_header *eh; + struct carp_if *cif = (struct carp_if *)m->m_pkthdr.rcvif->if_carp; + struct ifnet *ifp; - bcopy(mtag + 1, &carp_ifp, sizeof(struct ifnet *)); - sc = carp_ifp->if_softc; - - /* Set the source MAC address to Virtual Router MAC Address */ - switch (ifp->if_type) { - case IFT_ETHER: - case IFT_L2VLAN: { - struct ether_header *eh; - - eh = mtod(m, struct ether_header *); - eh->ether_shost[0] = 0; - eh->ether_shost[1] = 0; - eh->ether_shost[2] = 0x5e; - eh->ether_shost[3] = 0; - eh->ether_shost[4] = 1; - eh->ether_shost[5] = sc->sc_vhid; - } - break; - case IFT_FDDI: { - struct fddi_header *fh; - - fh = mtod(m, struct fddi_header *); - fh->fddi_shost[0] = 0; - fh->fddi_shost[1] = 0; - fh->fddi_shost[2] = 0x5e; - fh->fddi_shost[3] = 0; - fh->fddi_shost[4] = 1; - fh->fddi_shost[5] = sc->sc_vhid; - } - break; - case IFT_ISO88025: { - struct iso88025_header *th; - th = mtod(m, struct iso88025_header *); - th->iso88025_shost[0] = 3; - th->iso88025_shost[1] = 0; - th->iso88025_shost[2] = 0x40 >> (sc->sc_vhid - 1); - th->iso88025_shost[3] = 0x40000 >> (sc->sc_vhid - 1); - th->iso88025_shost[4] = 0; - th->iso88025_shost[5] = 0; + eh = mtod(m, struct ether_header *); + + if ((ifp = carp_ourether(cif, eh, m->m_pkthdr.rcvif->if_type, 0))) + ; + else if (m->m_flags & (M_BCAST|M_MCAST)) { + struct carp_softc *vh; + struct mbuf *m0; + + /* + * XXX Should really check the list of multicast addresses + * for each CARP interface _before_ copying. + */ + TAILQ_FOREACH(vh, &cif->vhif_vrs, sc_list) { + m0 = m_dup(m, M_DONTWAIT); + if (m0 == NULL) + continue; + m0->m_pkthdr.rcvif = vh->sc_ifp; + ether_input(vh->sc_ifp, m0); } - break; - default: - printf("%s: carp is not supported for this interface type\n", - ifp->if_xname); - return (EOPNOTSUPP); + return (1); } + if (ifp == NULL) + return (1); + + m->m_pkthdr.rcvif = ifp; + +#if 0 /* XXX: BPF */ + if (ifp->if_bpf) + bpf_mtap_hdr(ifp->if_bpf, (char *)&eh, ETHER_HDR_LEN, m, + BPF_DIRECTION_IN); +#endif + ifp->if_ipackets++; + ether_input(ifp, m); + return (0); } @@ -2131,9 +2192,14 @@ carp_set_state(struct carp_softc *sc, int state) } void -carp_carpdev_state(void *v) +carp_carpdev_state(struct ifnet *ifp) { - struct carp_if *cif = v; + struct carp_if *cif; + + if (ifp->if_type == IFT_CARP || ifp->if_carp == NULL) + return; + + cif = ifp->if_carp; CARP_LOCK(cif); carp_carpdev_state_locked(cif); diff --git a/sys/netinet/ip_carp.h b/sys/netinet/ip_carp.h index 1688b01..3525ab9 100644 --- a/sys/netinet/ip_carp.h +++ b/sys/netinet/ip_carp.h @@ -117,6 +117,13 @@ struct carpstats { uint64_t carps_preempt; /* if enabled, preemptions */ }; +#define CARPDEVNAMSIZ 16 +#ifdef IFNAMSIZ +#if CARPDEVNAMSIZ != IFNAMSIZ +#error +#endif +#endif + /* * Configuration structure for SIOCSVH SIOCGVH */ @@ -128,6 +135,7 @@ struct carpreq { int carpr_advskew; int carpr_advbase; unsigned char carpr_key[CARP_KEY_LEN]; + char carpr_carpdev[CARPDEVNAMSIZ]; }; #define SIOCSVH _IOWR('i', 245, struct ifreq) #define SIOCGVH _IOWR('i', 246, struct ifreq) @@ -152,15 +160,15 @@ struct carpreq { } #ifdef _KERNEL -void carp_carpdev_state(void *); -void carp_input (struct mbuf *, int); -int carp6_input (struct mbuf **, int *, int); -int carp_output (struct ifnet *, struct mbuf *, struct sockaddr *, - struct rtentry *); -int carp_iamatch (void *, struct in_ifaddr *, struct in_addr *, +void carp_carpdev_state(struct ifnet *); +void carp_proto_input(struct mbuf *, int); +int carp6_proto_input(struct mbuf **, int *, int); +int carp_iamatch(void *, struct in_ifaddr *, struct in_addr *, u_int8_t **); struct ifaddr *carp_iamatch6(void *, struct in6_addr *); void *carp_macmatch6(void *, struct mbuf *, const struct in6_addr *); -struct ifnet *carp_forus (void *, void *); +struct ifnet *carp_forus(void *, void *); +struct ifnet *carp_ourether(void *, struct ether_header *, u_char, int); +int carp_input(struct mbuf *); #endif #endif /* _IP_CARP_H */ diff --git a/sys/netinet6/in6_proto.c b/sys/netinet6/in6_proto.c index 2230741..fbd022d 100644 --- a/sys/netinet6/in6_proto.c +++ b/sys/netinet6/in6_proto.c @@ -319,7 +319,7 @@ struct ip6protosw inet6sw[] = { .pr_domain = &inet6domain, .pr_protocol = IPPROTO_CARP, .pr_flags = PR_ATOMIC|PR_ADDR, - .pr_input = carp6_input, + .pr_input = carp6_proto_input, .pr_output = rip6_output, .pr_ctloutput = rip6_ctloutput, .pr_usrreqs = &rip6_usrreqs --Boundary-00=_0fCRIvDhAIxj+va-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 17:06:03 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91395106568B for ; Mon, 2 Jun 2008 17:06:03 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 483AC8FC18 for ; Mon, 2 Jun 2008 17:06:03 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by an-out-0708.google.com with SMTP id b33so856478ana.13 for ; Mon, 02 Jun 2008 10:06:02 -0700 (PDT) Received: by 10.100.208.6 with SMTP id f6mr1296435ang.21.1212426357997; Mon, 02 Jun 2008 10:05:57 -0700 (PDT) Received: by 10.100.216.6 with HTTP; Mon, 2 Jun 2008 10:05:57 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2008 14:05:57 -0300 From: "Victor Hugo Bilouro" To: "Andre Oppermann" In-Reply-To: <4843D926.8010402@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> <4843A615.90809@freebsd.org> <4843D926.8010402@freebsd.org> Cc: net@freebsd.org Subject: Re: establish connection without tcp options X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:06:03 -0000 Hi, On Mon, Jun 2, 2008 at 8:27 AM, Andre Oppermann wrote: > Victor Hugo Bilouro wrote: >> >> On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann >>>> wrote: >>>>> >>>>> Victor Hugo Bilouro wrote: >>>>>> >>>>>> syn--------------------------------- >>>>>> sport 59966 >>>>>> dport 22022 >>>>>> sequence 874312230 >>>>>> ack_number 0 >>>>>> offset 5 >>>>>> reserved 0 >>>>>> urgent 0 >>>>>> ack 0 >>>>>> push 0 >>>>>> reset 0 >>>>>> syn 1 >>>>>> fin 0 >>>>>> window 65535 >>>>>> checksum 50667 >>>>>> urg_pointer 0 >>>>>> >>>>>> --------------------------------- >>>>>> >>>>>> syn+ack----------------------------- >>>>>> sport 22022 >>>>>> dport 59966 >>>>>> sequence 2755934977 >>>>>> ack_number 874312231 >>>>>> offset 6 >>>>>> reserved 0 >>>>>> urgent 0 >>>>>> ack 1 >>>>>> push 2 >>>>>> reset 4 >>>>>> syn 9 >>>>>> fin 0 >>>>>> window 65535 >>>>>> checksum 52952 >>>>>> urg_pointer 0 >>>>>> >>>>>> --------------------------------- >>>>>> >>>>>> ack--------------------------------- >>>>>> sport 59966 >>>>>> dport 22022 >>>>>> sequence 874312230 >>>>> >>>>> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >>>>> See also the ACK you got back above. >>>>> >>>>>> ack_number 2755934978 >>>>>> offset 5 >>>>>> reserved 0 >>>>>> urgent 0 >>>>>> ack 1 >>>>>> push 0 >>>>>> reset 0 >>>>>> syn 0 >>>>>> fin 0 >>>>>> window 65535 >>>>>> checksum 59030 >>>>>> urg_pointer 0 >>>>>> --------------------------------- >>>>>> >>>>>> ...and the log showed: >>>>>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>>>>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>>>>> >>>>>> I'm still working... >>>>> >>>>> You should familiarize yourself some more with the sequence number >>>>> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >>>>> are very good for that. >>>>> >>>>> -- >>>>> Andre >>>>> >>>> PS.: I forgot to copy the list in the previous email exchanging, so >>>> I'm doing now.... >>>> >>>> >>>> Andre, thank you SO VERY MUCH. It's working fine! >>>> >>>> As every book show tcpdump examples of connection establishment , and >>>> when the SYN flag is 0(as step #3 of three way handshake), sequence >>>> number(SN) are omitted of dump, BUT, it's present. >>> >>> You should use the "-S" option to tcpdump. It will show absolute >>> sequence number instead of relative ones (as guessed by tcpdump). >>> >>>> The thing is, the SN is present but it isn't consumed. So, packets >>>> that don't consumes the SN, must have the last consumed SN + 1. >>>> >>>> Only for curiosity, linux and windows 2k accomplished without >>>> problems the three way handshake without Sequence Number filled on >>>> step #3. >>> >>> I have a hard time believing that. At most they may have sent you >>> a retransmit or a challenge-ACK. >>> >>> -- >>> Andre >>> >> >> I will post here the tcpdump and tcptest dumps for both windows and >> linux with ACK with sequence 0. > >> >> >> windows tcpdump: (tcpdump -i ed0 -S tcp) >> 17:01:46.420016 IP 192.168.1.10.59537 > 192.168.1.101.http: S >> 770272892:770272892(0) win 65535 >> 17:01:46.421835 IP 192.168.1.101.http > 192.168.1.10.59537: S >> 1681202755:1681202755(0) ack 770272893 win 64240 >> 17:01:46.834808 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack >> 1681202756 win 65535 >> 17:01:46.839584 IP 192.168.1.10.59537 > 192.168.1.101.http: F >> 770272893:770272893(0) ack 1681202756 win 65535 >> 17:01:46.840613 IP 192.168.1.101.http > 192.168.1.10.59537: . ack >> 770272894 win 64240 >> 17:01:46.840675 IP 192.168.1.101.http > 192.168.1.10.59537: F >> 1681202756:1681202756(0) ack 770272894 win 64240 >> 17:01:47.297816 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack >> 1681202757 win 65535 > > That's interesting. I don't see any rationale why that should be > acceptable. We enforce the sequence number to be present and valid > in the ACK. This hasn't caused any complaints or incompatibilities > so far. What version/service-pack of Windows and Linux (kernel) are > you testing against? nmap -O (it's my hoster) "IPCop firewall 1.4.10 - 1.4.15 (Linux 2.4.31 - 2.4.34)" Windows Xp professional Service pack 1 build 2600.xpsp1.020828-1920 > > According to RFC793, Section 3.9, Page 69 the first check is actually > testing the SEG.SEQ as follows: RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND. > RCV.NXT is obviously the SEG.SEQ you sent with your SYN segment. It > seems that Windows and Linux are ignoring this test because you didn't > send any data with the ACK. Or they are simply ignoring the segment > as invalid and your FIN packet (with the correct SEG.SEQ and SEG.ACK) > causes the internal state transition. One may discuss which response, > none (just ignore segment) or sending a RST (as we do currently) is > better. I tend to argue the latter as it makes problems/bugs much > more evident as we've witnessed with your test. Now I know that a sucessful test of FreeBSD is receive back a Reset Packet. Test cataloged. > > -- > Andre > > >> windows dump of tcptest (every packet of connection establishment and >> finalization) >> SYN--------------------------------- >> sport 56121 >> dport 80 >> sequence 1046947043 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 60750 >> urg_pointer 0 >> >> --------------------------------- >> >> SYN+ACK--------------------------------- >> sport 80 >> dport 56121 >> sequence 1494256296 >> ack_number 1046947044 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 64240 >> checksum 63191 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (SYN)--------------------------------- >> sport 56121 >> dport 80 >> sequence 0 >> ack_number 1494256297 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 27857 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 56121 >> dport 80 >> sequence 1046947044 >> ack_number 1494256297 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 1 >> window 65535 >> checksum 2437 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 80 >> dport 56121 >> sequence 1494256297 >> ack_number 1046947045 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 0 >> window 64240 >> checksum 3732 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 80 >> dport 56121 >> sequence 1494256297 >> ack_number 1046947045 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 1 >> window 64240 >> checksum 3731 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 56121 >> dport 80 >> sequence 1046947045 >> ack_number 1494256298 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 2436 >> urg_pointer 0 >> >> --------------------------------- >> >> >> >> >> >> >> >> >> linux tcpdump: (tcpdump -i ed0 -S tcp) >> 17:06:12.493737 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: S >> 501941873:501941873(0) win 65535 >> 17:06:12.934559 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: S >> 1436097196:1436097196(0) ack 501941874 win 5840 >> 17:06:13.313919 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . >> ack 1436097197 win 65535 >> 17:06:13.320533 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: F >> 501941874:501941874(0) ack 1436097197 win 65535 >> 17:06:13.331289 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: . >> ack 501941874 win 5840 >> 17:06:13.337751 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: F >> 1436097197:1436097197(0) ack 501941875 win 5840 >> 17:06:13.762246 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . >> ack 1436097198 win 65535 >> >> >> >> >> linux dump of tcptest (every packet of connection establishment and >> finalization) >> SYN--------------------------------- >> sport 54458 >> dport 80 >> sequence 501941873 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 25507 >> urg_pointer 0 >> >> --------------------------------- >> >> SYN+ACK--------------------------------- >> sport 80 >> dport 54458 >> sequence 1436097196 >> ack_number 501941874 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 5840 >> checksum 50368 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (SYN)--------------------------------- >> sport 54458 >> dport 80 >> sequence 0 >> ack_number 1436097197 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 6059 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 54458 >> dport 80 >> sequence 501941874 >> ack_number 1436097197 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 1 >> window 65535 >> checksum 62284 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 80 >> dport 54458 >> sequence 1436097197 >> ack_number 501941874 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 0 >> window 5840 >> checksum 56445 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 80 >> dport 54458 >> sequence 1436097197 >> ack_number 501941875 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 1 >> window 5840 >> checksum 56443 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 54458 >> dport 80 >> sequence 501941875 >> ack_number 1436097198 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 62283 >> urg_pointer 0 >> >> --------------------------------- >> >> It was the first test conformance result of tcptest! >> >> >> cheers > > -- Victor Hugo Bilouro FreeBSD! From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 17:44:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C426A1065672 for ; Mon, 2 Jun 2008 17:44:52 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id B69188FC15 for ; Mon, 2 Jun 2008 17:44:52 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id F1D111A0007A0 for ; Mon, 2 Jun 2008 10:17:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Eb7VE0zmXzPj for ; Mon, 2 Jun 2008 10:17:41 -0700 (PDT) Received: from coal (unknown [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 3943B1A000B2F for ; Mon, 2 Jun 2008 10:17:41 -0700 (PDT) From: Freddie Cash To: freebsd-net@freebsd.org Date: Mon, 2 Jun 2008 10:17:40 -0700 User-Agent: KMail/1.9.9 References: <48442389.9000602@MonkeyBrains.NET> <4844265F.4000405@MonkeyBrains.NET> <200806021903.48986.max@love2party.net> In-Reply-To: <200806021903.48986.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806021017.40633.fjwcash@gmail.com> Subject: Re: carpdev? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:44:52 -0000 On June 2, 2008 10:03 am Max Laier wrote: > I did the attached patch some time ago, but didn't find sufficient > testers and when I did - I didn't have time. This should work. Is this the same patch I tested awhile back? Or is the "if the order of the IPs on the interfaces is different, they won't join the carp vhid" issue fixed in this patch? I'd be happy to test this again, if the IP order issue has been fixed. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 17:56:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1FF4106566C for ; Mon, 2 Jun 2008 17:56:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 5651E8FC0A for ; Mon, 2 Jun 2008 17:56:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-016-249.pools.arcor-ip.net [88.66.16.249]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1K3EH70Hat-0004Ou; Mon, 02 Jun 2008 19:56:53 +0200 Received: (qmail 28294 invoked from network); 2 Jun 2008 17:54:59 -0000 Received: from myhost.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 2 Jun 2008 17:54:59 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Mon, 2 Jun 2008 19:56:34 +0200 User-Agent: KMail/1.9.9 References: <48442389.9000602@MonkeyBrains.NET> <200806021903.48986.max@love2party.net> <200806021017.40633.fjwcash@gmail.com> In-Reply-To: <200806021017.40633.fjwcash@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806021956.34892.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+vcE9NuLeml3XccHwBzwmmcVk/ex1UeZkmhYp IWVH6xP1VTJiXRU/5beqgGgr4SDdqsF7q6KcBO9sC1DQj1EA40 RK9DJgs7/A4QVpvE/08uQ== Cc: Freddie Cash Subject: Re: carpdev? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:56:55 -0000 On Monday 02 June 2008 19:17:40 Freddie Cash wrote: > On June 2, 2008 10:03 am Max Laier wrote: > > I did the attached patch some time ago, but didn't find sufficient > > testers and when I did - I didn't have time. This should work. > > Is this the same patch I tested awhile back? Or is the "if the order > of the IPs on the interfaces is different, they won't join the carp > vhid" issue fixed in this patch? > > I'd be happy to test this again, if the IP order issue has been fixed. I completely forgot ... there even is a PR (and patch) in my queue: http://www.freebsd.org/cgi/query-pr.cgi?pr=121574&cat= I'll commit in a bit - this should not conflict with the carpdev patch. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 02:18:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5475D106564A for ; Tue, 3 Jun 2008 02:18:27 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from infoweapons.com (mail0.infoweapons.org [204.2.248.50]) by mx1.freebsd.org (Postfix) with ESMTP id F383A8FC15 for ; Tue, 3 Jun 2008 02:18:26 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from ([58.71.34.138]) by mail0.infoweapons.com with ESMTP with TLS id 4321444.249710; Mon, 02 Jun 2008 22:02:46 -0400 Message-ID: <4844A646.8010809@infoweapons.com> Date: Tue, 03 Jun 2008 10:02:46 +0800 From: "Archimedes S. Gaviola" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Regarding FreeBSD and RFC Compliance] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 02:18:27 -0000 To Whom It May Concerned: Good day! Is there any document or web site that lists all the standard Request for Comments (RFCs) for all the networking protocols currently implemented on FreeBSD? This will help users identify what specific sections of a standard a certain network protocol is being implemented especially interoperability with other platforms. Thank you! Archimedes From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 02:46:40 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 770F31065675; Tue, 3 Jun 2008 02:46:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 534428FC37; Tue, 3 Jun 2008 02:46:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m532keEl085721; Tue, 3 Jun 2008 02:46:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m532kemP085717; Tue, 3 Jun 2008 02:46:40 GMT (envelope-from linimon) Date: Tue, 3 Jun 2008 02:46:40 GMT Message-Id: <200806030246.m532kemP085717@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/124225: [ndis] [patch] ndis network driver sometimes loses network connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 02:46:40 -0000 Old Synopsis: ndis network driver sometimes loses network connection New Synopsis: [ndis] [patch] ndis network driver sometimes loses network connection Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 3 02:46:09 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124225 From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 03:52:55 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31E381065672 for ; Tue, 3 Jun 2008 03:52:55 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id EF5A98FC30 for ; Tue, 3 Jun 2008 03:52:54 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by an-out-0708.google.com with SMTP id b33so937176ana.13 for ; Mon, 02 Jun 2008 20:52:54 -0700 (PDT) Received: by 10.100.210.9 with SMTP id i9mr8901980ang.119.1212465173845; Mon, 02 Jun 2008 20:52:53 -0700 (PDT) Received: by 10.100.216.6 with HTTP; Mon, 2 Jun 2008 20:52:53 -0700 (PDT) Message-ID: Date: Tue, 3 Jun 2008 00:52:53 -0300 From: "Victor Hugo Bilouro" To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: [GSoC - tcptest] - Regression Tests, Conformance Tests... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 03:52:55 -0000 Hi, I'm in architectural phase of tcptest* development, so, I need understand every possible test it will need cover, because it would change tcptest architecture. I selected some tests: *connection establishment and finalization (a) *test cases where reset must be sent *tcp options establishment *tcp options conformance *tcp timmers *regression tests *basic: ping localhost *basic: checksum test I invite you to suggest some tests. :) (may be some remembered bug) (a)this test is done. It was the first test done, and as result, we notice different behaviors in windows, linux and freebsd network stack. Another important thing to know is: suppose you are planning to use this tool, how you intend to use? In which environment? What purpose? What do you initially prefer? (a)write tests programaticaly or (b)write tests ipfw-like oriented? Thank you! -- Victor Hugo Bilouro FreeBSD! tcptest** --> http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite tcptest is a GSoC (Google Summer of Code) project, it's a TCP/IP Regression Test Suite implementation. As a testing tool, it can perform regression, protocol conformance, and fuzz tests. The tool may also be employed as an aid to protocol developers and both testing and debugging of firewalls/routers. It's was built on top of pcs.sf.net of gnn at freebsd. ps: I will keep the nomenclature used at subject. From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 04:36:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 412E9106564A for ; Tue, 3 Jun 2008 04:36:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 18A628FC18 for ; Tue, 3 Jun 2008 04:36:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id A025E10D585; Tue, 3 Jun 2008 00:36:02 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 03 Jun 2008 00:36:02 -0400 X-Sasl-enc: UByoLQQZgtQtRsB/sFILIS1cpllRFxQKgBeMgLGvCPYs 1212467762 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id F15481E31D; Tue, 3 Jun 2008 00:36:01 -0400 (EDT) Message-ID: <4844CA2F.2030805@FreeBSD.org> Date: Tue, 03 Jun 2008 05:35:59 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: "Archimedes S. Gaviola" References: <4844A646.8010809@infoweapons.com> In-Reply-To: <4844A646.8010809@infoweapons.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [Regarding FreeBSD and RFC Compliance] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 04:36:03 -0000 Archimedes S. Gaviola wrote: > To Whom It May Concerned: > > Good day! Is there any document or web site that lists all the > standard Request for Comments (RFCs) for all the networking protocols > currently implemented on FreeBSD? This will help users identify what > specific sections of a standard a certain network protocol is being > implemented especially interoperability with other platforms. No, want to compile one and contribute it to the project? We'd be very grateful for the help. cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 04:39:23 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3DAA1065672 for ; Tue, 3 Jun 2008 04:39:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id BAB268FC17 for ; Tue, 3 Jun 2008 04:39:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6DDB1111FCC; Tue, 3 Jun 2008 00:39:23 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Jun 2008 00:39:23 -0400 X-Sasl-enc: CoFQta/shnsjjb2noSy5rh8kUnhkQWF8FX4+PAcZOspO 1212467963 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id F28F824D45; Tue, 3 Jun 2008 00:39:22 -0400 (EDT) Message-ID: <4844CAF8.5080709@FreeBSD.org> Date: Tue, 03 Jun 2008 05:39:20 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Victor Hugo Bilouro References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: [GSoC - tcptest] - Regression Tests, Conformance Tests... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 04:39:24 -0000 Victor Hugo Bilouro wrote: > Hi, > > I'm in architectural phase of tcptest* development, so, I need > understand every possible test it will need cover, because it would > change tcptest architecture. > Hey, have you seen gnn's PCS toolkit? http://pcs.sourceforge.net/ I've made a lot of changes to it; diffs are with him but I can send folk a copy of my Mercurial repo. I wrote a set of IGMPv2 and IGMPv3 baseline regression tests using it, now that I've added things like expect(), etc. It might save you a lot of work, although the TCP stuff needs attention. With expect() you can track state between segments. I started on IP reassembly, but ain't finished. I think Kip Macy's been using it for testing too, I saw a chunk of PCS-using TCP code on his site the other day. cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 05:01:27 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F6B51065673 for ; Tue, 3 Jun 2008 05:01:27 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.240]) by mx1.freebsd.org (Postfix) with ESMTP id 64C8E8FC14 for ; Tue, 3 Jun 2008 05:01:26 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by ag-out-0708.google.com with SMTP id 8so7902334agc.3 for ; Mon, 02 Jun 2008 22:01:25 -0700 (PDT) Received: by 10.100.5.16 with SMTP id 16mr16611584ane.35.1212469284689; Mon, 02 Jun 2008 22:01:24 -0700 (PDT) Received: by 10.100.216.6 with HTTP; Mon, 2 Jun 2008 22:01:24 -0700 (PDT) Message-ID: Date: Tue, 3 Jun 2008 02:01:24 -0300 From: "Victor Hugo Bilouro" To: "Bruce M. Simpson" In-Reply-To: <4844CAF8.5080709@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4844CAF8.5080709@FreeBSD.org> Cc: net@freebsd.org Subject: Re: [GSoC - tcptest] - Regression Tests, Conformance Tests... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 05:01:27 -0000 Hi On Tue, Jun 3, 2008 at 1:39 AM, Bruce M. Simpson wrote: > Victor Hugo Bilouro wrote: >> >> Hi, >> >> I'm in architectural phase of tcptest* development, so, I need >> understand every possible test it will need cover, because it would >> change tcptest architecture. >> > > Hey, have you seen gnn's PCS toolkit? > http://pcs.sourceforge.net/ sure, I'm using pcs. tcptest is built on top of pcs. > > I've made a lot of changes to it; diffs are with him but I can send folk a > copy of my Mercurial repo. I would appreciate that. > > I wrote a set of IGMPv2 and IGMPv3 baseline regression tests using it, now > that I've added things like expect(), etc. > > It might save you a lot of work, although the TCP stuff needs attention. > With expect() you can track state between segments. I started on IP > reassembly, but ain't finished. humm, track state is needed to make TCP tests. > > I think Kip Macy's been using it for testing too, I saw a chunk of PCS-using > TCP code on his site the other day. I didn't find his site, can you send me? > > cheers > BMS > -- Victor Hugo Bilouro FreeBSD! From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 08:16:30 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE5A81065681 for ; Tue, 3 Jun 2008 08:16:30 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0428FC26 for ; Tue, 3 Jun 2008 08:16:30 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id A9E5C1119BC; Tue, 3 Jun 2008 04:16:29 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 03 Jun 2008 04:16:29 -0400 X-Sasl-enc: pjf40qQUx+gyRlOdVefLkydktTGqW2bJUZTCAuhcOhDA 1212480989 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 126975937; Tue, 3 Jun 2008 04:16:28 -0400 (EDT) Message-ID: <4844FDDC.3020704@FreeBSD.org> Date: Tue, 03 Jun 2008 09:16:28 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Victor Hugo Bilouro References: <4844CAF8.5080709@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: [GSoC - tcptest] - Regression Tests, Conformance Tests... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 08:16:30 -0000 Victor Hugo Bilouro wrote: >> I've made a lot of changes to it; diffs are with him but I can send folk a >> copy of my Mercurial repo. >> > I would appreciate that. > Sent (off-list). As an example of the new PCS syntax and expect() stuff, I'll forward you the IGMPv2 test off-list. (Also sent.) > humm, track state is needed to make TCP tests. > It is something you'll have to build yourself around the expect() functionality. The experimental IP reassembly code (in pcs/packets/ipv4sar.py) might be a good place to start. It isn't finished, but it should demonstrate the general principles -- i.e. you read packets in a loop and you pass them to an object which knows what to do, in this case, ipv4sar. One big problem I had was that the concept of fragmentation requires deep copies of PCS objects. I imagine that's less of an issue for TCP segmentation, as the situation is made somewhat easier by the fact you're dealing with streams. BTW: My snapshot of PCS fixes the IP and TCP option parsers. If you look at the IGMP and DHCP decoders, there is an example of a dictionary driven option parser. This could also be applied to TCP where it's likely to be useful. I believe most of the bugs have been shaken out of expect(). The main problem is buffering and the fact that expect() depends on non-blocking I/O. pcap can return more than one packet from the kernel every time you call into the non-blocking dispatch function, so I did some internal refactoring to allow expect() to deal with that. So your code has to be able to deal with multiple matches from the Connector, even if you only asked to match at *least* one packet. "Count" is mostly about stopping expect() from hanging the flow of control anyway. The syntax and semantics are intentionally similar to PExpect for Python. In fact the IGMPv2 test uses PExpect to drive a QEMU virtual machine encapsulated as a Python object, for regression testing the IGMP code. So my suggestion is check out PExpect too. > I didn't find his site, can you send me? http://www.fsmware.com/freebsd/syntest2.py I've added some Scapy-like syntax to PCS which can make the code look a bit smaller. cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 10:06:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883B5106567D for ; Tue, 3 Jun 2008 10:06:17 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from infoweapons.com (mail0.infoweapons.net [204.2.248.50]) by mx1.freebsd.org (Postfix) with ESMTP id 90CB98FC1F for ; Tue, 3 Jun 2008 10:06:16 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from ([58.71.34.137]) by mail0.infoweapons.com with ESMTP with TLS id 4321444.252512; Tue, 03 Jun 2008 06:06:00 -0400 Message-ID: <48451786.3040002@infoweapons.com> Date: Tue, 03 Jun 2008 18:05:58 +0800 From: "Archimedes S. Gaviola" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4844A646.8010809@infoweapons.com> <4844CA2F.2030805@FreeBSD.org> In-Reply-To: <4844CA2F.2030805@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [Regarding FreeBSD and RFC Compliance] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 10:06:17 -0000 Bruce M. Simpson wrote: > Archimedes S. Gaviola wrote: >> To Whom It May Concerned: >> >> Good day! Is there any document or web site that lists all the >> standard Request for Comments (RFCs) for all the networking protocols >> currently implemented on FreeBSD? This will help users identify what >> specific sections of a standard a certain network protocol is being >> implemented especially interoperability with other platforms. > > No, want to compile one and contribute it to the project? We'd be very > grateful for the help. > > cheers > BMS > Ah okay, so this is still a window of opportunity for now but unfortunately I'm currently pre-occupied with my time. I might contribute on this someday. From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 11:46:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 525101065672 for ; Tue, 3 Jun 2008 11:46:27 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 17E2F8FC20 for ; Tue, 3 Jun 2008 11:46:27 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id A92EE520010 for ; Tue, 3 Jun 2008 13:22:00 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 5B6B3FD4E1 for ; Tue, 3 Jun 2008 13:22:00 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: freebsd-net@freebsd.org Date: Tue, 3 Jun 2008 13:21:41 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200806031321.41768.marc.loerner@hob.de> Subject: Unaligned references in /usr/src/sys/netinet6/in6.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 11:46:27 -0000 Hello, within testing on a ia64-platform I spotted unaligned references in the macros: IN6_IS_ADDR_UNSPECIFIED(a), IN6_IS_ADDR_LOOPBACK(a), IN6_IS_ADDR_V4COMPAT(a) and IN6_IS_ADDR_V4MAPPED(a) It's not always true that the s6_addr array is aligned to 4-byte and this causes some trouble at least with ia64-platforms. After changing from u_int32_t to u_int8_t accesses the unalignment faults seem to be gone. Regards, Marc P.S.: On replies please CC me because I'm not on the list. From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 13:52:04 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16994106568D for ; Tue, 3 Jun 2008 13:52:04 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id BB1058FC0A for ; Tue, 3 Jun 2008 13:52:02 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0BEA81111A9; Tue, 3 Jun 2008 09:52:02 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Jun 2008 09:52:02 -0400 X-Sasl-enc: i3LtDBG4q2kli6LbEpyf9ORMZJjz31nBki/N+fcGBblY 1212501121 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8376B109F7; Tue, 3 Jun 2008 09:52:01 -0400 (EDT) Message-ID: <48454C80.6080904@FreeBSD.org> Date: Tue, 03 Jun 2008 14:52:00 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Dalibor Gudzic References: <4844A646.8010809@infoweapons.com> <4844CA2F.2030805@FreeBSD.org> <866fa9520806030634q5c3f3be1sf6ccb44668e5c3@mail.gmail.com> In-Reply-To: <866fa9520806030634q5c3f3be1sf6ccb44668e5c3@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: [Regarding FreeBSD and RFC Compliance] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 13:52:04 -0000 Dalibor Gudzic wrote: > > > Any pointers for someone that wishes to do it? http://wiki.freebsd.org/NetworkRFCCompliance ...is one place to start... From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 15:17:09 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1148106567B for ; Tue, 3 Jun 2008 15:17:09 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32707.mail.mud.yahoo.com (web32707.mail.mud.yahoo.com [68.142.207.251]) by mx1.freebsd.org (Postfix) with SMTP id 7CD568FC19 for ; Tue, 3 Jun 2008 15:17:09 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 71496 invoked by uid 60001); 3 Jun 2008 14:50:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SN5UNv++yaWYHVhG7n12/7WqHAXtpU+eQJ0wyXaLI+F/5ngq1tEROL1wohA7taunt43r0IxYObZKnSC/R+ZyqJUxxwRq3Pm/YQ8/HZTRHI5vAPyKl8pt+5FkJ1F9CiDXvGWG6DN5eCh2lXPBR5eEWZWTrpzbQJ2wRPkM64iEsNY=; Received: from [190.157.196.204] by web32707.mail.mud.yahoo.com via HTTP; Tue, 03 Jun 2008 07:50:28 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 3 Jun 2008 07:50:28 -0700 (PDT) From: pfgshield-freebsd@yahoo.com To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <853261.35086.qm@web32707.mail.mud.yahoo.com> X-Mailman-Approved-At: Tue, 03 Jun 2008 16:02:13 +0000 Cc: freebsd-hackers@FreeBSD.org Subject: Anyone interested in HDLC support for pppd ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 15:17:09 -0000 Hello; I started playing a bit with net/pppd23 and I noticed there are some patche= s for FreeBSD-3.0 that were never committed (NetBSD certainly has them). Ou= r pppd(8) is derived from the "samba" pppd port and should have them if we = want to continue updating it. I started adapting them but I am actually in a dead point due to my profoun= d ignorance on FreeBSD and it's latest changes. I am stuck here: _____ ... ../../../net/ppp_tty.c: In function `pppsyncstart': ../../../net/ppp_tty.c:653: error: `cdevsw' undeclared (first use in this f= unction) ../../../net/ppp_tty.c:653: error: (Each undeclared identifier is reported = only once ../../../net/ppp_tty.c:653: error: for each function it appears in.) ../../../net/ppp_tty.c:653: warning: implicit declaration of function `majo= r' ../../../net/ppp_tty.c:653: warning: nested extern declaration of `major' *** Error code 1 ______ the offending code is this: ______ /* call device driver IOCTL to transmit a frame */ if ((*cdevsw[major(tp->t_dev)]->d_ioctl) (tp->t_dev,TIOCXMTFRAME,(caddr_t)&m,0,0)) { /* busy or error, set as current packet */ sc->sc_outm =3D m; _____ If someone can give me (easy to follow) suggestions on how to fix it I'll b= e grateful. The changes I already did to the original patches are not huge = but if someone wants to review them all just send me a private mail and I'l= l send them. cheers, Pedro.=0A=0A=0A ___________________________________ =0AScopri il B= log di Yahoo! Mail: trucchi, novit=E0, consigli... e la tua opinione!=0Ahtt= p://www.ymailblogit.com/blog/ From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 16:30:50 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03011065678 for ; Tue, 3 Jun 2008 16:30:50 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 97FAF8FC30 for ; Tue, 3 Jun 2008 16:30:50 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id BCC12112978; Tue, 3 Jun 2008 12:30:49 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 03 Jun 2008 12:30:49 -0400 X-Sasl-enc: fbnJRxRZwnn1xA8VvaQ3NCE7RrXveyR5ytY2Uox5SlII 1212510649 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id DEAA31E4CC; Tue, 3 Jun 2008 12:30:48 -0400 (EDT) Message-ID: <484571B7.1050004@FreeBSD.org> Date: Tue, 03 Jun 2008 17:30:47 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: pfgshield-freebsd@yahoo.com References: <853261.35086.qm@web32707.mail.mud.yahoo.com> In-Reply-To: <853261.35086.qm@web32707.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Anyone interested in HDLC support for pppd ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 16:30:50 -0000 pfgshield-freebsd@yahoo.com wrote: > Hello; > > I started playing a bit with net/pppd23 and I noticed there are some patches for FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived from the "samba" pppd port and should have them if we want to continue updating it. > Ed Schouten is currently rewriting the tty code. It sounds like line disciplines are about to go away, so pppd23 will most likely stop working at that point. There's a Netgraph node ng_cisco which claims to support HDLC. Perhaps tweaking MPD to work with it is a better use of effort. From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 21:26:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A01C106567A for ; Tue, 3 Jun 2008 21:26:36 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 211E48FC2C for ; Tue, 3 Jun 2008 21:26:35 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from onob5.irc.local ([217.197.56.98]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 23:14:55 +0200 Message-ID: <4845B417.6030400@ide.resurscentrum.se> Date: Tue, 03 Jun 2008 23:13:59 +0200 From: Jon Otterholm User-Agent: Thunderbird 2.0.0.9 (X11/20071216) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2008 21:14:55.0480 (UTC) FILETIME=[DEF02F80:01C8C5BE] Subject: carpdev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 21:26:36 -0000 Hi. Are there any plans to implement option carpdev to carp in FreeBSD? //Jon From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 22:05:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AE4F1065675 for ; Tue, 3 Jun 2008 22:05:53 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 276B48FC15 for ; Tue, 3 Jun 2008 22:05:52 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so199871uge.37 for ; Tue, 03 Jun 2008 15:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Jt+ELanKJZr/smtVBV6apU3t0549ht6M8AWROo0CPJU=; b=tgIiZcAnTILMHK8FVQFxstpA8sLUJ/jbnFGkAziNje6tU3HXjyi3iIcBl5DUAxVPT9 Uq1kPsK0s8uwpXZS/ARBHk3FySCW3r4wwy7bZ0bn9dm+oiy/oCN/jLphwbOaGKU4U1UB 1RJjcPF8BxEX8wL19SCPt4sKJ1IBvaQcesEP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=e4gTwK9rjYoIaZDtEBFfPWN2YBHYYtsTEaq3OAUUPgnGPaiKf27cfMws3kyrVlA0v1 SqmPhvKrxsvjG0YTHc9r748cNsFG1U/E7mZpVMawXm3mwu9NBQIDoA/RNROi6l9/4JIq MYn8sK/icq78TwXXPADM0MPhiQX7YaD1cw8i0= Received: by 10.78.134.7 with SMTP id h7mr2209713hud.94.1212529182453; Tue, 03 Jun 2008 14:39:42 -0700 (PDT) Received: by 10.78.160.14 with HTTP; Tue, 3 Jun 2008 14:39:42 -0700 (PDT) Message-ID: Date: Tue, 3 Jun 2008 17:39:42 -0400 From: "Scott Ullrich" To: "Jon Otterholm" In-Reply-To: <4845B417.6030400@ide.resurscentrum.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4845B417.6030400@ide.resurscentrum.se> Cc: freebsd-net@freebsd.org Subject: Re: carpdev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 22:05:53 -0000 On 6/3/08, Jon Otterholm wrote: > Hi. > > Are there any plans to implement option carpdev to carp in FreeBSD? > > //Jon See the freebsd-pf archives. Max has a patch ready for testing and needs more wide-spread testing. Scott From owner-freebsd-net@FreeBSD.ORG Tue Jun 3 22:20:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07B7F106566B for ; Tue, 3 Jun 2008 22:20:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4658FC0C for ; Tue, 3 Jun 2008 22:20:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-003-177.pools.arcor-ip.net [88.66.3.177]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1K3erV2Ug3-00048a; Wed, 04 Jun 2008 00:20:13 +0200 Received: (qmail 49376 invoked from network); 3 Jun 2008 22:18:17 -0000 Received: from myhost.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 3 Jun 2008 22:18:17 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 4 Jun 2008 00:19:50 +0200 User-Agent: KMail/1.9.9 References: <4845B417.6030400@ide.resurscentrum.se> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806040019.50942.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/X4XToFEJ6awjNuuFJnXanOgv3WHUQxCiIbyg +/tlufUdukT+1qeApbiF5iEGqwZZIVzAHIK4xSeg6PwCzdNcm2 ZRifF4q0+qnSfCJSV0W6A== Cc: Jon Otterholm , Scott Ullrich Subject: Re: carpdev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 22:20:15 -0000 On Tuesday 03 June 2008 23:39:42 Scott Ullrich wrote: > On 6/3/08, Jon Otterholm wrote: > > Hi. > > > > Are there any plans to implement option carpdev to carp in FreeBSD? > > > > //Jon > > See the freebsd-pf archives. Max has a patch ready for testing and > needs more wide-spread testing. Or scroll up to Monday on this list ;) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 08:14:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A14B3106564A for ; Wed, 4 Jun 2008 08:14:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 2C30F8FC1A for ; Wed, 4 Jun 2008 08:14:49 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m548EiO1021018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 18:14:47 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m548EiS6087055; Wed, 4 Jun 2008 18:14:44 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m548EhcI087054; Wed, 4 Jun 2008 18:14:43 +1000 (EST) (envelope-from peter) Date: Wed, 4 Jun 2008 18:14:43 +1000 From: Peter Jeremy To: Max Laier Message-ID: <20080604081443.GJ1028@server.vk2pj.dyndns.org> References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nhAUiXSLan16V5i8" Content-Disposition: inline In-Reply-To: <36735.192.168.4.151.1204669226.squirrel@router> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 08:14:50 -0000 --nhAUiXSLan16V5i8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Mar-04 23:20:26 +0100, Max Laier wrote: >You could try the attached patch. It adds carpdev support. You'll have >to recompile ifconfig to make use of it. I have just tried it and found that it does precisely the opposite of what I want :-( My situation: At work, I have a NAT box that is used to translate between our corporate intranet and my department's test models. There is (basically) 1:1 NAT and I use proxy-ARP on the intranet side (though I have gateway IPs on the internal side). I am trying to convert this to use CARP for failover. My external interface config currently looks like: ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 arp -s 10.10.10.2 auto pub arp -s 10.10.10.3 auto pub arp -s 10.10.10.4 auto pub arp -s 10.10.10.5 auto pub Ideally, I want to attach a carp device to vlan10 so I can do ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 ifconfig carp10 vhid 10 carpdev vlan10=20 arp -s 10.10.10.2 00:00:5e:00:01:0a pub arp -s 10.10.10.3 00:00:5e:00:01:0a pub arp -s 10.10.10.4 00:00:5e:00:01:0a pub arp -s 10.10.10.5 00:00:5e:00:01:0a pub ie the IP address remains with the specific box (the backup box has its own IP address). Unfortunately, the current carpdev code doesn't work this way: It lets me not assign an IP address to vlan10 but I still have to assign an IP address to carp10 (and it uses the latter address rather than the former address in the carp advertisements). Does what I want make sense to you and can you see any way it could be integrated into your carpdev patches. Note that one downside of your carpdev patches is that (AFAIK) it is no longer possible to identify which host sent the packet: The source and destination MAC addresses, as well as the destination IP address are all defined by CARP. Once you change the source IP address to be the shared address there's nothing to identify which host sent it. Finally, can anyone point me to a protocol specification for CARP. The only documentation I can find in either FreeBSD or OpenBSD is basically limited to "it's like VRRP but different to avoid the CISCO patent on HSRP". --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --nhAUiXSLan16V5i8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhGTvMACgkQ/opHv/APuIebRACfdweukYlycy9aRD0iQNapXMKR 6Q4AnRuAtwn66CavJ3sn8rZWT2BOi78S =JPrH -----END PGP SIGNATURE----- --nhAUiXSLan16V5i8-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 19:02:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 236181065673 for ; Wed, 4 Jun 2008 19:02:03 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id D18F88FC1F for ; Wed, 4 Jun 2008 19:02:02 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: by py-out-1112.google.com with SMTP id p76so189900pyb.10 for ; Wed, 04 Jun 2008 12:02:02 -0700 (PDT) Received: by 10.140.141.15 with SMTP id o15mr184352rvd.280.1212604635080; Wed, 04 Jun 2008 11:37:15 -0700 (PDT) Received: by 10.140.148.6 with HTTP; Wed, 4 Jun 2008 11:37:14 -0700 (PDT) Message-ID: Date: Thu, 5 Jun 2008 02:37:14 +0800 From: "Izwan Mohd" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 19:02:03 -0000 Hi, I have being encountering a weird problem on my freebsd 6 , one of my remote machine being down frequently lately for no particular reason, when I go to the remote site to check then machine it was in good running condition but no network, it even can't ping the server on the same subnet, the only way to restore it back is by running: route -n flush && /etc/netstart but because it a remote machine it really troublesome to do that each time the machine is down, I resorted to use a crontab scripts to automatically run the previous command when it down, even tho that partial of the problem is solve I still need to know what causing it. can anyone could advise me where to start digging?? they is no any particular error in the log or dmseg when the machine dropped it connection so I'm stuck here don't know where to start, some help should clear something up for me TQ From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 19:41:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DCA81065671 for ; Wed, 4 Jun 2008 19:41:08 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id CAC7D8FC12 for ; Wed, 4 Jun 2008 19:41:07 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m54Jf4XJ031653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 05:41:06 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m54Jexx5075703; Thu, 5 Jun 2008 05:40:59 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m54JexdZ075702; Thu, 5 Jun 2008 05:40:59 +1000 (EST) (envelope-from peter) Date: Thu, 5 Jun 2008 05:40:59 +1000 From: Peter Jeremy To: Izwan Mohd Message-ID: <20080604194059.GE1028@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wfe1KbQWcwuymTys" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 19:41:08 -0000 --Wfe1KbQWcwuymTys Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jun-05 02:37:14 +0800, Izwan Mohd wrote: >I have being encountering a weird problem on my freebsd 6 , one of my remo= te >machine being down frequently lately for no particular reason, when I go to >the remote site to check then machine it was in good running condition but >no network, it even can't ping the server on the same subnet, the only way >to restore it back is by running: > >route -n flush && /etc/netstart First question would be: What has changed? Are you able to identify when the problem occurs? This might let you associate the problem with an internal cronjob or network activity. What does ifconfig report? Does the interface look normal or is it reporting something strange? Is the switch reporting any events associated with your port? What do you see if you tcpdump the interface whilst its not working? Are you seeing normal subnet broadcast traffic? Unicast traffic directed to your box? Outgoing traffic from your box? Does physically unplugging and re-connecting the network cable correct the problem? Are you able to (temporarily) use a different swichport or NIC? Finally, more detail on your configuration might trigger someone's memory: What version of 6.x? What NIC/MII? How much memory? What network features (vlan, firewall, dummynet, netgraph, carp, ...) are you using? --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --Wfe1KbQWcwuymTys Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhG78sACgkQ/opHv/APuIfcUgCgg0+Ip71jGxW/JhIyqsEccgMB V+gAnjF1EjtvyiFmpc0LiZVox/wFUAxM =LMMU -----END PGP SIGNATURE----- --Wfe1KbQWcwuymTys-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 19:59:01 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DB5E1065676 for ; Wed, 4 Jun 2008 19:59:01 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2D60A8FC2A for ; Wed, 4 Jun 2008 19:59:01 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from desktop.home.serebryakov.spb.ru (unknown [89.163.10.141]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 435F213DFAB for ; Wed, 4 Jun 2008 23:42:31 +0400 (MSD) Date: Wed, 4 Jun 2008 23:42:31 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <1761236634.20080604234231@serebryakov.spb.ru> To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 19:59:01 -0000 Hello, net. I'm setupping file server for WindowsXP/SP3 clients, based on FreeBSD 7.0-Stable nad latest samba port. First of all, Is et these kernel variables: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 All tests are performed with only one client for start. Server and client are linked with 1Gig link, jumbo frames are enabled (9014 bytes) and iperf shows about 900Mbit/s of raw TCP with big windows (about 256Kb for start). Local tests shows 75Mb/s Read/write from/to shared file system with big files. Default configuration of samba gives me only 20Mb/s read and loosy 15Mb/s write. With "socket options = TCP_NODELAY" speed becomes 25/20 Mb/S R/W. Then I start to change SO_RCVBUF/SO_SNDBUF and found (with binary search), that best values are 49152. Yes, this strange values. 65536 is worse, and 32768 is worse too. This magic value gives me about 40MB/s read and 30-35Mb/s write. "Recommended" 8192 gives me 40K/s read (YES, 40 _K_ilobytes per second!) But I don't like this situation. Why? Because, it is black magic, not science. Why 49152? How can this value be found without binary search? What affects this value? Second problem is about TCP windows, which can give more thoughtput on 1Gig link. I've tried to tcpdump traffic between samba and WinXP client, and it shows, that window scaling is turned off. Always. It is enabled on WinXP client, it is enabled on FreeBSD server, it us used by iperf (with great effect), but not by samba! What do I do wrong? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 20:45:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93C4F1065674 for ; Wed, 4 Jun 2008 20:45:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.245]) by mx1.freebsd.org (Postfix) with ESMTP id 443B78FC18 for ; Wed, 4 Jun 2008 20:45:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by hs-out-0708.google.com with SMTP id h53so201198hsh.11 for ; Wed, 04 Jun 2008 13:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=f/vHNnM2CYxdpds1lz7bCVas/hjEz8pcFPQoMedzpF8=; b=YlJrDfvxJQOAK0kZZF0N/LnAh+uDWPfiyg3NdO2tZABHx2j/2bc1J1EoWBPMMBi4LI 8AwKUMGmOP9r2jQ+yjqQEvHHP53ZcoGVWdq2pN5eGmljuyqELn4vEKEPv8mKbAUWyJyz yna/HLParHC/fZoBABsze9HujrhacflQKhhxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=qGrIGku+mnIYYg6C37QZa2XoRw0riHijTLKHndkmsPeiNu5uH8M9pi4zbUTh4O7g6W sO4OrQzIR01QEo0EFuvGiXenqW0jO7SA8Tpdp4Ij9qmjoH/BV1xbqn9HD/rDTIGYAybM 25+pkf8ycbj/h1KxMvJW6aVu3SNEFDfn81C6w= Received: by 10.115.106.7 with SMTP id i7mr639258wam.131.1212612306952; Wed, 04 Jun 2008 13:45:06 -0700 (PDT) Received: by 10.114.174.13 with HTTP; Wed, 4 Jun 2008 13:45:06 -0700 (PDT) Message-ID: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> Date: Wed, 4 Jun 2008 13:45:06 -0700 From: "Jack Vogel" To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Addition to the vlan driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 20:45:22 -0000 I had our test group report a bug when using jumbo frames and vlans in the new igb driver. After a couple days chasing it down it turns out the issue is that the igb driver does not know when a vlan is first attached, and when you use jumbo frames you need to program a register with the maximum frame size. The test case sets the MTU first, then did the vlan setup, so the driver did not have the tag accounted for in the frame size, and thus the hardware was happily throwing frames away due to size :( Now, as a workaround I have them set up the vlan first and THEN change the MTU, but I'd rather not require that, so.... What I would like to do is add some code into the vlan_ioctl() routine that will make a call to the PARENT ioctl with SETVLAN type and an argument of the tag. By doing this both the em and igb drivers will be able to enable hardware vlan filtering as well, a feature we've never been able to use. Anyone see any issue with doing this or have any objections to it? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 21:06:05 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA661065675 for ; Wed, 4 Jun 2008 21:06:05 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id A99008FC29 for ; Wed, 4 Jun 2008 21:06:04 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.2/jtpda-5.4) with ESMTP id m54L62p0069067 for ; Wed, 4 Jun 2008 23:06:03 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m54L61Uq097919 for ; Wed, 4 Jun 2008 23:06:01 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m54L61K5097916; Wed, 4 Jun 2008 23:06:01 +0200 (MEST) (envelope-from arno) To: net@freebsd.org From: "Arno J. Klaassen" Date: 04 Jun 2008 23:06:01 +0200 Message-ID: Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.166]); Wed, 04 Jun 2008 23:06:03 +0200 (CEST) X-Virus-Scanned: ClamAV 0.92/7365/Wed Jun 4 20:39:36 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 484703BB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 484703BB.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 484703BB.000 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.012 -> S=0.012 X-j-chkmail-Status: Ham Cc: Subject: IP-forwarding (help) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 21:06:05 -0000 Hello, this is probably a FAQ and/or I'm to tired, but I'd be pleased if anyone can tell me what I do wrong : I have a box with two interfaces, one connected to my lan (172.16. ), one to a test-box (192.168.1.1) : em0: flags=8843 metric 0 mtu 1500 options=9b ether xxx inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether xxx inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active I enable ip.forwarding : # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 And this is my routing table : Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.1.254 UGS 0 20 em0 127.0.0.1 127.0.0.1 UH 0 0 lo0 172.16.1.0/24 link#3 UC 0 0 em0 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 1194 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 572 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 487 192.168.1.0/24 link#4 UC 0 0 em1 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 616 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 For this I added to rc.conf : static_routes="test lan" route_test="-net 192.168.1.0/24 192.168.1.254" route_lan="-net 172.16.1.0/24 172.16.1.240" Now from my test-box 192.168.1.1 I can reach (of course) 192.168.1.254, I can reach 172.16.1.240, but no other IP. What do I wrong, please!? Thank you very much for any help in advance. Best regards, Arno From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 21:56:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86AA6106564A for ; Wed, 4 Jun 2008 21:56:02 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB4C8FC13 for ; Wed, 4 Jun 2008 21:56:02 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 8BC50173AF; Thu, 5 Jun 2008 07:56:01 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (142.19.96.58.exetel.com.au [58.96.19.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 4A26A17262; Thu, 5 Jun 2008 07:55:57 +1000 (EST) Message-ID: <48470F61.6060907@modulus.org> Date: Thu, 05 Jun 2008 07:55:45 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> In-Reply-To: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack Vogel Subject: Re: Addition to the vlan driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 21:56:02 -0000 Jack Vogel wrote: > What I would like to do is add some code into the vlan_ioctl() routine > that will make a call > to the PARENT ioctl with SETVLAN type and an argument of the tag. > > By doing this both the em and igb drivers will be able to enable > hardware vlan filtering as > well, a feature we've never been able to use. I don't think vlan filtering is needed much, since I always use VLANs with switches that do the filtering at the port level. But it still sounds like a good idea and I can't think why not. - Andrew From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 21:58:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74AB11065675 for ; Wed, 4 Jun 2008 21:58:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1F98FC18 for ; Wed, 4 Jun 2008 21:58:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so172140wah.3 for ; Wed, 04 Jun 2008 14:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MIxhozAkOhwNet92U9UHZVUu8kMFO7+Bbg8gGPB9ksE=; b=uHpMKT9ff9+A2YZnT7HAgsNhuKMOyd+mXqPD/nQog4QdQnty6ncKnI1elwgXE7If3k 4Bh0pth7g6AfQzXKpPHSA4GRLWmsBST7D319+SJRGgEFZXhSW0lbSuAlmE9iWhL8CylP 3qLbbmwIQDeqNqdQqzSNuYJhIm36rrLWhz/rA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cECU2UeZmfHN90xEIUnyNL1aJbjhZK5Jmz/kLjOWi+4Pe4HxEAsfQC0gNsItwY2Doi vxA9ULb4+OgGMpR1eJd3Oj4enYU8N959s+QcwQXC19KJ3+ZsiahvCc8Bb6QD7RKe+bOO DA/gZ/PEwCAMtXuZkJmLRGPpvOMbCVnGARm8o= Received: by 10.114.58.6 with SMTP id g6mr753883waa.68.1212616680731; Wed, 04 Jun 2008 14:58:00 -0700 (PDT) Received: by 10.114.174.13 with HTTP; Wed, 4 Jun 2008 14:58:00 -0700 (PDT) Message-ID: <2a41acea0806041458p2f498dacvdf33dfbca75d8554@mail.gmail.com> Date: Wed, 4 Jun 2008 14:58:00 -0700 From: "Jack Vogel" To: "Andrew Snow" In-Reply-To: <48470F61.6060907@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> <48470F61.6060907@modulus.org> Cc: freebsd-net@freebsd.org Subject: Re: Addition to the vlan driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 21:58:01 -0000 On Wed, Jun 4, 2008 at 2:55 PM, Andrew Snow wrote: > Jack Vogel wrote: >> >> What I would like to do is add some code into the vlan_ioctl() routine >> that will make a call >> to the PARENT ioctl with SETVLAN type and an argument of the tag. >> >> By doing this both the em and igb drivers will be able to enable >> hardware vlan filtering as >> well, a feature we've never been able to use. > > I don't think vlan filtering is needed much, since I always use VLANs > with switches that do the filtering at the port level. But it still > sounds like a good idea and I can't think why not. > > - Andrew > Sam is going to make some change that should suit my needs, waiting to see his code to make my changes. Jack From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 22:28:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EFE7106564A for ; Wed, 4 Jun 2008 22:28:16 +0000 (UTC) (envelope-from petar@smokva.net) Received: from morrison.andev.ch (morrison.andev.ch [78.47.142.202]) by mx1.freebsd.org (Postfix) with ESMTP id C1A4B8FC22 for ; Wed, 4 Jun 2008 22:28:15 +0000 (UTC) (envelope-from petar@smokva.net) Received: from pintail.smokva.net (84-74-146-124.dclient.hispeed.ch [84.74.146.124]) by morrison.andev.ch (Postfix) with ESMTP id DC5135DB1D for ; Thu, 5 Jun 2008 00:19:34 +0200 (CEST) Date: Thu, 5 Jun 2008 00:17:38 +0200 From: Petar Bogdanovic To: freebsd-net@freebsd.org Message-ID: <20080604221738.GA6776@pintail.smokva.net> Mail-Followup-To: freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: IP-forwarding (help) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 22:28:16 -0000 On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > Hello, > > this is probably a FAQ and/or I'm to tired, but I'd be pleased > if anyone can tell me what I do wrong : > > I have a box with two interfaces, one connected to my lan > (172.16. ), one to a test-box (192.168.1.1) : > > em0: flags=8843 metric 0 mtu 1500 > options=9b > ether xxx > inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > em1: flags=8843 metric 0 mtu 1500 > options=9b > ether xxx > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > > I enable ip.forwarding : > > # sysctl net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > > > And this is my routing table : > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.16.1.254 UGS 0 20 em0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 172.16.1.0/24 link#3 UC 0 0 em0 > 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 1194 > 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 572 > 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 487 > 192.168.1.0/24 link#4 UC 0 0 em1 > 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 616 > 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > For this I added to rc.conf : > > static_routes="test lan" > route_test="-net 192.168.1.0/24 192.168.1.254" > route_lan="-net 172.16.1.0/24 172.16.1.240" I'm pretty sure that you don't need these three lines. Turning net.inet.ip.forwarding on should be enough. Petar From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 23:17:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 220BC1065685 for ; Wed, 4 Jun 2008 23:17:27 +0000 (UTC) (envelope-from fox@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id E1B2A8FC20 for ; Wed, 4 Jun 2008 23:17:26 +0000 (UTC) (envelope-from fox@verio.net) Received: from limbo.int.dllstx01.us.it.verio.net (nkfw1.it.verio.net [129.250.40.241]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 54A60B038260 for ; Wed, 4 Jun 2008 19:17:25 -0400 (EDT) Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 2920D8E298; Wed, 4 Jun 2008 18:17:25 -0500 (CDT) Date: Wed, 4 Jun 2008 18:17:25 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20080604231724.GG14447@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: IP-forwarding (help) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 23:17:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arno J. Klaassen wrote: > > Now from my test-box 192.168.1.1 I can reach (of course) > 192.168.1.254, I can reach 172.16.1.240, but no other IP. Check with tcpdump, are your network packets being sourced from the 192.168 network even when they go to the 172.16 network? Perhaps the box you reach does not know how to route back to you when you source from that IP. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIRyKEFSrKRjX5eCoRAhT0AJsGMjSpUqXl7DG5Q0hkPSt6Rh321ACfduQU wdIKoSXxfTDMrxaz3S+cKkI= =EdLO -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Jun 4 23:33:14 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7A681065671 for ; Wed, 4 Jun 2008 23:33:14 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA1B8FC13 for ; Wed, 4 Jun 2008 23:33:14 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.2/jtpda-5.4) with ESMTP id m54NXCI8078565 ; Thu, 5 Jun 2008 01:33:13 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m54NXBd7098594 ; Thu, 5 Jun 2008 01:33:11 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m54NX6ou098591; Thu, 5 Jun 2008 01:33:06 +0200 (MEST) (envelope-from arno) To: Petar Bogdanovic References: <20080604221738.GA6776@pintail.smokva.net> From: "Arno J. Klaassen" Date: 05 Jun 2008 01:33:05 +0200 In-Reply-To: <20080604221738.GA6776@pintail.smokva.net> Message-ID: Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.164]); Thu, 05 Jun 2008 01:33:13 +0200 (CEST) X-Virus-Scanned: ClamAV 0.92/7366/Wed Jun 4 22:03:12 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail2.jussieu.fr with ID 48470A1A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 48470A1A.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 48470A1A.000 on jchkmail2.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.009 -> S=0.009 X-j-chkmail-Status: Ham Cc: net@freebsd.org Subject: Re: IP-forwarding (help) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 23:33:15 -0000 Petar Bogdanovic writes: > On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > > > Hello, > > > > this is probably a FAQ and/or I'm to tired, but I'd be pleased > > if anyone can tell me what I do wrong : > > > > I have a box with two interfaces, one connected to my lan > > (172.16. ), one to a test-box (192.168.1.1) : > > > > em0: flags=8843 metric 0 mtu 1500 > > options=9b > > ether xxx > > inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 > > media: Ethernet autoselect (1000baseTX ) > > status: active > > > > em1: flags=8843 metric 0 mtu 1500 > > options=9b > > ether xxx > > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > > media: Ethernet autoselect (1000baseTX ) > > status: active > > > > > > I enable ip.forwarding : > > > > # sysctl net.inet.ip.forwarding > > net.inet.ip.forwarding: 1 > > > > > > And this is my routing table : > > > > Internet: > > Destination Gateway Flags Refs Use Netif Expire > > default 172.16.1.254 UGS 0 20 em0 > > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > > 172.16.1.0/24 link#3 UC 0 0 em0 > > 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 1194 > > 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 572 > > 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 487 > > 192.168.1.0/24 link#4 UC 0 0 em1 > > 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 616 > > 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > > > For this I added to rc.conf : > > > > static_routes="test lan" > > route_test="-net 192.168.1.0/24 192.168.1.254" > > route_lan="-net 172.16.1.0/24 172.16.1.240" > > I'm pretty sure that you don't need these three lines. Turning > net.inet.ip.forwarding on should be enough. That's what I thought? Without the above lines it doesn't work either. And ip.forwarding "works" in the sense trafic goes from 192.168.1.254 forward to 172.16.1.240 over lo0, but then taking "link#3" to go to 172.16.1.0/24 fails. I feel this is /me still not fully understand routing tables. NB, this is on 7-stable-amd64 Arno From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 00:16:28 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ABF21065671 for ; Thu, 5 Jun 2008 00:16:28 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 6465D8FC15 for ; Thu, 5 Jun 2008 00:16:28 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 6481A5B46; Wed, 4 Jun 2008 17:06:22 -0700 (PDT) To: "Arno J. Klaassen" In-reply-to: Your message of "05 Jun 2008 01:33:05 +0200." Date: Wed, 04 Jun 2008 17:06:22 -0700 From: Bakul Shah Message-Id: <20080605000622.6481A5B46@mail.bitblocks.com> Cc: Petar Bogdanovic , net@freebsd.org Subject: Re: IP-forwarding (help) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 00:16:28 -0000 On 05 Jun 2008 01:33:05 +0200 "Arno J. Klaassen" wrote: > Petar Bogdanovic writes: > > > On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > > > > > Hello, > > > > > > this is probably a FAQ and/or I'm to tired, but I'd be pleased > > > if anyone can tell me what I do wrong : > > > > > > I have a box with two interfaces, one connected to my lan > > > (172.16. ), one to a test-box (192.168.1.1) : > > > > > > em0: flags=8843 metric 0 mtu 15 > 00 > > > options=9b > > > ether xxx > > > inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > > > > em1: flags=8843 metric 0 mtu 15 > 00 > > > options=9b > > > ether xxx > > > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > > > > > > > I enable ip.forwarding : > > > > > > # sysctl net.inet.ip.forwarding > > > net.inet.ip.forwarding: 1 > > > > > > > > > And this is my routing table : > > > > > > Internet: > > > Destination Gateway Flags Refs Use Netif Expi > re > > > default 172.16.1.254 UGS 0 20 em0 > > > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > > > 172.16.1.0/24 link#3 UC 0 0 em0 > > > 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 11 > 94 > > > 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 5 > 72 > > > 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > > 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 4 > 87 > > > 192.168.1.0/24 link#4 UC 0 0 em1 > > > 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 6 > 16 > > > 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > > > > > For this I added to rc.conf : > > > > > > static_routes="test lan" > > > route_test="-net 192.168.1.0/24 192.168.1.254" > > > route_lan="-net 172.16.1.0/24 172.16.1.240" > > > > I'm pretty sure that you don't need these three lines. Turning > > net.inet.ip.forwarding on should be enough. > I feel this is /me still not fully understand routing tables. This is your topology, right? test-box main-box gateway [192.168.1.1]------[192.168.1.254 172.16.1.240]-------[172.16.1.254 On the test-box set default route to 192.168.1.254. On the main-box set net.inet.ip.forwarding 1 but remove the static routes. But how would machines on the 172.16.1.0/24 net know they must send packets for 192.168.1.0/24 to 172.16.1.240? For that you need static routes on all the machines on 172.16.1.0/24 that need to read your test box. From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 00:56:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 640E21065670 for ; Thu, 5 Jun 2008 00:56:59 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id E83E38FC18 for ; Thu, 5 Jun 2008 00:56:58 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-062-212.pools.arcor-ip.net [88.66.62.212]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1K43mj30ne-0007Df; Thu, 05 Jun 2008 02:56:58 +0200 Received: (qmail 68628 invoked from network); 5 Jun 2008 00:55:00 -0000 Received: from myhost.laiers.local (192.168.4.151) by laiers.local with SMTP; 5 Jun 2008 00:55:00 -0000 From: Max Laier Organization: FreeBSD To: Peter Jeremy Date: Thu, 5 Jun 2008 02:56:30 +0200 User-Agent: KMail/1.9.9 References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <20080604081443.GJ1028@server.vk2pj.dyndns.org> In-Reply-To: <20080604081443.GJ1028@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806050256.30476.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+IVSj8dpXOpnaUNQvmR2BxHOn70+HKJpBEF// DZnoAI5ksiG9Xlcm1jhUfPhf4E3LC/4ZyFcXGMFR9uiLbWs+TV 1aX3pQqes0573Ytyjeyog== Cc: freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 00:56:59 -0000 On Wednesday 04 June 2008 10:14:43 Peter Jeremy wrote: > On 2008-Mar-04 23:20:26 +0100, Max Laier wrote: > >You could try the attached patch. It adds carpdev support. You'll > > have to recompile ifconfig to make use of it. > > I have just tried it and found that it does precisely the opposite of > what I want :-( > > My situation: At work, I have a NAT box that is used to translate > between our corporate intranet and my department's test models. There > is (basically) 1:1 NAT and I use proxy-ARP on the intranet side (though > I have gateway IPs on the internal side). I am trying to convert this > to use CARP for failover. > > My external interface config currently looks like: > ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 > arp -s 10.10.10.2 auto pub > arp -s 10.10.10.3 auto pub > arp -s 10.10.10.4 auto pub > arp -s 10.10.10.5 auto pub > > Ideally, I want to attach a carp device to vlan10 so I can do > ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 > ifconfig carp10 vhid 10 carpdev vlan10 > arp -s 10.10.10.2 00:00:5e:00:01:0a pub > arp -s 10.10.10.3 00:00:5e:00:01:0a pub > arp -s 10.10.10.4 00:00:5e:00:01:0a pub > arp -s 10.10.10.5 00:00:5e:00:01:0a pub > ie the IP address remains with the specific box (the backup box has > its own IP address). Unfortunately, the current carpdev code doesn't > work this way: It lets me not assign an IP address to vlan10 but I > still have to assign an IP address to carp10 (and it uses the latter > address rather than the former address in the carp advertisements). > > Does what I want make sense to you and can you see any way it could be > integrated into your carpdev patches. Sorry, I don't quite understand what you are after here. Can you give a network layout and more details on the objective? > Note that one downside of your carpdev patches is that (AFAIK) it is > no longer possible to identify which host sent the packet: The source > and destination MAC addresses, as well as the destination IP address > are all defined by CARP. Once you change the source IP address to be > the shared address there's nothing to identify which host sent it. That's the point of CARP: *Transparent* address failover. In order to provide that you have to hide the identity of the actual host. If you want to talk to the individual hosts you have to assign them an IP of their own and if you do that you don't need the carpdev patch. > Finally, can anyone point me to a protocol specification for CARP. > The only documentation I can find in either FreeBSD or OpenBSD is > basically limited to "it's like VRRP but different to avoid the CISCO > patent on HSRP". Take a look at: http://www.countersiege.com/doc/pfsync-carp/ Really good pictures to get the gist of it. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 02:35:51 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69AA9106567C; Thu, 5 Jun 2008 02:35:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F59A8FC45; Thu, 5 Jun 2008 02:35:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m552ZpjI019969; Thu, 5 Jun 2008 02:35:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m552ZpPW019965; Thu, 5 Jun 2008 02:35:51 GMT (envelope-from linimon) Date: Thu, 5 Jun 2008 02:35:51 GMT Message-Id: <200806050235.m552ZpPW019965@freefall.freebsd.org> To: neil@hoggarth.me.uk, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122928: [em] interface watchdog timeouts and stops receiving packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 02:35:51 -0000 Synopsis: [em] interface watchdog timeouts and stops receiving packets State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Thu Jun 5 02:35:42 UTC 2008 State-Changed-Why: Feedback received. http://www.freebsd.org/cgi/query-pr.cgi?pr=122928 From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 03:23:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9CC106566B for ; Thu, 5 Jun 2008 03:23:46 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from infoweapons.com (mail0.infoweapons.com [204.2.248.50]) by mx1.freebsd.org (Postfix) with ESMTP id 778A48FC14 for ; Thu, 5 Jun 2008 03:23:46 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from ([58.71.34.137]) by mail0.infoweapons.com with ESMTP with TLS id 4321444.266331; Wed, 04 Jun 2008 23:08:21 -0400 Message-ID: <484758A5.2050808@infoweapons.com> Date: Thu, 05 Jun 2008 11:08:21 +0800 From: "Archimedes S. Gaviola" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4844A646.8010809@infoweapons.com> <4844CA2F.2030805@FreeBSD.org> <48451786.3040002@infoweapons.com> In-Reply-To: <48451786.3040002@infoweapons.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [Regarding FreeBSD and RFC Compliance] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 03:23:46 -0000 Archimedes S. Gaviola wrote: > Bruce M. Simpson wrote: >> Archimedes S. Gaviola wrote: >>> To Whom It May Concerned: >>> >>> Good day! Is there any document or web site that lists all the >>> standard Request for Comments (RFCs) for all the networking >>> protocols currently implemented on FreeBSD? This will help users >>> identify what specific sections of a standard a certain network >>> protocol is being implemented especially interoperability with other >>> platforms. >> >> No, want to compile one and contribute it to the project? We'd be >> very grateful for the help. >> >> cheers >> BMS >> > Ah okay, so this is still a window of opportunity for now but > unfortunately I'm currently pre-occupied with my time. I might > contribute on this someday. > By the way, I want to share the IPv6 conformance test results from TAHI project (www.tahi.org) because they are working on IPv6 conformance tools. On their web site, a FreeBSD-6.1 were tested for IPv6 core protocols conformance both router mode http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-1/freebsd61.router/ and host mode http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-1/freebsd61.host/. From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 03:33:04 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5616E106566B for ; Thu, 5 Jun 2008 03:33:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 261B68FC0C for ; Thu, 5 Jun 2008 03:33:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so502527rvf.43 for ; Wed, 04 Jun 2008 20:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=aNvAzqkKkeQLc0IHXRVHINPUNOhmCWbXsqYBS1Ds38Q=; b=AXQqHdA2+l0qR9tH/VGVtfDzJuuSEuVXCfVoRuSoNpC5AiWeH8FGcFNhwnw8dRllWA mo7Q6VXAAGRDqSPt/hAAXMSLzzX5ysCFiRNQJISTxF15i0SDRqNJRlesytE7/oEDj9L0 bBNS5EA9w0wU4jGCl7lffY7hsWcmiEKaA0eVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=b4lO8kLKnLKmB+vfP0GMyEtqS0toCkbjU/XJb07HCaZLzxay2HcGqmOGTKGCIeBIHT Eliq4pF+Cx7ispOMiXkVwPizj4ZC5aJkxSrWvA5JR2OT62xp8MW5rwg2RvqdMDBtpfYw SoLGRv5a4pMxX/D/uyYwsM9K7X8bcKuAlSm48= Received: by 10.140.127.13 with SMTP id z13mr501535rvc.194.1212635120110; Wed, 04 Jun 2008 20:05:20 -0700 (PDT) Received: by 10.141.70.11 with HTTP; Wed, 4 Jun 2008 20:05:20 -0700 (PDT) Message-ID: Date: Thu, 5 Jun 2008 11:05:20 +0800 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Lev Serebryakov" In-Reply-To: <1761236634.20080604234231@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1761236634.20080604234231@serebryakov.spb.ru> X-Google-Sender-Auth: 04c8c0bd794a4e92 Cc: net@freebsd.org Subject: Re: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 03:33:04 -0000 Figure out why window scaling isn't working - look at the options being negotiated (use tcpdump) and try to figure out which side isn't offering or is rejecting window size scaling negotiation. CIFS isn't the same profile as iperf/etc - its not just shovelling raw data down the socket, there's a whole protocol involved in scheduling what to transfer. Latency in handling commands screws your performance.. Adrian 2008/6/5 Lev Serebryakov : > Hello, net. > > I'm setupping file server for WindowsXP/SP3 clients, based on > FreeBSD 7.0-Stable nad latest samba port. > > First of all, Is et these kernel variables: > > kern.ipc.maxsockbuf=16777216 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.sendspace=131072 > net.inet.tcp.recvspace=131072 > > All tests are performed with only one client for start. Server and > client are linked with 1Gig link, jumbo frames are enabled (9014 > bytes) and iperf shows about 900Mbit/s of raw TCP with big windows > (about 256Kb for start). > > Local tests shows 75Mb/s Read/write from/to shared file system with > big files. > > Default configuration of samba gives me only 20Mb/s read and loosy > 15Mb/s write. > > With "socket options = TCP_NODELAY" speed becomes 25/20 Mb/S R/W. > > Then I start to change SO_RCVBUF/SO_SNDBUF and found (with binary > search), that best values are 49152. Yes, this strange values. 65536 > is worse, and 32768 is worse too. This magic value gives me about > 40MB/s read and 30-35Mb/s write. > > "Recommended" 8192 gives me 40K/s read (YES, 40 _K_ilobytes per > second!) > > But I don't like this situation. Why? Because, it is black magic, > not science. Why 49152? How can this value be found without binary > search? What affects this value? > > Second problem is about TCP windows, which can give more thoughtput > on 1Gig link. I've tried to tcpdump traffic between samba and WinXP > client, and it shows, that window scaling is turned off. Always. It is > enabled on WinXP client, it is enabled on FreeBSD server, it us used > by iperf (with great effect), but not by samba! What do I do wrong? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 04:27:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78B1D106567D for ; Thu, 5 Jun 2008 04:27:21 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id EA19F8FC21 for ; Thu, 5 Jun 2008 04:27:20 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: by fg-out-1718.google.com with SMTP id l26so288765fgb.35 for ; Wed, 04 Jun 2008 21:27:19 -0700 (PDT) Received: by 10.86.63.19 with SMTP id l19mr1252058fga.77.1212640039129; Wed, 04 Jun 2008 21:27:19 -0700 (PDT) Received: by 10.86.90.14 with HTTP; Wed, 4 Jun 2008 21:27:19 -0700 (PDT) Message-ID: Date: Thu, 5 Jun 2008 12:27:19 +0800 From: "Izwan Mohd" To: freebsd-net@freebsd.org In-Reply-To: <20080604194059.GE1028@server.vk2pj.dyndns.org> MIME-Version: 1.0 References: <20080604194059.GE1028@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Peter Jeremy Subject: Re: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 04:27:21 -0000 > First question would be: What has changed? > > Are you able to identify when the problem occurs? This might let you > associate the problem with an internal cronjob or network activity. it randomly happen so I can't determine when it happen my cron script just try to ping and if it not successfull it will flush and restart the network > > What does ifconfig report? Does the interface look normal or is it > reporting something strange? ifconfig does not show any abnormality but maybe I will double check it Is the switch reporting any events associated with your port? > Nope no report from switch indicating something wrong the the port that the machine are using > What do you see if you tcpdump the interface whilst its not working? > Are you seeing normal subnet broadcast traffic? Unicast traffic > directed to your box? Outgoing traffic from your box? > I will check this one this afternoon because the machine is dead again I'll post the finding later on > > Does physically unplugging and re-connecting the network cable > correct the problem? Are you able to (temporarily) use a different > swichport or NIC? > sometime it does sometime it wont, already try changing to other port on the switch still the same, changing the NIC is not an option for me because it a rack mount server using on board NIC and no extra slot to add a new network card on it. > Finally, more detail on your configuration might trigger someone's > memory: What version of 6.x? What NIC/MII? How much memory? What > network features (vlan, firewall, dummynet, netgraph, carp, ...) are > you using? > The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the model but freebsd detect it as "em0" the server memory is 1GB, not special network fetures it only running snort and nessus will post more detail after I check the machine this afternoon Thank You, Regards, Zuan > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > -- Izwan Mohd Malaysian Linux Community http://mylinux.net.my From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 06:39:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33D3F10656A8 for ; Thu, 5 Jun 2008 06:39:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 07A0C8FC2D for ; Thu, 5 Jun 2008 06:39:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 86390111C9C; Thu, 5 Jun 2008 02:39:58 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 05 Jun 2008 02:39:58 -0400 X-Sasl-enc: 1Fr2GGLXcojEOfJ6A4HJy3QpibLY8vtLm5LRqK8MUCj+ 1212647998 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id C1A5B3D05; Thu, 5 Jun 2008 02:39:57 -0400 (EDT) Message-ID: <48478A3C.6070107@FreeBSD.org> Date: Thu, 05 Jun 2008 07:39:56 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Peter Jeremy References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <20080604081443.GJ1028@server.vk2pj.dyndns.org> In-Reply-To: <20080604081443.GJ1028@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 06:39:59 -0000 Peter Jeremy wrote: > Note that one downside of your carpdev patches is that (AFAIK) it is > no longer possible to identify which host sent the packet: The source > and destination MAC addresses, as well as the destination IP address > are all defined by CARP. Once you change the source IP address to be > the shared address there's nothing to identify which host sent it. > If you really, really wanted to, you could write code to prepend the original IP or MAC as an experimental IP option. Options less than <0x80 are not forwarded in IP fragments. I can understand why you'd want to do this (debugging springs to mind), though it does go against the gist of what carp is and does. Also, there is compatibility to keep in mind, and it's entirely possible that the presence of a new and unknown IP option is going to break implementations which don't parse IP option headers correctly, or trigger other unwanted behaviour ("I don't know what this IP option is therefore I will drop it"). From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 09:09:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88282106564A for ; Thu, 5 Jun 2008 09:09:47 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 5DC478FC16 for ; Thu, 5 Jun 2008 09:09:47 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: by rv-out-0506.google.com with SMTP id b25so640628rvf.43 for ; Thu, 05 Jun 2008 02:09:47 -0700 (PDT) Received: by 10.141.141.3 with SMTP id t3mr676070rvn.213.1212656986852; Thu, 05 Jun 2008 02:09:46 -0700 (PDT) Received: by 10.140.148.6 with HTTP; Thu, 5 Jun 2008 02:09:46 -0700 (PDT) Message-ID: Date: Thu, 5 Jun 2008 17:09:46 +0800 From: "Izwan Mohd" To: freebsd-net@freebsd.org In-Reply-To: MIME-Version: 1.0 References: <20080604194059.GE1028@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 09:09:47 -0000 Update: just got back from the remote site and checked the following: 1. tcpdump on the interface only show switch broadcast nothing more 2. the connection restored by doing arp -ad && ping On Thu, Jun 5, 2008 at 12:27 PM, Izwan Mohd wrote: > > First question would be: What has changed? >> >> Are you able to identify when the problem occurs? This might let you >> associate the problem with an internal cronjob or network activity. > > > it randomly happen so I can't determine when it happen my cron script just > try to ping and if it not successfull it will flush and restart the network > >> >> What does ifconfig report? Does the interface look normal or is it >> reporting something strange? > > > ifconfig does not show any abnormality but maybe I will double check it > > Is the switch reporting any events associated with your port? >> > > Nope no report from switch indicating something wrong the the port that > the machine are using > > >> What do you see if you tcpdump the interface whilst its not working? >> Are you seeing normal subnet broadcast traffic? Unicast traffic >> directed to your box? Outgoing traffic from your box? >> > > I will check this one this afternoon because the machine is dead again > I'll post the finding later on > > >> >> Does physically unplugging and re-connecting the network cable >> correct the problem? Are you able to (temporarily) use a different >> swichport or NIC? >> > > sometime it does sometime it wont, already try changing to other port on > the switch still the same, changing the NIC is not an option for me because > it a rack mount server using on board NIC and no extra slot to add a new > network card on it. > > >> Finally, more detail on your configuration might trigger someone's >> memory: What version of 6.x? What NIC/MII? How much memory? What >> network features (vlan, firewall, dummynet, netgraph, carp, ...) are >> you using? >> > > The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the > model but freebsd detect it as "em0" the server memory is 1GB, not special > network fetures it only running snort and nessus > > will post more detail after I check the machine this afternoon > > Thank You, > > Regards, > Zuan > >> >> -- >> Peter Jeremy >> Please excuse any delays as the result of my ISP's inability to implement >> an MTA that is either RFC2821-compliant or matches their claimed >> behaviour. >> > From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 09:10:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98108106564A for ; Thu, 5 Jun 2008 09:10:59 +0000 (UTC) (envelope-from freebsd-net@pp.dyndns.biz) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1728FC25 for ; Thu, 5 Jun 2008 09:10:59 +0000 (UTC) (envelope-from freebsd-net@pp.dyndns.biz) Received: from ironport.bredband.com (195.54.101.120) by proxy3.bredband.net (7.3.127) id 481183EA00C4DB68 for freebsd-net@freebsd.org; Thu, 5 Jun 2008 10:50:08 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUxABBGR0hV4juxPGdsb2JhbACBVYcMiR0BAQEBLZ1M Received: from c-b13be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.177]) by ironport1.bredband.com with ESMTP; 05 Jun 2008 10:50:08 +0200 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.2/8.14.2) with ESMTP id m558o6Z7085892 for ; Thu, 5 Jun 2008 10:50:07 +0200 (CEST) (envelope-from freebsd-net@pp.dyndns.biz) Message-ID: <4847A8BE.4010201@pp.dyndns.biz> Date: Thu, 05 Jun 2008 10:50:06 +0200 From: PP User-Agent: Thunderbird 2.0.0.14 (X11/20080521) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 09:10:59 -0000 Izwan Mohd wrote: > Hi, > > I have being encountering a weird problem on my freebsd 6 , one of my remote > machine being down frequently lately for no particular reason, when I go to > the remote site to check then machine it was in good running condition but > no network, it even can't ping the server on the same subnet, the only way > to restore it back is by running: > > route -n flush && /etc/netstart > > but because it a remote machine it really troublesome to do that each time > the machine is down, I resorted to use a crontab scripts to automatically > run the previous command when it down, even tho that partial of the problem > is solve I still need to know what causing it. can anyone could advise me > where to start digging?? they is no any particular error in the log or dmseg > when the machine dropped it connection so I'm stuck here don't know where to > start, some help should clear something up for me > > TQ This sounds vaguely similar to what I've experienced myself with an onboard em0 on a Supermicro mainboard. NIC suddenly stopped working for no appearent reason. Believing the NIC was bad I throw in an extra NIC and ran the machine from that. But within a month a capacitor blew in the PSU and when I replaced the PSU the onboard NIC worked again. This scenario repeated 3 times in exactly the same way before I switched to another PSU brand and haven't had any problems since. In my case I couldn't get the NIC running with a simple flushing of the routes though. But if nothing has changed in the software on the machine you should probably start looking at the hardware. /PP From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 11:19:59 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2D4A106566C for ; Thu, 5 Jun 2008 11:19:59 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id A06AD8FC1F for ; Thu, 5 Jun 2008 11:19:59 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from [192.18.98.64] (brmea-proxy-3.Sun.COM [192.18.98.64]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 9F3AD13DFBE; Thu, 5 Jun 2008 15:19:57 +0400 (MSD) Message-ID: <4847CC58.4060104@serebryakov.spb.ru> Date: Thu, 05 Jun 2008 15:22:00 +0400 From: "Lev A. Serebryakov" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.14) Gecko/20071210 Thunderbird/1.5.0.14 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Adrian Chadd References: <1761236634.20080604234231@serebryakov.spb.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 11:20:00 -0000 Adrian Chadd wrote: > Figure out why window scaling isn't working - look at the options > being negotiated (use tcpdump) and try to figure out which side isn't > offering or is rejecting window size scaling negotiation. FreeBSD suggest scaling 9, Windows -- scaling 0. After that FreeBSD uses scaling, but windows is 49152 (scaled! 0x0060 in header!) always from FreeBSD to Win due to SO_RCVBUF=49152. Without this option window is 130560, but speed is MUCH worse! > CIFS isn't the same profile as iperf/etc - its not just shovelling raw > data down the socket, there's a whole protocol involved in scheduling > what to transfer. Latency in handling commands screws your > performance.. But how this "magic values" in socket buffers can be explained? As far as I know, there are "big read/big write" commands in CIFS, which allows use more than 64K in one operation? -- // Lev Sserebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 15:13:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91474106566C for ; Thu, 5 Jun 2008 15:13:08 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 58EAA8FC21 for ; Thu, 5 Jun 2008 15:13:08 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 7592B520015 for ; Thu, 5 Jun 2008 17:13:06 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 0F674FD269 for ; Thu, 5 Jun 2008 17:13:06 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: freebsd-net@freebsd.org Date: Thu, 5 Jun 2008 17:12:47 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200806051712.47048.marc.loerner@hob.de> Subject: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 15:13:08 -0000 Hello, I probably found a bug in declaration of "struct tcphdr"! struct tcphdr { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ #if BYTE_ORDER == LITTLE_ENDIAN u_int th_x2:4, /* (unused) */ <---here th_off:4; /* data offset */ <--- #endif #if BYTE_ORDER == BIG_ENDIAN u_int th_off:4, /* data offset */ th_x2:4; /* (unused) */ #endif u_char th_flags; First of all I have the problam of misalignment of th_off. Because in this way always 4 bytes are read and the the bits of th_off are replaced. Then the 4 bytes are written back. But should (th_x and th_off) not only be 1 byte in whole -> only read and write 1 byte? I think if this was changed, my misalignment problems would go away! I'll appreciate any thoughts on this! Regards, Marc P.S.: Please cc me because I'm not on the list! From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 15:56:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 965371065677 for ; Thu, 5 Jun 2008 15:56:55 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.176]) by mx1.freebsd.org (Postfix) with ESMTP id 260628FC12 for ; Thu, 5 Jun 2008 15:56:54 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so406944ika.3 for ; Thu, 05 Jun 2008 08:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent:sender; bh=aNA+3m7G34TihAYJBQ5VstWebQ8IN2OyPrqXrdkM3bI=; b=Lmp1k+XQkWCof2r1WHfLfiWxZ3vTVXz7xJPAOIR++u/pMZVuY9nLFz6jLN7rLCG7/M xCm6Hc6FUJGFm2iuTWA0ntrZGg36Aiwjwa0h3KOxcoIbCdTPh5P8tz60DU3snH71qHIm luN9DFGPcQsx3toWFrWDnGmjzHlhU8I35dU1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent:sender; b=w6oUdXDZPhYB5YYqvO5Zb3X5nYbaticLNEiwH2AlIUmIm10YCmd9uS/ge0QGZSQiwg WCb2DMkI8OsMwclDmTY2Z2/60QsR5vwfVn3cHpurWz9+PJYXGqieKr3JCodR+MjHknPZ 90ctkkaiSdcAqSmZnUx+J8xmrBSYlGpKzqeoU= Received: by 10.210.77.3 with SMTP id z3mr1107091eba.183.1212681413663; Thu, 05 Jun 2008 08:56:53 -0700 (PDT) Received: from epsilon.local ( [92.250.76.8]) by mx.google.com with ESMTPS id z33sm1881241ikz.0.2008.06.05.08.56.51 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Jun 2008 08:56:53 -0700 (PDT) Date: Thu, 5 Jun 2008 16:56:46 +0100 From: Rui Paulo To: marc.loerner@hob.de Message-ID: <20080605155646.GC6864@epsilon.local> References: <200806051712.47048.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806051712.47048.marc.loerner@hob.de> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 15:56:55 -0000 On Thu, Jun 05, 2008 at 05:12:47PM +0200, =?ISO-8859-1?Q?Marc_L=F6rner_ wrote: > Hello, > I probably found a bug in declaration of "struct tcphdr"! > > struct tcphdr { > u_short th_sport; /* source port */ > u_short th_dport; /* destination port */ > tcp_seq th_seq; /* sequence number */ > tcp_seq th_ack; /* acknowledgement number */ > #if BYTE_ORDER == LITTLE_ENDIAN > u_int th_x2:4, /* (unused) */ <---here > th_off:4; /* data offset */ <--- > #endif > #if BYTE_ORDER == BIG_ENDIAN > u_int th_off:4, /* data offset */ > th_x2:4; /* (unused) */ > #endif > u_char th_flags; > > First of all I have the problam of misalignment of th_off. Because in this way > always 4 bytes are read and the the bits of th_off are replaced. Then the 4 > bytes are written back. > > But should (th_x and th_off) not only be 1 byte in whole -> only read and > write 1 byte? > > I think if this was changed, my misalignment problems would go away! I'm not sure what you mean. Please supply more information, like: 1) Are you running on little endian? Or big endian? 2) th_x2 + th_off are 1 byte in size. What do you mean? 3) What is exactly the effect? I don't understand the "replaced", "written back" etc. sentence. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 16:09:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12FBF1065673 for ; Thu, 5 Jun 2008 16:09:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id E04D78FC16 for ; Thu, 5 Jun 2008 16:09:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 50A5B112094; Thu, 5 Jun 2008 12:09:11 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 05 Jun 2008 12:09:11 -0400 X-Sasl-enc: miiA9Gx+281s71nW7B6xJaycIauVCfQDuht+5px+MlGO 1212682151 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CEA022C7FE; Thu, 5 Jun 2008 12:09:10 -0400 (EDT) Message-ID: <48480FA5.3020800@FreeBSD.org> Date: Thu, 05 Jun 2008 17:09:09 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Marc_L=F6rner?= References: <200806051712.47048.marc.loerner@hob.de> In-Reply-To: <200806051712.47048.marc.loerner@hob.de> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 16:09:12 -0000 Marc L=F6rner wrote: > .. > First of all I have the problam of misalignment of th_off. Because in t= his way=20 > always 4 bytes are read and the the bits of th_off are replaced. Then t= he 4=20 > bytes are written back.=20 > > But should (th_x and th_off) not only be 1 byte in whole -> only read a= nd=20 > write 1 byte? > =20 Which machine architecture are you attempting to compile this code on? On FreeBSD Tier 1 platforms, the access is probably going to come out of = L2 cache anyway, so the fields in question will be read by a burst cycle.= It is worth noting that NetBSD changed the base type of tcphdr's=20 bitfields to uint8_t, however this shuffles the compiler dependency into = the treatment of the "char" type. Most modern C compilers support=20 "unsigned char". From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 19:08:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9F601065672 for ; Thu, 5 Jun 2008 19:08:09 +0000 (UTC) (envelope-from raggen@passagen.se) Received: from av10-2-sn2.hy.skanova.net (av10-2-sn2.hy.skanova.net [81.228.8.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFDC8FC25 for ; Thu, 5 Jun 2008 19:08:09 +0000 (UTC) (envelope-from raggen@passagen.se) Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id E180F37EFF; Thu, 5 Jun 2008 20:36:20 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id CAB6137EEA; Thu, 5 Jun 2008 20:36:20 +0200 (CEST) Received: from [192.168.1.31] (90-230-141-139-no41.tbcn.telia.com [90.230.141.139]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id BB08337E45; Thu, 5 Jun 2008 20:36:17 +0200 (CEST) Message-ID: <48483297.5030809@passagen.se> Date: Thu, 05 Jun 2008 20:38:15 +0200 From: Roger Olofsson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: PP References: <4847A8BE.4010201@pp.dyndns.biz> In-Reply-To: <4847A8BE.4010201@pp.dyndns.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 19:08:09 -0000 PP skrev: > Izwan Mohd wrote: >> Hi, >> >> I have being encountering a weird problem on my freebsd 6 , one of my >> remote >> machine being down frequently lately for no particular reason, when I >> go to >> the remote site to check then machine it was in good running condition >> but >> no network, it even can't ping the server on the same subnet, the only >> way >> to restore it back is by running: >> >> route -n flush && /etc/netstart >> >> but because it a remote machine it really troublesome to do that each >> time >> the machine is down, I resorted to use a crontab scripts to automatically >> run the previous command when it down, even tho that partial of the >> problem >> is solve I still need to know what causing it. can anyone could advise me >> where to start digging?? they is no any particular error in the log or >> dmseg >> when the machine dropped it connection so I'm stuck here don't know >> where to >> start, some help should clear something up for me >> >> TQ > > This sounds vaguely similar to what I've experienced myself with an > onboard em0 on a Supermicro mainboard. NIC suddenly stopped working for > no appearent reason. Believing the NIC was bad I throw in an extra NIC > and ran the machine from that. But within a month a capacitor blew in > the PSU and when I replaced the PSU the onboard NIC worked again. This > scenario repeated 3 times in exactly the same way before I switched to > another PSU brand and haven't had any problems since. In my case I > couldn't get the NIC running with a simple flushing of the routes > though. But if nothing has changed in the software on the machine you > should probably start looking at the hardware. > /PP > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 270.0.0/1484 - Release Date: 2008-06-04 16:40 Is it on DHCP? Sounds like it's lost the lease or the default route? /R From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 19:31:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 947911065671 for ; Thu, 5 Jun 2008 19:31:57 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 053908FC1E for ; Thu, 5 Jun 2008 19:31:56 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-027-213.pools.arcor-ip.net [88.66.27.213]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1K4LBj3BZl-0007EE; Thu, 05 Jun 2008 21:31:56 +0200 Received: (qmail 74815 invoked from network); 5 Jun 2008 19:29:56 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 5 Jun 2008 19:29:56 -0000 From: Max Laier Organization: FreeBSD To: Julian Elischer , Rajkumar S Date: Thu, 5 Jun 2008 21:31:22 +0200 User-Agent: KMail/1.9.9 References: <483763B5.4030205@elischer.org> <64de5c8b0805300118v3874ec3bx2b2978a80bae08b8@mail.gmail.com> <483FCCBC.6040802@elischer.org> In-Reply-To: <483FCCBC.6040802@elischer.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_L8DSIfS2qfuGi2B" Message-Id: <200806052131.23063.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+2h+MrRk6vjxut5Q18BQDsV89eObyIdjr+O64 09BPW19qxa1H/oCoCr9B4orL6neKu999ZrHFVYG+dQK3NMPK12 ZslsBr1TFkdIOf3+ZquoQ== Cc: freebsd-net@freebsd.org Subject: Re: anyone tried the Multi routing table code yet? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 19:31:57 -0000 --Boundary-00=_L8DSIfS2qfuGi2B Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 30 May 2008 11:45:32 Julian Elischer wrote: > Rajkumar S wrote: > > On Sat, May 24, 2008 at 6:09 AM, Julian Elischer wrote: > >> subject says it all really.. > > > > I am using pf and rtable to setfib and get an pfctl: DIOCADDRULE: > > Device busy when trying to load "pass in quick on fxp0 from any to > > any keep state rtable 1" > > I'm not really familiar with the pf syntax > as I didn't do that part of the patch (max laier (CC'd) did) > and I don't use pf. > > Max may be able to see if the patch to the pf code ahs an error. See attached - stupid error, my bad. Confirmed to work now, with limited testing, though. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-00=_L8DSIfS2qfuGi2B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Description: Max Laier : svn commit: r179570 - head/sys/contrib/pf/net Content-Disposition: inline; filename*= Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on router.laiers.local X-Spam-Level: X-Spam-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SPF_PASS autolearn=ham version=3.2.4 Delivered-To: mlaier@vampire.homelinux.org Received: (qmail 74745 invoked by alias); 5 Jun 2008 19:28:30 -0000 Delivered-To: max@vampire.homelinux.org Received: (qmail 74742 invoked from network); 5 Jun 2008 19:28:30 -0000 Received: from mx2.freebsd.org (69.147.83.53) by dslb-088-066-027-213.pools.arcor-ip.net with SMTP; 5 Jun 2008 19:28:30 -0000 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7FAFB178023 for ; Thu, 5 Jun 2008 19:30:26 +0000 (UTC) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 6C09510656AD; Thu, 5 Jun 2008 19:30:25 +0000 (UTC) Delivered-To: mlaier@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 98D4F106567C; Thu, 5 Jun 2008 19:30:21 +0000 (UTC) Delivered-To: src-committers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88FF71065678 for ; Thu, 5 Jun 2008 19:30:20 +0000 (UTC) (envelope-from mlaier@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8A48FC12 for ; Thu, 5 Jun 2008 19:30:20 +0000 (UTC) (envelope-from mlaier@FreeBSD.org) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.2/8.14.2) with ESMTP id m55JUKSJ080639 for ; Thu, 5 Jun 2008 19:30:20 GMT (envelope-from mlaier@svn.freebsd.org) Received: (from mlaier@localhost) by svn.freebsd.org (8.14.2/8.14.2/Submit) id m55JUKb5080638 for src-committers@freebsd.org; Thu, 5 Jun 2008 19:30:20 GMT (envelope-from mlaier@svn.freebsd.org) Message-Id: <200806051930.m55JUKb5080638@svn.freebsd.org> From: Max Laier Date: Thu, 5 Jun 2008 19:30:20 +0000 (UTC) To: src-committers@freebsd.org Subject: svn commit: r179570 - head/sys/contrib/pf/net MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with clamdscan / ClamAV 0.93/7373/Thu Jun 5 18:55:14 2008 X-Length: 3606 X-UID: 74068 Author: mlaier Date: Thu Jun 5 19:30:20 2008 New Revision: 179570 URL: http://svn.freebsd.org/changeset/base/179570 Log: Fix range check for rtable id. Modified: head/sys/contrib/pf/net/pf_ioctl.c Modified: head/sys/contrib/pf/net/pf_ioctl.c ============================================================================== --- head/sys/contrib/pf/net/pf_ioctl.c Thu Jun 5 19:01:31 2008 (r179569) +++ head/sys/contrib/pf/net/pf_ioctl.c Thu Jun 5 19:30:20 2008 (r179570) @@ -1532,7 +1532,7 @@ } #ifdef __FreeBSD__ /* ROUTEING */ - if (rule->rtableid > 0 && rule->rtableid < rt_numfibs) + if (rule->rtableid > 0 && rule->rtableid > rt_numfibs) #else if (rule->rtableid > 0 && !rtable_exists(rule->rtableid)) #endif @@ -1795,7 +1795,7 @@ if (newrule->rtableid > 0 && #ifdef __FreeBSD__ /* ROUTING */ - newrule->rtableid < rt_numfibs) + newrule->rtableid > rt_numfibs) #else !rtable_exists(newrule->rtableid)) #endif --Boundary-00=_L8DSIfS2qfuGi2B-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 21:01:32 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77384106567A for ; Thu, 5 Jun 2008 21:01:32 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 0B22C8FC0A for ; Thu, 5 Jun 2008 21:01:31 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.2/jtpda-5.4) with ESMTP id m55L1QxZ053153 ; Thu, 5 Jun 2008 23:01:27 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m55L1OVf003613 ; Thu, 5 Jun 2008 23:01:24 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m55L1J00003610; Thu, 5 Jun 2008 23:01:19 +0200 (MEST) (envelope-from arno) To: Bakul Shah References: <20080605000622.6481A5B46@mail.bitblocks.com> From: "Arno J. Klaassen" Date: 05 Jun 2008 23:01:18 +0200 In-Reply-To: <20080605000622.6481A5B46@mail.bitblocks.com> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.168]); Thu, 05 Jun 2008 23:01:27 +0200 (CEST) X-Virus-Scanned: ClamAV 0.92/7373/Thu Jun 5 18:55:14 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 48485426.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 48485426.002/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 48485426.002 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.013 -> S=0.013 X-j-chkmail-Status: Ham Cc: Petar Bogdanovic , net@freebsd.org Subject: Re: IP-forwarding (help) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 21:01:32 -0000 Bakul Shah writes: > On 05 Jun 2008 01:33:05 +0200 "Arno J. Klaassen" wrote: > > Petar Bogdanovic writes: > > > > > On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > > > > > > > [ problem description ] > > I feel this is /me still not fully understand routing tables. > > This is your topology, right? yes > test-box main-box gateway > [192.168.1.1]------[192.168.1.254 172.16.1.240]-------[172.16.1.254 > > On the test-box set default route to 192.168.1.254. > On the main-box set net.inet.ip.forwarding 1 but remove the > static routes. > > But how would machines on the 172.16.1.0/24 net know they > must send packets for 192.168.1.0/24 to 172.16.1.240? For > that you need static routes on all the machines on > 172.16.1.0/24 that need to read your test box. Yes, of course ... Thank you very much (I felt it were a simple problem, but somehow blocked finding the solution). Best regards, Arno From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 02:21:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D137B106567E for ; Fri, 6 Jun 2008 02:21:03 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id B7C138FC0A for ; Fri, 6 Jun 2008 02:21:03 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from [192.168.0.101] (busymonkey.monkeybrains.net [66.92.187.117]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id m562L370073762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2008 19:21:03 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <48489F0E.3030203@monkeybrains.net> Date: Thu, 05 Jun 2008 19:21:02 -0700 From: "Support (Rudy)" User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on pita.monkeybrains.net X-Virus-Status: Clean Subject: vlan oddness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 02:21:03 -0000 I created and destoryed, brought up and down a vlan... now it is not accepting an IP.... what does the 'File exists' mean? #ifconfig vlan9 vlan9: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:5c:ba:9c media: Ethernet autoselect (1000baseTX ) status: active vlan: 9 parent interface: em0 # ifconfig vlan9 10.5.43.225/27 ifconfig: ioctl (SIOCAIFADDR): File exists Also, I don't have the IP/net assigned on any IPs: # ifconfig | grep inet inet 10.5.40.8 netmask 0xffffff00 inet 10.5.42.254 netmask 0xffffff80 inet 64.215.30.154 netmask 0xfffffffc inet 127.0.0.1 netmask 0xff000000 inet 10.9.212.1 netmask 0xfffffe00 inet 10.5.41.1 netmask 0xffffff00 inet 10.9.2215.225 netmask 0xffffffe0 inet 10.9.215.9 netmask 0xfffffffc inet 10.77.0.6 netmask 0xffffff00 inet 10.5.42.126 netmask 0xffffff80 inet 10.99.0.1 netmask 0xffffff00 probably a reboot will fix it, but if anyone has seen this oddness, let me know if you found out what caused it. (Running fresh freebsd 7.0-STABLE) Rudy From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 02:27:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4FF21065674 for ; Fri, 6 Jun 2008 02:27:32 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from atlas.gtcomm.net (atlas.gtcomm.net [67.215.15.242]) by mx1.freebsd.org (Postfix) with ESMTP id 99C0F8FC0C for ; Fri, 6 Jun 2008 02:27:32 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from c-76-108-179-28.hsd1.fl.comcast.net ([76.108.179.28] helo=[192.168.1.3]) by atlas.gtcomm.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1K4ReY-0000Yu-Lm; Thu, 05 Jun 2008 22:26:06 -0400 Message-ID: <4848A106.9050709@gtcomm.net> Date: Thu, 05 Jun 2008 22:29:26 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Support (Rudy)" References: <48489F0E.3030203@monkeybrains.net> In-Reply-To: <48489F0E.3030203@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vlan oddness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 02:27:32 -0000 Probably still in the routing table and didn't get removed when the interface was destroyed.. do a route get 10.5.43.225 Support (Rudy) wrote: > > I created and destoryed, brought up and down a vlan... now it is not > accepting an IP.... what does the 'File exists' mean? > > #ifconfig vlan9 > vlan9: flags=8843 metric 0 mtu > 1500 > options=3 > ether 00:30:48:5c:ba:9c > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 9 parent interface: em0 > > # ifconfig vlan9 10.5.43.225/27 > ifconfig: ioctl (SIOCAIFADDR): File exists > > Also, I don't have the IP/net assigned on any IPs: > # ifconfig | grep inet > inet 10.5.40.8 netmask 0xffffff00 > inet 10.5.42.254 netmask 0xffffff80 > inet 64.215.30.154 netmask 0xfffffffc > inet 127.0.0.1 netmask 0xff000000 > inet 10.9.212.1 netmask 0xfffffe00 > inet 10.5.41.1 netmask 0xffffff00 > inet 10.9.2215.225 netmask 0xffffffe0 > inet 10.9.215.9 netmask 0xfffffffc > inet 10.77.0.6 netmask 0xffffff00 > inet 10.5.42.126 netmask 0xffffff80 > inet 10.99.0.1 netmask 0xffffff00 > > probably a reboot will fix it, but if anyone has seen this oddness, > let me know if you found out what caused it. > (Running fresh freebsd 7.0-STABLE) > > Rudy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 02:42:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7D8A1065675 for ; Fri, 6 Jun 2008 02:42:17 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id A30978FC19 for ; Fri, 6 Jun 2008 02:42:17 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from [192.168.0.101] (busymonkey.monkeybrains.net [66.92.187.117]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id m562gHuu076564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 19:42:17 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <4848A408.4070008@monkeybrains.net> Date: Thu, 05 Jun 2008 19:42:16 -0700 From: "Support (Rudy)" User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Paul References: <48489F0E.3030203@monkeybrains.net> <4848A106.9050709@gtcomm.net> In-Reply-To: <4848A106.9050709@gtcomm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on pita.monkeybrains.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: vlan oddness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 02:42:17 -0000 Paul wrote: > Probably still in the routing table Yep. Had to go into quagga and delete the route... :) moved GW from another router to another. Thanks, Rudy From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 05:57:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9014D1065676 for ; Fri, 6 Jun 2008 05:57:34 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 63E648FC17 for ; Fri, 6 Jun 2008 05:57:34 +0000 (UTC) (envelope-from zuan@mylinux.net.my) Received: by rv-out-0506.google.com with SMTP id b25so1203981rvf.43 for ; Thu, 05 Jun 2008 22:57:34 -0700 (PDT) Received: by 10.140.139.3 with SMTP id m3mr1466379rvd.165.1212731853900; Thu, 05 Jun 2008 22:57:33 -0700 (PDT) Received: by 10.140.148.6 with HTTP; Thu, 5 Jun 2008 22:57:33 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 13:57:33 +0800 From: "Izwan Mohd" To: "Roger Olofsson" In-Reply-To: <48483297.5030809@passagen.se> MIME-Version: 1.0 References: <4847A8BE.4010201@pp.dyndns.biz> <48483297.5030809@passagen.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, PP Subject: Re: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 05:57:34 -0000 Hi, > > > Is it on DHCP? Sounds like it's lost the lease or the default route? > > /R > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Nope it not on DHCP it using static configuration and even to eliminate fw issue I even put it before firewall without going thru firewall it just use my ISP default router as it gateway tks From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 07:30:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE231106566B for ; Fri, 6 Jun 2008 07:30:49 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id A358B8FC20 for ; Fri, 6 Jun 2008 07:30:49 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 462A6520032; Fri, 6 Jun 2008 09:30:48 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id C6B67FD381; Fri, 6 Jun 2008 09:30:47 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: Rui Paulo Date: Fri, 6 Jun 2008 09:30:28 +0200 User-Agent: KMail/1.6.2 References: <200806051712.47048.marc.loerner@hob.de> <20080605155646.GC6864@epsilon.local> In-Reply-To: <20080605155646.GC6864@epsilon.local> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200806060930.28527.marc.loerner@hob.de> Cc: freebsd-net@freebsd.org Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 07:30:50 -0000 On Thursday 05 June 2008 17:56, Rui Paulo wrote: > On Thu, Jun 05, 2008 at 05:12:47PM +0200, =?ISO-8859-1?Q?Marc_L=F6rner_ wrote: > > Hello, > > I probably found a bug in declaration of "struct tcphdr"! > > > > struct tcphdr { > > u_short th_sport; /* source port */ > > u_short th_dport; /* destination port */ > > tcp_seq th_seq; /* sequence number */ > > tcp_seq th_ack; /* acknowledgement number */ > > #if BYTE_ORDER == LITTLE_ENDIAN > > u_int th_x2:4, /* (unused) */ <---here > > th_off:4; /* data offset */ <--- > > #endif > > #if BYTE_ORDER == BIG_ENDIAN > > u_int th_off:4, /* data offset */ > > th_x2:4; /* (unused) */ > > #endif > > u_char th_flags; > > > > First of all I have the problam of misalignment of th_off. Because in > > this way always 4 bytes are read and the the bits of th_off are replaced. > > Then the 4 bytes are written back. > > > > But should (th_x and th_off) not only be 1 byte in whole -> only read and > > write 1 byte? > > > > I think if this was changed, my misalignment problems would go away! > > I'm not sure what you mean. > > Please supply more information, like: > 1) Are you running on little endian? Or big endian? I'm on itanium-architecture, therefore I can run big and little endian. But for now it is little endian. > 2) th_x2 + th_off are 1 byte in size. What do you mean? th_x2 and th_off are created as a bitfield. But C-Standard says that bitfields are accessed as integers => 4-bytes On itanium integers are read with ld4-command but the address of th_x2/th_off may not be aligned to 4-bytes => we get an unaligned reference fault. If we'd change to 1 byte-accesses => I won't get any misaligned faults anymore. Hope this makes my dilemma a bit clearer, Marc From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 07:36:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED37F1065673 for ; Fri, 6 Jun 2008 07:36:40 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9CE8FC14 for ; Fri, 6 Jun 2008 07:36:40 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 6739C52006F; Fri, 6 Jun 2008 09:36:39 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 42F98FD2A5; Fri, 6 Jun 2008 09:36:39 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: "Bruce M. Simpson" Date: Fri, 6 Jun 2008 09:36:20 +0200 User-Agent: KMail/1.6.2 References: <200806051712.47048.marc.loerner@hob.de> <48480FA5.3020800@FreeBSD.org> In-Reply-To: <48480FA5.3020800@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200806060936.20113.marc.loerner@hob.de> Cc: freebsd-net@freebsd.org Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 07:36:41 -0000 On Thursday 05 June 2008 18:09, Bruce M. Simpson wrote: > Marc Lörner wrote: > > .. > > First of all I have the problam of misalignment of th_off. Because in > > this way always 4 bytes are read and the the bits of th_off are replaced. > > Then the 4 bytes are written back. > > > > But should (th_x and th_off) not only be 1 byte in whole -> only read and > > write 1 byte? > > Which machine architecture are you attempting to compile this code on? > ia64/itanium > On FreeBSD Tier 1 platforms, the access is probably going to come out of > L2 cache anyway, so the fields in question will be read by a burst cycle. > I know! But the problem (on itanium) is that bitfields are always accessed as integers => 4-byte access But th_x/th_off may not always be aligned to 4-bytes => I get an unalignment reference fault If access of th_x/th_off could be changed to 1-byte => 1-byte aligned => my unaligned reference fault would go away > It is worth noting that NetBSD changed the base type of tcphdr's > bitfields to uint8_t, however this shuffles the compiler dependency into > the treatment of the "char" type. Most modern C compilers support > "unsigned char". Does this really change the access to 1-byte? As in "Programming in C" by Kernighan and Ritchie is stated that bitfields must and will always be defined as ints. From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 07:40:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65DEB106566B for ; Fri, 6 Jun 2008 07:40:13 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7368FC0C for ; Fri, 6 Jun 2008 07:40:13 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5E3B3112E71; Fri, 6 Jun 2008 03:40:12 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 06 Jun 2008 03:40:12 -0400 X-Sasl-enc: dvB8Gvl395xe5cW172gANP8OjXxbrSwO3fwBW4/SSoX4 1212738012 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id B6EAADF6E; Fri, 6 Jun 2008 03:40:11 -0400 (EDT) Message-ID: <4848E9DA.8090802@FreeBSD.org> Date: Fri, 06 Jun 2008 08:40:10 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Marc_L=F6rner?= References: <200806051712.47048.marc.loerner@hob.de> <20080605155646.GC6864@epsilon.local> <200806060930.28527.marc.loerner@hob.de> In-Reply-To: <200806060930.28527.marc.loerner@hob.de> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Rui Paulo Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 07:40:13 -0000 Marc L=F6rner wrote: > th_x2 and th_off are created as a bitfield. But C-Standard says that bi= tfields=20 > are accessed as integers =3D> 4-bytes > > On itanium integers are read with ld4-command but the address of th_x2/= th_off=20 > may not be aligned to 4-bytes =3D> we get an unaligned reference fault.= > > If we'd change to 1 byte-accesses =3D> I won't get any misaligned fault= s=20 > anymore. > =20 It's worth noting that Linux implements its version of tcphdr using a=20 32-bit-wide bitfield and the TCP header flags live there as bits instead = of as integer quantities. I think it should be OK to change the u_int to a uint8_t as NetBSD has.=20 The problem with bitfields in "signed char" is that they can become=20 unintentionally sign extended on a read, and for many years compilers=20 only supported "char", not "unsigned char". Does anyone see a reason why we should not make this change? From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 07:49:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C152A10656AD for ; Fri, 6 Jun 2008 07:49:43 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 6A61A8FC22 for ; Fri, 6 Jun 2008 07:49:43 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Whg-0009n8-R5; Fri, 06 Jun 2008 15:49:40 +0800 Message-ID: <4848EC14.8060700@micom.mng.net> Date: Fri, 06 Jun 2008 15:49:40 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080415) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jfv@freebsd.org, "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: MFC of em/igb drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 07:49:43 -0000 Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > MSIX, there will be more server type enhancements in that driver as I get the > time. > > The em driver now will be client oriented, the latest hardware support however > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > that actually also has MSIX. This first released support for it will > use 3 interrupt > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > vectors, so I am planning to add support for another RX and TX queue as my > schedule allows. > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > provides init and an ioctl interface to use that facility, I hope we > see software > support follow on soon. This is an early announcement, I am not sure on > exact dates for availability but they should be soon. > > As ever, issues and bugs should be sent to me. Cheers everyone! > > Jack > Jack, I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943 metric 0 mtu 1500 options=198 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX (autoselect) status: no carrier ... Any idea how to solve this issue? thanks, Ganbold > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- Q: How many pre-med's does it take to change a lightbulb? A: Five: One to change the bulb and four to pull the ladder out from under him. From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 07:52:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81D04106566C for ; Fri, 6 Jun 2008 07:52:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6178FC12 for ; Fri, 6 Jun 2008 07:52:13 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m567qAtO021402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2008 17:52:11 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m567qAOX077716; Fri, 6 Jun 2008 17:52:10 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m567qAfN077715; Fri, 6 Jun 2008 17:52:10 +1000 (EST) (envelope-from peter) Date: Fri, 6 Jun 2008 17:52:10 +1000 From: Peter Jeremy To: Marc =?iso-8859-1?Q?L=F6rner?= Message-ID: <20080606075210.GD67629@server.vk2pj.dyndns.org> References: <200806051712.47048.marc.loerner@hob.de> <20080605155646.GC6864@epsilon.local> <200806060930.28527.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <200806060930.28527.marc.loerner@hob.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 07:52:14 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jun-06 09:30:28 +0200, Marc L=F6rner wrote: >th_x2 and th_off are created as a bitfield. But C-Standard says that >bitfields are accessed as integers =3D> 4-bytes > >On itanium integers are read with ld4-command but the address of >th_x2/th_off may not be aligned to 4-bytes =3D> we get an unaligned >reference fault. If the C compiler chooses to implement bitfields as a subset of a 32-bit integers, it is up to it to load an aligned 32-bit integer and shift/mask the result appropriately to extract the fields. In this particular case, th_x2/th_off are immediately preceeded by a tcp_seq (u_int32_t) field and so will have 32-bit alignment. Note that the presence of 32-bit fields in the definition for struct tcphdr means that the struct must be aligned to at least 32 bits. >If we'd change to 1 byte-accesses =3D> I won't get any misaligned faults= =20 >anymore. I gather from this comment that you have some code using struct tcphdr that is getting alignment errors. struct tcphdr is extensively used in the TCP stack within the kernel so it's likely that any layout or alignment problem with it would show up there. I suspect you are dereferencing a mis-aligned struct tcphdr. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhI7KoACgkQ/opHv/APuIccbwCgtGkXwOIifLt4K4DN0V0VQU6H k6IAn1S0C0soIZdtaesp62Y9g/xVOwN3 =5suD -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 08:25:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF8791065671 for ; Fri, 6 Jun 2008 08:25:58 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 857FD8FC18 for ; Fri, 6 Jun 2008 08:25:58 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id A48A752005A; Fri, 6 Jun 2008 10:25:57 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 0EC0FFD3AA; Fri, 6 Jun 2008 10:25:57 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: Peter Jeremy Date: Fri, 6 Jun 2008 10:25:37 +0200 User-Agent: KMail/1.6.2 References: <200806051712.47048.marc.loerner@hob.de> <200806060930.28527.marc.loerner@hob.de> <20080606075210.GD67629@server.vk2pj.dyndns.org> In-Reply-To: <20080606075210.GD67629@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200806061025.37856.marc.loerner@hob.de> Cc: freebsd-net@freebsd.org Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 08:25:58 -0000 On Friday 06 June 2008 09:52, Peter Jeremy wrote: > On 2008-Jun-06 09:30:28 +0200, Marc Lörner wrote: > >th_x2 and th_off are created as a bitfield. But C-Standard says that > >bitfields are accessed as integers => 4-bytes > > > >On itanium integers are read with ld4-command but the address of > >th_x2/th_off may not be aligned to 4-bytes => we get an unaligned > >reference fault. > > If the C compiler chooses to implement bitfields as a subset of a > 32-bit integers, it is up to it to load an aligned 32-bit integer > and shift/mask the result appropriately to extract the fields. > > In this particular case, th_x2/th_off are immediately preceeded by > a tcp_seq (u_int32_t) field and so will have 32-bit alignment. Note > that the presence of 32-bit fields in the definition for struct tcphdr > means that the struct must be aligned to at least 32 bits. > > >If we'd change to 1 byte-accesses => I won't get any misaligned faults > >anymore. > > I gather from this comment that you have some code using struct tcphdr > that is getting alignment errors. struct tcphdr is extensively used > in the TCP stack within the kernel so it's likely that any layout or > alignment problem with it would show up there. I suspect you are > dereferencing a mis-aligned struct tcphdr. The funny thing is that the dereferencing occurs in "/usr/src/sys/netinet/tcp_input.c" in function tcp_input in line 550: /* * Check that TCP offset makes sense, * pull out TCP options and adjust length. XXX */ off = th->th_off << 2; <----- here if (off < sizeof (struct tcphdr) || off > tlen) { tcpstat.tcps_rcvbadoff++; goto drop; } So the misalignment may probably lie in TCP stack? From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 09:04:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6D6C1065681; Fri, 6 Jun 2008 09:04:52 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 84F408FC18; Fri, 6 Jun 2008 09:04:52 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 692CE1CC031; Fri, 6 Jun 2008 02:04:52 -0700 (PDT) Date: Fri, 6 Jun 2008 02:04:52 -0700 From: Jeremy Chadwick To: Ganbold Message-ID: <20080606090452.GA38593@eos.sc1.parodius.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4848EC14.8060700@micom.mng.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: jfv@freebsd.org, "freebsd-net@freebsd.org" , FreeBSD Stable List , Jack Vogel Subject: Re: MFC of em/igb drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 09:04:52 -0000 On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: > Jack Vogel wrote: >> I got the new drivers in Friday afternoon for those that don't see CVS >> messages. >> >> The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >> MSIX, there will be more server type enhancements in that driver as I get the >> time. >> >> The em driver now will be client oriented, the latest hardware support however >> is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >> that actually also has MSIX. This first released support for it will >> use 3 interrupt >> vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >> vectors, so I am planning to add support for another RX and TX queue as my >> schedule allows. >> >> Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >> provides init and an ioctl interface to use that facility, I hope we >> see software >> support follow on soon. This is an early announcement, I am not sure on >> exact dates for availability but they should be soon. >> >> As ever, issues and bugs should be sent to me. Cheers everyone! > > I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: > ... > em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82566DM Gigabit Network Connection' > class = network > subclass = ethernet > ... > # uname -an > FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 > 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL > i386 > > > It has some problem, 1000baseTX connection status almost never goes to > active in bridged mode, sometimes > it goes to active but then immediately it goes to no carrier. (The other > end is Cisco4507R, Gigabit Ethernet port) > ... > em0: flags=8943 metric 0 > mtu 1500 > options=198 > ether 00:0f:fe:82:23:db > media: Ethernet 1000baseTX (autoselect) > status: no carrier > ... > > Any idea how to solve this issue? Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0="... media 1000baseTX mediaopt full-duplex" Cisco switches have a notorious history of not being "friendly" with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 09:29:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD1D21065684; Fri, 6 Jun 2008 09:29:49 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 542C78FC1B; Fri, 6 Jun 2008 09:29:49 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4YGY-000AXN-BO; Fri, 06 Jun 2008 17:29:46 +0800 Message-ID: <4849038A.5040007@micom.mng.net> Date: Fri, 06 Jun 2008 17:29:46 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080415) MIME-Version: 1.0 To: Jeremy Chadwick References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> In-Reply-To: <20080606090452.GA38593@eos.sc1.parodius.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jfv@freebsd.org, "freebsd-net@freebsd.org" , FreeBSD Stable List , Jack Vogel Subject: Re: MFC of em/igb drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 09:29:49 -0000 Jeremy Chadwick wrote: > On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: > >> Jack Vogel wrote: >> >>> I got the new drivers in Friday afternoon for those that don't see CVS >>> messages. >>> >>> The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >>> MSIX, there will be more server type enhancements in that driver as I get the >>> time. >>> >>> The em driver now will be client oriented, the latest hardware support however >>> is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >>> that actually also has MSIX. This first released support for it will >>> use 3 interrupt >>> vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >>> vectors, so I am planning to add support for another RX and TX queue as my >>> schedule allows. >>> >>> Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >>> provides init and an ioctl interface to use that facility, I hope we >>> see software >>> support follow on soon. This is an early announcement, I am not sure on >>> exact dates for availability but they should be soon. >>> >>> As ever, issues and bugs should be sent to me. Cheers everyone! >>> >> I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: >> ... >> em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82566DM Gigabit Network Connection' >> class = network >> subclass = ethernet >> ... >> # uname -an >> FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 >> 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL >> i386 >> >> >> It has some problem, 1000baseTX connection status almost never goes to >> active in bridged mode, sometimes >> it goes to active but then immediately it goes to no carrier. (The other >> end is Cisco4507R, Gigabit Ethernet port) >> ... >> em0: flags=8943 metric 0 >> mtu 1500 >> options=198 >> ether 00:0f:fe:82:23:db >> media: Ethernet 1000baseTX (autoselect) >> status: no carrier >> ... >> >> Any idea how to solve this issue? >> > > Have you tried disabling speed and duplex negotiation and explicitly > stating speed and duplex like so? > > ifconfig_em0="... media 1000baseTX mediaopt full-duplex" > I tried it and it doesn't work. > Cisco switches have a notorious history of not being "friendly" with > non-Cisco hardware. Forcing duplex on both ends of the link (that means > on both the host side, and the Cisco side!) usually fixes it. > Tried too, doesn't work. Ganbold -- Life is too important to take seriously. -- Corky Siegel From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 10:13:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46095106568C for ; Fri, 6 Jun 2008 10:13:56 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id C0C638FC23 for ; Fri, 6 Jun 2008 10:13:55 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m56ADkGE007707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2008 20:13:52 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m56ADhUa078551; Fri, 6 Jun 2008 20:13:43 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m56ADhrP078550; Fri, 6 Jun 2008 20:13:43 +1000 (EST) (envelope-from peter) Date: Fri, 6 Jun 2008 20:13:43 +1000 From: Peter Jeremy To: Izwan Mohd Message-ID: <20080606101343.GI67629@server.vk2pj.dyndns.org> References: <20080604194059.GE1028@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3O1VwFp74L81IIeR" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: network keep droping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 10:13:56 -0000 --3O1VwFp74L81IIeR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jun-05 12:27:19 +0800, Izwan Mohd wrote: >The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the >model but freebsd detect it as "em0" the server memory is 1GB, not special >network fetures it only running snort and nessus 6.0-RELEASE is very old and no longer supported. There have been lots of bug-fixes since then. I suggest you include an upgrade to 6.3/6.4 or 7.0/7.1 in your forward planning. The em(4) device is quite well supported and maintained (by an Intel employee). There have been major changes to em(4) included in 6.3 and 7.0 and these may correct the problem you are seeing. My initial recommendation would be that you try 6.3 (or 7.0). If that is impractical, you may be able to upgrade the em driver to whilst retaining the rest of your 6.0 system - I haven't tried that but I don't see anything in UPDATING that would rule it out. [The approach would be to checkout a RELENG_6_0_0_RELEASE kernel then update sys/dev/em to RELENG_6_3 and build a new kernel]. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --3O1VwFp74L81IIeR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhJDdcACgkQ/opHv/APuIdlmQCfXwdH7dCflHxN7c9l9eRIoTlR +LEAoKaTWa25AsKjWtwfaTsSdEWiU0+E =fcun -----END PGP SIGNATURE----- --3O1VwFp74L81IIeR-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 12:14:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B641065670; Fri, 6 Jun 2008 12:14:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 662268FC14; Fri, 6 Jun 2008 12:14:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 1FB9A1CC05B; Fri, 6 Jun 2008 05:14:57 -0700 (PDT) Date: Fri, 6 Jun 2008 05:14:57 -0700 From: Jeremy Chadwick To: Ganbold Message-ID: <20080606121457.GA46283@eos.sc1.parodius.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> <4849038A.5040007@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4849038A.5040007@micom.mng.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: jfv@freebsd.org, "freebsd-net@freebsd.org" , FreeBSD Stable List , Jack Vogel Subject: Re: MFC of em/igb drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 12:14:57 -0000 On Fri, Jun 06, 2008 at 05:29:46PM +0800, Ganbold wrote: >> Have you tried disabling speed and duplex negotiation and explicitly >> stating speed and duplex like so? >> >> ifconfig_em0="... media 1000baseTX mediaopt full-duplex" >> > > I tried it and it doesn't work. > >> Cisco switches have a notorious history of not being "friendly" with >> non-Cisco hardware. Forcing duplex on both ends of the link (that means >> on both the host side, and the Cisco side!) usually fixes it. >> > > Tried too, doesn't work. Good to know. Sounds like a driver problem; back to Jack for that one. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 12:15:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D487E1065680 for ; Fri, 6 Jun 2008 12:15:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 61FA38FC1F for ; Fri, 6 Jun 2008 12:15:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m56CF5b6018123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2008 22:15:07 +1000 Date: Fri, 6 Jun 2008 22:15:05 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "Bruce M. Simpson" In-Reply-To: <48480FA5.3020800@FreeBSD.org> Message-ID: <20080606212657.X16250@delplex.bde.org> References: <200806051712.47048.marc.loerner@hob.de> <48480FA5.3020800@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-263961645-1212754505=:16250" Cc: freebsd-net@freebsd.org, =?ISO-8859-1?Q?Marc_L=F6rner?= Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 12:15:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-263961645-1212754505=:16250 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 5 Jun 2008, Bruce M. Simpson wrote: > Marc L=F6rner wrote: >> .. >> First of all I have the problam of misalignment of th_off. Because in th= is=20 >> way always 4 bytes are read and the the bits of th_off are replaced. The= n=20 >> the 4 bytes are written back.=20 >> But should (th_x and th_off) not only be 1 byte in whole -> only read an= d=20 >> write 1 byte? 1 or 2, since struct tcphdr must be 16-bit aligned due to the shorts in it. An unportability in gcc's treatment of bit-fields results in gcc thinking that the struct is 4-byte aligned. Thus alignment traps may occur if an instance of the struct is not in fact aligned. > Which machine architecture are you attempting to compile this code on? [ia64]. > On FreeBSD Tier 1 platforms, the access is probably going to come out of = L2=20 > cache anyway, so the fields in question will be read by a burst cycle. > > It is worth noting that NetBSD changed the base type of tcphdr's bitfield= s to=20 > uint8_t, however this shuffles the compiler dependency into the treatment= of=20 > the "char" type. Most modern C compilers support "unsigned char". No C compilers support bit-fields of type uint8_t (unless _Bool is uint8_t), since C requires bit-fields to have type a possibly-qualified version of _Bool, signed int or insigned int. Howver, the behaviour for other types is unspecified, so the compiler can do anything with them including what broken software wants, so it is really no C programs that use bit-fields of type uint8_t. Bit-fields of type larger than u_int are useful for holding more bits than a u_int (since C unfortunately limits the number of bits in a bit-field to the number in the type of the bit-field, so you can't write u_int foo:64 to get a 64-bit integer), but bit-fields of type smaller than u_int are not very useful -- compilers are free to treat them the same as bit fields of larger type. gcc's actual treatment of bit-fields of type smaller than u_int is unportab= le and apparently undocumented. It affects alignment and the struct size but not padding: e.g., in the following struct: =09struct { =09=09unsigned x:1; =09=09char y; =09} foo; This allocates 1 bit for x and pads to a byte boundary, so that y has offset 1. Any more padding would be bogus. Then, bogusly, due to the bit-field having type unsigned, gcc makes the whole struct have alignment requirements that of u_int and pads the struct at the end to have size a multiple of sizeof(u_int) =3D 32 bits. Then it is justified as accessing foo.x as part of an an aligned object of size 32 bits, and may trap if foo.x is not actually aligned. Something like this happens for struct tcphdr, with the alignment trap actually ocurring on ia64. Some bug elsewhere is responsible for generating a misaligned struct. OTOH, if `unsigned' in the above is changed to `unsigned char', giving a non-C program: =09struct { =09=09unsigned char x:1; =09=09char y; =09} foo; then all the padding is non-bogus when this is compiled by the non-C compiler gcc: the offset of y is unchanged, but now the struct has size 2 and alignment 1. Due to unportabilities like this, bit-fields should never be used when the layout of an object must be controlled precisely. This includes layouts related to hardware which includes most network layouts. Unportabilities like this are sometimes hacked around using packed structs. ipv6 headers do this a lot. ipv4 headers are not so bad. ip.h now says `__packed __aligned(4)' for struct ip where it used to say just `__packed' __packed forces 1-byte alignment for everything. On ia64, this results in specially pessimized accesses for all the fields in a struct, with 1- byte accesses even for the 32-bit fields and large code to combine the bytes into a word. But struct ip (unlike struct tcphdr?) must always be 32-bit aligned, and declaring it as __aligned(4) is supposed to restore the possibility of wide accesses after declaration it as __packed forces it to have no padding. No padding should occur automatically, and the u_int bit-fields don't affect this since the size of struct ip is 20, but there is a another problem with bogus padding at the end (on arm only?). Bruce --0-263961645-1212754505=:16250-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 12:25:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049EA1065678 for ; Fri, 6 Jun 2008 12:25:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 728AC8FC22 for ; Fri, 6 Jun 2008 12:25:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m56CPbXS030742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2008 22:25:38 +1000 Date: Fri, 6 Jun 2008 22:25:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Marc =?iso-8859-1?q?L=F6rner?= In-Reply-To: <200806061025.37856.marc.loerner@hob.de> Message-ID: <20080606221917.A16250@delplex.bde.org> References: <200806051712.47048.marc.loerner@hob.de> <200806060930.28527.marc.loerner@hob.de> <20080606075210.GD67629@server.vk2pj.dyndns.org> <200806061025.37856.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1804253105-1212755137=:16250" Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: Probable Bug in tcp.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 12:25:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1804253105-1212755137=:16250 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 6 Jun 2008, Marc [iso-8859-1] L=F6rner wrote: > On Friday 06 June 2008 09:52, Peter Jeremy wrote: >> I gather from this comment that you have some code using struct tcphdr >> that is getting alignment errors. struct tcphdr is extensively used >> in the TCP stack within the kernel so it's likely that any layout or >> alignment problem with it would show up there. I suspect you are >> dereferencing a mis-aligned struct tcphdr. > > The funny thing is that the dereferencing occurs in > "/usr/src/sys/netinet/tcp_input.c" in function tcp_input in line 550: > > =09/* > =09 * Check that TCP offset makes sense, > =09 * pull out TCP options and adjust length.=09=09XXX > =09 */ > =09off =3D th->th_off << 2;=09=09=09=09=09=09=09=09<----- here > =09if (off < sizeof (struct tcphdr) || off > tlen) { > =09=09tcpstat.tcps_rcvbadoff++; > =09=09goto drop; > =09} > > So the misalignment may probably lie in TCP stack? Quite likely. th is normally at offset off0 in ip, where ip is required to be 32-bit aligned (see my previous reply). You can see off0 in a stack trace. Bruce --0-1804253105-1212755137=:16250-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 16:47:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A34E1065670 for ; Fri, 6 Jun 2008 16:47:51 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id BC2D28FC2A for ; Fri, 6 Jun 2008 16:47:50 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 1137 invoked from network); 6 Jun 2008 16:21:08 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Jun 2008 16:21:08 -0000 Date: Fri, 06 Jun 2008 18:21:08 +0200 (CEST) Message-Id: <20080606.182108.74659907.sthaug@nethelp.no> To: koitsu@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <20080606090452.GA38593@eos.sc1.parodius.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: MFC of em/igb drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 16:47:51 -0000 > Have you tried disabling speed and duplex negotiation and explicitly > stating speed and duplex like so? > > ifconfig_em0="... media 1000baseTX mediaopt full-duplex" Disagree with this piece of advice. > Cisco switches have a notorious history of not being "friendly" with > non-Cisco hardware. Forcing duplex on both ends of the link (that means > on both the host side, and the Cisco side!) usually fixes it. I might have said the same myself five years ago. But this is 2008, and we have autoneg as default on all ports (even at 100 Mbps). Our Cisco switch ports (and we have a *lot* of them) work just fine with autoneg. Note that GigE is different from FE here - autoneg is a compulsory part of the GigE standard, while it's not compulsory for FE. The only GigE ports that have needed anything else were some pre-standard GigE ports. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 20:18:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C921065678 for ; Fri, 6 Jun 2008 20:18:45 +0000 (UTC) (envelope-from mainland@eecs.harvard.edu) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.freebsd.org (Postfix) with ESMTP id A16D58FC1B for ; Fri, 6 Jun 2008 20:18:45 +0000 (UTC) (envelope-from mainland@eecs.harvard.edu) Received: from minipax.eecs.harvard.edu (minipax.eecs.harvard.edu [140.247.60.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.eecs.harvard.edu (Postfix) with ESMTP id 6BC061A3C87; Fri, 6 Jun 2008 16:02:00 -0400 (EDT) Message-ID: <484997B1.5020708@eecs.harvard.edu> Date: Fri, 06 Jun 2008 16:01:53 -0400 From: Geoffrey Mainland User-Agent: Thunderbird 2.0.0.14 (X11/20080503) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Major Atheros issues with Ubiquiti SR9/XR9 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 20:18:45 -0000 Hi, I'm running 7-CURRENT on several ALIX 3c2 boards with SR9 radios and having major performance problems: throughput on TCP streams generated by iperf often falls to zero, and, depending on the HAL I use, I see ping latencies during one of these iperf transfers of up to more than a *minute*. I've tried both the 0.9.30.13 HAL and the new 0.10.5.6 HAL. I see this bad behavior with both, but the new HAL seems even worse. I've documented my configuration and the test results at http://www.eecs.harvard.edu/~mainland/freebsd/sr9/. This includes the kernel configuration, dmesg output, pciconf output, rc.conf, athstats output, appropriate sysctl values, iperf/ping output generated by my driver script and some plots showing the problem. We are trying to deploy a bunch of these nodes outdoors, using the 900MHz radios as a backhaul, so the drop-outs I see with SR9s are a major problem for us. I've also run the same tests on Soekris nodes, used different SR9s, and also tried the new XR9s on the same ALIX boards---all with similar results. We also have a bunch of Wistrom CM9s which seem to work just fine. Any idea what could be going on? Thanks! Geoff From owner-freebsd-net@FreeBSD.ORG Fri Jun 6 23:30:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99FBF106566C for ; Fri, 6 Jun 2008 23:30:34 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from infoweapons.com (mail0.infoweapons.com [204.2.248.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDD08FC26 for ; Fri, 6 Jun 2008 23:30:34 +0000 (UTC) (envelope-from agaviola@infoweapons.com) Received: from ([58.71.34.138]) by mail0.infoweapons.com with ESMTP with TLS id 4321444.282173; Fri, 06 Jun 2008 19:30:07 -0400 Message-ID: <4849C87F.9030804@infoweapons.com> Date: Sat, 07 Jun 2008 07:30:07 +0800 From: "Archimedes S. Gaviola" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Removal of mrouted in FreeBSD-7.0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 23:30:34 -0000 To Whom It May Concerned: Hi! I have just read from the FreeBSD-7.0 release notes http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted multicast routing protocol (DVMRP implementation) has been removed from the base system. I want to know what multicast routing protocol will served as replacement to this? The KAME snap kit have PIM-SM and PIM-DM implementations but are specific only to IPv6. Thanks, Archimedes From owner-freebsd-net@FreeBSD.ORG Sat Jun 7 04:45:21 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C66821065674; Sat, 7 Jun 2008 04:45:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A47648FC0A; Sat, 7 Jun 2008 04:45:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m574jLVE018742; Sat, 7 Jun 2008 04:45:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m574jLQm018738; Sat, 7 Jun 2008 04:45:21 GMT (envelope-from linimon) Date: Sat, 7 Jun 2008 04:45:21 GMT Message-Id: <200806070445.m574jLQm018738@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/124341: [ral] promiscuous mode for wireless device ral0 looses signal after ~30 mins (airodump-ng loses all stations after ~30 minutes) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2008 04:45:21 -0000 Old Synopsis: promiscuous mode for wireless device ral0 looses signal after ~30 mins (airodump-ng loses all stations after ~30 minutes) New Synopsis: [ral] promiscuous mode for wireless device ral0 looses signal after ~30 mins (airodump-ng loses all stations after ~30 minutes) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jun 7 04:44:24 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124341 From owner-freebsd-net@FreeBSD.ORG Sat Jun 7 05:31:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66ADC10656AE for ; Sat, 7 Jun 2008 05:31:46 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.200.14]) by mx1.freebsd.org (Postfix) with ESMTP id AB4B88FC14 for ; Sat, 7 Jun 2008 05:31:45 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:5573 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S8372546AbYFGFVD (ORCPT ); Sat, 7 Jun 2008 09:21:03 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp1 X-Yandex-TimeMark: 1212816063 X-MsgDayCount: 4 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: bu7cher Message-ID: <484A1ABB.2080501@yandex.ru> Date: Sat, 07 Jun 2008 09:20:59 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: "Archimedes S. Gaviola" References: <4849C87F.9030804@infoweapons.com> In-Reply-To: <4849C87F.9030804@infoweapons.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [Removal of mrouted in FreeBSD-7.0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2008 05:31:46 -0000 Archimedes S. Gaviola wrote: > To Whom It May Concerned: > > Hi! I have just read from the FreeBSD-7.0 release notes > http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted > multicast routing protocol (DVMRP implementation) has been removed from > the base system. If you want to use mrouted, you can install it from ports/net/mrouted. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Sat Jun 7 08:42:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95031065670 for ; Sat, 7 Jun 2008 08:42:01 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A58FC8FC12 for ; Sat, 7 Jun 2008 08:42:01 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id D6F541126AD; Sat, 7 Jun 2008 04:42:00 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 07 Jun 2008 04:42:00 -0400 X-Sasl-enc: LwafDAK+cSjqKbIDI36zvlWQpI0g+tsJMJZA8mgdeTPh 1212828120 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 54C1D27421; Sat, 7 Jun 2008 04:42:00 -0400 (EDT) Message-ID: <484A49D6.1000808@FreeBSD.org> Date: Sat, 07 Jun 2008 09:41:58 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: "Archimedes S. Gaviola" References: <4849C87F.9030804@infoweapons.com> In-Reply-To: <4849C87F.9030804@infoweapons.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [Removal of mrouted in FreeBSD-7.0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2008 08:42:02 -0000 Archimedes S. Gaviola wrote: > Hi! I have just read from the FreeBSD-7.0 release notes > http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted > multicast routing protocol (DVMRP implementation) has been removed > from the base system. I want to know what multicast routing protocol > will served as replacement to this? The KAME snap kit have PIM-SM and > PIM-DM implementations but are specific only to IPv6. DVMRP is something of a legacy protocol now, most deployments use PIM-SM. mrouted is still available in ports as other folk have pointed out If you want a freely available router with full multicast capability, please give XORP a try. From owner-freebsd-net@FreeBSD.ORG Sat Jun 7 21:34:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B66F1065674; Sat, 7 Jun 2008 21:34:36 +0000 (UTC) (envelope-from daniel@skytek.it) Received: from mail.skytek.it (mail.skytek.it [217.194.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id DBA6A8FC12; Sat, 7 Jun 2008 21:34:35 +0000 (UTC) (envelope-from daniel@skytek.it) Received: from [192.168.30.100] ([192.168.30.100]) by mail.skytek.it (Skytek Mail Server v.11.47-p9) with ASMTP id NBP18835; Sat, 07 Jun 2008 23:34:35 +0200 Message-ID: <484AFEF1.4040500@skytek.it> Date: Sat, 07 Jun 2008 23:34:41 +0200 From: Daniel Ponticello User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kernel panic on em0/taskq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2008 21:34:36 -0000 Hello, i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. My big problem is that the system is not performing memory dumping and/or automatic reoboot, it just stays there. Here' console output: em0: watchdog timeout -- resetting kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic_id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present intruction pointerr = 0x20:0xc056e2ce stack pointer = 0x28:0xe537fc08 frame pointer = 0x28:0xe537fc28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 29 (em0 taskq) trap number = 12 panic: page fault cpuid = 0 It just stays there, unresponsive (no automatic reboot). Any ideas? Thanks, Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it ---