brad@polaris.ucsc.edu (11/23/88)
I have been working with a FastPath 4 running the KSTAR code, and have been unable to get the FP to interact with the "Appletalk Information Server" (atis in the KIP distribution) running on a Unix host with the same intimacy (?) as a FastPath 3 running the KIP code. The problem shows up in that Macs on the LocalTalk net attached to the FP4 don't see any services offered by the KIP/CAP Unix host. It appears that, when doing the NBP type queries when looking for LaserWriters, AppleShare servers, etc. the KSTAR code only looks on LocalTalk and EtherTalk (it sees services available through other FastPaths). Is there some subtly in the configuration that I have missed? Another question I had is what rev of atalkad information does KSTAR support? Specifically, does it understand the "stayinzone", "laserfilter", and "tildefilter" values for the "flags" field (rev 9/87)? I could (and will) check this out, but thought I'd ask while I had your attention :-). Thank you, Brad Smith Unix System Administrator CIS Board, UC Santa Cruz brad@polaris.ucsc.edu
falken@caen.engin.umich.edu (David R Falkenburg) (11/24/88)
In article <5566@saturn.ucsc.edu>, brad@polaris.ucsc.edu writes: > I have been working with a FastPath 4 running the KSTAR code, and > have been unable to get the FP to interact with the "Appletalk > Information Server" (atis in the KIP distribution) running on a > Unix host with the same intimacy (?) as a FastPath 3 running the > KIP code. The problem shows up in that Macs on the LocalTalk net > attached to the FP4 don't see any services offered by the KIP/CAP > Unix host. It appears that, when doing the NBP type queries when > looking for LaserWriters, AppleShare servers, etc. the KSTAR code > only looks on LocalTalk and EtherTalk (it sees services available > through other FastPaths). Is there some subtly in the configuration > that I have missed? I've gotten a few KFPS-4s to work in finding CAP based services, but only after I removed all the KFPS-3a from my atalkatab. Strange thing is that InterPoll cannot "see" these entities, but the Chooser DA can (I guess there are more retries etc. being done by Chooser) > > Another question I had is what rev of atalkad information does KSTAR > support? Specifically, does it understand the "stayinzone", "laserfilter", > and "tildefilter" values for the "flags" field (rev 9/87)? I could > (and will) check this out, but thought I'd ask while I had your > attention :-). The "security" options such as conf_laserfilter, etc. DON'T seem to work on any of my FastPath 4s. I've got rom v3.1 and K-STAR 1.1d > > Thank you, > > Brad Smith > Unix System Administrator > CIS Board, UC Santa Cruz > brad@polaris.ucsc.edu -dave falkenburg -- Dave Falkenburg @ University of Michigan Computer Aided Engineering Network ARPA: falken@caen.engin.umich.edu UUCP: umix!caen.engin.umich.edu!falken
rapatel@athos.rutgers.edu ( Rakesh Patel) (11/25/88)
I would also like to know if Kinetics is planning to implement/support the KIP "stayinezone", "laserfilter", and "tildefilter" protection flags as well as whether they intend to allow the use of the NIC assigned UDP port numbers. This is fairly important to know. Also, will the gatorbox support similar features in addition to the NIC assigned UDP ports? So, anyone at Cayman or Kinetics care to comment? Thanks, Rakesh Patel.
brad%cayman@HARVARD.HARVARD.EDU (Brad Parker) (11/25/88)
Date: 25 Nov 88 01:39:51 GMT From: harvard!rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!rapatel ( Rakesh Patel) Organization: Rutgers Univ., New Brunswick, N.J. References: <5566@saturn.ucsc.edu> Sender: harvard!andrew.cmu.edu!info-appletalk-request ... Also, will the gatorbox support similar features in addition to the NIC assigned UDP ports? Yes, we (Cayman) plan to support the NIC standard ports - it will be a selectable option. Our support for atalkad is largely symbolic at the momment, so support for the new flags is not really an issue (supporting atalkad correctly is the my current issue). We plan to look closely at the changes and determine how best to integrate them. It would be helpful to know how widespread their use is (I'b been running kip from the early days and was not aware of them till recently - but that's no measure of their use) Hope this helps. -brad
tjh+@ANDREW.CMU.EDU (Tom Holodnik) (11/28/88)
We use KIP security flags/options pretty extensively. Fortunately, we hadn't relied on using them on KFPS-4s running KStar. In my opinion, it'd be a really powerful feature to have KStar (and the Cayman Gatorware) support these options. Many faculty and staff members have requested these options on their gateway(s). Tom Holodnik CMU
minshall@kinetics.UUCP (Greg Minshall) (12/01/88)
1. Brad Smith at UCSC is having trouble getting K-STAR to talk with CAP on a Unix host. My main suggestion here is to make sure that CAP is using the "old-style" UDP port numbers (in the 768-range) rather than the "new-style, officially blessed" port numbers (in the 200-range), as the current K-STAR does not support the new-style port numbers. 2. There is a lot of interest expressed in "laserfilter", "tildefilter", etc. K-STAR does not currently support any of these flags. We are trying to decide on exactly what to support here, and this is a timely discussion. My (personal) main worry is that these options might soon be superseded by some other set and then we get to carry more luggage in the name of "backwards compatibility". However, hearing many positive comments, and no negative ones, is somewhat convincing. (By the way, another reason for the hesitation is that "laserfilter" and "tildefilter" can slow the gateway down a fair bit; "stayinzone", on the other hand, is very straightforward.) It would be nice if there were some forum where all the interested parties could sit down and hash out the required security features for an AppleTalk bridge. 3. Dave Falkenburg mentions that he has had to remove all KFPS-3's from his atalkatab file in order to get the K-STAR code to work. This is a mystery, and I'd love to know more. The intent with K-STAR is to be compatible with KIP, and incompatibilities would be considered bugs. 4. On a totally unrelated subject, there has been a lot of discussion about Apple's TCP (to appear at some point in the future), and sockets. It has been mentioned that the Kinetics "TCPort" product supports sockets, and is based on the CITI code. I'd also mention that TCPort is, in fact, available now, and has been significantly upgraded over the CITI distribution (both in "ease of setup" and in "functionality"). Greg Minshall Kinetics (415)947-0998 ...!ucbvax!unisoft!kinetics!minshall
falken@caen.engin.umich.edu (David R Falkenburg) (12/04/88)
In article <673@kinetics.UUCP>, minshall@kinetics.UUCP (Greg Minshall) writes: > > 2. There is a lot of interest expressed in "laserfilter", "tildefilter", > etc. K-STAR does not currently support any of these flags. We are > trying to decide on exactly what to support here, and this is a > timely discussion. My (personal) main worry is that these options > might soon be superseded by some other set and then we get to carry > more luggage in the name of "backwards compatibility". However, hearing > many positive comments, and no negative ones, is somewhat convincing. > (By the way, another reason for the hesitation is that "laserfilter" > and "tildefilter" can slow the gateway down a fair bit; "stayinzone", > on the other hand, is very straightforward.) It would be nice if > there were some forum where all the interested parties could sit > down and hash out the required security features for an AppleTalk bridge. These features are EXTREMELY important for us here at umich. We have several large internets across campus which cross quite a few adminstrative and financial boundaries. Basically the introduction of the FastPath 4 (with no support for laserfilter) has caused a few people Im working with to be hesitant in getting their faspaths included in any of the larger internets. > > 3. Dave Falkenburg mentions that he has had to remove all KFPS-3's from > his atalkatab file in order to get the K-STAR code to work. This > is a mystery, and I'd love to know more. The intent with K-STAR is to > be compatible with KIP, and incompatibilities would be considered bugs. Actually it turns out that I had PROM revision 3.1 & K-STAR 1.1d (not the current versions) Kinetics just contacted us here about both this upgrade for the KFPS-4, *and* a new program for updating KFPS-3s > > Greg Minshall Kinetics > (415)947-0998 ...!ucbvax!unisoft!kinetics!minshall -dave -- Dave Falkenburg @ University of Michigan Computer Aided Engineering Network ARPA: falken@caen.engin.umich.edu UUCP: umix!caen.engin.umich.edu!falken
rapatel@athos.rutgers.edu ( Rakesh Patel) (12/04/88)
Aside from the security issues mentioned, I would like some other info. According to Inside Appletalk in the RTMP section: "For internets with a large number of networks, the entire routing table may not fit in a single datagram. In that case, the tuples are distributed over as many RTMP data packets as necessary." If my information is correct, KIP does not currently support this feature. Hopefully it will at some point. Does K* support this? I have recompiled KIP with a larger values for # of zones, zone name space, and number of routes. Until KIP and K* support this feature, the appletalk internetwork we have put together can't grow much. I really do not want to split into multiple appletalk internets, since we use the internetwork in order to distribute new network software to the various departments within our present appletalk internet. We would like to increase the types of services available and make them gloabally available to all the departments within our university. It seems to be a step backwards to have to spilt the internet. Part of the problem is that the KFPS-2s we run are tight on memory with the current KIP we are running (we are down from 22 to 12 buffers avaliable). Upgrading to KFPS-4s is going to be a real problem for us if K* does not have the ability to handle the security issues as well as the ability to handle large number of zones and routes. Does K* have hard limits on the # of zones, zone name space, and # of routes? If so, can I get some info on these limits? Does it handle the splitting of the routing table into multiple datagrams? We also use Hayes Interbridges and I am wondering what their limits actually are as well. Does anyone have any idea what they are? I have found it to be a real problem getting info on these issues from many vendors. I really wonder what limits there are on the various products available; especially in the local/remote Appletalk Bridges and the dialup appletalk bridges. Does anyone have further information in this area? Rakesh Patel.
rapatel@athos.rutgers.edu ( Rakesh Patel) (12/04/88)
I forgot another question I had. One of the problems we tend run into is that KIP does not respond to redirects from our IP gateways. This is a known problem. I would like to know if K* and the software used on the GatorBox respond to redirects or not. Correct me if I am wrong, but my understanding is that if the gateway the KIP sends non-local IP packets to goes down, there is no way for KIP to switch to anothe gateway. Is there a way for KIP to arp for the address instead of assigning a fixed IP gateway? Again of course, do K* and the Gatorbox hhave similar problems? If not, how is the situation handled? Rakesh Patel.
eshop@saturn.ucsc.edu (Jim Warner) (12/06/88)
In article <673@kinetics.UUCP> minshall@kinetics.UUCP (Greg Minshall) writes: >1. Brad Smith at UCSC is having trouble getting K-STAR to talk with >CAP on a Unix host. My main suggestion here is to make sure that >CAP is using the "old-style" UDP port numbers (in the 768-range) >rather than the "new-style, officially blessed" port numbers >(in the 200-range), as the current K-STAR does not support the >new-style port numbers. This really isn't a question of "style" as much as whether a company has a commitment to track development of standards. Please call technical support (yours) and explain port numbers to them. I called with this very question (UDP port numbers) before your posting and Kinetics Tech support thought I was asking which connector to use on the back. Another topic-- The "FastPath Addendum" (P/N 4230394 Rev A) shipped with our new FP4s contains dangerous advice. You recommend (page 20-21) that it is OK to choose any (unassigned) address for use on a localtalk net. Today's unassigned address will be assigned to a site some day. Suggestions like this plant black hole time bombs throughout the internet, set to go off long after anyone remembers this little hack. I really don't think a responsible networking company would make this suggestion. jim warner uc santa cruz
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (12/09/88)
In article <5642@saturn.ucsc.edu> eshop@saturn.ucsc.edu (Jim Warner) writes: > >The "FastPath Addendum" (P/N 4230394 Rev A) shipped with our new FP4s >contains dangerous advice. You recommend (page 20-21) that it is OK >to choose any (unassigned) address for use on a localtalk net. Today's >unassigned address will be assigned to a site some day. Suggestions >like this plant black hole time bombs throughout the internet, set to >go off long after anyone remembers this little hack. I really don't >think a responsible networking company would make this suggestion. > Responsible companies with no valid network numbers to offer use their own corporate network address in examples and suggestions. That way only Kinetics suffers when all your advice comes back in network routing updates. Kinetics should get a corporate Class C just for this purpose, if you don't already have one.
minshall@kinetics.UUCP (Greg Minshall) (12/13/88)
From article <Dec.3.19.43.38.1988.15050@athos.rutgers.edu>, by rapatel@athos.rutgers.edu ( Rakesh Patel): > Does K* have hard limits on the # of zones, zone name space, and # of > routes? If so, can I get some info on these limits? Does it handle the > splitting of the routing table into multiple datagrams? K-STAR has no hard limits on the number of zones, zone names, etc.* It is important, perhaps, to realize that K-STAR contains some KIP code, more KIP features, but is not KIP. The AppleTalk part of K-STAR is that code which Kinetics has been working on (and distributing in our products) for "all these years". K-STAR sends as many RTMP packets as necessary in order to transfer its routing information. Greg Minshall Kinetics ...!ucbvax!unisoft!kinetics!minshall (415)947-0998 * the "soft limit" (ie: available memory) is there, however.
minshall@kinetics.UUCP (Greg Minshall) (12/13/88)
From article <Dec.3.19.52.50.1988.15079@athos.rutgers.edu>, by rapatel@athos.rutgers.edu ( Rakesh Patel): > > I forgot another question I had. One of the problems we tend run into > is that KIP does not respond to redirects from our IP gateways. This > is a known problem. I would like to know if K* and the software used on > the GatorBox respond to redirects or not. K-STAR responds to ICMP redirects by believing the information in the redirect for approximately 5 minutes. It then goes back to whatever the current "default router" is. > Correct me if I am wrong, but my understanding is that if the gateway > the KIP sends non-local IP packets to goes down, there is no way for > KIP to switch to anothe gateway. Is there a way for KIP to arp for the > address instead of assigning a fixed IP gateway? > > Again of course, do K* and the Gatorbox hhave similar problems? If > not, how is the situation handled? If you *do not* fill in the "default router" field, K-STAR will use existing RIP (Berkeley's "Routing Information Protocol"; a TCP/IP version of RTMP) packets on the network to discover gateways, again retaining information for approximately 5 minutes (RIP packets are "supposed to" be generated every 30 seconds or so). Greg Minshall Kinetics ...!ucbvax!unisoft!kinetics!minshall (415)947-0998
morgan@JESSICA.STANFORD.EDU (12/21/88)
Greg Minshall writes: > K-STAR has no hard limits on the number of zones, zone names, etc. One advantage of the "hard limits" in KIP is that we know when things will break (we took action when we realized we had 63 nets in our atalkatab, for example). While I have faith that the 256K memory in the KFPS-4 will allow any of the K* tables to grow as much as we may want, I'm not so sanguine about the 80(?)K memory in the KFPS-[123] with the recently announced memory upgrade. Is there any way we can tell if K* tables overflow? Is there a formula for totting up all the entries in all the relevant tables and comparing against a total heap-space size, or something? - RL "Bob" Morgan Networking Systems Stanford