From vk@vk.pp.ru  Fri Nov 19 06:59:29 2004
Return-Path: <vk@vk.pp.ru>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 58ABF16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 19 Nov 2004 06:59:29 +0000 (GMT)
Received: from dss.kbb.ru (dss.kbb.ru [217.116.159.103])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 51E4543D2F
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 19 Nov 2004 06:59:27 +0000 (GMT)
	(envelope-from vk@vk.pp.ru)
Received: from dss.kbb.ru (localhost.kbb.ru [127.0.0.1])
	by dss.kbb.ru (8.13.1/8.13.1) with ESMTP id iAJ6xC4h086147;
	Fri, 19 Nov 2004 13:59:13 +0700 (NKZ)
	(envelope-from vk@vk.pp.ru)
Received: (from vk@localhost)
	by dss.kbb.ru (8.13.1/8.13.1/Submit) id iAJ6x8SB086144
	for bp@butya.kz; Fri, 19 Nov 2004 13:59:08 +0700 (NKZ)
	(envelope-from vk@vk.pp.ru)
Message-Id: <200411180445.iAI4jLPC002002@fbsd5.kbb.kemerovo.su>
Date: Thu, 18 Nov 2004 11:45:21 +0700 (NKZ)
From: Vladimir Kurtukov <vk@vk.pp.ru>
Reply-To: Vladimir Kurtukov <vk@vk.pp.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: IPX protocol support doesn't work
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         74105
>Category:       kern
>Synopsis:       [ipx] IPX protocol support doesn't work
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    rwatson
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 19 07:00:49 GMT 2004
>Closed-Date:    Sun Jan 13 15:35:46 UTC 2008
>Last-Modified:  Sun Jan 13 15:35:46 UTC 2008
>Originator:     Vladimir Kurtukov
>Release:        FreeBSD 5.3-RELEASE i386
>Organization:
KBB
>Environment:
System: FreeBSD fbsd5.kbb.kemerovo.su 5.3-RELEASE FreeBSD 5.3-RELEASE #2: Thu Nov 18 09:22:33 NKZ 2004 vk@fbsd5.kbb.kemerovo.su:/usr/obj/usr/src/sys/TEST i386

world compiled with 
CPUTYPE=p2
CFLAGS= -O -pipe
COPTFLAGS= -O -pipe
NOPROFILE=true
MODULES_WITH_WORLD=true

xl0: <3Com 3cSOHO100-TX OfficeConnect> port 0xc000-0xc07f mem
0xd5100000-0xd5100
07f irq 12 at device 4.0 on pci1
miibus0: <MII bus> on xl0
xlphy0: <3Com internal media interface> on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:01:02:fb:33:e2
xl0: [GIANT-LOCKED]
fxp0: <Intel 82557 Pro/100 Ethernet> port 0xc400-0xc41f mem
0xd5000000-0xd50ffff
f,0xd6000000-0xd6000fff irq 11 at device 10.0 on pci1
miibus1: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus1
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:a0:c9:91:34:8f
fxp0: [GIANT-LOCKED]

kernel config is like GENERIC bit with commented out SCSI, firewire, USB,
network cards and this options:

options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPDIVERT
options         BRIDGE
# ipx support
options         IPX
device          ef
options         ETHER_II


>Description:

	IPX support work fine on 4-STABLE, but with 5-BETA7 and 5.3-RELEASE
        I can't force it to work. tcpdump shows strange IPX network in
        outgoing packets.

        # tcpdump -p -i xl0 -n -e ipx 
        correct packet (net 0x123) comes from Novell Netware server:

10:30:07.740774 00:60:08:96:c0:46 > ff:ff:ff:ff:ff:ff, ethertype IPX
(0x8137), length 494: (NOV-ETHII) 00000123.00:60:08:96:c0:46.0452 >
00000123.ff:ff:ff:ff:ff:ff.0452:ipx-sap-resp[|ipx 448]

        # tcpdump -p -i xl0 -n -e ipx and ether host 00:01:02:fb:33:e2
        outgoing packet from out machine:

