Well, I've got a sample split "rcon status" response packet that does NOT have the same split behavior as usual (or what I expected). I have the entire packet contents of both parts. I'd like to post it here, but I know some people would not like having their IPs and WON IDs made public, so is there someone I can send it to directly?
The first part was 1380 bytes and the second part was 437. I also noticed that the packet was split "cleanly" at the end of a line. I suspect there may be some code that checks to see if it can split at a line boundary and just send it as two "normal" packets. Could this be the case? Each part starts with "FF FF FF FF 6C". Also, I know the MTU size of my router and the hlds server at the other send is set to 1500, but I don't know about in-between. If I send an ICMP ping with data, I find I can send a max of 1440 bytes before things get split, which seems about right to me. Let me know where I can send the contents of those packets. It was pretty reproducible tonight - about 2 out of 3 "rcon status" commands resulted in this behavior. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Kris > Sent: Monday, December 30, 2002 12:06 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlds_apps] Bug report, question on packet splitting & > secure > > > At 03:33 27/12/2002, you wrote: > >hmm, can you say how to replicate this? (i.e start a server with > "x" in the > >command line, then type "y" 10 times, blah...) > > Easy - Start up a server and get 24 clients to join, then do a > remote 'rcon > status' :) > > >I have a similar program which uses rcon extensively and have never seen > >this behaviour... I would like to replicate it :) > > You could probably replicate this by lowering the MTU (Maximum > Transmission > Unit) size from within your OS. (note, this may drastically affect your > network throughput if set too small). > > If we could get some sort of packet ID in the response, or if half-life > could be clever and split up packets based on the host OS's MTU that'd be > great... > > Kris. > > >----- Original Message ----- > >From: "Terry" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Wednesday, December 25, 2002 1:58 AM > >Subject: RE: [hlds_apps] Bug report, question on packet > splitting & secure > > > > > > > I'd like to resurrect this again. :-) > > > > > > I've changed my code to work with this so that split packets get > >reassembled > > > and properly ordered. This works *most* of the time, but I find that > > > sometimes responses to commands like "rcon status" are split > but do not > >use > > > this convention. > > > > > > For example, if there are 24 players on my server, usually > the response to > > > an "rcon status" is split. Sometimes, it uses the convention > below and I > > > can reassemble and reorder it. But sometimes it just looks like two > > > seperate "normal" packets, i.e. each packet starts with "ff > ff ff ff 6C > > > <data>". > > > > > > I'm guessing that it only does this if the break happens to > fall at the > >end > > > of a line. (??) If so, is this a bug or intended behavior? > I personally > > > would rather it *always* split the same way because my > program is trying > >to > > > parse what comes back but I have no way of knowing if/when > all the data is > > > there. > > > > > > Terry > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Alfred > > > > Sent: Thursday, November 21, 2002 1:14 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [hlds_apps] Bug report, question on packet splitting & > > > > secure > > > > > > > > > > > > [EMAIL PROTECTED] wrote: > > > > <snip> > > > > > > > > > > > > > > > >first- splitted udp packets if the response of a query > gets to long > > > > > >(discussed here one than one time.) > > > > > > > > > > > >I found this analysis - describing the rules response - anywhere > > > > > (qstat I > > > > > >think): > > > > > > > > > > > >splitted to two packets: > > > > > >FF FF FF FF 6C [data] > > > > > >FE FF FF FF 07 02 00 00 02 FF FF FF FF 6C [data] > > > > > >FE FF FF FF 07 02 00 00 12 [data] > > > > > > > > > > > >splitted to three packets: > > > > > >FE FF FF FF 07 02 00 00 03 FF FF FF FF 6C [data] > > > > > >FE FF FF FF 07 02 00 00 13 [data] > > > > > >FE FF FF FF 07 02 00 00 23 [data] > > > > > > > > > > > >07 02 00 00 variates and is some kind of challenge numer - an > > > > id telling > > > > > >which packets schould be one. > > > > > >the next byte is splittet into two 4 bit nibles - the upper > > > > one describes > > > > > >the packet number, the lower one how many packets will be sent. > > > > > > > > > > > >is this correct??? > > > > > > > > > > > > > > > > > > > > > > > > > > <snip> > > > > > > > > No, its not quiet right. Split packets are denoted by an > initial FF FF > > > > FF FE tag (rather than FF FF FF FF) (that is, decimal -2 rather than > > > > decimal -1). The next byte in a split packet contains 2 4 > bit nibbles > > > > (mmm, nibbles), with the first 4 bits being the packet > number and the > > > > last 4 being the total number of packets. > > > > If the packet is the first in the sequence it will then > have a FF FF FF > > > > FF tag on the first packet and then data (i.e the long > packet was simply > > > > "packed" inside of multiple shorter packets). > > > > > > > > > > > > > > > > _______________________________________________ > > > > hlds_apps mailing list > > > > [EMAIL PROTECTED] > > > > http://list.valvesoftware.com/mailman/listinfo/hlds_apps > > > > > > > > > > > > > > > > _______________________________________________ > > > hlds_apps mailing list > > > [EMAIL PROTECTED] > > > http://list.valvesoftware.com/mailman/listinfo/hlds_apps > > > > > > >_______________________________________________ > >hlds_apps mailing list > >[EMAIL PROTECTED] > >http://list.valvesoftware.com/mailman/listinfo/hlds_apps > > _______________________________________________ > hlds_apps mailing list > [EMAIL PROTECTED] > http://list.valvesoftware.com/mailman/listinfo/hlds_apps _______________________________________________ hlds_apps mailing list [EMAIL PROTECTED] http://list.valvesoftware.com/mailman/listinfo/hlds_apps
