<commit_before># Observed LIFX network protocol

It is a work in progress and is not, in any way, affiliated or related to LIFX
Labs.

## Packet frame

The network protocol uses UDP and TCP in various places, but there seems to be
a common packet format used. Packet field data appears to be of mixed
endianness.

````c
packet
{
  uint16 size;              // LE
  uint16 protocol;
  uint32 reserved1;         // Always 0x0000
  byte   target_mac_address[6];
  uint16 reserved2;         // Always 0x00
  byte   site[6];           // MAC address of gateway PAN controller bulb
  uint16 reserved3;         // Always 0x00
  uint64 timestamp;
  uint16 packet_type;       // LE
  uint16 reserved4;         // Always 0x0000
  
  varies payload;
}
````

## Packet types

### Network management
 * 0x02 - app to bulb - get PAN gateway
 * 0x03 - bulb to app - device state<pan gateway>

### Power management
 * 0x15 - app to bulb - set state
 * 0x16 - bulb to app - power state
 * 0x20 - app to bulb - get state [?]

### Wireless management
 * 0x12d - app to bulb - get state
 * 0x12e - app to bulb - set state
 * 0x12f - bulb to app - wifi state
 * 0x130 - app to bulb - get access point
 * 0x131 - app to bulb - set access point
 * 0x132 - bulb to app - wifi state<access point>

### Labels and Tags
 * 0x17 - app to bulb - get label
 * 0x18 - app to bulb - set label
 * 0x19 - bulb to app - device state<label>
 * 0x1a - app to bulb - get tags
 * 0x1c - bulb to app - device state<tags>
 * 0x1d - app to bulb - get tag labels
 * 0x1f - bulb to app - device state<tag labels>

### Brightness and Colors
 * 0x65 - app to bulb - get color
 * 0x66 - app to bulb - set color
 * 0x67 - app to bulb - set waveform
 * 0x68 - app to bulb - set dim (absolute)
 * 0x69 - app to bulb - set dim (relative)
 * 0x6b - bulb to app - light state
 
## Discovery

The apps start by sending UDP "discovery" packets to the network broadcast
address, port 56700.  They do this repeatedly until a bulb responds by sending
a UDP packet back to you on port 56700. Packets are identified via its type (of
0x03).

The first response which matches this is what I'm using as the "controller"
bulb.  The controller appears to continue sending UDP packets, but I have not
yet dug in to these; my assumption is that they are general announcements to
the rest of the network in case there are multiple apps running which want to
control the bulbs.

### Packet type 0x02 - Discovery request

This is the discovery packet, and is sent by the apps via UDP to the network
broadcast address (either the LAN broadcast address or 255.255.255.255) on UDP
port 56700.  It has all of the address fields (bytes 10-15 and 18-23) set to
zeroes because it does not yet know about the gateway bulb.

 * Byte  32:      0x02
 * Bytes 33 - 35: Always zeroes.

Will hopefully cause a packet type 0x03 to be sent back; the apps should treat
the originator of this response as the gateway bulb for further communication.

### Packet type 0x03 - Discovery response

This is the response to the discovery packet, and is sent by the gateway bulb
via UDP to port 56700 to the network broadcast address.

 * Byte  32:      0x02
 * Bytes 33 - 35: Always zeroes.
 * Byte  36:      Unknown, observed to be either 0x01 or 0x02.
 * Bytes 37 - 40: Unknown, always 0x7c 0xdd 0x00 0x00

After receiving this packet, I open a TCP connection to the originator on TCP
port 56700 for subsequent communication.

## Registration

An unconfigured bulb will listen at 172.16.0.1 and act as an access point,
hosting a secure network with the name "LIFX Bulb" and password of '<PASSWORD>'.

Configuration of a bulb involves connecting to the bulb's hosted network and
sending a "set access point" message to the bulb. This message contains the
information it needs to join your existing wireless network infrastructure
(such as SSID and password). Networks using WEP security are not supported.

After receipt of the message, the bulb will shut down the hosted network
and attempt connection to the existing wireless network infrastructure.

### Packet type 0x131 - Set Access Point

#### Payload (98 bytes)

````c
payload
{
  INTERFACE_MODE interface;
  char ssid[32];
  char password[64];
  SECURITY_PROTOCOL security_protocol; 
}

enum INTERFACE_MODE : byte
{
  SOFT_AP, // listen + connect
  STATION  // connect
}

enum SECURITY_PROTOCOL : byte
{
   UNKNOWN,
   OPEN,
   WEP_PSK, // Not officially supported
   WPA_TKIP_PSK,
   WPA_AES_PSK,
   WPA2_AES_PSK,
   WPA2_TKIP_PSK,
   WPA2_MIXED_PSK,
}
````

## Control

After finding a controller bulb, open a TCP connection to it on port 56700.
All commands are sent down this stream.

### Packet type 0x15 - On / off request

This packet type turns the bulbs on and off.

 * Byte  32:      0x15
 * Bytes 33 - 35: Always zeroes.
 * Bytes 36:      0x01 to turn on, or 0x00 to turn off
 * Bytes 37:      Always zero.
<commit_msg>Removed Unknown member in security enumeration<commit_after># Observed LIFX network protocol

It is a work in progress and is not, in any way, affiliated or related to LIFX
Labs.

