WonderGate/bplXX.mopera.ne.jp: Difference between revisions

From WSdev Wiki
Jump to navigationJump to search
(initial multipart block documentation)
No edit summary
Line 72: Line 72:
=== Multipart blocks ===
=== 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.
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.


{| class="wikitable"
{| class="wikitable"

Revision as of 19:51, 21 August 2023

For the MobileWonderGate software, NTT DoCoMo operated network servers for handling URL requests:

  • bpl01.mopera.ne.jp
  • bpl02.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:
  • 0x0010 - response: allow + 0 blocks
  • 0x0012 - response: deny/redirect? + 1 block
  • 0x0021 - response: require ID/password + 1 block
  • 0x0023 - response: unknown (too large?) + 0 blocks
0x04 4? (>= 2) Total packet size in bytes, including all headers and blocks
0x08 4 Unknown
0x0C 4 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:
  • 0x01 - 0x00? byte, followed by requested URL string
  • 0x03 - 0x00? byte, followed by previous URL string (referrer?)
  • 0x11 - ID string, followed by PASS string
  • 0x22 - 0x00? byte, followed by query field name string, followed by query field value string

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.

Header
Offset Length Description
0x00 1 Number of parts?
0x01

0x04

? Unknown
Part
Offset Length Description
0x00

0x01

? Unknown
0x02 2 Length of data, in bytes
0x04

0x05

? Unknown
0x06... <length> Data
Footer
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.