From owner-freebsd-firewire@FreeBSD.ORG Mon Aug 9 03:06:30 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4FC216A4CE for ; Mon, 9 Aug 2004 03:06:30 +0000 (GMT) Received: from smtp2.jp.viruscheck.net (smtp2.jp.viruscheck.net [154.33.69.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6756143D55 for ; Mon, 9 Aug 2004 03:06:30 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from scan4.jp.viruscheck.net ([154.33.69.39] helo=mail4.jp.viruscheck.net) by smtp2.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1Bu0UW-0002uz-00 for freebsd-firewire@freebsd.org; Mon, 09 Aug 2004 12:06:28 +0900 Received: from [220.221.2.219] (helo=noc.orchid) by mail4.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1Bu0UW-0005m8-00 for freebsd-firewire@FreeBSD.org; Mon, 09 Aug 2004 12:06:28 +0900 Received: from [89.60.10.11] (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id i7936Rwb094792 for ; Mon, 9 Aug 2004 12:06:27 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <4116EA33.8040405@FreeBSD.org> Date: Mon, 09 Aug 2004 12:06:27 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-firewire@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 03:06:30 -0000 Hi again, Is there any reason why we do not support MTUs higher than 1500 bytes on firewire links? Thanks, Alexander. From owner-freebsd-firewire@FreeBSD.ORG Mon Aug 9 07:59:35 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 215FD16A4CE; Mon, 9 Aug 2004 07:59:35 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EBA543D31; Mon, 9 Aug 2004 07:59:34 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i797xUvl064326; Mon, 9 Aug 2004 08:59:30 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-firewire@freebsd.org Date: Mon, 9 Aug 2004 08:59:34 +0100 User-Agent: KMail/1.6.2 References: <4116EA33.8040405@FreeBSD.org> In-Reply-To: <4116EA33.8040405@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <200408090859.34574.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: Alexander Nedotsukov Subject: Re: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 07:59:35 -0000 On Monday 09 August 2004 04:06, Alexander Nedotsukov wrote: > Hi again, > Is there any reason why we do not support MTUs higher than 1500 bytes > on firewire links? Basically, we are limited by the specification. The rfc states that the default MTU should be 1500 bytes. From the spec: "NOTE: IP-capable nodes may operate with an MTU size larger than the default, but the means by which a larger MTU is configured are beyond the scope of this document." From owner-freebsd-firewire@FreeBSD.ORG Mon Aug 9 10:23:14 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E96C416A4CE for ; Mon, 9 Aug 2004 10:23:14 +0000 (GMT) Received: from hermes4.uws-edv.de (hermes4.uws-edv.de [194.8.213.87]) by mx1.FreeBSD.org (Postfix) with SMTP id 307F043D1F for ; Mon, 9 Aug 2004 10:23:14 +0000 (GMT) (envelope-from oliver.hoffmann@uw-service.de) Received: (qmail 15454 invoked by uid 83); 9 Aug 2004 10:21:39 -0000 Received: from unknown (HELO hoffmann.uwskoeln.de) (192.168.8.99) by 192.168.8.93 with SMTP; 9 Aug 2004 10:21:39 -0000 From: Oliver Hoffmann Organization: UW Service To: freebsd-firewire@freebsd.org Date: Mon, 9 Aug 2004 12:23:45 +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: <200408091223.45993.oliver.hoffmann@uw-service.de> Subject: Odd Problems with second FW-device X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: oliver.hoffmann@uw-service.de List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 10:23:15 -0000 Hi all! I have a fileserver with a raid-system and two FW-harddisks for backups. The first HD is for daily the second for monthly backups. If there are two partitioned HDs in then everything is ok. The devices looked like this: da0 the second FW-HD da1 the first FW-HD da2 the raid Yesterday I put in a new disk which was not partitioned. I started sysinstall and my first one switched from da1 to da0, the new one wanted to be da1. I didn't want that because I had to rewrite my scripts then. Thus I switched off the first and started sysinstall again. It crashed. Means it hung with scanning devices and due to a D in the process list it was unkillable. I did several busresets. After a while it was impossible to login at the console. A ssh-connection was still there but died when I typed in ps ax. smb users could work but no new connections could be made. That means all processes went on but the system wasn't able to start new ones. I had that problem a few months ago and I thought it has something to do with the hardware (RAM?). I replaced the whole server. Now this odd behavior seems to be caused by the fw-system. Could that be? Next I had to reset of course. I saw that the fw-devices are always there before the raid because the system waits 15s to let the SCSI devices settle down. I often run into problems while booting because of that. The raid has certainly not a noauto in the /etc/fstab and a displacing of the device assignment is always annoying. Is there a way to assign all the fw-devices at the end of the booting process to avoid this? Now da0 is my fw, da1 my raid and da2 will be my fw2 (I don't dare to put in the blank disk again). That means next time I reboot a have to let the fw switched on to get no device-confusion. And I have to prepare every blank disk in another (non-critical) system. Every help will be gratefully appreciated!! Thanks. Regards, Oliver From owner-freebsd-firewire@FreeBSD.ORG Tue Aug 10 03:41:59 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FA2A16A4CE for ; Tue, 10 Aug 2004 03:41:59 +0000 (GMT) Received: from smtp4.jp.viruscheck.net (smtp4.jp.viruscheck.net [154.33.69.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id E03D643D2F for ; Tue, 10 Aug 2004 03:41:58 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from scan4.jp.viruscheck.net ([154.33.69.39] helo=mail4.jp.viruscheck.net) by smtp4.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1BuNWJ-0002bl-00; Tue, 10 Aug 2004 12:41:51 +0900 Received: from [220.221.2.219] (helo=noc.orchid) by mail4.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1BuNWJ-0003Ff-00; Tue, 10 Aug 2004 12:41:51 +0900 Received: from [89.60.10.11] (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id i7A3fnAB079447; Tue, 10 Aug 2004 12:41:50 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <411843FD.4090201@FreeBSD.org> Date: Tue, 10 Aug 2004 12:41:49 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <4116EA33.8040405@FreeBSD.org> <200408090859.34574.dfr@nlsystems.com> In-Reply-To: <200408090859.34574.dfr@nlsystems.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-firewire@FreeBSD.org Subject: Re: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 03:41:59 -0000 Doug Rabson wrote: >On Monday 09 August 2004 04:06, Alexander Nedotsukov wrote: > > >>Hi again, >>Is there any reason why we do not support MTUs higher than 1500 bytes >>on firewire links? >> >> > >Basically, we are limited by the specification. The rfc states that the >default MTU should be 1500 bytes. From the spec: "NOTE: IP-capable >nodes may operate with an MTU size larger than the default, but the >means by which a larger MTU is configured are beyond the scope of this >document." > > Well standards are good. But I don't see any restriction here. In fact I belive that effective MTU should be evaluated from maximum payload table (RFC2734 Table 1) and ieee1394 header size. Anyway this 1500 which comes from 10Mbit ethernet land may be good for default but manual configuration should not be prohibited. Btw default MTU size on MacOSX for fw? interface is 2030 which is 10 bytes less that theoretical maximum for S400 async stream. All the best, Alexander. From owner-freebsd-firewire@FreeBSD.ORG Tue Aug 10 07:51:32 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B556616A4CE; Tue, 10 Aug 2004 07:51:32 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9441543D3F; Tue, 10 Aug 2004 07:51:31 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7A7pR0o075106; Tue, 10 Aug 2004 08:51:27 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Alexander Nedotsukov Date: Tue, 10 Aug 2004 08:51:32 +0100 User-Agent: KMail/1.6.2 References: <4116EA33.8040405@FreeBSD.org> <200408090859.34574.dfr@nlsystems.com> <411843FD.4090201@FreeBSD.org> In-Reply-To: <411843FD.4090201@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <200408100851.32087.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: freebsd-firewire@FreeBSD.org Subject: Re: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 07:51:32 -0000 On Tuesday 10 August 2004 04:41, Alexander Nedotsukov wrote: > Doug Rabson wrote: > >On Monday 09 August 2004 04:06, Alexander Nedotsukov wrote: > >>Hi again, > >>Is there any reason why we do not support MTUs higher than 1500 > >> bytes on firewire links? > > > >Basically, we are limited by the specification. The rfc states that > > the default MTU should be 1500 bytes. From the spec: "NOTE: > > IP-capable nodes may operate with an MTU size larger than the > > default, but the means by which a larger MTU is configured are > > beyond the scope of this document." > > Well standards are good. But I don't see any restriction here. In > fact I belive that effective MTU should be evaluated from maximum > payload table (RFC2734 Table 1) and ieee1394 header size. Anyway this > 1500 which comes from 10Mbit ethernet land may be good for default > but manual configuration should not be prohibited. > > Btw default MTU size on MacOSX for fw? interface is 2030 which is 10 > bytes less that theoretical maximum for S400 async stream. > Interesting. The specification for IPv6 on firewire is clearer: The default MTU size for IPv6 packets on an IEEE1394 network is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on an IEEE1394 interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but MUST be otherwise ignored. The mechanism to extend MTU size between particular two nodes is for further study. From owner-freebsd-firewire@FreeBSD.ORG Tue Aug 10 09:13:00 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C401116A4CF for ; Tue, 10 Aug 2004 09:13:00 +0000 (GMT) Received: from smtp4.jp.viruscheck.net (smtp4.jp.viruscheck.net [154.33.69.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AAAB43D48 for ; Tue, 10 Aug 2004 09:13:00 +0000 (GMT) (envelope-from bland@freebsd.org) Received: from scan3.jp.viruscheck.net ([154.33.69.38] helo=mail5.jp.viruscheck.net) by smtp4.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1BuSgk-0003EK-00; Tue, 10 Aug 2004 18:12:58 +0900 Received: from [220.221.2.219] (helo=noc.orchid) by mail5.jp.viruscheck.net with esmtp (Exim 3.36 #2) id 1BuSgk-00013I-00; Tue, 10 Aug 2004 18:12:58 +0900 Received: from [89.60.10.11] (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id i7A9CvoY080388; Tue, 10 Aug 2004 18:12:57 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <41189199.5020201@FreeBSD.org> Date: Tue, 10 Aug 2004 18:12:57 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <4116EA33.8040405@FreeBSD.org> <200408090859.34574.dfr@nlsystems.com> <411843FD.4090201@FreeBSD.org> <200408100851.32087.dfr@nlsystems.com> In-Reply-To: <200408100851.32087.dfr@nlsystems.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-firewire@FreeBSD.org Subject: Re: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 09:13:00 -0000 Doug Rabson wrote: >On Tuesday 10 August 2004 04:41, Alexander Nedotsukov wrote: > > >>Doug Rabson wrote: >> >> >>>On Monday 09 August 2004 04:06, Alexander Nedotsukov wrote: >>> >>> >>>>Hi again, >>>>Is there any reason why we do not support MTUs higher than 1500 >>>>bytes on firewire links? >>>> >>>> >>>Basically, we are limited by the specification. The rfc states that >>>the default MTU should be 1500 bytes. From the spec: "NOTE: >>>IP-capable nodes may operate with an MTU size larger than the >>>default, but the means by which a larger MTU is configured are >>>beyond the scope of this document." >>> >>> >>Well standards are good. But I don't see any restriction here. In >>fact I belive that effective MTU should be evaluated from maximum >>payload table (RFC2734 Table 1) and ieee1394 header size. Anyway this >>1500 which comes from 10Mbit ethernet land may be good for default >>but manual configuration should not be prohibited. >> >>Btw default MTU size on MacOSX for fw? interface is 2030 which is 10 >>bytes less that theoretical maximum for S400 async stream. >> >> >> > >Interesting. The specification for IPv6 on firewire is clearer: > > The default MTU size for IPv6 packets on an IEEE1394 network is 1500 > octets. This size may be reduced by a Router Advertisement [DISC] > containing an MTU option which specifies a smaller MTU, or by manual > configuration of each node. If a Router Advertisement received on an > IEEE1394 interface has an MTU option specifying an MTU larger than > 1500, or larger than a manually configured value, that MTU option may > be logged to system management but MUST be otherwise ignored. The > mechanism to extend MTU size between particular two nodes is for > further study. > > Mmm. I still do not see any prohibition of MTU size > 1500. What I see here is definition of automatic MTU adjustment. It's stated that ATM MTU size may be only reduced by such mechanism. Am I right? So manual configuration of interface for MTU size > 1500 violates nothing. All the best, Alexander. From owner-freebsd-firewire@FreeBSD.ORG Tue Aug 10 10:27:37 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A57EB16A4CE; Tue, 10 Aug 2004 10:27:37 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id C57BF43D1F; Tue, 10 Aug 2004 10:27:36 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i7AARZGR018894; Tue, 10 Aug 2004 11:27:35 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i7AARYfJ031084; Tue, 10 Aug 2004 11:27:35 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Alexander Nedotsukov In-Reply-To: <41189199.5020201@FreeBSD.org> References: <4116EA33.8040405@FreeBSD.org> <411843FD.4090201@FreeBSD.org><41189199.5020201@FreeBSD.org> Content-Type: text/plain Message-Id: <1092133653.13089.0.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 11:27:34 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-firewire@freebsd.org Subject: Re: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 10:27:37 -0000 On Tue, 2004-08-10 at 10:12, Alexander Nedotsukov wrote: > Doug Rabson wrote: > > >On Tuesday 10 August 2004 04:41, Alexander Nedotsukov wrote: > > > > > >>Doug Rabson wrote: > >> > >> > >>>On Monday 09 August 2004 04:06, Alexander Nedotsukov wrote: > >>> > >>> > >>>>Hi again, > >>>>Is there any reason why we do not support MTUs higher than 1500 > >>>>bytes on firewire links? > >>>> > >>>> > >>>Basically, we are limited by the specification. The rfc states that > >>>the default MTU should be 1500 bytes. From the spec: "NOTE: > >>>IP-capable nodes may operate with an MTU size larger than the > >>>default, but the means by which a larger MTU is configured are > >>>beyond the scope of this document." > >>> > >>> > >>Well standards are good. But I don't see any restriction here. In > >>fact I belive that effective MTU should be evaluated from maximum > >>payload table (RFC2734 Table 1) and ieee1394 header size. Anyway this > >>1500 which comes from 10Mbit ethernet land may be good for default > >>but manual configuration should not be prohibited. > >> > >>Btw default MTU size on MacOSX for fw? interface is 2030 which is 10 > >>bytes less that theoretical maximum for S400 async stream. > >> > >> > >> > > > >Interesting. The specification for IPv6 on firewire is clearer: > > > > The default MTU size for IPv6 packets on an IEEE1394 network is 1500 > > octets. This size may be reduced by a Router Advertisement [DISC] > > containing an MTU option which specifies a smaller MTU, or by manual > > configuration of each node. If a Router Advertisement received on an > > IEEE1394 interface has an MTU option specifying an MTU larger than > > 1500, or larger than a manually configured value, that MTU option may > > be logged to system management but MUST be otherwise ignored. The > > mechanism to extend MTU size between particular two nodes is for > > further study. > > > > > Mmm. I still do not see any prohibition of MTU size > 1500. What I see > here is definition of automatic MTU adjustment. It's stated that ATM MTU > size may be only reduced by such mechanism. Am I right? > So manual configuration of interface for MTU size > 1500 violates nothing. Of course - I certainly don't want to stop people from configuring an MTU size > 1500. I just think that for the compiled in default, we should go with the spec for now. From owner-freebsd-firewire@FreeBSD.ORG Tue Aug 10 10:33:30 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA41716A4CE for ; Tue, 10 Aug 2004 10:33:30 +0000 (GMT) Received: from bbnest.net (r135052.ap.plala.or.jp [220.108.135.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C58643D1F for ; Tue, 10 Aug 2004 10:33:30 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from [127.0.0.1] (bland@localhost [127.0.0.1]) by bbnest.net (8.13.1/8.13.1) with ESMTP id i7AAXGPG002136; Tue, 10 Aug 2004 19:33:17 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <4118A46B.9030901@FreeBSD.org> Date: Tue, 10 Aug 2004 19:33:15 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <4116EA33.8040405@FreeBSD.org> <200408090859.34574.dfr@nlsystems.com> <411843FD.4090201@FreeBSD.org> <200408100851.32087.dfr@nlsystems.com> <41189199.5020201@FreeBSD.org> <1092133653.13089.0.camel@builder02.qubesoft.com> In-Reply-To: <1092133653.13089.0.camel@builder02.qubesoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-firewire@FreeBSD.org Subject: Re: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 10:33:31 -0000 >>>Interesting. The specification for IPv6 on firewire is clearer: >>> >>> The default MTU size for IPv6 packets on an IEEE1394 network is 1500 >>> octets. This size may be reduced by a Router Advertisement [DISC] >>> containing an MTU option which specifies a smaller MTU, or by manual >>> configuration of each node. If a Router Advertisement received on an >>> IEEE1394 interface has an MTU option specifying an MTU larger than >>> 1500, or larger than a manually configured value, that MTU option may >>> be logged to system management but MUST be otherwise ignored. The >>> mechanism to extend MTU size between particular two nodes is for >>> further study. >>> >>> >>> >>> >>Mmm. I still do not see any prohibition of MTU size > 1500. What I see >>here is definition of automatic MTU adjustment. It's stated that ATM MTU >>size may be only reduced by such mechanism. Am I right? >>So manual configuration of interface for MTU size > 1500 violates nothing. >> >> > >Of course - I certainly don't want to stop people from configuring an >MTU size > 1500. I just think that for the compiled in default, we >should go with the spec for now. > > > I do not object default MTU either. But the problem is we have hardcoded 1500 limit in SIOCSIFMTU ioctl handler ATM. Check sys/net/if_fwsubr.c ;-) From owner-freebsd-firewire@FreeBSD.ORG Tue Aug 10 11:06:03 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5A4B16A4CE; Tue, 10 Aug 2004 11:06:03 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED6F643D41; Tue, 10 Aug 2004 11:06:02 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i7AB62GR020245; Tue, 10 Aug 2004 12:06:02 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i7AB61fJ031820; Tue, 10 Aug 2004 12:06:02 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Alexander Nedotsukov In-Reply-To: <4118A46B.9030901@FreeBSD.org> References: <4116EA33.8040405@FreeBSD.org> <411843FD.4090201@FreeBSD.org><41189199.5020201@FreeBSD.org> <1092133653.13089.0.camel@builder02.qubesoft.com> <4118A46B.9030901@FreeBSD.org> Content-Type: text/plain Message-Id: <1092135961.13089.2.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 12:06:01 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-firewire@FreeBSD.org Subject: Re: max MTU for fwip device. X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 11:06:03 -0000 On Tue, 2004-08-10 at 11:33, Alexander Nedotsukov wrote: > >>>Interesting. The specification for IPv6 on firewire is clearer: > >>> > >>> The default MTU size for IPv6 packets on an IEEE1394 network is 1500 > >>> octets. This size may be reduced by a Router Advertisement [DISC] > >>> containing an MTU option which specifies a smaller MTU, or by manual > >>> configuration of each node. If a Router Advertisement received on an > >>> IEEE1394 interface has an MTU option specifying an MTU larger than > >>> 1500, or larger than a manually configured value, that MTU option may > >>> be logged to system management but MUST be otherwise ignored. The > >>> mechanism to extend MTU size between particular two nodes is for > >>> further study. > >>> > >>> > >>> > >>> > >>Mmm. I still do not see any prohibition of MTU size > 1500. What I see > >>here is definition of automatic MTU adjustment. It's stated that ATM MTU > >>size may be only reduced by such mechanism. Am I right? > >>So manual configuration of interface for MTU size > 1500 violates nothing. > >> > >> > > > >Of course - I certainly don't want to stop people from configuring an > >MTU size > 1500. I just think that for the compiled in default, we > >should go with the spec for now. > > > > > > > I do not object default MTU either. But the problem is we have hardcoded > 1500 limit in SIOCSIFMTU ioctl handler ATM. Check sys/net/if_fwsubr.c ;-) Oops - I'll fix that when I get a chance. I've been side-tracked recently trying to finish off the TLS stuff.