Difference between revisions of "User:Zamujasa/Station Network"

From Space Station 13 Wiki
Jump to navigation Jump to search
m (Bolded packet line.)
 
(13 intermediate revisions by 5 users not shown)
Line 5: Line 5:
Here's some information on abusing the station network. Use responsibly. Or don't. Probably don't.
Here's some information on abusing the station network. Use responsibly. Or don't. Probably don't.


{{User:Zamujasa/Terminal|<nowiki>NERD ALERT!!!!</nowiki>}}
'''Any and all packets typed into a terminal are formatted as the following:''' code=output; - they must always be ended with a semi-colon. For example, command=open;address_1=1234


== DWAINE for smartasses ==


=== Advanced tips and tricks ===
== DWAINE ==
[[DWAINE for Dummies]] is pretty basic and there's a lot of weird shit you can do with the terminals and mainframe beyond what it explains (it also seems to be pretty out of date).
The mainframe on the station network runs on DWAINE. It's pretty important if you want to futz around with the network.


I'd like to make a better tutorial/guide for using it here.
There's a book in-game about it called ''[[DWAINE for Dummies]]''. It's pretty basic, though. I'm working on a more... power-focused guide. See ''[[../DWAINE for Smartasses|DWAINE for Smartasses]]''.


=== Telescience for people who love typing ===
== Authentication ==
There are a handful of authentication codes you may or may not need.


You'll need <code>su</code> access (though ''that's'' easy). The first thing you should (probably) do is copy <code>teleman</code> out of the <code>/sys/srv</code> folder into one you make yourself. Then run these wherever you copied it:
The first three are stored on the Authentication Disk, so if you ask nicely maybe the Captain will give it to you.
* <code>netpass_heads</code>: Used for Guardbuddy management, shuttle (re)calling, etc.
* <code>netpass_security</code>: Used only for networked turrets, which don't really exist anywhere.
* <code>netpass_medical</code>: Not used at all, as far as I can tell.
* <code>netpass_syndicate</code>: Exclusively for the Detomatix cart.