10:30:57.458631 00:01:02:fb:33:e2 > ff:ff:ff:ff:ff:ff, ethertype IPX
(0x8137), length 58: (NOV-ETHII) 04530000.01:23:00:01:02:fb.33e2 >
00000000.01:23:ff:ff:ff:ff.ffff: ipx-#ffff 14

        IPX network on interface is configured as 0x123, but tcpdump shows
        0x4530000 and node number not same as MAC address. seems like net
        number shifted to right by 2 bytes:
           04530000.01:23:00:01:02:fb - incorrect
           00000123.00:01:02:fb:33:e2 - correct

        the same behavior is with xl0, fxp0 and with device ef's xl0f0,
        fxp0f0
        
>How-To-Repeat:

        compile kernel with IPX support:

        options         IPX

        #ifconfig <iface> ipx 0x123

        #tcpdump -p -i <face> -n -e ipx and ether host <iface mac>

        address in outgoing packets must be 00000123.<iface mac>

>Fix:

	unknown


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->rwatson 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Fri Nov 19 12:10:40 GMT 2004 
Responsible-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=74105 

From: Robert Watson <rwatson@FreeBSD.org>
To: gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/74105: IPX protocol support doesn't work
Date: Thu, 30 Dec 2004 21:42:10 +0000 (GMT)

 Sorry for the delay in picking up on this one; I've planned to start doing
 cleanup and fixing of the IPX code for the past couple of months but have
 been time-starved.  I've recently started to pick it up again and would
 like to gather some more information on this bug.  In particular, could
 you use "tcpdump -s 1500 -w" (and appropriate other arguments) to generate
 a tcpdump packet trace of the corrupted IPX traffic to a file, and then
 post the file to a web server somewhere and send me the URL?   Not sure
 how easy it would be, but it would also be quite interesting to see a
 trace of the expected traffic from an earlier revision that is known to
 work, if possible.
 
 Thanks, and apologies again for the delay,
 
 Robert N M Watson
 
 
 
State-Changed-From-To: open->patched 
State-Changed-By: rwatson 
State-Changed-When: Sun Jan 2 02:42:21 GMT 2005 
State-Changed-Why:  
This problem is believed to be fixed in FreeBSD CVS HEAD (6.x) as 
ipx.h:1.19.  In addition, ipx_outputfl.c:1.21 and ipx_pcb.c:1.36 are 
highly recommended.  I'll merge these to RELENG_5 in a week or so, 
and request a merge to RELENG_5_3 for 5.3 errata fixes shortly 
thereafter.  Follow-up e-mail with copies of the patches will follow 
shortly.  Thanks for the excellent bug report! 


http://www.freebsd.org/cgi/query-pr.cgi?pr=74105 

