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

From WSdev Wiki
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
For the MobileWonderGate software, NTT DoCoMo operated network servers for validating and redirecting URL requests:
For the MobileWonderGate software, NTT DoCoMo operated network servers for handling URL requests:


* <code>bpl01.mopera.ne.jp</code>
* <code>bpl01.mopera.ne.jp</code>
Line 5: Line 5:


These servers listened on TCP port 5555 for request packets in the following format, and issued a response in the same format.
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 <code>Mozilla/3.0 (compatible; InfoBridge-mopera 1.1.1; Linux)</code>, as opposed to the browser's own <code>SWAN/1.0</code>.


== Packet format ==
== Packet format ==
Line 35: Line 37:
| Response type:
| Response type:
* 0x0010 - response: allow + 0 blocks
* 0x0010 - response: allow + 0 blocks
* 0x0012 - response: deny + 1 block
* 0x0012 - response: deny/redirect? + 1 block
* 0x0021 - response: require ID/password + 1 block
* 0x0021 - response: require ID/password + 1 block
* 0x0023 - response: unknown (too large?) + 0 blocks
* 0x0023 - response: unknown (too large?) + 0 blocks
Line 70: Line 72:
== TODO ==
== TODO ==


* Why does the browser not send POST queries despite using an "allow" command? Is there a related Mopera flag?
* How does one send an HTTP response through the bridge? This has to be possible, as the bridge had its own distinct user agent.

Revision as of 18:00, 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

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.