Jon's Aibo protocol analysis page
All data in this page can be downloaded here
| Name | Description | Time | Pcap | Analysis |
| NO-BRAIN | Does the aibo have any wireless functionality w/o a memory stick? | 45s | 1 2 3 | Nope. |
| NO-AP | What does the aibo do when no AP around? | 45s | 1 2 | Send out probes requests for its configured SSID |
| ASSOCIATION | Just a basic capture of the aibo associating with the AP. Does he do anything else immediately after association? | 1m30s | 1 2 |
Aibo sends an 802.11 assoc request approx 12s after booting.
(Which is around when he 'wakes up')
Approx 35s after boot he sends his first IGMP membersip report.
A second after that comes SSDP NOTIFYS. (over UDP)
48s into the capture DNS querys for Standard query A < Root > start.
These IGMP messages seem to repeat every 10 secs. usually in pairs? The SSDP messages go out at a rate of approx 7 every 1/10th of a sec. The DNS querys seem to repeat every 5 secs for .. (?) Yes he joins a multi cast group using IP 239.255.255.250. He then sends SSDP NOTIFY messages out to the multi-cast addr advertising he is here. This behavior can be disabled using Aibo's ssdp configuration. This is how the client finds aibos on the local net. |
| Name | Description | Time | Pcap | Analysis |
| FIND-AIBO | How does client find aibo? (this uses the 'search' button) | 15s | 1 |
client sends SSDP M-SEARCH to 239.255.255.250 client sends GET/AIBO.XML to 10.0.0.222 port 80. (tcp) client sends SSDP M-SEARCH to 239.255.255.250 10.0.0.222 sends SSDP OK to 10.0.0.100 10.0.0.222 sends SSDP OK to 10.0.0.100 10.0.100 sends TCP GET /AIBO.XML TO 10.0.0.222 80 (tcp) Repeat.. Aibo always transmits to 10.0.0.100 Client transmits to multicast (SSDP Searches) and directly to aibo httpd Was client already aware of aibo? how did it send http request before SSDP reply. |
| VALID-PASS | In this capture the client successfully logs in as johnycsh/password The particular TCP stream used for authentication is followed, the rest are filtered. | 10s | 1 2 | Client establishes connection to aibo from port 1110 to port 50000. The client sends the username in the clear and the password not. This tcp session remains active throughout the life of the client connection Shortly afterward another sessions is established -from the aibo- on port 50201 to port 56000 on the computer. This sessions seems to be used to transmit 60 bytes of data via tcp in bursts. not sure in response to what yet. Many other tcp/udp sessions start. Too many to document here. |
| INVALID-PASS | In this capture the client un-successfully attempts to login twice. uses "baduser"/"badpass" | 15s | 1 2 | For details see the authentication page. |
| NO-PASS | Client connects with no auth | 5s | 1 2 | not alot to say here. See remark above about negotiation. |
| AUTO | Client switches aibo from remote to auto mode. | 5s | 1 2 | |
| REMOTE | Client switched aibo from auto to remote mode | 5s | 1 2 | This would be real handy.. |
| Name | Description | Time | Pcap | Analysis |
| SIT | Tell Aibo to sit | s | 1 2 | |
| STAND | Tell Aibo to stand | s | 1 2 | |
| SIT-STAND | Tell Aibo to sit then ~ 1s later stand. the 2nd pcap has many stand cmd's issued at the end | s | 1 2 | |
| FORWARD | Tell Aibo go forward. 2s later send stop. | s | 1 2 | Nope. |
| FORWARD-STOP | Tell Aibo go forward. 2s later send stop. we catch middle of connection, less noise. | 2s | 1 2 | |
| BACKARD-STOP | Tell Aibo go backward. 2s later send stop. | 2s | 1 2 |
| Name | Description | Time | Pcap | Analysis |
| TWO-CONTROLLERS-NO-AUTH | What happens when two controllers try to communicate with one aibo and authentication is enabled? In this capture we introduce a 2nd box 10.0.0.200 00:0E:35:39:C9:5B that attempts to establish a connection after the aibo is in remote mode. | 30s | 1 2 3 | The aibo rejects the connection? |