From: Robert Watson <rwatson@FreeBSD.org>
To: gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/74105: IPX protocol support doesn't work
Date: Sun, 2 Jan 2005 02:36:22 +0000 (GMT)

 On Thu, 30 Dec 2004, Robert Watson wrote:
 
 >  Sorry for the delay in picking up on this one; I've planned to start doing
 >  cleanup and fixing of the IPX code for the past couple of months but have
 >  been time-starved.  I've recently started to pick it up again and would
 >  like to gather some more information on this bug.  In particular, could
 >  you use "tcpdump -s 1500 -w" (and appropriate other arguments) to generate
 >  a tcpdump packet trace of the corrupted IPX traffic to a file, and then
 >  post the file to a web server somewhere and send me the URL?   Not sure
 >  how easy it would be, but it would also be quite interesting to see a
 >  trace of the expected traffic from an earlier revision that is known to
 >  work, if possible.
 
 Actually, that's unnecessary -- I was able to reproduce the problem here,
 as well as patch it.  Apparently the last gcc import changed the padding
 behavior for 'struct ipx', which defines the IPX packet header, resulting
 in 2 bytes of additional padding getting stuck in each packet.  Could you
 try the attached patch?  I've committed to the FreeBSD 6.x head, and will
 merge to 5.x in a couple of days once it's settled.  There's a second
 useful patch that you'll also want, also attached, that fixes a bug in the
 route handling that could lead to a panic with INVARIANTS present in the
 kernel.  This would probably not manifest without debugging features in
 the kernel turned on, however. 
 
 Robert N M Watson
 
 
 Index: ipx.h
 ===================================================================
 RCS file: /home/ncvs/src/sys/netipx/ipx.h,v
 retrieving revision 1.18
 retrieving revision 1.19
 diff -u -r1.18 -r1.19
 --- ipx.h	22 Jun 2004 21:46:49 -0000	1.18
 +++ ipx.h	2 Jan 2005 02:30:27 -0000	1.19
 @@ -145,7 +145,7 @@
  	u_char	ipx_pt;		/* Packet Type (i.e. level 2 protocol) */
  	struct ipx_addr	ipx_dna;	/* Destination Network Address */
  	struct ipx_addr	ipx_sna;	/* Source Network Address */
 -};
 +} __packed;
  
  #define ipx_neteqnn(a,b) \
  	(((a).s_net[0] == (b).s_net[0]) && ((a).s_net[1] == (b).s_net[1]))
 Index: ipx_outputfl.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/netipx/ipx_outputfl.c,v
 retrieving revision 1.20
 retrieving revision 1.21
 diff -u -r1.20 -r1.21
 --- ipx_outputfl.c	2 Jan 2005 01:39:38 -0000	1.20
 +++ ipx_outputfl.c	2 Jan 2005 01:47:56 -0000	1.21
 @@ -96,7 +96,7 @@
  		/*
  		 * The old route has gone away; try for a new one.
  		 */
 -		rtfree(ro->ro_rt);
 +		RTFREE(ro->ro_rt);
  		ro->ro_rt = NULL;
  		rtalloc_ign(ro, 0);
  	}
 Index: ipx_pcb.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/netipx/ipx_pcb.c,v
 retrieving revision 1.35
 retrieving revision 1.36
 diff -u -r1.35 -r1.36
 --- ipx_pcb.c	2 Jan 2005 01:39:38 -0000	1.35
 +++ ipx_pcb.c	2 Jan 2005 01:47:56 -0000	1.36
 @@ -275,7 +275,7 @@
  	so->so_pcb = 0;
  	sotryfree(so);
  	if (ipxp->ipxp_route.ro_rt != NULL)
 -		rtfree(ipxp->ipxp_route.ro_rt);
 +		RTFREE(ipxp->ipxp_route.ro_rt);
  	LIST_REMOVE(ipxp, ipxp_list);
  	FREE(ipxp, M_PCB);
  }
 
 

From: Vladimir Kurtukov <vk@vk.pp.ru>
To: freebsd-gnats-submit@FreeBSD.org
Cc: rwatson@FreeBSD.org
Subject: Re: kern/74105: IPX protocol support doesn't work
Date: Wed, 12 Jan 2005 09:06:56 +0700

 Sun Jan  2 09:36, Robert Watson <rwatson@FreeBSD.org> wrote:
 
 >  Apparently the last gcc import changed the padding
 >  behavior for 'struct ipx', which defines the IPX packet header, resulting
 >  in 2 bytes of additional padding getting stuck in each packet.  Could you
 >  try the attached patch? 
 
 IPX packets are OK now. but there are some stranges in 
 netstat -rn -f ipx output and NCP doesn't work. 
 
 5-STABLE
 
 # netstat -rn -f ipx
 Routing tables
 IPX:
 Destination        Gateway            Flags    Netif Expire
 default            123.d0b768cbb3     U        fxp0
 default            123.5004d59590     UG       fxp0
 default            123.600896c046     UG       fxp0
 default            123.2035223c6b     UG       fxp0
 default            123.805f27a068     UG       fxp0
 default            123.2035220bc2     UG       fxp0
 default            123.110a999309     UG       fxp0
 default            123.423a8e527      UG       fxp0
 
 # ncplist s
 Can't find any file server
 
 4-STABLE
 
 # netstat -rn -f ipx
 Routing tables
 IPX:
 Destination        Gateway            Flags    Netif Expire
 123.*              123.203567521e     U        fxp0
 35a717.*           123.110a999309     UG       fxp0
 52a9ce7.*          123.2035220bc2     UG       fxp0
 5a1e610.*          123.423a8e527      UG       fxp0
 7f68577.*          123.805f27a068     UG       fxp0
 97d62fe.*          123.2035223c6b     UG       fxp0
 45734613.*         123.5004d59590     UG       fxp0
 5a6154fd.*         123.600896c046     UG       fxp0
 
 # ncplist s
 Visible servers (from FS2):
 Name                                            Network    Node       Port
 ----------------------------------------------- -------- ------------ ----
 FS1                                             0035A717:000000000001:0451
 FS2                                             052A9CE7:000000000001:0451
 FS3                                             05A1E610:000000000001:0451
 FS4                                             07F68577:000000000001:0451
 FS6                                             5A6154FD:000000000001:0451
 
 4 and 5 machines are in same subnet
 
 ---
 Best regards, 
   Vladimir
 

