gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > pictochat captures?

#30792 - ecurtz - Sat Dec 04, 2004 7:16 pm

Anybody else out there looking at the non-chat packets from pictochat? I've got a pcap dump from chizu, but I could use another one.

If anybody is busy sniffing pictochat it would really help if you could post a dump. Things of interest:

Raw pcap files rather than edited messages.

Information about user names (roman characters preferably, I can't find the Hiragana in chizu's name so it isn't in unicode or shift-JIS unless it's encoded somehow.)

What room was the chat it.

I'm using Java (causes too many headaches to switch languages over the weekend) and jnetstream if anybody wants my stuff so far, but it's really early, just trying to identify all the packet types. I'll probably do a bit to show the chat images this afternoon for fun as a break from looking at hex dumps.

- eli

#31045 - ecurtz - Tue Dec 07, 2004 9:02 am

I got some more dumps from gladius and have made slight progress, but I thought I'd brain dump a few things here before I call it a night in case anybody else is looking at these.

There are about 5 unique packet types of which three are pretty clear:

Beacons - 88 bytes in Airopeek, 232 pcap
Room list - 142 bytes Airopeek, 286 pcap - LE shorts of all MACs in room
Chat data - 210, 354 - format described on gladius' site, last row of final tile in following frame


There are also ack or resends for these which are slightly shorter and have a control frame header (four bytes before the first MAC) normal frames begin 28 02, acks/resend whatever begin 18 01, beacons begin 80 00. These also have different MACs (DS to DS instead of broadcast.) <edit> Everything seems to have the beacon type, even frames with bogus protocol versions, maybe to try to keep aps from freaking out about the packets? The to/from bits seem to be to spec. Values of E0 04 in the duration/id field of the room frames seem to get an ACK from the client, F0 00 values do not. Client and server packet ids do not seem to be in sync.</edit>

The control frames seem fairly accurate but are using unused version bits (except the beacon, which is kosher) unless I'm reading the bit fields wrong on my big Endian macintosh looking at hex from a little endian machine displaying a bit field from a ? endian data packet.

Everything has a packet index and checksum at the end indices grow in an obvious manner but differ among types. Haven't tried to get the checksum. Anybody who wanted to volunteer to calc the checksum (might be super simple) can look at the shortest packets (28/172 bytes), nothing changes in them except the packet id. <edit> These don't even appear in the pcap data so they are probably just the official 802.11b frame checksum. </edit>

Goodnight moon.