home *** CD-ROM | disk | FTP | other *** search
/ HAM Radio 3 / hamradioversion3.0examsandprograms1992.iso / news / inham07 / 911. < prev    next >
Text File  |  1980-01-01  |  18KB  |  537 lines
  1. |To:           Jay Appell
  2. |Date Sent:    89Nov21 at 5:51 am
  3. |From:         uucp
  4. ----------------------------------------------------------------------------
  5.  
  6. From uucp Tue Nov 21 05:51 EST 1989
  7. >From bu.edu!WSMR-SIMTEL20.ARMY.MIL!INFO-HAMS-REQUEST!WSMR-SIMTEL20.ARMY.MIL  Tue Nov 21 05:47:04 1989 remote from cloud9
  8. Received: from cloud9 by es with UUCP; Tue, 21 Nov 89 05:51:54 EST
  9. Received: by cloud9.Stratus.COM (smail2.5)
  10.     id AA15168; 21 Nov 89 05:47:04 EST (Tue)
  11. Received: from BU-IT.BU.EDU by BU.EDU (1.90) Tue, 21 Nov 89 01:36:39 -0500
  12. Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7)
  13.     id AA29503; Tue, 21 Nov 89 01:36:36 EST
  14. Received:  from WSMR-SIMTEL20.ARMY.MIL by buita.bu.edu (11/17/89); Tue, 21 Nov 89 01:35:49 EST
  15. Message-Id:  <8911210635.AA17351@buita.bu.edu>
  16. Date: Mon, 20 Nov 89 23:15:08 MST
  17. From: cloud9!WSMR-SIMTEL20.ARMY.MIL!bu.edu!INFO-HAMS-REQUEST
  18.  
  19. Reply-To: bu.edu!INFO-HAMS@WSMR-SIMTEL20.ARMY.MIL
  20. Subject: INFO-HAMS Digest V89 #911
  21. To: INFO-HAMS@WSMR-SIMTEL20.ARMY.MIL
  22.  
  23. INFO-HAMS Digest            Mon, 20 Nov 89       Volume 89 : Issue 911
  24.  
  25. Today's Topics:
  26.    (#1 in series) Listen to store security guards catch shoplifters
  27.                    INTERNET CALLSIGN SERVER CLIENT
  28.         Military aircraft callsigns...Eugene Balinski (3 msgs)
  29.                     News From OSCAR-11  17-Nov-89
  30. ----------------------------------------------------------------------
  31.  
  32. Date: 21 Nov 89 01:04:33 GMT
  33. From: vsi1!daver!lynx!neal@apple.com  (Neal Woodall)
  34. Subject: (#1 in series) Listen to store security guards catch shoplifters
  35.  
  36. Jim Grubs writes:
  37. Bob Parnass writes:
  38.  
  39. >>It's getting near the holiday season -- a great time for listening
  40. >>to store security guards catch shoplifters.
  41.  
  42. >Parnass, you've gone off the deep end with this irresponsible posting. Is
  43. >your hobby of electronic voyerurism so vital to you that it justifies aiding  
  44. >criminals to evade detection and apprehension? I think you need to recheck
  45. >your priorities.
  46.  
  47. Grubbs, I think that you are really in need of help. Lighten up, will you?
  48. How in the hell will listening to security guards catch petty thieves aid
  49. the theives in getting away?
  50.  
  51. Bob, please don't let "Scrooge" Grubbs discourage you from posting.
  52.  
  53. Oh.......Grubbs, happy holidays!
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Neal
  60.  
  61. ------------------------------
  62.  
  63. Date: 20 Nov 89 22:56:59 GMT
  64. From: rochester!rit!ultb!cep4478@cu-arpa.cs.cornell.edu  (C.E. Piggott)
  65. Subject: INTERNET CALLSIGN SERVER CLIENT
  66.  
  67. In their infinite wisdom, the people at R.I.T. saw necessary to
  68. remove alternate port access via telnet.  Thus, I lost access to the
  69. callsign server for a month or so.
  70.  
  71. To counter this, I have written my own interface to the server.
  72.  
  73. It is for any BSD compatible system (ultrix-32 is what I used, but it
  74. worked on the 4.3 machine here, too).  (Sorry, I don't do VMS -
  75. actually, I wouldn't mind, if somebody would teach me how sockets
  76. work under vms).
  77.  
  78. Anyhow, if you have telnet alternate port access already, you don't
  79. really gain much by using this program, except maybe a little typing
  80. here and there, so if you don't need it, it's probably best not to
  81. confuse yourself.  The one thing you DO gain is that you can batch
  82. your requests into files, and use the < and > shell operators to
  83. process the lists.  For example, you could create a file called "input"
  84. that looks like this:
  85.  
  86.         ka2rvo
  87.         n2jgw
  88.         n1gph
  89.  
  90. and then type:
  91.  
  92.     ncall < input | lpr
  93.  
  94. or something like that.
  95.  
  96. Anyhow, here are the rules:
  97.  
  98.     (1) Please don't fool with the code.  If you DO modify
  99.         it, you may not distribute it further.
  100.  
  101.     (2) I'm not responsible for any of this.  No warranties
  102.         etc.  Devon looked at the code and has no
  103.         objection to the program, but it's not his
  104.         problem, either :-) (actually, I'm a nice
  105.         guy with lots of time to kill, so I'll help)
  106.  
  107.     (3) Please drop me a note if you find this thing useful.
  108.         I'm a poor college student, and I'm very vain. =)
  109.  
  110.  
  111. So, here goes.
  112.  
  113.                     Christopher E. Piggott
  114. internet: cep4478@ultb.isc.rit.edu
  115. packet: cep4478@wb2wxq
  116. uucp: ..!rutgers!rochester!ritcv!ultb!cep4478
  117. BITNET: cep4478@RITVAXA.BITNET
  118.  
  119. ------------------------------- cut here -------------------------------------
  120. /*
  121.  * ncall.c - a local interface to Devon Bowen's internet callsign server
  122.  * written by Christopher E. Piggott, N2JGW  cep4478@ultb.isc.rit.edu
  123.  * This program (c)1989 Christopher Piggott, all rights reserved.
  124.  */
  125.  
  126. #include <sys/types.h>
  127. #include <sys/socket.h>
  128. #include <netinet/in.h>
  129. #include <netdb.h>
  130. #include <stdio.h>
  131. #include <signal.h>
  132.  
  133. #define PORT 2000
  134. #define PROMPT ">>"
  135.  
  136. main()
  137. {
  138.         int sock;
  139.  
  140.         (void) signal(SIGINT, SIG_IGN);
  141.  
  142.     if(isatty(0))
  143.             (void) puts("Callsign client (local interface) written by Christopher Piggott, N2JGW\nCallsign server by Devon Bowen, bowen@cs.buffalo.edu");
  144.         sock = find_marvin();
  145.         process(sock);
  146.  
  147. }
  148.  
  149.  
  150. int find_marvin()
  151. /* open the connection to marvin, print hello message, and wait for prompt */
  152. {
  153.         int sock;
  154.         char buf[128];
  155.         struct sockaddr_in server;
  156.         struct hostent *hp, *gethostbyname();
  157.  
  158.         sock = socket(AF_INET, SOCK_STREAM, 0);
  159.  
  160.         if(!sock)
  161.                 oops("error creating socket");
  162.  
  163.         server.sin_family = AF_INET;
  164.  
  165.         hp = gethostbyname("marvin.cs.buffalo.edu");
  166.         if(!hp)
  167.                 oops("error looking up host");
  168.  
  169.         bcopy(hp->h_addr, (char *) &server.sin_addr, hp->h_length);
  170.         server.sin_port = htons(PORT);
  171.  
  172.         if(connect(sock, (struct sockaddr_in *)&server, sizeof(server)) < 0)
  173.                 oops("connnect()");
  174.  
  175.         (void) read(sock, buf, 6);
  176.         (void) write(sock, "\377\375\001\377\375\003", 6);
  177.  
  178.     if(isatty(0)) {
  179.         if(!expect("Call", sock, 0)) /* this looks stupid, but "trust me" =) */
  180.             oops("Didn't receive expected output");
  181.         (void) printf("Call");
  182.     }
  183.  
  184.     if(!expect(PROMPT,sock, (isatty(0) ? 1 : 0) ))
  185.         oops("Didn't receive expected prompt");
  186.         return(sock);
  187. }
  188.  
  189. oops(s)
  190. char *s;
  191. {
  192.         perror(s);
  193.         exit(1);
  194. }
  195.  
  196.  
  197. process(sock_fd)
  198. int sock_fd;
  199. {
  200.         char c;
  201.         int i;
  202.         char buf[128], call[64];
  203.  
  204.         while(1) {
  205.         if(isatty(0)) {
  206.                     (void) printf("\nCallsign? ");
  207.                     (void) fflush(stdout);
  208.         }
  209.                 if(!(fgets(call,63,stdin) && strlen(call)-1))
  210.                         break;
  211.  
  212.                 switch(*call) {
  213.                         case 'n': case 'N':    /* valid callsigns */
  214.                         case 'a': case 'A':
  215.                         case 'w': case 'W':
  216.                         case 'k': case 'K':
  217.                                 (void) (void) sprintf(buf, "call %s\r", call);
  218.                                 break;
  219.                         case 'q': case 'Q':    /* search by QTH */
  220.                                 for(i=0;call[i]!='\0'&&call[i]!=' ';++i);
  221.                                 (void) (void) sprintf(buf, "city %s\r",&call[++i]);
  222.                                 break;
  223.                         case 'i': case 'I':    /* view callserve info */
  224.                                 (void) strcpy(buf, "info\r");
  225.                 break;
  226.                         case 'l': case 'L':    /* search by last name */
  227.                                 for(i=0;call[i]!='\0'&&call[i]!=' ';++i);
  228.                                 (void) (void) sprintf(buf, "name %s\r",&call[++i]);
  229.                                 break;
  230.             case 'h': case 'H': case '?':    /* help */
  231.                 list_help();
  232.                 continue;
  233.                         default:            /* oops! */
  234.                                 (void) puts("\nBad command.");
  235.                                 continue;
  236.                 }
  237.                                 
  238.                                 
  239.                 if(write(sock_fd,buf,strlen(buf))<0)    /* send command to marvin */
  240.                         oops("write() failed");
  241.  
  242.                 if(!expect("\n",sock_fd,0))        /* absorb command echo */
  243.             oops("Didn't get expected text");
  244.                 putchar('\n');
  245.  
  246.                 if(!expect(PROMPT,sock_fd,1))    /* dump output to stdout */
  247.             oops("Expected prompt from marvin");
  248.         }
  249.  
  250.         (void) sprintf(buf, "quit\r");            /* issue terminating command */
  251.         (void) write(sock_fd, buf, strlen(buf));
  252.  
  253.         while(read(sock_fd, &c, 1));            /* flush fd */
  254.         if(shutdown(sock_fd, 2))
  255.         oops("shutdown()");
  256. }
  257.  
  258. expect(s,fd, echo_flag)
  259. char *s;
  260. int fd, echo_flag;
  261. /* expect - wait for a contiguous group of characters 's' from stream fd */
  262. {
  263.         char c;
  264.         register int i=0, j, sl;
  265.  
  266.         sl=strlen(s);
  267.  
  268.         while(read(fd, &c, 1)) {
  269.                 if(c==s[i]) {
  270.                         if(++i==sl)
  271.                                 break;
  272.                 }
  273.                 else {
  274.                         if(echo_flag) {         /* do not echo expected string */
  275.                                 for(j=0;j!=i;j++)
  276.                                         putchar(s[j]);
  277.                                 putchar(c);
  278.                         }
  279.                         
  280.                         i=0;
  281.                 }
  282.         }
  283.  
  284.         return(i==sl);
  285.  
  286. }
  287.  
  288.  
  289. list_help()
  290. {
  291. (void) puts("\n\
  292. Callsign Server local interface commands:\n\n\
  293. \ti  -  info about callsign server\n\n\
  294. \tl lastname  -  search by surname\n\n\
  295. \tqth city state  -  list all hams at QTH\n\n\
  296. \t<callsign>  -  look up <callsign> - prefix must be W, K, A, or N\n\n");
  297. }
  298.  
  299. ------------------------------
  300.  
  301. Date: 21 Nov 89 00:11:20 GMT
  302. From: vsi1!daver!lynx!neal@apple.com  (Neal Woodall)
  303. Subject: Military aircraft callsigns...Eugene Balinski
  304.  
  305. Jim Grubs writes:
  306. EUGENE BALINSKI writes:
  307. DUBE TODD writes:
  308.  
  309. >>>My question is:  Why would you be interested in what the call signs are
  310. >>>or represent?
  311.  
  312. >>Why am I interested ? Because it is one part of the hobby (the hobby
  313. >>being radio in general) that I enjoy. There are many people who enjoy
  314. >>scanning the mil aircraft band or the FBI or the CIA or the DEA etc.
  315.  
  316. >...and the fact you're eavesdropping on things not intended for you is  
  317. >irrelevant, right?
  318.  
  319. I think that this response is somewhat flippant....if these things are
  320. so secret, then let the people or agencies doing the transmitting encrypt
  321. them! Hey, if the guy wants to listen to an un-encrypted transmission, I
  322. say more power to him!
  323.  
  324. Look, the Russians pick up the military aircraft transmissions, so why
  325. shouldn't an American citizen be allowed to do the same?
  326.  
  327.  
  328.  
  329.  
  330. Neal
  331.  
  332. ------------------------------
  333.  
  334. Date: 21 Nov 89 00:24:32 GMT
  335. From: vsi1!daver!lynx!neal@apple.com  (Neal Woodall)
  336. Subject: Military aircraft callsigns...Eugene Balinski
  337.  
  338. In article <10253@attctc.Dallas.TX.US> Steve Sampson writes:
  339. >
  340. >.........................As a political statement - I personally feel that
  341. >first they take your radios, then they take your guns.
  342.  
  343. In the past I thought that it would be guns first, then radios. Now, however,
  344. I am beginning to believe that they will grab both at about the same time!
  345.  
  346. The banning of guns or radios is a step that would be taken only by a police-
  347. state government that has grown too oppressive and distrustful of its own
  348. citizens....neither should be tolerated.
  349.  
  350. >I would rather they forced secure communication on the Cellular Lobby, than
  351. >ban radios.
  352.  
  353. I agree totally with this.....if the people who make and use cellular phones,
  354. or ANY communication equipment that used the electromagnetic spectrum for
  355. transmissions, think that their signals are of such a nature that they should
  356. be secure, then let them encrypt!
  357.  
  358. If radio waves reach into my home, then I have a right to receive and attempt
  359. to demodulate them. The whole idea that people should be punished for receiving
  360. or demodulating radio signals was invented by those who have a monetary
  361. interest in some kind of communications, and who therefore do not care about
  362. people's personal freedoms.
  363.  
  364.  
  365.  
  366.  
  367.  
  368. Neal
  369.  
  370. ------------------------------
  371.  
  372. Date: 21 Nov 89 00:56:34 GMT
  373. From: vsi1!daver!lynx!neal@apple.com  (Neal Woodall)
  374. Subject: Military aircraft callsigns...Eugene Balinski
  375.  
  376. Jim Grubs writes:
  377.  
  378. >> Are you telling me that it is OK for the Russians to listen to SAC, but
  379. >> NOT OK for Americans to listen to SAC?
  380.  
  381. >It's not OK for either.
  382.  
  383. I would like to see you try to tell the Soviet intelligence people to stop
  384. listening to SAC because it is "not OK" for them to do so!
  385.  
  386. When you say it is "not OK", do you mean in a legal or moral sense? If you
  387. mean in a legal sense, then please quote references....of course, I don't
  388. think that the Soviets will be deterred by any US laws! If you mean in a
  389. moral sense, then I would like to discuss your reasoning.....
  390.  
  391. >The ECPA became necessary because electronic Peeping Toms abused the privacy
  392. >portions of the CommAct
  393.  
  394. Wrong. The ECPA never was "necessary".
  395.  
  396. It was seen as a slight disadvantage by the CTIA (Cellurlar Telephone Industry
  397. Assn.) that the cellular transmissions could be received by ordinary scanners,
  398. especially since the CTIA and cellular dealers had been advertising the
  399. cell-phones as "snoop proof" (a total lie). The CTIA pushed the ECPA because
  400. they needed to be able to "assure" their customers that their communications
  401. were "secure". The ECPA was a total abuse of the law making system of the US.
  402.  
  403. What a bunch of B.S.! If you want security, then encrypt! If your idea of
  404. "security" is to rely on a law that is practically unenforcable, then you
  405. are very confused.
  406.  
  407. >You shouldn't have to trust me. I'm not involved. It's the message sender's  
  408. >right to say "This is none of your business."
  409.  
  410. It is also his right to encrypt! If he encrypts, then I have no problem with
  411. that. However, telling me that I cannot listen to something that is easy to
  412. receive and demodulate is absurd.
  413.  
  414. >This right is protected by the constitution and laws of the United States.
  415.  
  416. Really? In what way? There is no "privacy" clause in the US Constitution.
  417. The 4th Amendment might apply, but I don't think so. Think of this analogy:
  418. if I talk out-loud in a public place, do I have a reasonable expectation of
  419. privacy? If someone wanted to talk about "secure matters", they would most
  420. likely take some reasonable precautions. If someone wants to transmit some
  421. "secure info" over the public airwaves, I think it is up to him to encrypt
  422. that info.
  423.  
  424.  
  425.  
  426.  
  427.  
  428. Neal
  429.  
  430. ------------------------------
  431.  
  432. Date: 20 Nov 89 02:48:01 GMT
  433. From: att!tsdiag!ka2qhd!kd2bd@ucbvax.Berkeley.EDU  (John Magliacane)
  434. Subject: News From OSCAR-11  17-Nov-89
  435.  
  436. **UOSAT 2 COMPUTER STATUS INFORMATION**
  437.  
  438. FAD1 OPERATING SYSTEM V2.0
  439. TODAY'S DATE IS 20 /11 /89
  440. UNIVERSAL TIME IS 2 :11 :14  DAY 2
  441. AUTO MODE IS SELECTED
  442. SPIN PERIOD IS - 315
  443. Z  MAG FIRINGS = 0
  444. + SPIN FIRINGS = 41
  445. - SPIN FIRINGS = 3
  446. RAM WASH POINTER AT 89C4
  447. WOD COMMENCED 20 /11 /89 AT 0 :0 :10
  448. WITH CHANNELS 1 ,2 ,3 ,61 ,
  449. LAST CMD RECEIVED WAS 109 TO 0 WITH DATA 0
  450.  
  451. ATTITUDE CONTROL INITIATED, MODE 1
  452.  
  453. DATA COLLECTION IN PROGRESS
  454.  
  455. DIGITALKER ACTIVE
  456.  
  457.  
  458.  
  459.         **** UoSAT-OSCAR-11 BULLETIN - 205      17th November 1989 ****
  460.  
  461.                          UoSAT MISSION CONTROL CENTRE
  462.           University of Surrey, Guildford, Surrey, GU2 5XH, England
  463.  
  464. *** UoSAT-D & E LAUNCH ADVANCED! ***
  465.  
  466. In a surprise move this week, the launch of the UoSAT-D & E spacecraft and the
  467. Microsats has been brought forward to 09 January 1990 - due to problems with
  468. the SUPERBIRD satellite that was scheduled for launch in mid-December.  UoSAT-
  469. D & E are now undergoing pre-flight preparations before being shipped (with
  470. the launch integration team) to Paris on 30 Nov and then Kourou on 01 Dec in
  471. readiness for mating to the ASAP on 12 Dec.
  472.  
  473. UoSAT-D & E have ccmpleted RF tests in the screen room at UoS and have been
  474. exposed to low temperature tests in the Clean Room 'freezer'at -20 C.  Marc
  475. Fouquet, designer of the CCD camera on-board UoSAT-E, has been taking 'bench-
  476. mark' images for comparison with orbital images.  Totally 'black' images have
  477. been collected to provide data for image processing using the Transputer Data
  478. Processing Experiment - also on UoSAT-E in collaboration with the European
  479. Space Agency.  The additional solar simulation tests planned for next week
  480. have had to be cancelled due to the advance in departure date, and the
  481. spacecraft are now undergoing final cleaning and assembly in the Clean Room.
  482. Uplink & downlink calibrations in an RF anechoic chamber are planned for next
  483. week - providing that the chamber can be made available within the very tight
  484. schedule.  Numerous visitors from several countries (as well as the UK) have
  485. recently come to UoS to view the new UoSAT spacecraft.
  486.  
  487. ** Phase III-D **
  488.  
  489. AMSAT-DL announced that they have received substantial funding for the Phase
  490. III-D satellite which, as outlined by DJ4ZC's paper presented at the 1988
  491. AMSAT-UK Colloquium, will depart quite radically from its predecessors -- it
  492. is designed to have an RF output of 250 W, will weigh 200 to 400 kg and will
  493. be placed in a high-altitude Molniya orbit, similar to OSCAR-13.
  494.  
  495. **  OSCAR-13 OPERATING SCHEDULE  **
  496.  
  497. MODE B         MA 060 to MA 160   NOTE: MODE S Operation will
  498. MODE JL        MA 160 to MA 195         return Nov. 23rd after
  499. MODE B Beacon  MA 195 to MA 200         the next AO-13 attitude
  500. MODE B         MA 200 to MA 240         re-adjustment.
  501. OFF            MA 240 to MA 060
  502.  
  503. ** AMSAT OSCAR-10 Status Report **
  504.  
  505. Please DO NOT USE the Mode B transponder on AO-10 until 20-Nov-89 since AO-10
  506. does not have sufficient solar illumination to support the general use of the
  507. Mode-B transponder at this time.
  508.  
  509. *** Thanks for Reports ***
  510.  
  511. Thanks to all those who have sent in reports and telemetry from the last days
  512. of UO-9.  Dave Guimont, Jr. WB6LLO still holds the record with telemetry at
  513. 05:15 UTC (13 October).  Can anyone do better?
  514.  
  515. Reports received this week from:-
  516.  
  517. Angus Newman, G6CSG
  518.  
  519. ** $BID **
  520.  
  521. Please use BID $UOSAT.205 for PR BBS use.
  522.  
  523.  
  524.  
  525.  
  526. -- 
  527. AMPR : KD2BD @ NN2Z (Neptune, NJ)
  528. UUCP : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd
  529.        "For every problem, there is one solution which is simple,
  530.        neat and wrong." -- H.L. Mencken
  531.  
  532. ------------------------------
  533.  
  534. End of INFO-HAMS Digest V89 Issue #911
  535. **************************************
  536.  
  537.