From: Bob Johnson <bob89@eng.ufl.edu>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/74105: IPX protocol support doesn't work
Date: Thu, 10 Feb 2005 11:48:13 -0500

 Using -STABLE downloaded yesterday (9 Feb) the patches in the 
 PR appear to be in place, but neither mount_nwfs nor ncp* work.  
 
 FreeBSD scanner.engnet.ufl.edu 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb  9 
 18:33:41 EST 2005  x@scanner.engnet.ufl.edu:/usr/obj/usr/src/sys/BOBJ28  i386
 
 Kernel config includes:
 options         IPX
 device          ef
 options         ETHER_II
 options         IPFIREWALL
 options         IPFIREWALL_VERBOSE
 options         TCP_DROP_SYNFIN
 options         MAXDSIZ=(1024UL*1024*1024)
 options         MAXSSIZ=(256UL*1024*1024)
 options         DFLDSIZ=(512UL*1024*1024)
 
 and is otherwise mostly generic except for deleting unused SCSI and ethernet 
 drivers (and AGP to make nvidia driver happy).
 
 What is actually seen on the wire:
 
 # tcpdump -i bfe0 -XX -e -s 0x100 ether proto 0x8137
 [...]
 19:06:24.835872 00:e0:18:f3:33:4f > Broadcast, ethertype IPX (0x8137), length 
 48: (NOV-ETHII) 80e39800.00:e0:18:f3:33:4f.401f > 
 80e39800.ff:ff:ff:ff:ff:ff.0452:ipx-sap-nearest-req 050e
         0x0000:  ffff ffff ffff 00e0 18f3 334f 8137 ffff  ..........3O.7..
         0x0010:  0022 0000 80e3 9800 ffff ffff ffff 0452  .".............R
         0x0020:  80e3 9800 00e0 18f3 334f 401f 0003 050e  ........3O@.....
 19:06:27.625146 00:30:c1:ae:36:03 > Broadcast, ethertype IPX (0x8137), length 
 60: (NOV-ETHII) 80e39800.00:30:c1:ae:36:03.400b > 
 80e39800.ff:ff:ff:ff:ff:ff.0452:ipx-sap-req FileServer
         0x0000:  ffff ffff ffff 0030 c1ae 3603 8137 ffff  .......0..6..7..
         0x0010:  0022 0000 80e3 9800 ffff ffff ffff 0452  .".............R
         0x0020:  80e3 9800 0030 c1ae 3603 400b 0001 0004  .....0..6.@.....
         0x0030:  3030 3330 4331 4145 3336 3033            0030C1AE3603
 
 
 Note the first packet is from FreeBSD, I believe bytes 2E and 2F should be 
 0x0004 (NCP_BINDERY_FSERVER) as in the next packet.  Bytes 2C,2D are correct 
 as 0x0003 (IPX_SAP_NEAREST_QUERY).  The packet looks correct to me except for 
 the bogus 0x050e value.  mount_nwfs produces same bad packet.  
 
 
 
 - Bob
 

