Hello everyone!
I’ve been building my own small OSCAR server for fun, but I ran into a problem.
During protocol negotiation, all AIM Windows clients newer than 1.0 just crash. It appears that enabling foodgroup 4 in SNAC (01,03) causes this. But I don’t know how or why does this happen.
I’ve been trying everything I can to fix this, but no luck.
Can somebody help me figure out what that is?
iserverd documentation says that’s [Core Services]->[Family List] and says it’s formatted as (excluding SNAC/FLAP headers) an array of u16 with no predefined length for what is supported on the server for what we know now as foodgroups.
That being said, the client should not crash when taking in at least 00 01 as the argument, though you’ll probably want 00 02, 00 03, 00 04, 00 07, 00 09 and 00 13 for AIM clients?
Unless the client is parsing it incorrectly or clients straight up crash on invalid foodgroups (They shouldn’t? That doesn’t make much sense), you should be getting a “Client error” if it’s missing a foodgroup that the client considers essential.
everything is okay when sending, bascially any foodgroup, 0001, 0003.
but with 0004 everything crashes
Try returning the full list of foodgroups, just returning 3 of them may cause some logic error in the client
So 00 01 00 02 00 03 00 04 00 07 00 09 00 13 crashes?
That’s not good if that’s what you’re sending (otherwise if it’s just 00 04, the client might be right here, it doesn’t make sense and would want at least 00 01 to be there)
You should be seeing 00 01 00 17 from the client after the foodgroup list is sent.
yeah, it does crash.
but when removing 0004 from this list, it suddenly works fine.
here’s the faulty packet: 2a020001001800010003000066cdf8f00001000200030004000700090013
i don’t know if i’m doing something wrong, i’ve been following iserverd docs
Important to say, AIM 1.0 for Windows works perfectly fine.
It doesn’t crash, sends messages…
The only thing I can be concerned about here is the request ID… Is that following one of the clients? I have a feeling the client might crash if it’s got a response for something it never sent…
Otherwise if that is the client’s request ID, then i’m not sure. People say it works better for this SNAC if you set the response’s request ID to 0h, but that isn’t following the protocol’s standard. Feel free to try it though.
Okay, i’ll try it out. Hope it works…
It seems like SNAC(01,03) itself isn’t the problem.
Maybe it’s in one of foodgroup 4 subtypes? I’ll try to rewrite my implementation for them.