From owner-freebsd-questions Fri Jul 19 15:08:51 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA22509 for questions-outgoing; Fri, 19 Jul 1996 15:08:51 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA22504 for ; Fri, 19 Jul 1996 15:08:49 -0700 (PDT) Received: from ime.net by mail.crl.com with SMTP id AA29138 (5.65c/IDA-1.5 for ); Fri, 19 Jul 1996 15:08:01 -0700 Received: from kimiko.tcguy.net (buxton-13.ime.net [206.231.148.142]) by ime.net (8.7.4/8.6.12) with SMTP id SAA27602; Fri, 19 Jul 1996 18:04:30 -0400 (EDT) Message-Id: <31F00670.6C5E@ime.net> Date: Fri, 19 Jul 1996 18:04:32 -0400 From: Gary Chrysler Reply-To: tcg@ime.net Organization: The Computer Guy X-Mailer: Mozilla 3.0b4Gold (Win95; I) Mime-Version: 1.0 To: John Hay Cc: questions@freebsd.org Subject: Re: Scanning for Interfaces! References: <199607191819.UAA02586@zibbi.mikom.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Hay wrote: > > > I see Garrett has already answered the other questions, so I will just > comment on this one. Yup, I haven't had enough time yet to fully asorb Garrets reply as of yet.. :( Working on it. Thanks Garret! > Defining sipx_network there will probably not work, because the kernel > part of ipx will expect it inside sipx_addr. Maybe you can make a #define > to make getting to it easier, eg. > #define sipx_network (*(union ipx_net_u *)&sipx_addr.x_net)).long_e > Note that this may not be correct because I have been looking at a > -current ipx.h file. Yea, I did use a define at first and that caused trouble, But I didn't do it as you suggest! I'll try it as well as show what I have in ipx.h, I belive it is the same as current. (MCI's Wonderfull high speed back bone is up to it's normal speed. So I couldn't get to a -current ipx.h for comparision before this reply, I will look later when usage is lower.) My ipx.h is from the fbsd-ipx.tgz. It is: (Revelant part, shortened) union ipx_host { u_char c_host[6]; u_short s_host[3]; }; union ipx_net { u_char c_net[4]; u_short s_net[2]; }; union ipx_net_u { union ipx_net net_e; u_long long_e; }; struct ipx_addr { union ipx_net x_net; union ipx_host x_host; u_short x_port; }; struct sockaddr_ipx { u_char sipx_len; u_char sipx_family; struct ipx_addr sipx_addr; char sipx_zero[2]; u_char sipx_type; /* tcg */ u_long sipx_network; /* tcg */ }; #define sipx_port sipx_addr.x_port #define sipx_special sipx_addr.x_port /* tcg */ /* #define sipx_network sipx_addr.x_net tcg */ #define sipx_node sipx_addr.x_host.c_host /* tcg */ NOTE: Ok pick yourself up off the floor and quit laughing! These (whatevers) did move me along.. Maybe not in the right direction but any direction is better then no direction. I did get further and learned a bunch! sipx_special, Is defined the same in the Linux ipx.h sipx_node, :) I know it's wrong.. whats right/better?? sipx_network, ?? John, is your suggestion fitting?? In hopes maybe one of you kind souls will pass along better/right methods I've included the Linux sockaddr_ipx. (it was in my ipx.h for my reference.) I do realize the parsing of these variables in the program needs to be changed to match the different types. I would rather change the program then the kernel. :) /* tcg linux struct sockaddr_ipx { short sipx_family; ok short sipx_port; ok unsigned long sipx_network; added unsigned char sipx_node[IPX_NODE_LEN]; kludged unsigned char sipx_type; added unsigned char sipx_zero; 16 byte fill }; */ > I'm not sure what the purpose of the sipx_type field is. Is it the > ipx type that should be used in the type field of the packet? Because > that is set with a setsockopt(....., SO_DEFAULT_HEADERS, ...) call. > You can get an example of that in IPXrouted/main.c Yes John, That is what it is. (I belive) It's one of: #define IPX_NCP_PTYPE 0x17 #define IPX_RIP_PTYPE (1U) #define IPX_SAP_PTYPE (4U) #define IPX_USER_PTYPE (0) I've assumed PTYPE means Packet type.. Code looks that way as well. :) Thanks John, I'll look into the setsockopt(...). I really appreciate your alls assistance. -Enjoy Gary ~~~~~~~~~~~~~~~~ Improve America's Knowledge... Share yours The Borg... Where minds meet (207) 929-3848