<pre>echo #!|nteleman coords $arg0 $arg1 $arg2|nteleman scan ^ scan
echo #!|nteleman coords $arg0 $arg1 $arg2|nteleman receive ^ recv
echo #!|nteleman coords $arg0 $arg1 $arg2|nteleman send ^ send
echo #!|nteleman coords $arg0 $arg1 $arg2|nteleman portal ^ portal
echo #!|nteleman relay $arg0 $arg1 $arg2 $arg3 $arg4 $arg5 ^ relay</pre>
These will combine the "set coordinates" and "do a thing" commands into one, simplifying things a great deal. The copy of <code>teleman</code> also means you won't need su to access it again.
As an AI or Cyborg, terminal windows will stay with you and update, making it much more effective to use than trying to use the telescience computer itself, since the interface for that doesn't update if you aren't near it (and people can modify the numbers you input). As a human, if you can make a copy of this, you can use it anywhere a wireless computer can reach the mainframe! (Or if you're REALLY into it, PDA messages...)


== Wired Network ==
Stuff on the station network connected by red power cables.


=== Artifact research for people who hate typing ===
'''Important note for packet sniffers''': The packet sniffer spaces out the various fields in a packet. If you want to copy them for your own use in, say, some Mechanics deathtrap, ''remove the spaces after the semicolons''.


This will make a copy of the artlab utilities in the event some dummy breaks the tape drive or it goes offline or whatever, and provide a list of very handy shortcuts to make everything much easier.


<pre>mkdir /artlab
=== Networked devices ===
cp /mnt/artlab/gptio /artlab
Get a list of these by running <code>term_ping</code> on any [[TermOS]] computer that isn't currently connected to something. Not all devices can be connected to via TermOS, though, and some won't reply to pings either. Sneaky!
cd /artlab
echo #!|ngptio activate $arg0 ^ a
echo #!|ngptio deactivate $arg0 ^ d
echo #!|ngptio sense $arg0|ngptio read $arg0 ^ r
echo #!|ngptio info $arg0 ^ i
echo #!|ngptio poke heater temptarget 200 ^ cold
echo #!|ngptio poke heater temptarget 400 ^ hot
echo #!|ngptio poke impactpad stand 1 ^ raise
echo #!|ngptio poke impactpad stand 0 ^ lower
echo #!|ngptio poke xray radstrength $arg0 ^ radstrength
</pre>


Now just use <code>a heater</code> to start something up, <code>d heater</code> to turn it off, <code>r xray</code> to automatically sense shit and print it out.


<s>Hell, get creative and do <code>a x_ray ^ /mnt/lp-whatever/butt</code> to automatically print out info! ''wow''</s> this didn't seem to work, have to try again later
==== Mainframe (PNET_MAINFRAME) ====
 
The good ol' mainframe, usually hanging around the [[Computer Core]]. Connect to this to access [[DWAINE]]. Pretty much every terminal on the station starts out connected to this.
'''Bonus''': You don't need to type the underscores in device names. <code>impactpad</code> works for <code>impact_pad</code>, <code>xray</code> works for <code>x_ray</code>, etc.
 
 
=== Oops the mainframe died, now what ===
 
When the mainframe is restored (e.g. from a temporary power outage/APC tomfoolery), <code>gptio</code> will helpfully forget all of the device names -- they'll all show up as <code>UNKNOWN</code>, so you can't refer to them by name.
 
To get their names back, use <code>gptio info <i>address</i></code>, which will update its name and allow you to use it as a shortcut again.
 
If someone REALLY fucked it up and removed the memory core (only doable when it's unpowered), you'll have to get a replacement from Hemera or maybe the Lava Moon. Good luck!
 
 
=== The goddamn [[Research Director|RD]] deleted prman ===
 
There's a backup ThinkTape in the RD's office you can insert into the databank. It contains a copy of everything in <code>/mnt/control</code>, and when inserted into the RD's databank will show up at <code>/mnt/rd</code>. Be sure to let your local RD know that he is very mean.
 
 
=== Scanning paper and other junk ===
 
Put piece of paper or other doodad onto a scanner. Go to your local DWAINE terminal and look for <code>/mnt/sc-<i>location</i></code>. Run <code>cat /mnt/sc-<i>location</i>/document</code> to take a look at it (or copy it or whatever). Note that half-broken HTML and other garbage comes along for the ride. Welp!
 
 
== Wired Network ==
Stuff on the station network connected by red power cables.  


=== Types of networked devices ===
There are a few of these scattered around [[Adventure Zone|the universe]], though a lot of them are broken and don't actually work.
Get a list of these by running <code>term_ping</code> on any [[TermOS]] computer that isn't currently connected to something. Not all devices can be connected to via TermOS, though!


==== PNET_MAINFRAME ====


The good ol' mainframe, usually hanging around the [[Computer Core]]. Connect to this to access [[DWAINE]], and from that, a bunch of other things.
==== AI (MAINFRAME_AI) ====
The [[AI]]. Connecting to this will make the AI see "''Direct connection from (02001234)''". You can chat with the AI by simply sending messages, and it will be able to reply as long as you're connected &mdash; your messages show up like PDA messages and the AI can respond in the same way.


Some of these exist off the station!


==== Communications Dish (PNET_COM_ARRAY) ====
The communications dish, primarily used for calling (or recalling) the shuttle, as well as delivering the often completely inaccurate "threat report" at the start of a round.


==== MAINFRAME_AI ====
===== Commands =====


The [[AI]]. Connecting to this will make the AI see "''Direct connection from (02001234)''". You can chat with the AI by simply sending messages, and it will be able to reply as long as you're connected.
* Call or recall the Emergency Shuttle. Returns '''<code>status</code>''' = <code>SHUTL_E_DIS</code> (failed), <code>SHUTL_E_SEN</code> (called), or <code>SHUTL_E_RET</code> (recalled).
** '''<code>command</code>''': <code>call</code> or <code>recall</code> (call or recall the shuttle; self-explanatory)
** '''<code>shuttle_id</code>''': <code>emergency</code> (the only usable option)
** '''<code>acc_code</code>''': The [[#Authentication|netpass_heads authentication code]]
** '''<code>reason</code>''': optional reason for calling the shuttle


* Transmit something to [[Admin|Centcom]]. Returns '''<code>status</code>''' = <code>TRANSMIT_E_SUCCESS</code> or <code>TRANSMIT_E_COOLDOWN</code>.
** '''<code>command</code>''': <code>transmit</code>
** '''<code>acc_code</code>''': The [[#Authentication|netpass_heads authentication code]]
** '''<code>title</code>''': transmission title
** '''<code>data</code>''': message to transmit
** '''<code>user</code>''': user transmitting message


==== PNET_COM_ARRAY ====
* View / download Centcom messages (generally the "threat report" which is always wildly wrong, sometimes other things).
The communications array! Connecting to this will usually give you a short message with two commands, <code>View</code> and <code>Download ##</code>. Using <code>View</code> will give you a list of available messages (usually only one, the "threat report") that you can get; using <code>Download (id)</code> will send the message directly to your terminal, which you can print out with <code>file_print</code>. Keep in mind that the information on the threat report is usually wildly incorrect.
** Unlike the above commands, these are entered from a terminal connected directly to the array.
** '''<code>command</code>''': <code>term_message</code> (automatically added if sending from a terminal)
** '''<code>data</code>''': The text entered into the terminal, e.g. "<code>command=download&amp;message=1</code>".
*** '''<code>command</code>''': One of the following:
**** <code>list</code>: Lists available messages
**** <code>download</code>: Sends a message as a file that you can then <code>file_print</code> (etc)
*** '''<code>message</code>''': If using <code>download</code>, a message number


Packet dump:
Packet dump:
Line 98: Line 74:
(recv) command=device_reply; status=SHUTL_E_SEN; address_1=0200c069; sender=020036fd;</pre>
(recv) command=device_reply; status=SHUTL_E_SEN; address_1=0200c069; sender=020036fd;</pre>


The ''authentication code'' above is randomly generated each round -- it looks something like "<code>1234 Alpha-567</code>". You can get it from reading GuardBuddy command packets, which include it. Actually sending this signal can probably be done by using [[ThinkDOS]] and the SigCraft builder, but doing that is left as an exercise to the reader.


==== PNET_ADAPTER ====
==== Terminals (PNET_ADAPTER) ====
TODO: Probably other terminals on the network?
Other terminals and data terminals on the network, generally. You can direct-connect two TermOS computers together if you want, but there's not much you can really do with that beyond chat back and forth and send files, maybe.




==== PNET_S_TELEPAD ====
==== Telepad (PNET_S_TELEPAD) ====
The telepad. TODO: Document commands, packets, etc.
The Telescience Telepad. There can be more than one of these; you specify which one you want with the <code>-p [0-9]</code> argument to <code>teleman</code>.


'''You can't change the coordinates with just packets!''' You can only send, receive, and maybe toggle a portal. (info by AngriestIBM via Luis Smith)
'''You can't change the coordinates with just packets.''' Coordinates are updated by the computer contacting the mainframe, which sends out the command to the telepad with an attached file.


Raw packet dump:
Raw packet dump:
Line 125: Line 100:




 
==== Printers (PNET_PRINTDEVC) ====
==== PNET_PRINTDEVC ====
Printers. Not sure if you can print directly to them (maybe with <code>file_send</code>); generally you just write to the <code>/mnt/lp-whatever</code> folders on the mainframe.
Printers. Unsure if you can print directly to them (maybe with <code>file_send</code>), generally you just write to the <code>/mnt/lp-whatever</code> folders on the mainframe.




==== PNET_DATA_BANK ====
==== Databanks (PNET_DATA_BANK) ====
The data banks that contain all of the information on the mainframe. Probably not useful to connect to.
The data banks that contain all of the information on the mainframe.




==== PNET_PR6_CHARG ====
==== GuardBuddy docking station (PNET_PR6_CHARG) ====
[[GuardBuddy]] chargers.
[[GuardBuddy]] chargers. These also communicate wirelessly to the buddies; see the section there for more.


Raw packet log (likely, might be another device):
Raw packets below. You can see the <code>netpass_heads</code> authentication code in here as well (''3635 Bravo-51'').


<pre>[37:25:5]:command=term_message; data=_command=add&_freq=1219; render; address_1=020020f4; sender=02002182;  
<pre>[37:25:5]:command=term_message; data=_command=add&_freq=1219; render; address_1=020020f4; sender=02002182;  
[37:25:5]:command=term_message; data=_freq=1219&acc_code=3635 Bravo-501;command=dock_return; render; address_1=020020f4; sender=02002182;  
[37:25:5]:command=term_message; data=_freq=1219&acc_code=3635 Bravo-501;command=dock_return; render; address_1=020020f4; sender=02002182;  
[37:25:5]:command=term_message; data=command=status&status=success; address_1=02002182; sender=020020f4;  
[37:25:5]:command=term_message; data=command=status&status=success; address_1=02002182; sender=020020f4;  
[40:30:1]:address_1=02002182; data=prman upload 0200143B heckle name=titusgettemy; command=term_message; sender=0200b5ce;
[49:37:5]:command=term_message; data=command=status&status=ejected&botid=020032dd; address_1=02002182; sender=0200143b;</pre>
Some of the commands you can use, as <code>command=#######</code>:
* <code>status</code>: Gets the status of a buddy docked to this station as a reply:
** <code>status=nobot</code>: If you get "nobot", there's no buddy here. You'll get only this for every command.
** <code>status=########</code>: The buddy's network identifier.
** <code>charge=###</code>: Either <code>nocell</code> (no power cell) or a number from 0 to 100 representing the percent of power remaining in the buddy's cell.
** <code>tool=#####</code>: The current tool (weapon), or "NONE" if there's no tool installed.
** <code>deftask=#####</code>: The ''default'' task this buddy runs when it has nothing better to do, or "NONE" if it doesn't have one.
** <code>curtask=#####</code>: The ''current'' task this buddy is running, or "NONE" if it doesn't have one.
* <code>eject</code>: Boots the buddy out of the docking station.
** No reply here. If you didn't get a <code>nobot</code> reply, it worked.
* <code>upload</code>: Uploads a new task to the buddy. Optionally with <code>overwrite=?</code> and <code>newmodel=?</code>, which overwrite the current task or default task respectively. Requires a file to be sent along with the data, so good luck spoofing this.
** You'll get a reply with <code>status=upload_success</code> if the task has been uploaded.
** You'll get a reply with <code>status=badtask</code> if the task is bad (or missing).
* <code>download</code>: Downloads a task from the buddy. Use <code>model=?</code> to download the default task, otherwise it'll download the current one.
** Replies with <code>command=taskfile</code> if it worked. In theory you'll get a file sent to your terminal with the task. What can you do with it?
** Replies with <code>command=status&status=notask</code> if there's no task to download.
* <code>taskinq</code>: Gets the buddy's currently installed tasks.
** Replies with <code>command=trep</code>, with <code>deftask=#####</code> for the default task and <code>curtask=#####</code> for the current task, or "NONE" if there isn't one.
* <code>wipe</code>: Erases the buddy's installed tasks and replaces them with nothing.
** Replies with <code>command=status&status=wipe_success</code>.


[40:30:1]:address_1=02002182; data=prman upload 0200143B heckle name=titusgettemy; command=term_message; sender=0200b5ce;


[49:37:5]:command=term_message; data=command=status&status=ejected&botid=020032dd; address_1=02002182; sender=0200143b;</pre>
The chargers also occasionally report back to their host (i.e. the mainframe) when things happen. The format of these may not be 100% correct.
* <code>command=status&status=ejected&botid=########</code>: Ejected a buddy.
* <code>command=status&status=connect&botid=########</code>: A buddy docked itself or was docked by someone.


Importantly, the <code>acc_code</code> is the same one required to call the shuttle via packet communication. (How to do this still needs to be documented here, though.)


==== PNET_PR6_RADIO ====
==== Mainframe Radio (PNET_PR6_RADIO) ====
Mainframe radio, mostly used for talking to the [[GuardBuddy]] bots when they're away from chargers.
The radio near the Mainframe. It's mostly used for talking to the [[GuardBuddy]] bots when they're away from chargers, but you can do some other stuff with it.


Capturing packets with the power of the mainframe:
Capturing packets with the power of the mainframe:
Line 163: Line 165:


Regardless, packet dumps (raw, not bothering to explain):
Regardless, packet dumps (raw, not bothering to explain):
<code>[19:41:7]:command=term_message; data=_command=add&_freq=1149; render; address_1=02002303; sender=02002275;  
<pre>[19:41:7]:command=term_message; data=_command=add&_freq=1149; render; address_1=02002303; sender=02002275;  
[20:03:3]:command=term_message; data=_freq=1149&command=text_message&message=butt&sender_name=fart; render; address_1=02002303; sender=02002275;  
[20:03:3]:command=term_message; data=_freq=1149&command=text_message&message=butt&sender_name=fart; render; address_1=02002303; sender=02002275;  
[45:35:6]:address_1=02002275; data=echo test=butt ^ x; command=term_message; sender=02018e2a;  
[45:35:6]:address_1=02002275; data=echo test=butt ^ x; command=term_message; sender=02018e2a;  
[45:35:6]:command=term_message; data=command=status&status=success; address_1=02002275; sender=02002303;  
[45:35:6]:command=term_message; data=command=status&status=success; address_1=02002275; sender=02002303;  
[45:35:6]:command=term_message; data=_freq=1149&test=butt; render; address_1=02002303; sender=02002275;</code>
[45:35:6]:command=term_message; data=_freq=1149&test=butt; render; address_1=02002303; sender=02002275;</pre>


==== PNET_IR_DETECT ====
==== IR detectors (PNET_IR_DETECT) ====
The IR detectors around the outside of the north part of the [[Computer Core]], guarding the AI. Sends a packet to you immediately upon connect (TODO: put here), doesn't seem to do anything interesting. Note that the top-right IR detector on the AI core, at least, doesn't seem to actually be on the network (it says '''NO CONNECTION''' if you check it).
IR detectors, usually placed around important things like the Armory and sometimes the AI core.


''(Todo: update)''


==== PNET_TEST_APPT ====
 
The various testing apparatus in the artifact lab TODO:Check what GPTIO sends
==== Artlab test apparatus (PNET_TEST_APPT) ====
The various testing apparatuses in the Artifact Lab. Also includes the "Gas Sensors" you see in places like Toxins.
:<code>[34:18:5]:command=term_message; data=command=deactivate; render; address_1=02000d04; sender=02000673; </code>
:<code>[34:18:5]:command=term_message; data=command=deactivate; render; address_1=02000d04; sender=02000673; </code>
:<code>[34:18:5]:command=term_message; data=OK; render; address_1=0200cbf2; sender=02000673; </code>
:<code>[34:18:5]:command=term_message; data=OK; render; address_1=0200cbf2; sender=02000673; </code>
:<code>[34:18:5]:address_1=02000673; data=gptio deactivate elec_box; command=term_message; sender=0200cbf2; </code>
:<code>[34:18:5]:address_1=02000673; data=gptio deactivate elec_box; command=term_message; sender=0200cbf2; </code>


==== SRV_TERMINAL ====
 
The teleport computer for the science teleporter. It doesn't communicate directly with the teleport pad, but instead sends commands to the mainframe. If you want to learn to control the science teleporter remotely, these would be the packets you want to sniff out.
==== Terminals (SRV_TERMINAL) ====
The teleport computer for the Telescience telepad. It doesn't communicate directly with the teleport pad, but instead sends commands to the mainframe. If you want to learn to control the science teleporter remotely, these would be the packets you want to sniff out.
 
Note that a few other things also use this as a tag.


<pre>P: [020639b9]-TYPE: SRV_TERMINAL
<pre>P: [020639b9]-TYPE: SRV_TERMINAL
Line 194: Line 201:
[58:27:7]:command=term_message; data=command=OK; render; address_1=020639b9; sender=02002d0e; </pre>
[58:27:7]:command=term_message; data=command=OK; render; address_1=020639b9; sender=02002d0e; </pre>


==== PNET_NUCCHARGE ====
 
The nuclear charge. Authentication is easily spoofed by using the mainframe's built in nuke manager nukeman (doesn't actually seem to be on Hemera VII's mainframe, just take the datatape from the bridge/mainframe area). Just use the same packet you used to spoof superuser access when asked to login with an authorized ID, then repeat with 2 more login packets under 2 different names (the registered= field).
==== Nuclear charge (PNET_NUCCHARGE) ====
The nuclear charge. Authentication is easily spoofed by using the mainframe's built in nuke manager, <code>nukeman</code>. Just use the same packet you used to spoof superuser access when asked to login with an authorized ID, then repeat with two more login packets under two different names (the registered= field).
 
Hemera VII's main tape doesn't include this, so you'll have to bring a tape of your own with it or "borrow" one of the replacement Master Tapes on the station.
 
<sub>You can also scan the nuclear charge with a Syndicate device analyzer and deploy one elsewhere, if that's more [[Traitor|your thing]].</sub>
 
==== Area Power Controllers (PNET_PWR_CNTRL) ====
The [[Engineer#APCs|Area Power Controllers]] attached to the network. They have settings for the equipment, lights, and environmental controls, as well as control of the cover lock. The three power settings can be values from 0 to 3, which represent the following states:
* <code>0</code>: Off
* <code>1</code>: Auto (Off)
* <code>2</code>: On
* <code>3</code>: Auto (On)
 
APCs start off connected to the mainframe, and as such will only respond to packets they believe came from the mainframe. You'll need to override the sender field or disconnect it with a spoofed <code>term_disconnect</code>, the latter allowing you to connect directly with a DWAINE terminal. Some of the packets you can use to interact with them look like this:
 
<pre>sender=02003c12; address_1=02006754; command=term_message; data=command=setmode&light=0&environ=0;
sender=02003c12; address_1=02006754; command=term_message; data=command=status;</pre>
 
You can use the following commands with <code>data=command=#######</code> or simply <code>command=#######</code> if connected by terminal:
* <code>status</code>: Returns the status of the APC, including all the following fields (but unfortunately not the area name):
** <code>charge=###</code>: A number from 0 to 100 representing the percent of power remaining in the APC's cell
** <code>equip=#</code>: A number from 0 to 3 representing the state of the equipment setting for the APC
** <code>light=#</code>: A number from 0 to 3 representing the state of the light setting for the APC
** <code>environ=#</code>: A number from 0 to 3 representing the state of the environmental control setting for the APC
** <code>cover=#</code>: A number representing the state of the cover lock, with 1 for engaged and 0 for disengaged
* <code>setmode</code>: This command allows you to control the state of the APC, supplying any of the values you wish to change. You can include settings for any of:
** <code>equip=#</code>
** <code>light=#</code>
** <code>environ=#</code>
** <code>cover=#</code>
 
Please note that if you turn off equipment power to the computer core APC, you'll have a difficult time executing any more commands.
 


=== Creating packets ===
=== Creating packets ===
Line 227: Line 267:
* <code>registered=Pubbie Jones</code>
* <code>registered=Pubbie Jones</code>
* <code>assignment=Staff Assistant</code>
* <code>assignment=Staff Assistant</code>
* <code>access=</code>, followed by a (semicolon? comma?)-separated list of rights -- every access in the ID computer has a different one. The important one for <code>su</code> access is 34
* <code>access=</code>, followed by a (semicolon? comma?)-separated list of rights &mdash; every access in the ID computer has a different one. The important one for <code>su</code> access is 34.


Applying all of the above to create the packet and register it for <code>file_send</code>:
Applying all of the above to create the packet and register it for <code>file_send</code>:
:<code>echo registered=Pubbie Jones|nassignment=Hacker|naccess=34 ^ /mnt/term/loginpacket</code>
:<code>echo registered=Pubbie Jones|nassignment=Staff Assistant|naccess=34 ^ /mnt/term/loginpacket</code>


Keep in mind that [[Rules#Don't grief|you shouldn't use this]] to set the [[GuardBuddy|Guardbuddies]] to purge or other destructive things unless you're a [[traitor]].


Keep in mind that [[Rules#Don't grief|you shouldn't use this]] to set the [[GuardBuddy|Guardbuddies]] to purge or other destructive things unless you're a [[traitor]]!


=== Sending packets using the mainframe's radio ===
=== Sending packets using the mainframe's radio ===
Line 240: Line 280:


# Create a directory for the frequency you want to transmit on. Directories are the four numbers without the decimal point, e.g. <code>/mnt/radio/1149</code> for 114.9, by using the command <code>mkdir /mnt/radio/1149</code>
# Create a directory for the frequency you want to transmit on. Directories are the four numbers without the decimal point, e.g. <code>/mnt/radio/1149</code> for 114.9, by using the command <code>mkdir /mnt/radio/1149</code>
#* If the directory already exists for whatever reason, you can skip this step
#* If the directory already exists for whatever reason, you can skip this step.
# Craft your packet
# Craft your packet.
#* Optional: Save it if you need to use it more than once. Otherwise, just use <code>echo</code> and pipe it directly.
#* Optional: Save it if you need to use it more than once. Otherwise, just use <code>echo</code> and pipe it directly.
# Copy or move your crafted packet to the folder you created, e.g. <code>copy packet /mnt/radio/1149</code> or <code>echo ... ^ /mnt/radio/1149/packet</code>
# Copy or move your crafted packet to the folder you created, e.g. <code>copy packet /mnt/radio/1149</code> or <code>echo ... ^ /mnt/radio/1149/packet</code>
Line 247: Line 287:
If it worked, the packet you crafted should automatically be sent out by the radio. You can use the Packet Sniffer program on your [[PDA]] to confirm.
If it worked, the packet you crafted should automatically be sent out by the radio. You can use the Packet Sniffer program on your [[PDA]] to confirm.


 
== Wireless Network ==
 
== Radio Frequencies ==


Basically everything you can spoof (aside from PDA messages) will require a <code>address_1</code> field, indicating the target of the message.
Basically everything you can spoof (aside from PDA messages) will require a <code>address_1</code> field, indicating the target of the message.


<code>sender</code> is added automatically to almost every packet-sending device, though apparently you can get away without one by manually crafting a signal and using a wireless computer's free mode (with greatly reduced range)
<code>sender</code> is added automatically to almost every packet-sending device, though apparently you can get away without one by manually crafting a signal and using a wireless computer's free mode (with greatly reduced range).
 


PDA Ping ranges. Sending may be similar (or unlimited size?). Measured by dropping a PDA and seeing how far away it would still respond.
PDA Ping ranges. Sending may be similar (or unlimited size?). Measured by dropping a PDA and seeing how far away it would still respond.
Line 261: Line 298:
* <code>max</code>: 64 tiles
* <code>max</code>: 64 tiles


Note that pings go ''through'' [[Z-level]]s! If you manage to pin down a signal but there doesn't seem to be anything there, it's probably in the debris field or in one of the [[Adventure Zone|adventure zones]]. Welp!  
Note that pings go ''through'' [[Z-level]]s! If you manage to pin down a signal but there doesn't seem to be anything there, it's probably in the debris field or in one of the [[Adventure Zone|adventure zones]]. Welp! <sup>(todo: is this still true?)</sup>


=== 114.9 - Various devices ===
Broadcast ranges are ''only'' for broadcasting &mdash; anything can receive a packet if it's in the broadcast range of the source, even if its own broadcast range is far smaller. If your device has a broadcast range of 64 tiles, and your target device has a range of 16 tiles, the target device will receive your signal as long as you're anywhere within 64 tiles, but you won't receive the device's beyond those 16.


==== [[PDA]]s ====


=== PDAs (114.9) ===
They're [[PDA]]s. You know, the ones almost everyone spawns with.
* Device name: <code>NET_PDA_51XX</code>
* Device name: <code>NET_PDA_51XX</code>
* Broadcast range: &ge; 64 tiles (127 &times; 127)
* Broadcast range: &ge; 64 tiles (127 &times; 127)


Packets:
Packets:
* Really easy to scan, the Network Tools cartridge defaults to this frequency
* Really easy to scan, the Network Tools cartridge defaults to this frequency.
* Snoop on people trying to use PDAs to covertly message people! <s>Just be sure to get your ID switched to "NSA Operative" first</s> Clear the log regularly so it doesn't clog up with PDA pings.
* Snoop on people trying to use PDAs to covertly message people! <s>Just be sure to get your ID switched to "NSA Operative" first</s> Clear the log regularly so it doesn't clog up with PDA pings.
Packet spoofing:
Packet spoofing:
* <code>address_1</code>: Needed if you're targeting one PDA, otherwise it's a mass broadcast to every PDA
* <code>address_1</code>: Omit to broadcast to every PDA in range. Otherwise, set to a PDA's address to send only to that PDA.
* <code>command</code>: Generally <code>text_message</code>, though there are others, including but not limited to:
* <code>command</code>: Generally <code>text_message</code>, though there are others, including but not limited to:
**<code>file_send_req</code> Used send file send requests, can't actually send anything without using the PDA clip board
**<code>file_send_req</code> Used to send file send requests, though you can't actually send anything without using the PDA clipboard.
***<code>file_size</code> The size of the file
***<code>file_size</code> The size of the file
***<code>file_ext</code> The file extension (PPROG, TXT, etc.)
***<code>file_ext</code> The file extension (PPROG, TXT, etc.)
***<code>file_name</code> The name of the file
***<code>file_name</code> The name of the file
**<code>file_send_acc</code> Used to accept file send requests, doesn't work unless someone's sending you a file. Can be spoofed with a ThinkDOS computer on free mode, causing the file to download to the target PDA. Note that this still requires a valid file send request.
**<code>file_send_acc</code> Used to accept file send requests. Can be spoofed with a ThinkDOS computer on free mode, causing the file to download to the target PDA. Can only accept a valid file send request, and must be sent to the pda that sent the request.
**<code>file_send</code> Used to send files after send requests are accepted, doesn't work without an accepted file request
**<code>file_send</code> Used to send files after send requests are accepted, doesn't work without an accepted file request.
**<code>report_pda</code> The scan function in the pda messenger
**<code>report_pda</code> The scan function in the PDA messenger.
**<code>report_reply</code> Replies to report_pda, can be used to change your pda's name to other people on the messenger
**<code>report_reply</code> Replies to <code>report_pda</code>, can be used to change your PDA's name to other people on the messenger
* <code>message</code>: The text you want to send. Surprise!
* <code>message</code>: The text you want to send. Surprise!
* <code>sender_name</code>: What the name should show up as. Leaving it blank will make PDAs show it as '''!UNKNOWN!''' (or something close)
* <code>sender_name</code>: What the name should show up as. Leaving it blank will make PDAs show it as '''!UNKNOWN!'''
* And more!
* <code>sender_assignment</code> What the job assignment of the sender should show up as.


<!--
Experiment! Maybe you'll find more.


todo: move this to a "deleted" section -- this doesnt seem to exist any more, or if it does it isn't responding to point-blank pings
=== Ruckingenur kits (114.9) ===
 
Ruckingenur kits, like the one in the [[Electronics|Electronics lab]].
==== <code>NET_DNASCANNER</code> ====
DNA scanners in [[Genetics]]. Don't seem to respond to anything but pings, no packets sniffed when stuffing someone into or out of them. Probably used for the Geneticist PDA scanner.
-->
 
==== Ruckingeur kits ====


* Device name: <code>NET_RKANALYZER</code>
* Device name: <code>NET_RKANALYZER</code>
* Broadcast range: &ge; 64 tiles (127 &times; 127)
* Broadcast range: &ge; 64 tiles (127 &times; 127)


Ruckingenur kits, like the one in the [[Electronics|Electronics lab]].


Packet sent when adding something to the database via PDA scan:
Packet sent when adding something to the database via PDA scan:
* <code>command</code>: <code>add</code> -- Adds something to the database. Doesn't actually specify what it is. D'oh.
* <code>command</code>: <code>add</code> -- Adds something to the database. Doesn't actually specify what it is. D'oh.
* <code>address_1</code>: <code>02xxxxxx</code> -- Address of the kit, as usual
* <code>address_1</code>: <code>02xxxxxx</code> -- Address of the kit, as usual
* A file, which you can't sniff, I guess.


After that, the kit will send out a PDA text message to the sending PDA informing them that it has been added to the database.
After that, the kit will send out a PDA text message to the scanning PDA that it was either added or already in the database.


Spoofing the packet does nothing. Scanning a device using a Device Analyzer sends no packets at scan or on addition to the kit.
Spoofing the packet does nothing, as it requires the file that you can't send. Scanning a device using a Device Analyzer sends no packets at scan or on addition to the kit.




==== <code>WNET_ADAPTER</code> - Security computer ====
=== Wireless network adapters (114.9, variable) ===
Computers that have a wireless network card. Some of these are included even in devices that aren't ''really'' computers, and they don't really do anything, like the "filing cabinet" Security computers.


Security computers, like the filing cabinet in the [[Morgue]]. Doesn't send or receive any packets when interacting with it normally.
* Device name: <code>WNET_ADAPTER</code>
* Broadcast range: varies


Morgue filing cabinet:
 
Cogmap1's Morgue filing cabinet, for example:
* Broadcast range: 18 tiles (35 &times; 35)
* Broadcast range: 18 tiles (35 &times; 35)


Others may be different.
Others may be different. The ranges are dependent on the type of card and its mode.


=== 121.9 - [[GuardBuddy|GuardBuddies]] ===
=== GuardBuddy devices (121.9) ===
[[GuardBuddy|GuardBuddies]] and their docking stations.


Raw packet log:
* Device name: <code>PNET_PR6_GUARD</code> (buddies), <code>PNET_PR6_CHARG</code> (docking stations)
<pre>[25:20:0]:data=1248.5; address_1=recharge; sender=02000fbc;
* Broadcast range: &asymp; 75 tiles (150 &times; 150)
[25:20:2]:data=1492.5; address_1=recharge; sender=020015e1;
[25:20:4]:command=recharge_src; data=x=68&y=65; address_1=02000fbc; sender=02001358;
[25:20:4]:command=recharge_src; data=x=66&y=66; address_1=02000fbc; sender=0200142a;  
[25:20:4]:command=recharge_src; data=x=66&y=67; address_1=02000fbc; sender=0200150a;
[25:20:4]:command=recharge_src; data=x=71&y=68; address_1=02000fbc; sender=020015e0;
[25:20:5]:command=recharge_src; data=x=69&y=65; address_1=02000fbc; sender=0200135e;
[25:20:5]:command=recharge_src; data=x=71&y=66; address_1=02000fbc; sender=0200143a;
[25:20:5]:command=recharge_src; data=x=71&y=67; address_1=02000fbc; sender=0200151a;
[25:20:6]:command=recharge_src; data=x=136&y=59; address_1=020015e1; sender=02000fc0;
[25:20:6]:command=recharge_src; data=x=69&y=65; address_1=020015e1; sender=0200135e;
[25:20:6]:command=recharge_src; data=x=71&y=67; address_1=020015e1; sender=0200151a;
[25:20:6]:command=recharge_src; data=x=71&y=68; address_1=020015e1; sender=020015e0;
[25:20:6]:command=recharge_src; data=x=71&y=69; address_1=020015e1; sender=0200168d;
[25:20:6]:command=recharge_src; data=x=136&y=59; address_1=02000fbc; sender=02000fc0;
[25:20:6]:command=recharge_src; data=x=71&y=69; address_1=02000fbc; sender=0200168d;
[25:20:7]:command=recharge_src; data=x=71&y=66; address_1=020015e1; sender=0200143a;
[25:20:8]:command=recharge_src; data=x=68&y=65; address_1=020015e1; sender=02001358;
[25:20:8]:command=recharge_src; data=x=66&y=66; address_1=020015e1; sender=0200142a;
[25:20:8]:command=recharge_src; data=x=66&y=67; address_1=020015e1; sender=0200150a;
[25:26:2]:data=1490.5; address_1=recharge; sender=0200143b;
[25:26:4]:data=1490.5; address_1=recharge; sender=0200168e;
[25:26:6]:command=recharge_src; data=x=69&y=65; address_1=0200143b; sender=0200135e;
[25:26:6]:command=recharge_src; data=x=71&y=66; address_1=0200143b; sender=0200143a;
[25:26:6]:command=recharge_src; data=x=66&y=67; address_1=0200143b; sender=0200150a;
[25:26:7]:command=recharge_src; data=x=66&y=66; address_1=0200143b; sender=0200142a;
[25:26:7]:command=recharge_src; data=x=71&y=67; address_1=0200143b; sender=0200151a;
[25:26:8]:command=recharge_src; data=x=68&y=65; address_1=0200143b; sender=02001358;
[25:26:8]:command=recharge_src; data=x=71&y=69; address_1=0200143b; sender=0200168d;
[25:26:8]:command=recharge_src; data=x=69&y=65; address_1=0200168e; sender=0200135e;
[25:26:8]:command=recharge_src; data=x=71&y=67; address_1=0200168e; sender=0200151a;
[25:26:8]:command=recharge_src; data=x=71&y=69; address_1=0200168e; sender=0200168d;
[25:26:9]:command=recharge_src; data=x=68&y=65; address_1=0200168e; sender=02001358;
[25:26:9]:command=recharge_src; data=x=71&y=66; address_1=0200168e; sender=0200143a;
[25:26:9]:command=recharge_src; data=x=66&y=67; address_1=0200168e; sender=0200150a;
[25:27:1]:command=recharge_src; data=x=66&y=66; address_1=0200168e; sender=0200142a;</pre>


The following is sent exclusively by the docking stations. They also communicate over the wired network; see their section above for more.
* <code>command=recharge_src; data=x=##&y=##;</code>: Sent by the docking station as a reply to the <code>recharge</code> broadcast, with its current X and Y (GPS) position, so the buddies know where to go to charge.


=== 141.1 - Doors ===


There's a lot of network traffic, but here's some examples. If you aren't targeting a specific bot's address, you need to include <code>acc_code=(netpass_heads)</code>.
* <code>address_1=recharge</code>: Sent ''by'' the buddies as a broadcast. Causes the docking stations to report their locations; see above.
* <code>command=dock_return</code>: Adds a task to the buddy to go to a docking station and dock. Makes the buddy say "Software update requested" and show the "update" emotion.
* <code>command=captain_greet</code>: Makes the buddy say one of several goofy lines, if it's wearing the captain's hat. Sent by the tour guide buddy if it runs into another buddy wearing it.
* <code>command=wizard_greet</code>: Makes the buddy say of several other goofy lines, if it's wearing a wizard's hat. Sent by the tour guide buddy if it runs into another buddy wearing it.
=== Doors (141.1) ===
Pretty much every airlock on, and off, the station.
* Device name: <code>DOR_AIRLOCK</code>
* Device name: <code>DOR_AIRLOCK</code>
* Broadcast range: 6 tiles (11 &times; 11)
* Broadcast range: 6 tiles (11 &times; 11)




Doors only broadcast signals nearby, so you'll have to be close if you want to see anything. You can sniff packets if you click on a door (or someone else does), or just ping and try to pick the right one from the list. Alternatively, screwdriving the access panel open will reveal the network address, as well.
Sending a command to a door requires an access code, a number usually between 1 and 32 (inclusive). This can be found on the maintenance panel by screwdrivering the door. Doors only broadcast signals relatively close by, so you'll have to be nearby if you want to see anything. You can get the address of a door by screwdrivering it open and checking, using the packet sniffer and touching the door, or just taking a guess from doors that respond to your pings.  
Some doors can't be screwdrivered so you'll have to use a different option, but those doors also tend to resist packet hacking. AI control is a requirement for doors to receive packets, and most of these doors have it off by default.


Doors broadcast certain details whenever they're interacted with, as well as a few moments later when they auto-close.
Doors broadcast certain details whenever they're interacted with, as well as a few moments later when they auto-close.
Line 382: Line 397:
Sending packets manually to open/close doors:
Sending packets manually to open/close doors:
* <code>address_1</code>: Network address of door (required)
* <code>address_1</code>: Network address of door (required)
* <code>access_code</code>: Access code of the door (required)
* <code>command</code>: One of the following:
* <code>command</code>: One of the following:
** <code>open</code>: Opens a door
** <code>open</code>: Opens a door
Line 392: Line 408:
<small>*Used by the [[Syndicate Items#EMAG|cryptographic sequencer]].</small>
<small>*Used by the [[Syndicate Items#EMAG|cryptographic sequencer]].</small>


=== 141.1 - PNET_PR6_RADIO ===
=== Network Radio (141.1, 141.9, also varies) ===
 
The "Network Radio", which looks like... well, an old timey radio. Usually located near the mainframe in the computer core, sometimes it's elsewhere. This is what interfaces with the mainframe's <code>/mnt/radio</code>.
?
* Device name: <code>PNET_PR6_RADIO</code>
 
* Broadcast range: ?
 
=== 141.9 - PNET_PR6_RADIO ===


?
You can log into the mainframe by connecting to this using a computer with a wireless network peripheral and FROG or TermOS. You can create a login packet using ThinkDOS's WizWrite and put it on the main drive in ThinkDOS under whatever name you want, then restart with a TermOS disk and run "<code>file_load [name]</code>" in TermOS, which will allow you to run <code>file_send</code> with the login packet.
The actual device is a 'Network Radio' (a unique looking terminal). It's located in the CE office(cog2), or the computer cores in Cog1 and Destiny.
(Some) messages send to it will be converted into a DWAINE network packet and relayed to the mainframe.


Alternatively, maybe you can receive other files and save them to the disk with <code>file_save [name]</code>, too...?


If you switch a 'portable computer' to it's wireless mode, it's network card will default to this frequency.
If you run FROG (or restart the laptop with TermOS disk), you can ping the network and connect to this device.
This will allow you to use the DWAINE network on the laptop, with all of it's perks.
You can create a login packet using WizWrite and put it on the main drive in ThinkDOS under whatever name you want. Then, you can run "file_load [name]" in TermOS, which will allow you to run file_send with the login packet.
=== 143.1 - Secure Lockers ===


=== Secure Lockers (143.1) ===
Secure lockers that require an ID to open, including personal lockers in the [[Crew Quarters]].
* Device name: <code>WNET_SECLOCKER</code>
* Device name: <code>WNET_SECLOCKER</code>
* Broadcast range: 3 tiles (5 &times; 5)
* Broadcast range: 3 tiles (5 &times; 5)


Secure lockers, including personal lockers in the [[Crew Quarters]]. Personal lockers don't send messages when opened/claimed with an ID.
The range on these is ''extremely'' short.


=== 143.1 - More Patrol Shit ===
You can send these a few commands over the radio, though you'll need <code>netpass_security</code> to lock or unlock them and <code>netpass_heads</code> to find <code>netpass_security</code>.
* <code>command=status</code>: Replies with <code>command=lock=[locked]&open=[open]</code>
* <code>command=lock; pass=(netpass_security)</code>: Locks the locker.
* <code>command=unlock; pass=(netpass_security)</code>: Unlocks the locker. Surprise.


What's sending these? Who knows!
If you use one of the lock or unlock packets, you'll get a response with <code>command=ack</code> or <code>command=nack; data=badpass</code> depending on if it worked or not.


<pre>[13:28:2]:findbeacon=patrol; address_1=!BEACON!; sender=02008ad5;
Personal lockers don't send messages when opened/claimed with an ID.
[13:28:3]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access;
[13:28:3]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage;
[13:28:3]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters;
[13:28:3]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction;
[13:34:3]:findbeacon=patrol; address_1=!BEACON!; sender=02008b00;
[13:34:3]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access;
[13:34:3]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage;
[13:34:3]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters;
[13:34:3]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction;
[13:34:4]:findbeacon=patrol; address_1=!BEACON!; sender=02008af3;
[13:34:4]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access;
[13:34:4]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage;
[13:34:4]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters;
[13:34:4]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction;
[13:47:5]:findbeacon=patrol; address_1=!BEACON!; sender=02008ad5;
[13:47:5]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access;
[13:47:5]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage;
[13:47:5]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters;
[13:47:5]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction;
[13:54:2]:findbeacon=patrol; address_1=!BEACON!; sender=02008b00;
[13:54:3]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access;
[13:54:3]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage;
[13:54:3]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters;
[13:54:3]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction; </pre>




=== 143.3 - Hydroponics trays ===
=== Hydroponics trays (143.3) ===


* Device name: <code>WNET_PACKETSPY</code>, <code>WNET_GENERIC</code>, <code>WNET_DETECTOR</code>, <code>WNET_SYN%%^#FF</code>
* Device name: One of <code>WNET_PACKETSPY</code>, <code>WNET_GENERIC</code>, <code>WNET_DETECTOR</code>, <code>WNET_SYN%%^#FF</code>, randomly
** They randomly cycle between these on each ping.
* Broadcast range: &ge;64 tiles (129 &times; 129)
* Broadcast range: &ge;64 tiles (129 &times; 129)


Packets:
Packets:
* <code>netid</code>: <code>02001234</code> -- The address of that particular tray
* <code>netid</code>: <code>02001234</code> -- The address of that particular tray. (Isn't this what <code>sender</code> is for?)
* <code>data</code>: One of the following:
* <code>data</code>: One of the following:
** <code>event_new</code>: A seed was planted in the tray
** <code>event_new</code>: A seed was planted in the tray.
** <code>event_death</code>: The plant died. RIP
** <code>event_death</code>: The plant died.
** <code>event_cleared</code>: The plant (dead or otherwise) was removed from the tray
** <code>event_cleared</code>: The plant (dead or otherwise) was removed from the tray.


Doesn't seem to be a way to actually make any of this information useful.
Yep, that's it. There's nothing useful here <sub>(as of the 2016 release)</sub>. Not even the type of seed, or if it's ready to harvest, or anything. Sorry.






=== 143.7 - Fire Alarms ===
=== Fire Alarms (143.7) ===
This is from the 2016 release and may not be entirely relevant now, but...
* Device name: <code>PNET_FIREALARM</code> (even though it's WNET...)
* Broadcast range: &infin; (possibly)


Packet Sniffing:
* <code>zone</code>: Fire alarm's location (e.g. <code>Head of Research's Office</code>)
* <code>type</code>: Alert type (e.g. <code>Fire</code>)
* <code>netid</code>: Fire alarm's network address?
* <code>alert</code>: Alert type (e.g. <code>fire</code>, <code>reset</code>, maybe more?)


Broadcasts a packet when things happen:
* <code>zone</code>: Location name (like <code>Head of Research's Office</code>)
* <code>type</code>: Alarm type (always <code>Fire</code>)
* <code>netid</code>: Network address (as well as <code>sender</code> for some reason)
* <code>alert</code>: What happened:
** <code>fire</code>: Fire alarm triggered
** <code>reset</code>: Fire alarm cleared


=== 144.3 - Robot patrol beacons ===
 
You can also trigger these remotely if you want to be annoying.
* <code>command=#####</code>: One of the following:
** <code>status</code>: Triggers the above packet broadcast.
** <code>trigger</code>: Triggers the alarm.
** <code>reset</code>: Resets the alarm.
 
 
=== Robot patrol beacons (many frequencies) ===
Various patrol beacons around the station. These are used by Guardbuddies, Securitrons, and the tour guide, though often not on the same frequencies.
* Frequencies: 143.1, 144.1, 144.3, 144.5, and so on.
 
They don't respond to pings, but they do respond to beacon requests. Beacons have a specific format and options available to control how bots act and what they do.


Securitron and tour guide beacons broadcast on this frequency. They're located under floor tiles, and you can access them by popping them open with a screwdriver and swiping an appropriate card.
Securitron and tour guide beacons broadcast on this frequency. They're located under floor tiles, and you can access them by popping them open with a screwdriver and swiping an appropriate card.
Todo: This section needs some updating, for triggering and receiving beacon broadcasts, as well as editing them and how they work.


'''Tour Guide beacon''', this one from the Escape Arm:
'''Tour Guide beacon''', this one from the Escape Arm:
Line 487: Line 493:
** <code>patrol</code>: <code>1</code> -- Marks it as a patrol beacon
** <code>patrol</code>: <code>1</code> -- Marks it as a patrol beacon
** <code>next_patrol</code>: <code>bar</code> -- Which beacon comes after this in the route (TODO: verify the name)
** <code>next_patrol</code>: <code>bar</code> -- Which beacon comes after this in the route (TODO: verify the name)


You can't move the beacons around or create new ones, but you can at least make Murray shout obscenities when describing places. Or make him get stuck into a loop forever. Keep in mind that the text length you're allowed to enter is much shorter than the length of the default tour messages.
You can't move the beacons around or create new ones, but you can at least make Murray shout obscenities when describing places. Or make him get stuck into a loop forever. Keep in mind that the text length you're allowed to enter is much shorter than the length of the default tour messages.
Line 495: Line 500:
[37:15:3]:beacon=tour13; netid=02000e46; tour=1; next_tour=tour14; desc=...;  
[37:15:3]:beacon=tour13; netid=02000e46; tour=1; next_tour=tour14; desc=...;  
[37:15:3]:beacon=tour16; netid=02000fa6; tour=1; next_tour=tour14; desc=...;  
[37:15:3]:beacon=tour16; netid=02000fa6; tour=1; next_tour=tour14; desc=...;  
[37:15:3]:beacon=tour14; netid=020016f1; tour=1; next_tour=tour16; desc=...;
</pre>
[37:15:3]:beacon=tour15; netid=02001894; tour=1; next_tour=tour16; desc=...;
[37:15:3]:beacon=tour12; netid=02001905; tour=1; next_tour=tour13; desc=...;
[37:15:3]:beacon=tour11; netid=020026bb; tour=1; next_tour=tour12; desc=...;
[37:15:3]:beacon=tour10; netid=02002e0c; tour=1; next_tour=tour11; desc=...;
[37:15:3]:beacon=tour17; netid=02002e0f; tour=1; next_tour=tour18; desc=...;
[37:15:3]:beacon=tour8; netid=02003897; tour=1; next_tour=tour9; desc=...;</pre>
 
=== 144.5 - ? ===
 
Something to do with patrolling and beacons. TODO: Packet captures, etc


=== 144.7 - [[Robot|Securitrons and MULEs]] ===


[[Robots#Securitron|Securitrons]] and [[Robots#MULEBot|MULE bots]] share this frequency.
=== Securitrons (144.7) ===
 
[[Robots#Securitron|Securitrons]].
 
==== Securitrons ====


'''Status updates, sent from the bots:'''
'''Status updates, sent from the bots:'''
Line 519: Line 511:
* <code>loca</code>: <code>Cafeteria</code> -- where the bot is currently located.
* <code>loca</code>: <code>Cafeteria</code> -- where the bot is currently located.
* <code>mode</code>: <code>0</code> -- One of various modes (as described by the Securitron control PDA app):
* <code>mode</code>: <code>0</code> -- One of various modes (as described by the Securitron control PDA app):
** <code>0</code>: ''Ready'' (idle)
** <code>0</code>: Idle (''Ready'')
** <code>1</code>: ''Apprehending target'' (chasing after someone set to arrest)
** <code>1</code>: Spotted someone marked as arrest (''Apprehending target'')
** <code>2</code>: (unknown - one of these is probably for when it's actually caught someone, or detaining)
** <code>2</code>: At target, preparing to arrest
** <code>3</code>: (unknown)
** <code>3</code>: Arresting target
** <code>4</code>: ''Starting patrol''
** <code>4</code>: ''Starting patrol''
** <code>5</code>: ''On patrol''
** <code>5</code>: ''On patrol''
** <code>6</code>: ''Responding to summons'' (will go to mode 4 and start patrolling when it reaches its destination)
** <code>6</code>: (''Responding to summons'') &mdash; will go to mode 4 and start patrolling when it reaches its destination




Line 534: Line 526:
** <code>stop</code>: Stop patrolling
** <code>stop</code>: Stop patrolling
** <code>summon</code>: Summons the bot
** <code>summon</code>: Summons the bot
* <code>active</code>: <code>Officer Beepsky</code> -- again, no way to differentiate between different bots
* <code>active</code>: <code>Officer Beepsky</code> (see note below)
* <code>target</code>: <code>the floor</code> -- Only if <code>command</code>=<code>summon</code>. Theoretically should be where the bot should go, but...
* <code>target</code>: <code>the floor</code>; only if <code>command=summon</code>. (see note below)
** The <code>target</code> seems to ''always'' be <code>the floor</code>, regardless of where you are
 
*** This is because a byond atom reference is being passed in the packet, printing this reference will yield its name ("(the) floor"). ''It is impossible to replicate this packet.'' I'd recommend bringing this to IBM's attention. --[[User:Marquesas|Marquesas]]
Notes: These are BYOND internal atom references, and not actually text, so they're impossible to replicate in packets. These only work from the PDA application for that reason.
** Bots don't actually respond to these summons, unless they're from the [[PDA#R.O.B.U.S.T.|R.O.B.U.S.T. cart's Securitron app]]
 
<small>(Original note: This is because a byond atom reference is being passed in the packet, printing this reference will yield its name ("(the) floor"). ''It is impossible to replicate this packet.'' I'd recommend bringing this to IBM's attention. --[[User:Marquesas|Marquesas]])</small>
 


==== MULE Bots ====
=== MULE bots (144.7) ===
[[Robots#MULEBot|MULE bots]].


'''Status updates, sent from the bots:'''
'''Status updates, sent from the bots:'''
Line 555: Line 550:
* <code>pick</code>: <code>1</code> -- Pick up crates at the destination
* <code>pick</code>: <code>1</code> -- Pick up crates at the destination


'''Controlling via the QM's PDA:'''
Controlling via the QM's PDA: (todo)
* TODO. But hey, at least you can tell what's being shipped around (and where), so you can go intercept that nice crate full of goodies.
 
Likely has the same bug as Securitrons above, since they share a lot of the same code.
 
 
=== Armory Authorization (146.1) ===
This is the computer used by heads of staff to authorize the armory.
* Device name: <code>ARM_AUTH</code>
* Broadcast range: todo
 
The armory responds with <code>acc_code=netpass_security</code> when authorized, which is needed to open lockers via packets.
 
 
'''Getting netpass_security:'''
Sending the following packet authorizes the armory:
 
<code>address_1=[arm_auth netid];command=authorize;acc_code=[netpass_heads];</code>
 
The armory will reply with a packet containing a different <code>acc_code</code> than what you sent it. This new code is <code>netpass_security</code>.
 
There does not seem to be a way to unauthorize the armory, and there is currently no other method for getting <code>netpass_security</code>.

Latest revision as of 04:26, 21 December 2020

This page is probably REALLY out of date -- see this for what's been updated in my absence.

Somehow this page became The Definitive Guide to the Station Network and I don't even. Welp! I never finished it and lost interest but a few people have been updating it in my absence.

Here's some information on abusing the station network. Use responsibly. Or don't. Probably don't.

Any and all packets typed into a terminal are formatted as the following: code=output; - they must always be ended with a semi-colon. For example, command=open;address_1=1234


DWAINE

The mainframe on the station network runs on DWAINE. It's pretty important if you want to futz around with the network.

There's a book in-game about it called DWAINE for Dummies. It's pretty basic, though. I'm working on a more... power-focused guide. See DWAINE for Smartasses.

Authentication

There are a handful of authentication codes you may or may not need.

The first three are stored on the Authentication Disk, so if you ask nicely maybe the Captain will give it to you.

  • netpass_heads: Used for Guardbuddy management, shuttle (re)calling, etc.
  • netpass_security: Used only for networked turrets, which don't really exist anywhere.
  • netpass_medical: Not used at all, as far as I can tell.
  • netpass_syndicate: Exclusively for the Detomatix cart.


Wired Network

Stuff on the station network connected by red power cables.

Important note for packet sniffers: The packet sniffer spaces out the various fields in a packet. If you want to copy them for your own use in, say, some Mechanics deathtrap, remove the spaces after the semicolons.


Networked devices

Get a list of these by running term_ping on any TermOS computer that isn't currently connected to something. Not all devices can be connected to via TermOS, though, and some won't reply to pings either. Sneaky!


Mainframe (PNET_MAINFRAME)

The good ol' mainframe, usually hanging around the Computer Core. Connect to this to access DWAINE. Pretty much every terminal on the station starts out connected to this.

There are a few of these scattered around the universe, though a lot of them are broken and don't actually work.


AI (MAINFRAME_AI)

The AI. Connecting to this will make the AI see "Direct connection from (02001234)". You can chat with the AI by simply sending messages, and it will be able to reply as long as you're connected — your messages show up like PDA messages and the AI can respond in the same way.


Communications Dish (PNET_COM_ARRAY)

The communications dish, primarily used for calling (or recalling) the shuttle, as well as delivering the often completely inaccurate "threat report" at the start of a round.

Commands
  • Call or recall the Emergency Shuttle. Returns status = SHUTL_E_DIS (failed), SHUTL_E_SEN (called), or SHUTL_E_RET (recalled).
    • command: call or recall (call or recall the shuttle; self-explanatory)
    • shuttle_id: emergency (the only usable option)
    • acc_code: The netpass_heads authentication code
    • reason: optional reason for calling the shuttle
  • Transmit something to Centcom. Returns status = TRANSMIT_E_SUCCESS or TRANSMIT_E_COOLDOWN.
  • View / download Centcom messages (generally the "threat report" which is always wildly wrong, sometimes other things).
    • Unlike the above commands, these are entered from a terminal connected directly to the array.
    • command: term_message (automatically added if sending from a terminal)
    • data: The text entered into the terminal, e.g. "command=download&message=1".
      • command: One of the following:
        • list: Lists available messages
        • download: Sends a message as a file that you can then file_print (etc)
      • message: If using download, a message number

Packet dump:

(sent) address_1=020036fd; command=call; shuttle_id=emergency; acc_code=(Authentication code); sender=0200c069; 
(recv) command=device_reply; status=SHUTL_E_SEN; address_1=0200c069; sender=020036fd;


Terminals (PNET_ADAPTER)

Other terminals and data terminals on the network, generally. You can direct-connect two TermOS computers together if you want, but there's not much you can really do with that beyond chat back and forth and send files, maybe.


Telepad (PNET_S_TELEPAD)

The Telescience Telepad. There can be more than one of these; you specify which one you want with the -p [0-9] argument to teleman.

You can't change the coordinates with just packets. Coordinates are updated by the computer contacting the mainframe, which sends out the command to the telepad with an attached file.

Raw packet dump:

[18:47:4]:command=term_message; data=command=teleman&args=-p 1 send; address_1=02002182; sender=02001ed4; 
[18:47:5]:command=term_message; data=command=send&session=746; render; address_1=02001cbd; sender=02002182; 
[18:47:5]:command=term_message; data=command=ack&session=746; address_1=02002182; sender=02001cbd; 
[18:48:1]:command=term_message; data=command=OK; render; address_1=02001ed4; sender=02002182; 
[19:10:1]:command=term_message; data=command=teleman&args=-p 1 receive; address_1=02002182; sender=02001ed4; 
[19:10:1]:command=term_message; data=command=receive&session=17; render; address_1=02001cbd; sender=02002182; 
[19:10:1]:command=term_message; data=command=nack&cause=recharge&session=17; address_1=02002182; sender=02001cbd; 
[19:10:7]:command=term_message; data=command=Telepad is recharging.; render; address_1=02001ed4; sender=02002182; 
[19:13:3]:command=term_message; data=command=teleman&args=-p 1 receive; address_1=02002182; sender=02001ed4; 
[19:13:4]:command=term_message; data=command=receive&session=333; render; address_1=02001cbd; sender=02002182; 
[19:13:4]:command=term_message; data=command=ack&session=333; address_1=02002182; sender=02001cbd; 
[19:14:0]:command=term_message; data=command=OK; render; address_1=02001ed4; sender=02002182;


Printers (PNET_PRINTDEVC)

Printers. Not sure if you can print directly to them (maybe with file_send); generally you just write to the /mnt/lp-whatever folders on the mainframe.


Databanks (PNET_DATA_BANK)

The data banks that contain all of the information on the mainframe.


GuardBuddy docking station (PNET_PR6_CHARG)

GuardBuddy chargers. These also communicate wirelessly to the buddies; see the section there for more.

Raw packets below. You can see the netpass_heads authentication code in here as well (3635 Bravo-51).

[37:25:5]:command=term_message; data=_command=add&_freq=1219; render; address_1=020020f4; sender=02002182; 
[37:25:5]:command=term_message; data=_freq=1219&acc_code=3635 Bravo-501;command=dock_return; render; address_1=020020f4; sender=02002182; 
[37:25:5]:command=term_message; data=command=status&status=success; address_1=02002182; sender=020020f4; 
[40:30:1]:address_1=02002182; data=prman upload 0200143B heckle name=titusgettemy; command=term_message; sender=0200b5ce; 
[49:37:5]:command=term_message; data=command=status&status=ejected&botid=020032dd; address_1=02002182; sender=0200143b;

Some of the commands you can use, as command=#######:

  • status: Gets the status of a buddy docked to this station as a reply:
    • status=nobot: If you get "nobot", there's no buddy here. You'll get only this for every command.
    • status=########: The buddy's network identifier.
    • charge=###: Either nocell (no power cell) or a number from 0 to 100 representing the percent of power remaining in the buddy's cell.
    • tool=#####: The current tool (weapon), or "NONE" if there's no tool installed.
    • deftask=#####: The default task this buddy runs when it has nothing better to do, or "NONE" if it doesn't have one.
    • curtask=#####: The current task this buddy is running, or "NONE" if it doesn't have one.
  • eject: Boots the buddy out of the docking station.
    • No reply here. If you didn't get a nobot reply, it worked.
  • upload: Uploads a new task to the buddy. Optionally with overwrite=? and newmodel=?, which overwrite the current task or default task respectively. Requires a file to be sent along with the data, so good luck spoofing this.
    • You'll get a reply with status=upload_success if the task has been uploaded.
    • You'll get a reply with status=badtask if the task is bad (or missing).
  • download: Downloads a task from the buddy. Use model=? to download the default task, otherwise it'll download the current one.
    • Replies with command=taskfile if it worked. In theory you'll get a file sent to your terminal with the task. What can you do with it?
    • Replies with command=status&status=notask if there's no task to download.
  • taskinq: Gets the buddy's currently installed tasks.
    • Replies with command=trep, with deftask=##### for the default task and curtask=##### for the current task, or "NONE" if there isn't one.
  • wipe: Erases the buddy's installed tasks and replaces them with nothing.
    • Replies with command=status&status=wipe_success.


The chargers also occasionally report back to their host (i.e. the mainframe) when things happen. The format of these may not be 100% correct.

  • command=status&status=ejected&botid=########: Ejected a buddy.
  • command=status&status=connect&botid=########: A buddy docked itself or was docked by someone.


Mainframe Radio (PNET_PR6_RADIO)

The radio near the Mainframe. It's mostly used for talking to the GuardBuddy bots when they're away from chargers, but you can do some other stuff with it.

Capturing packets with the power of the mainframe:

  1. Make a folder for the frequency you want to monitor, e.g. /mnt/radio/1149
  2. Periodically ls /mnt/radio/1149 to see if any packets have appeared
  3. cat /mnt/radio/1149/Q2158018 to view packets

The mainframe will capture any packet sent to a frequency that has a directory created.

Note: The actual mechanics behind this are a bit different (there's some communications going on between the mainframe and radio) but for the most part this will get you what you want.

Regardless, packet dumps (raw, not bothering to explain):

[19:41:7]:command=term_message; data=_command=add&_freq=1149; render; address_1=02002303; sender=02002275; 
[20:03:3]:command=term_message; data=_freq=1149&command=text_message&message=butt&sender_name=fart; render; address_1=02002303; sender=02002275; 
[45:35:6]:address_1=02002275; data=echo test=butt ^ x; command=term_message; sender=02018e2a; 
[45:35:6]:command=term_message; data=command=status&status=success; address_1=02002275; sender=02002303; 
[45:35:6]:command=term_message; data=_freq=1149&test=butt; render; address_1=02002303; sender=02002275;

IR detectors (PNET_IR_DETECT)

IR detectors, usually placed around important things like the Armory and sometimes the AI core.

(Todo: update)


Artlab test apparatus (PNET_TEST_APPT)

The various testing apparatuses in the Artifact Lab. Also includes the "Gas Sensors" you see in places like Toxins.

[34:18:5]:command=term_message; data=command=deactivate; render; address_1=02000d04; sender=02000673;
[34:18:5]:command=term_message; data=OK; render; address_1=0200cbf2; sender=02000673;
[34:18:5]:address_1=02000673; data=gptio deactivate elec_box; command=term_message; sender=0200cbf2;


Terminals (SRV_TERMINAL)

The teleport computer for the Telescience telepad. It doesn't communicate directly with the teleport pad, but instead sends commands to the mainframe. If you want to learn to control the science teleporter remotely, these would be the packets you want to sniff out.

Note that a few other things also use this as a tag.

P: [020639b9]-TYPE: SRV_TERMINAL
P: [02002d0e]-TYPE: PNET_MAINFRAME
[58:26:4]:command=term_message; data=command=teleman&args=-p 2 coords x=50 y=50 z=4; address_1=02002d0e; sender=020639b9; 
[58:26:5]:command=term_message; data=command=ack&session=641; address_1=02002d0e; sender=020639b6; 
[58:26:5]:data=command=set_coords&session=641; address_1=020639b6; command=term_file; sender=02002d0e; 
[58:27:0]:command=term_message; data=command=teleman&args=-p 2 send; address_1=02002d0e; sender=020639b9; 
[58:27:1]:command=term_message; data=command=OK; render; address_1=020639b9; sender=02002d0e; 
[58:27:1]:command=term_message; data=command=send&session=708; render; address_1=020639b6; sender=02002d0e; 
[58:27:1]:command=term_message; data=command=ack&session=708; address_1=02002d0e; sender=020639b6; 
[58:27:7]:command=term_message; data=command=OK; render; address_1=020639b9; sender=02002d0e; 


Nuclear charge (PNET_NUCCHARGE)

The nuclear charge. Authentication is easily spoofed by using the mainframe's built in nuke manager, nukeman. Just use the same packet you used to spoof superuser access when asked to login with an authorized ID, then repeat with two more login packets under two different names (the registered= field).

Hemera VII's main tape doesn't include this, so you'll have to bring a tape of your own with it or "borrow" one of the replacement Master Tapes on the station.

You can also scan the nuclear charge with a Syndicate device analyzer and deploy one elsewhere, if that's more your thing.

Area Power Controllers (PNET_PWR_CNTRL)

The Area Power Controllers attached to the network. They have settings for the equipment, lights, and environmental controls, as well as control of the cover lock. The three power settings can be values from 0 to 3, which represent the following states:

  • 0: Off
  • 1: Auto (Off)
  • 2: On
  • 3: Auto (On)

APCs start off connected to the mainframe, and as such will only respond to packets they believe came from the mainframe. You'll need to override the sender field or disconnect it with a spoofed term_disconnect, the latter allowing you to connect directly with a DWAINE terminal. Some of the packets you can use to interact with them look like this:

sender=02003c12; address_1=02006754; command=term_message; data=command=setmode&light=0&environ=0;
sender=02003c12; address_1=02006754; command=term_message; data=command=status;

You can use the following commands with data=command=####### or simply command=####### if connected by terminal:

  • status: Returns the status of the APC, including all the following fields (but unfortunately not the area name):
    • charge=###: A number from 0 to 100 representing the percent of power remaining in the APC's cell
    • equip=#: A number from 0 to 3 representing the state of the equipment setting for the APC
    • light=#: A number from 0 to 3 representing the state of the light setting for the APC
    • environ=#: A number from 0 to 3 representing the state of the environmental control setting for the APC
    • cover=#: A number representing the state of the cover lock, with 1 for engaged and 0 for disengaged
  • setmode: This command allows you to control the state of the APC, supplying any of the values you wish to change. You can include settings for any of:
    • equip=#
    • light=#
    • environ=#
    • cover=#

Please note that if you turn off equipment power to the computer core APC, you'll have a difficult time executing any more commands.


Creating packets

Packets can be created by using the following command:

echo field=value|nfield2=value2|nfield3=value3

To store the packet as a file on the mainframe:

echo ... ^ /home/pjones/filename

To send a file (like a packet!) to your terminal, so you can send it with file_send or print it with file_print, save the file to the /mnt/term directory:

cp /home/pjones/filename /mnt/term/x

If you just need to get the file right away, you can simply save the file in /mnt/term right away:

echo ... ^ /mnt/term/foo


Spoofing the login packet

Faking a login involves a few specific steps. You'll generally always need a valid ID of any kind to do the initial login, though.

  1. Log into the mainframe (insert your card and term_login)
  2. Craft a login packet
  3. Send the crafted packet back to your terminal
  4. Either enter su for admin rights, or disconnect and reconnect to log in as a completely different user
  5. Instead of using term_login, use file_send to send the packet you saved earlier
  6. You are now logged in with your forged user

The login packet looks like this:

  • registered=Pubbie Jones
  • assignment=Staff Assistant
  • access=, followed by a (semicolon? comma?)-separated list of rights — every access in the ID computer has a different one. The important one for su access is 34.

Applying all of the above to create the packet and register it for file_send:

echo registered=Pubbie Jones|nassignment=Staff Assistant|naccess=34 ^ /mnt/term/loginpacket

Keep in mind that you shouldn't use this to set the Guardbuddies to purge or other destructive things unless you're a traitor.


Sending packets using the mainframe's radio

You can use DWAINE to send out packets over the air. The mainframe's radio has a limited range, though, so it won't reach everything.

  1. Create a directory for the frequency you want to transmit on. Directories are the four numbers without the decimal point, e.g. /mnt/radio/1149 for 114.9, by using the command mkdir /mnt/radio/1149
    • If the directory already exists for whatever reason, you can skip this step.
  2. Craft your packet.
    • Optional: Save it if you need to use it more than once. Otherwise, just use echo and pipe it directly.
  3. Copy or move your crafted packet to the folder you created, e.g. copy packet /mnt/radio/1149 or echo ... ^ /mnt/radio/1149/packet

If it worked, the packet you crafted should automatically be sent out by the radio. You can use the Packet Sniffer program on your PDA to confirm.

Wireless Network

Basically everything you can spoof (aside from PDA messages) will require a address_1 field, indicating the target of the message.

sender is added automatically to almost every packet-sending device, though apparently you can get away without one by manually crafting a signal and using a wireless computer's free mode (with greatly reduced range).

PDA Ping ranges. Sending may be similar (or unlimited size?). Measured by dropping a PDA and seeing how far away it would still respond.

  • min: 16 tiles
  • med: 32 tiles
  • max: 64 tiles

Note that pings go through Z-levels! If you manage to pin down a signal but there doesn't seem to be anything there, it's probably in the debris field or in one of the adventure zones. Welp! (todo: is this still true?)

Broadcast ranges are only for broadcasting — anything can receive a packet if it's in the broadcast range of the source, even if its own broadcast range is far smaller. If your device has a broadcast range of 64 tiles, and your target device has a range of 16 tiles, the target device will receive your signal as long as you're anywhere within 64 tiles, but you won't receive the device's beyond those 16.


PDAs (114.9)

They're PDAs. You know, the ones almost everyone spawns with.

  • Device name: NET_PDA_51XX
  • Broadcast range: ≥ 64 tiles (127 × 127)


Packets:

  • Really easy to scan, the Network Tools cartridge defaults to this frequency.
  • Snoop on people trying to use PDAs to covertly message people! Just be sure to get your ID switched to "NSA Operative" first Clear the log regularly so it doesn't clog up with PDA pings.

Packet spoofing:

  • address_1: Omit to broadcast to every PDA in range. Otherwise, set to a PDA's address to send only to that PDA.
  • command: Generally text_message, though there are others, including but not limited to:
    • file_send_req Used to send file send requests, though you can't actually send anything without using the PDA clipboard.
      • file_size The size of the file
      • file_ext The file extension (PPROG, TXT, etc.)
      • file_name The name of the file
    • file_send_acc Used to accept file send requests. Can be spoofed with a ThinkDOS computer on free mode, causing the file to download to the target PDA. Can only accept a valid file send request, and must be sent to the pda that sent the request.
    • file_send Used to send files after send requests are accepted, doesn't work without an accepted file request.
    • report_pda The scan function in the PDA messenger.
    • report_reply Replies to report_pda, can be used to change your PDA's name to other people on the messenger
  • message: The text you want to send. Surprise!
  • sender_name: What the name should show up as. Leaving it blank will make PDAs show it as !UNKNOWN!
  • sender_assignment What the job assignment of the sender should show up as.

Experiment! Maybe you'll find more.

Ruckingenur kits (114.9)

Ruckingenur kits, like the one in the Electronics lab.

  • Device name: NET_RKANALYZER
  • Broadcast range: ≥ 64 tiles (127 × 127)


Packet sent when adding something to the database via PDA scan:

  • command: add -- Adds something to the database. Doesn't actually specify what it is. D'oh.
  • address_1: 02xxxxxx -- Address of the kit, as usual
  • A file, which you can't sniff, I guess.

After that, the kit will send out a PDA text message to the scanning PDA that it was either added or already in the database.

Spoofing the packet does nothing, as it requires the file that you can't send. Scanning a device using a Device Analyzer sends no packets at scan or on addition to the kit.


Wireless network adapters (114.9, variable)

Computers that have a wireless network card. Some of these are included even in devices that aren't really computers, and they don't really do anything, like the "filing cabinet" Security computers.

  • Device name: WNET_ADAPTER
  • Broadcast range: varies


Cogmap1's Morgue filing cabinet, for example:

  • Broadcast range: 18 tiles (35 × 35)

Others may be different. The ranges are dependent on the type of card and its mode.

GuardBuddy devices (121.9)

GuardBuddies and their docking stations.

  • Device name: PNET_PR6_GUARD (buddies), PNET_PR6_CHARG (docking stations)
  • Broadcast range: ≈ 75 tiles (150 × 150)

The following is sent exclusively by the docking stations. They also communicate over the wired network; see their section above for more.

  • command=recharge_src; data=x=##&y=##;: Sent by the docking station as a reply to the recharge broadcast, with its current X and Y (GPS) position, so the buddies know where to go to charge.


There's a lot of network traffic, but here's some examples. If you aren't targeting a specific bot's address, you need to include acc_code=(netpass_heads).

  • address_1=recharge: Sent by the buddies as a broadcast. Causes the docking stations to report their locations; see above.
  • command=dock_return: Adds a task to the buddy to go to a docking station and dock. Makes the buddy say "Software update requested" and show the "update" emotion.
  • command=captain_greet: Makes the buddy say one of several goofy lines, if it's wearing the captain's hat. Sent by the tour guide buddy if it runs into another buddy wearing it.
  • command=wizard_greet: Makes the buddy say of several other goofy lines, if it's wearing a wizard's hat. Sent by the tour guide buddy if it runs into another buddy wearing it.


Doors (141.1)

Pretty much every airlock on, and off, the station.

  • Device name: DOR_AIRLOCK
  • Broadcast range: 6 tiles (11 × 11)


Sending a command to a door requires an access code, a number usually between 1 and 32 (inclusive). This can be found on the maintenance panel by screwdrivering the door. Doors only broadcast signals relatively close by, so you'll have to be nearby if you want to see anything. You can get the address of a door by screwdrivering it open and checking, using the packet sniffer and touching the door, or just taking a guess from doors that respond to your pings. Some doors can't be screwdrivered so you'll have to use a different option, but those doors also tend to resist packet hacking. AI control is a requirement for doors to receive packets, and most of these doors have it off by default.

Doors broadcast certain details whenever they're interacted with, as well as a few moments later when they auto-close.

  • user_id: Person whose ID was used (e.g. Pubbie Jones). If a mob like Beepsky opens a door, this is ??? (yes, three question marks) instead.
  • If the door opens:
    • data: denied, if someone who didn't have access tried to open a door
  • Otherwise:
    • door_status: State the door is in (e.g. open, closed)
    • lock_status: State of the door bolts (e.g. locked, unlocked)
    • tag: This appears to always be blank.


Sending packets manually to open/close doors:

  • address_1: Network address of door (required)
  • access_code: Access code of the door (required)
  • command: One of the following:
    • open: Opens a door
    • close: Closes a door
    • lock: Drops the door bolts
    • unlock: Raises the door bolts
    • secure_open: Bolts a door open*
    • secure_close: Bolts a door closed*

*Used by the cryptographic sequencer.

Network Radio (141.1, 141.9, also varies)

The "Network Radio", which looks like... well, an old timey radio. Usually located near the mainframe in the computer core, sometimes it's elsewhere. This is what interfaces with the mainframe's /mnt/radio.

  • Device name: PNET_PR6_RADIO
  • Broadcast range: ?

You can log into the mainframe by connecting to this using a computer with a wireless network peripheral and FROG or TermOS. You can create a login packet using ThinkDOS's WizWrite and put it on the main drive in ThinkDOS under whatever name you want, then restart with a TermOS disk and run "file_load [name]" in TermOS, which will allow you to run file_send with the login packet.

Alternatively, maybe you can receive other files and save them to the disk with file_save [name], too...?


Secure Lockers (143.1)

Secure lockers that require an ID to open, including personal lockers in the Crew Quarters.

  • Device name: WNET_SECLOCKER
  • Broadcast range: 3 tiles (5 × 5)

The range on these is extremely short.

You can send these a few commands over the radio, though you'll need netpass_security to lock or unlock them and netpass_heads to find netpass_security.

  • command=status: Replies with command=lock=[locked]&open=[open]
  • command=lock; pass=(netpass_security): Locks the locker.
  • command=unlock; pass=(netpass_security): Unlocks the locker. Surprise.

If you use one of the lock or unlock packets, you'll get a response with command=ack or command=nack; data=badpass depending on if it worked or not.

Personal lockers don't send messages when opened/claimed with an ID.


Hydroponics trays (143.3)

  • Device name: One of WNET_PACKETSPY, WNET_GENERIC, WNET_DETECTOR, WNET_SYN%%^#FF, randomly
  • Broadcast range: ≥64 tiles (129 × 129)

Packets:

  • netid: 02001234 -- The address of that particular tray. (Isn't this what sender is for?)
  • data: One of the following:
    • event_new: A seed was planted in the tray.
    • event_death: The plant died.
    • event_cleared: The plant (dead or otherwise) was removed from the tray.

Yep, that's it. There's nothing useful here (as of the 2016 release). Not even the type of seed, or if it's ready to harvest, or anything. Sorry.


Fire Alarms (143.7)

This is from the 2016 release and may not be entirely relevant now, but...

  • Device name: PNET_FIREALARM (even though it's WNET...)
  • Broadcast range: ∞ (possibly)


Broadcasts a packet when things happen:

  • zone: Location name (like Head of Research's Office)
  • type: Alarm type (always Fire)
  • netid: Network address (as well as sender for some reason)
  • alert: What happened:
    • fire: Fire alarm triggered
    • reset: Fire alarm cleared


You can also trigger these remotely if you want to be annoying.

  • command=#####: One of the following:
    • status: Triggers the above packet broadcast.
    • trigger: Triggers the alarm.
    • reset: Resets the alarm.


Robot patrol beacons (many frequencies)

Various patrol beacons around the station. These are used by Guardbuddies, Securitrons, and the tour guide, though often not on the same frequencies.

  • Frequencies: 143.1, 144.1, 144.3, 144.5, and so on.

They don't respond to pings, but they do respond to beacon requests. Beacons have a specific format and options available to control how bots act and what they do.

Securitron and tour guide beacons broadcast on this frequency. They're located under floor tiles, and you can access them by popping them open with a screwdriver and swiping an appropriate card.

Todo: This section needs some updating, for triggering and receiving beacon broadcasts, as well as editing them and how they work.

Tour Guide beacon, this one from the Escape Arm:

  • Location: tour16
    • tour: 1 -- Marks it as a tour beacon
    • next_tour: tour17 -- Which beacon comes after this in the route
    • desc: In the event of catastrophic station damage... (What the tour guide will say when stopping here)

Patrol beacon, a fictional example (TODO: get a real one):

  • Location: sec
    • patrol: 1 -- Marks it as a patrol beacon
    • next_patrol: bar -- Which beacon comes after this in the route (TODO: verify the name)

You can't move the beacons around or create new ones, but you can at least make Murray shout obscenities when describing places. Or make him get stuck into a loop forever. Keep in mind that the text length you're allowed to enter is much shorter than the length of the default tour messages.

Sample log:

[37:15:3]:findbeacon=tour; address_1=!BEACON!; sender=0200564a; 
[37:15:3]:beacon=tour13; netid=02000e46; tour=1; next_tour=tour14; desc=...; 
[37:15:3]:beacon=tour16; netid=02000fa6; tour=1; next_tour=tour14; desc=...; 


Securitrons (144.7)

Securitrons.

Status updates, sent from the bots:

  • type: secbot
  • name: Officer Beepsky -- this is whatever the bot is named. No way to distinguish between identically-named bots
  • loca: Cafeteria -- where the bot is currently located.
  • mode: 0 -- One of various modes (as described by the Securitron control PDA app):
    • 0: Idle (Ready)
    • 1: Spotted someone marked as arrest (Apprehending target)
    • 2: At target, preparing to arrest
    • 3: Arresting target
    • 4: Starting patrol
    • 5: On patrol
    • 6: (Responding to summons) — will go to mode 4 and start patrolling when it reaches its destination


Controlling via the R.O.B.U.S.T. cart's Securitron app:

  • command: One of the following:
    • bot_status: Get the status of the bot
    • go: Start patrolling
    • stop: Stop patrolling
    • summon: Summons the bot
  • active: Officer Beepsky (see note below)
  • target: the floor; only if command=summon. (see note below)

Notes: These are BYOND internal atom references, and not actually text, so they're impossible to replicate in packets. These only work from the PDA application for that reason.

(Original note: This is because a byond atom reference is being passed in the packet, printing this reference will yield its name ("(the) floor"). It is impossible to replicate this packet. I'd recommend bringing this to IBM's attention. --Marquesas)


MULE bots (144.7)

MULE bots.

Status updates, sent from the bots:

  • type: mulebot
  • name: 1 -- Likely the name in the Quartermaster's PDA MULE control app, likely unique to each bot
  • loca: Supply Lobby -- whatever the location of the bot is
  • mode: 0 -- One of the various modes:
    • (TODO, no research on this yet)
  • powr: 100 -- Current cell charge
  • dest: unknown -- TODO. Destination, format is unknown. Probably the name of the location
  • home: QM #1 -- Bot's home location (TODO: Underfloor beacon?)
  • load: Jon Pubbie -- Whatever is currently loaded on top of the bot, e.g. player name, Crate, etc
  • retn: 1 -- Return home after delivery
  • pick: 1 -- Pick up crates at the destination

Controlling via the QM's PDA: (todo)

Likely has the same bug as Securitrons above, since they share a lot of the same code.


Armory Authorization (146.1)

This is the computer used by heads of staff to authorize the armory.

  • Device name: ARM_AUTH
  • Broadcast range: todo

The armory responds with acc_code=netpass_security when authorized, which is needed to open lockers via packets.


Getting netpass_security: Sending the following packet authorizes the armory:

address_1=[arm_auth netid];command=authorize;acc_code=[netpass_heads];

The armory will reply with a packet containing a different acc_code than what you sent it. This new code is netpass_security.

There does not seem to be a way to unauthorize the armory, and there is currently no other method for getting netpass_security.