From: Bob Johnson <bob89@eng.ufl.edu>
To: freebsd-gnats-submit@freebsd.org
Cc: vk@vk.pp.ru
Subject: Re: kern/74105: IPX protocol support doesn't work
Date: Fri, 11 Mar 2005 11:11:44 -0500

 The following patch fixes the problem I reported above (bad packet content at 
 bytes 0x2E and 0x2F).  Beyond this point, our Netware servers seem to want to 
 speak a different protocol than the FreeBSD client is using, so I probably 
 won't pursue this further.  If IPX support worked for you and recently broke, 
 this patch, applied to a recent -STABLE (the afternoon of Feb 25th or newer), 
 might be all you need.
 
 ==============
 
 diff -u -r1.1 ipxsap.h
 --- ipxsap.h    2005/03/01 18:39:32     1.1
 +++ ipxsap.h    2005/03/02 15:32:46
 @@ -30,6 +30,7 @@
   * SUCH DAMAGE.
   *
   * $FreeBSD: src/lib/libncp/ipxsap.h,v 1.1 1999/10/12 11:56:37 bp Exp $
 + * $Id: ipxsap.h,v 1.4 2005/03/02 14:52:34 bobj Exp bobj $
   */
  #ifndef _IPXSAP_H_
  #define _IPXSAP_H_
 @@ -58,7 +59,7 @@
         u_char          server_name[IPX_SAP_SERVER_NAME_LEN];
         struct ipx_addr ipx;
         u_short         hops;
 -};
 +} __packed;
 
  struct sap_packet {
         u_short         operation;
 
 
 ==============
 
 You might also consider something like the following patch that prints an 
 error message when the client can't proceed further in my situation.  Of 
 course, if the real problem is that I don't understand what is going on, this 
 will only make things worse:
 
 ==============
 
 diff -u -r1.1 sap.c
 --- sap.c       2005/03/03 01:24:20     1.1
 +++ sap.c       2005/03/11 15:34:38
 @@ -29,6 +29,7 @@
   * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   */
 + /*$Id: sap.c,v 1.10 2005/03/11 15:34:30 bobj Exp $*/
 
  #include <sys/cdefs.h>
  __FBSDID("$FreeBSD: src/lib/libncp/sap.c,v 1.4 2002/02/18 20:35:18 mike Exp 
 $");
 @@ -292,6 +293,20 @@
         if (packets == 0) {
                 close(sock);
                 return ENETDOWN;
 +       }
 +
 +       /* If we received a response on our network with a valid host addr, */
 +       /* we can return it, else we have an internal server address */
 +       /* and we must ask a router to translate it to an external address */
 +       /* The host part of the internal server address is always 1 */
 +
 +       if (reply->sap_entries[0].ipx.x_host.s_host[0] == 0 \
 +       &&  reply->sap_entries[0].ipx.x_host.s_host[1] == 0 \
 +       &&  reply->sap_entries[0].ipx.x_host.s_host[2] == 0x0100)
 +       {
 +               printf("Need to query a router to resolve server address.\n");
 +               printf("This client doesn't know how to do that!\n");
 +               return(EPROTONOSUPPORT);
         }
 
         daddr->sipx_addr = reply->sap_entries[0].ipx;
 
 ================

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/74105: commit references a PR
Date: Mon, 26 Feb 2007 12:07:20 +0000 (UTC)

 rwatson     2007-02-26 12:07:08 UTC
 
   FreeBSD src repository
 
   Modified files:
     lib/libncp           ipxsap.h 
   Log:
   Mark data structures used on the wire with IPX SAP as __packed so that
   they are not inappropriately padded as a result of compiler changes.
   
   PR:             kern/74105
   Submitted by:   Bob Johnson <bob89 at eng dot ufl dot edu>
   
   Revision  Changes    Path
   1.3       +3 -3      src/lib/libncp/ipxsap.h
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: rwatson 
State-Changed-When: Sun Jan 13 15:25:53 UTC 2008 
State-Changed-Why:  
Close this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=74105 
>Unformatted:
