WonderGate/bplXX.mopera.ne.jp: Difference between revisions
No edit summary |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 43: | Line 43: | ||
| 0x04 || 4? (>= 2) || Total packet size in bytes, including all headers and blocks | | 0x04 || 4? (>= 2) || Total packet size in bytes, including all headers and blocks | ||
|- | |- | ||
| 0x08 | | | 0x08<br/> | ||
0x0F | |||
| ? | |||
| Unknown | |||
|- | |- | ||
| | | 0x10 || 4? || Unknown (216.0.192.1?) | ||
|- | |- | ||
| | | 0x14 || 4? || Unknown (255.255.0.0?) | ||
|} | |} | ||
| Line 73: | Line 74: | ||
Sending a block with a block size of <code>0xFFFF</code> and a block type of <code>0x00</code> in a response will trigger a multipart block mode, which sends data in portions between a header and footer. | Sending a block with a block size of <code>0xFFFF</code> and a block type of <code>0x00</code> in a response will trigger a multipart block mode, which sends data in portions between a header and footer. | ||
While the <code>0xFFFF/0x00</code> preamble has to be included in the total length from the global header, the remainder of the multipart block section does not have to be. | |||
{| class="wikitable" | {| class="wikitable" | ||
Latest revision as of 08:29, 22 August 2023
For the MobileWonderGate software, NTT DoCoMo operated network servers for handling URL requests:
bpl01.mopera.ne.jpbpl02.mopera.ne.jp
These servers listened on TCP port 5555 for request packets in the following format, and issued a response in the same format.
Pages accessed via the mopera network server reported themselves as Mozilla/3.0 (compatible; InfoBridge-mopera 1.1.1; Linux), as opposed to the browser's own SWAN/1.0.
Packet format
Every packet sent from and to the server follows the same format: a global header, followed by an arbitrary number of blocks with their respective headers.
Header
| Offset | Length | Description |
|---|---|---|
| 0x00 | 1 | Unknown, always 0x01 |
| 0x01 | 1 | Header size in bytes, always 0x18 |
| 0x02 | 2 | Request type/Browser configuration:
ee?i ?s?w ???? ??p? || | | | +- POST request || | | +---------- Width: 0 = 1-screen, 1 = 2-screen || | +------------ Image size: 0 = 50%, 1 = 100% || +--------------- Images: 0 = enabled, 1 = disabled ++----------------- Encoding: 0 = auto, 1 = S-JIS, 2 = EUC |
Response type:
| ||
| 0x04 | 4? (>= 2) | Total packet size in bytes, including all headers and blocks |
| 0x08 0x0F |
? | Unknown |
| 0x10 | 4? | Unknown (216.0.192.1?) |
| 0x14 | 4? | Unknown (255.255.0.0?) |
Block header
Blocks typically consist of zero-terminated strings - a final zero appears to be omitted.
| Offset | Length | Description |
|---|---|---|
| 0x00 | 2 | Block size in bytes, including header |
| 0x02 | 1 | Block type:
|
Multipart blocks
Sending a block with a block size of 0xFFFF and a block type of 0x00 in a response will trigger a multipart block mode, which sends data in portions between a header and footer.
While the 0xFFFF/0x00 preamble has to be included in the total length from the global header, the remainder of the multipart block section does not have to be.
| Offset | Length | Description |
|---|---|---|
| 0x00 | 1 | Number of parts? |
| 0x01 0x04 |
? | Unknown |
| Offset | Length | Description |
|---|---|---|
| 0x00 0x01 |
? | Unknown |
| 0x02 | 2 | Length of data, in bytes |
| 0x04 0x05 |
? | Unknown |
| 0x06... | <length> | Data |
| Offset | Length | Description |
|---|---|---|
| 0x00 0x01 |
? | Unknown |
TODO
- How does one send an HTTP response through the bridge? This has to be possible, as the bridge had its own distinct user agent.
