From owner-freebsd-net Fri May 25 16:59:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id BCBF837B423 for ; Fri, 25 May 2001 16:59:40 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org ([134.68.31.99]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f4Q02BX19809; Fri, 25 May 2001 19:02:14 -0500 Message-ID: <3B0EF1DE.84C68B2F@aurora.regenstrief.org> Date: Fri, 25 May 2001 23:59:26 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hay Cc: freebsd-net@FreeBSD.ORG Subject: Re: NetWare / IPX routing facts and a question References: <200105251917.f4PJH7f93967@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Hay wrote: > > > Here is a patch that I'm running. The problem is that on a large network > > > the SAP table can grow very large and take a long time to be transmitted. > > > (Only 7 SAP entries fit into a packet and you need to space them 50ms > > > apart.) The current code will do it in one go, but during that time it > > > will not read any received packets so the input buffers can overflow. The > > > patch will check for received packets between each SAP broadcast and > > > process them. > > > > Hmm, how would this problem become manifest? It would seem that ... > It depends on which packets got lost in the receive buffer overrun. If > it was SAP packets, you wouldn't see the machine anymore, although you > would be able to get to it if you use the ipx address. If it was the > RIP packets that got lost, you would see the machine, but wouldn't be > able to connect to it. Hi John, I tried you patch but still without luck. A listing of servers will show a server, then if you right click on it to login, it takes forever and all of the Windoze client hangs until finally the pop-up menu appears. If I then click "Login to server" it immediately knows that I cannot connect. I assume that on right click it has started searching for that server and then can't find it. After a very long time has passed with frequent retrials and doing other stuff, suddenly the login may work (but then quite likely this Revelation IPX database will not work anyway.) What is wrong there? Is FreeBSD simply very slow to route IPX? A bug? This is so strange. I go ahead and try debugging with some unix level tools to see whether this is a windoze problem. The routing table is 2227 entries long. Is that too much for FreeBSD to handle? Do I have to change some buffer sizes or something? regards -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message