I was browsing around the forums and saw someone say that you could "log on" to battle.net and send stuff "anonymously", but not receive stuff. How would one go about adding this into a bot, because I am intrigued.

Don't enter chat. Or, if you do, leave chat again. It's not hard to do.

Cool TY I'll try this out.

~Edit I can't get it to work, I send packet 0x10 right? and then try and whisper some one?

~Edit Again I Got it Thanks Andy.

FailBot, watch out... remember... he can write a bot in less than half an hour... as stated by him. So don't take his word for it

[quote author=chyea link=topic=17728.msg180610#msg180610 date=1228196446]
FailBot, watch out... remember... he can write a bot in less than half an hour... as stated by him. So don't take his word for it
[/quote]

Is it just me or is there always a new troll to take place of the retired one's?

Uh.... he said he got it. What are you talking about?

@Yegg: I'm fairly certain there's only 2 or 3 of them with constantly shifting accounts.

What? It could be hard to that FailBot guy... RealityNipple doesn't know.

By leaving chat, you're basically simulating being in a game. You're logged onto Battle.net but not in any channels.

Not quite... To simulate being in a game, you have to send STARTADVEX3. I've actually seen people on official clients that leave chat for about 5 minutes before being disconnected (ISPs do weird things).

[quote author=Andy link=topic=17728.msg180619#msg180619 date=1228247100]
Not quite... To simulate being in a game, you have to send STARTADVEX3. I've actually seen people on official clients that leave chat for about 5 minutes before being disconnected (ISPs do weird things).
[/quote]

What do you mean? You're able to tell that people are still on bnet with them being off the chat servers for 5 minutes? Like in some sort of ghost mode? The ISPs grant them this ghost mode ability?

Clients send leavechat before disconnecting. The client has to actually terminate the connection in order to be offline. Before that state, you are in an empty area. If your ISP is stupid, it won't send the connection termination, thus leaving your account logged in to that empty area until BNet times you out and disconnects you itself.

[quote author=Andy link=topic=17728.msg180636#msg180636 date=1228285992]
Clients send leavechat before disconnecting. The client has to actually terminate the connection in order to be offline. Before that state, you are in an empty area. If your ISP is stupid, it won't send the connection termination, thus leaving your account logged in to that empty area until BNet times you out and disconnects you itself.
[/quote]
It has nothing to do with your ISP sending the connection termination, it's about your client not sending the connection tear-down packets (FIN) correctly.

[quote author=iago link=topic=17728.msg180639#msg180639 date=1228331339]
[quote author=Andy link=topic=17728.msg180636#msg180636 date=1228285992]
Clients send leavechat before disconnecting. The client has to actually terminate the connection in order to be offline. Before that state, you are in an empty area. If your ISP is stupid, it won't send the connection termination, thus leaving your account logged in to that empty area until BNet times you out and disconnects you itself.
[/quote]
It has nothing to do with your ISP sending the connection termination, it's about your client not sending the connection tear-down packets (FIN) correctly.

[/quote]

hehe, that's what i was getting at

Hence why if you try to get back on right away, you'll get an error message saying that your own CDKey is in use by you.

iago: it was on the actual D1 client. It also happened to the same person on SC, D2, and W2. It was most definitely the ISP.

[quote author=Andy link=topic=17728.msg180647#msg180647 date=1228346266]
iago: it was on the actual D1 client. It also happened to the same person on SC, D2, and W2. It was most definitely the ISP.
[/quote]
ISPs have absolutely nothing to do with this, unless they're *preventing* you from sending the teardown (like, maybe they dropped the packet); but that wouldn't really make sense.

The concept of this being caused by the ISP doesn't actually make sense.

Why not? It's a TCP connection, the ISP might save a bit of bandwidth by not disconnecting so you won't have to reconnect. Makes sense for web browsing... If it has no port detection, it might do it to bnet, too?

[quote author=Andy link=topic=17728.msg180683#msg180683 date=1228607612]
Why not? It's a TCP connection, the ISP might save a bit of bandwidth by not disconnecting so you won't have to reconnect. Makes sense for web browsing... If it has no port detection, it might do it to bnet, too?
[/quote]

Why would the ISP implement a protocol at that level and use it for individual users? That's a lot of work for an ISP.

[quote author=chyea link=topic=17728.msg180685#msg180685 date=1228609406]
[quote author=Andy link=topic=17728.msg180683#msg180683 date=1228607612]
Why not? It's a TCP connection, the ISP might save a bit of bandwidth by not disconnecting so you won't have to reconnect. Makes sense for web browsing... If it has no port detection, it might do it to bnet, too?
[/quote]

Why would the ISP implement a protocol at that level and use it for individual users? That's a lot of work for an ISP.
[/quote]
Not to mention it would save like, 30 bytes of bandwidth....

Per page...? Why else would it be doing it, though?

Wait, I'm not sure what MyndFyre was trying to say. I'm saying I don't think the ISP would bother to do what Andy is saying it should be doing.

And, to Andy, oh I don't know... serving up bandwidth to it's other thousands of users?

The ISP CAN'T do what Andy's saying, the Internet doesn't work like that.

The behaviour you're seeing is likely because of a broken client, or because the server doesn't bother to clean up sessions properly.

It's DRTL. The official client. On the official server.

i do code a lot of lowlevel network stuff and i agree 100% with iago. ISPs have nothing to do with it.

[quote author=Andy link=topic=17728.msg180712#msg180712 date=1228773529]
It's DRTL. The official client. On the official server.
[/quote]
Then the server isn't managing state properly.

For one user constantly? I find it much more likely a hop along the route (for example, the ISP) is just not disconnecting from the server.

I think its battle.net because this has happened somtimes when an unexpected drop from my end or my cable was unplugged, when i try to get back on battle.net yet to recongnize that i have dropped. :[

[quote author=Andy link=topic=17728.msg180755#msg180755 date=1228956560]
For one user constantly? I find it much more likely a hop along the route (for example, the ISP) is just not disconnecting from the server.
[/quote]
The problem is that that doesn't make sense. That's not how the Internet works.

A hop happens at layer 2 (link layer), while the connection happens at layer 4 (transport). There is no concept of a connection at layer 2 -- packets are sent from one mac address to another with no regard to what's in the packet. A connection starts with a SYN is sent, which is a TCP concept (layer 4) -- the routers along the way don't know that the connection exists, and they can be swapped out *during* the connection without breaking it. The connection ends with FIN is sent, which is also a TCP concept. The routers in the middle again don't care.

Under usual circumstances they don't care? Or never care at all? I don't see why it wouldn't be possible to have a router that sniffs packets and does a bit of modification.

It's *possible* to sniff and modify packets, for things like traffic shaping or whatever, but it isn't something that'll affect the connections.

What about a router, then? Would that be a possible cause?

iago is both correct and incorrect. Layer 2 indeed does not have any mechanism for deterministically dropping packets. It can, however, be instructed to drop packets by upper layer inspection mechanisms (though somehow I doubt that is the case).

What I do think is the case is that it could simply be regular packet loss which is resulting in this behaviour. TCP is supposed to automagically correct for packet loss. It would make sense that the end user might not notice anything abnormal (except maybe abnormally high chat latency) until the end of the connection -- at which point, there's no further information that needs to be guaranteed to be received by the other end. You can ask that user to monitor their route to Battle.net for high packet loss using Ping Plotter (JFGI).

Note that it's normal for some ISPs to have their routers not respond to pings at all (or when under high load), which would result in Ping Plotter determining that hop along the route to have (near-)100% packet loss. If you're still communicating with Battle.net just fine, then obviously that 100% packet loss would be incorrect. In my opinion, those ISPs are stupid fucks and shouldn't be service providers in the first place, but that's a different story.

In either case, if you do find a router that has abnormally high packet loss (more than about 1% is considered high), then you should contact your ISP about it. If the bad hop is further along the route, your ISP might not do anything and might tell you to contact the ISP that owns the malfunctioning (or misconfigured) router... and you should.

In the end though, if the user is honestly using a legitimate unaltered Blizzard client, then they shouldn't be having this issue.

I don't talk to the person much anymore... She's been on once in the last 4 months or so (though I was able to recognize her by the fact that she got dropped from chat and was still in "USWest").

Lol, that sounds like a MITM attack, but completely different concept, as there is no middle man involved.

As Andy said the client is disconnected from BNET once he leaves chat. I've been ghosted plenty times on Warcraft 3 to know that it also happens on there as well.

Why would modifying a packet prevent the client from properly logging off of battle.net?

[quote author=vector link=topic=17728.msg180802#msg180802 date=1229124455]Why would modifying a packet prevent the client from properly logging off of battle.net?[/quote]Well, if the packet that notifies the server that the client has closed the connection isn't received properly by the server, it would still think that the user is connected.

I haven't checked in a while, but historically, there was a bug in the Blizzard clients that the SNP would not close the socket until the client unloaded the SNP.  Returning to the multiplayer menu is not sufficient to unload the SNP.  Returning to the main menu is sufficient.  I know this applied to Diablo, and it wouldn't surprise me if it affected the other clients, especially the legacy ones.