|
in reply to Re^9: Querying program port
in thread Querying program port
Before I get into Permission denied, I need to address my mistakes I made .
333networks is not a game, but a game server browser. That uses UDP port 27900 and TCP port 28900. I sent that info so you could have some idea of what I was trying to do, forgetting 333networks was a browser and not a game. That explains the weirdness you seen with 333networks.
You launch a game, your game send 333networks a UDP heartbeat packet with your game server info.
I launch the same game, wanting to find a server to play on, I click scan internet in the game browser, using TCP protocol.
333networks then sends me your game server info, highlighting it, clicking join, we are now using UDP protocol connecting our games, and no longer using 333networks game server browser.
Games use TCP protocol to be queried, that why Jetfighter returned nothing using UDP port 8181, but did using TCP port 8182. You said the -u means UDP, that really has me confused because nc 12.234.56.789 8182 -u , \status\, returned a response from Jetfighter, using a TCP port with -u UDP switch resulted in a response, confusing!
The following is from my Ubuntu terminal,
$ /home/cougarxr7/Perl/portscript333.pl
bash: /home/cougarxr7/Perl/portscript333.pl: Permission denied.
Now I change permissions on the file to run as program.
$ /home/cougarxr7/Perl/portscript333.pl
bash: /home/cougarxr7/Perl/portscript333.pl: /usr/bin/perl^M: bad interpreter: No such file or directory.
chmod a+x /home/cougarxr7/Perl/portscript333.pl.
The terminal started a new session after doing the above input. Tried again same results.
I am asking, since I cannot run this script, Can you please rewrite it with port inc? As I described earlier in my post.
Then I can watch the terminal displaying port inc. starting with port 25000.
~$ 25001
~$ 25002
~$ 25003
Keeps incrementing by 1 until game response/replies.
I like the #parse and pretty print!
I hope you will rewrite this script for me!
I now realize when sending a pm, You Said means message sent!
For kicks and giggles, I wound up #'ing every line of code in that file,starting at the bottom and still got permission denied. So it's not what's in the file but the file itself. |
Re^11: Querying program port
by poj (Abbot) on Aug 12, 2019 at 12:29 UTC
|
> sudo apt-get install dos2unix
> dos2unix portscript333.pl
poj | [reply] |
|
|
Thanks for helping!
I did not create this file, jcb created that file. I tried to download it but it took me to another page and did nothing.
First time I copied and pasted using my win10 comp, pasted into padre. No luck.
Second time using my Ubuntu comp, I copied and pasted into bluefish, again same results.
Tried your suggestion, the following is from my Ubuntu terminal.
~$ dos2unix /home/cougarxr7/Perl/blueports.pl
dos2unix: converting file /home/cougarxr7/Perl/blueports.pl to Unix format...
~$ /home/cougarxr7/Perl/blueports.pl
bash: /home/cougarxr7/Perl/blueports.pl: Permission denied
The file is named blueports to let me know I used Bluefish.
Not sure what you mean with, "windows line ending"?
| [reply] |
|
|
"Not sure what you mean with, "windows line ending"?"
See Newline. when you've used dos2unix you need to set the permissions on the new file, adding execute as required. chmod +x blueports.pl. You'd also benefit from an introduction to the command prompt.
| [reply]
[d/l] |
|
|
Re^11: Querying program port
by marto (Cardinal) on Aug 12, 2019 at 12:31 UTC
|
bad interpreter: No such file or directory.
Had you searched for this you'd have found out that you've got a carriage return on the end of the shebang line. dos2unix will help. | [reply]
[d/l] |
|
|
I've used Unix systems where CR on the shebang line is not a problem. So I guess this is Unix variant or local installation option specific. A bigger annoyance to me was that LPR interpreted the CR as an extra LF so any printout of my Windows code had blank lines interspersed. I am no longer am working in that mixed environment, but I had a simple s/\s*$//; print "$_\n"; at each end to correct any weirdness encountered although Windows appears to be very well behaved with just <LF> endings.
Perhaps as interesting sidenote, the network standard is CR/LF. So all TCP lines end that way whether generated on Unix or Windows. Perl takes care of the details for you. So on Unix if you print to the printer, \n means just LF while when printing to a TCP socket \n means CR/LF.
Your Newline link was hoot! A trip down memory lane. The ASR 33 teletype was the first computer terminal I ever used. Not mentioned in the Wiki is that the standard way to end a line was: CR/LF/Rubout(NULL). Dr. StrangeLove has an ASR 33 teletype in it. When you hit a rubout, the carriage that does the printing, bobs up and down. Tapes would start with a sequence of rubouts and end with a series of rubouts. This has a distinctive sound to it. The rubout or NULL caused all 8 columns on the tape to be punched. This was a reliability issue. The paper tape was soaked with oil. Inserting a NULL every line caused all 8 pins to be exercised (and hence lubricated) on read or write.
Update: For fun, I was able to find some ASR33 documentation online at: ASR33. The Wiki describes a scenario where a certain sequence of characters could cause the terminal to misprint (a printing character sent too soon after a CR). I don't remember anything like that. I figure this part of the Wiki is highly suspect! Folks should understand that this was way before the age of microprocessors and we are talking about an extremely "stupid" machine. Each key press resulted in one mechanical action on the terminal. I suspect that this thing was too "stupid" to see a single character and then perform a sequence of mechanical actions (couldn't do CR and LF at the same time even if it wanted to). There was RS-232 hardware flow control via the hardware lines with names like RTS (Request to Send)/CTS(Clear to Send) etc. So there was a way for the terminal to signal that it wasn't ready to accept the next character until it was ready. Times have certainly changed! Nowadays, there is often either software flow control (XON/XOFF) or none at all. The assumption in the latter case is that you can receive my max length request packet at full speed. And implicit is that I can receive your max length response packet at full speed. This requires "smarts" and buffers - neither was available in the ASR33 days.
| [reply]
[d/l] |
|
|
Thank you for helping!
Please read my previous reply to poj.
Also what is, "shebang line"?
| [reply] |
|
|
| [reply] |
|
|