## Packet frame

The network protocol uses UDP and TCP in various places, but there seems to be
a common packet format used. Packet field data appears to be of mixed
endianness.

````c
packet
{
  uint16 size;              // LE
  uint16 protocol;
  uint32 reserved1;         // Always 0x0000
  byte   target_mac_address[6];
  uint16 reserved2;         // Always 0x00
  byte   site[6];           // MAC address of gateway PAN controller bulb
  uint16 reserved3;         // Always 0x00
  uint64 timestamp;
  uint16 packet_type;       // LE
  uint16 reserved4;         // Always 0x0000
  
  varies payload;
}
````

## Packet types

### Network management
 * 0x02 - app to bulb - get PAN gateway
 * 0x03 - bulb to app - device state<pan gateway>

### Power management
 * 0x15 - app to bulb - set state
 * 0x16 - bulb to app - power state
 * 0x20 - app to bulb - get state [?]

### Wireless management
 * 0x12d - app to bulb - get state
 * 0x12e - app to bulb - set state
 * 0x12f - bulb to app - wifi state
 * 0x130 - app to bulb - get access point
 * 0x131 - app to bulb - set access point
 * 0x132 - bulb to app - wifi state<access point>

### Labels and Tags
 * 0x17 - app to bulb - get label
 * 0x18 - app to bulb - set label
 * 0x19 - bulb to app - device state<label>
 * 0x1a - app to bulb - get tags
 * 0x1c - bulb to app - device state<tags>
 * 0x1d - app to bulb - get tag labels
 * 0x1f - bulb to app - device state<tag labels>

### Brightness and Colors
 * 0x65 - app to bulb - get color
 * 0x66 - app to bulb - set color
 * 0x67 - app to bulb - set waveform
 * 0x68 - app to bulb - set dim (absolute)
 * 0x69 - app to bulb - set dim (relative)
 * 0x6b - bulb to app - light state
 
## Discovery

The apps start by sending UDP "discovery" packets to the network broadcast
address, port 56700.  They do this repeatedly until a bulb responds by sending
a UDP packet back to you on port 56700. Packets are identified via its type (of
0x03).

The first response which matches this is what I'm using as the "controller"
bulb.  The controller appears to continue sending UDP packets, but I have not
yet dug in to these; my assumption is that they are general announcements to
the rest of the network in case there are multiple apps running which want to
control the bulbs.

### Packet type 0x02 - Discovery request

This is the discovery packet, and is sent by the apps via UDP to the network
broadcast address (either the LAN broadcast address or 255.255.255.255) on UDP
port 56700.  It has all of the address fields (bytes 10-15 and 18-23) set to
zeroes because it does not yet know about the gateway bulb.

 * Byte  32:      0x02
 * Bytes 33 - 35: Always zeroes.

Will hopefully cause a packet type 0x03 to be sent back; the apps should treat
the originator of this response as the gateway bulb for further communication.

### Packet type 0x03 - Discovery response

This is the response to the discovery packet, and is sent by the gateway bulb
via UDP to port 56700 to the network broadcast address.

 * Byte  32:      0x02
 * Bytes 33 - 35: Always zeroes.
 * Byte  36:      Unknown, observed to be either 0x01 or 0x02.
 * Bytes 37 - 40: Unknown, always 0x7c 0xdd 0x00 0x00

After receiving this packet, I open a TCP connection to the originator on TCP
port 56700 for subsequent communication.

## Registration

An unconfigured bulb will listen at 172.16.0.1 and act as an access point,
hosting a secure network with the name "LIFX Bulb" and password of '<PASSWORD>'.

Configuration of a bulb involves connecting to the bulb's hosted network and
sending a "set access point" message to the bulb. This message contains the
information it needs to join your existing wireless network infrastructure
(such as SSID and password). Networks using WEP security are not supported.

After receipt of the message, the bulb will shut down the hosted network
and attempt connection to the existing wireless network infrastructure.

### Packet type 0x131 - Set Access Point

#### Payload (98 bytes)

````c
payload
{
  INTERFACE_MODE interface;
  char ssid[32];
  char password[64];
  SECURITY_PROTOCOL security_protocol; 
}

enum INTERFACE_MODE : byte
{
  SOFT_AP, // listen + connect
  STATION  // connect
}

enum SECURITY_PROTOCOL : byte
{
   OPEN,
   WEP_PSK, // Not officially supported
   WPA_TKIP_PSK,
   WPA_AES_PSK,
   WPA2_AES_PSK,
   WPA2_TKIP_PSK,
   WPA2_MIXED_PSK,
}
````

## Control

After finding a controller bulb, open a TCP connection to it on port 56700.
All commands are sent down this stream.

### Packet type 0x15 - On / off request

This packet type turns the bulbs on and off.

 * Byte  32:      0x15
 * Bytes 33 - 35: Always zeroes.
 * Bytes 36:      0x01 to turn on, or 0x00 to turn off
 * Bytes 37:      Always zero.

{'fraction_non_alphanumeric': 0.06432867774492813, 'fraction_numerical': 0.05117749006014884, 'mean_word_length': 3.0671641791044775, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 4, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3246430', 'n_tokens_mistral': 3413, 'n_tokens_neox': 2895, 'n_words': 1462}