Two networking geeks discussing on how to propose a girl

bakuryu

Rob says:
We've all had our fair share of mishaps in that department I can assure you.

Dave says:
if you ever find a manual, make sure you share it

Rob says:
Girls are written in a bizarre server side language neither of us have heard of
There's an open source compatibility layer between guys and girls but the developers abandoned it half way through so you gotta tweak it heavily ot make it work

Dave says:
heh

Rob says:
Think... samba.

Dave says:
ahhh

Rob says:
Girl > Girl communication is fine
Girl > Guy communication is supported unofficially
Through a third party, unsupported compatibility layer

Dave says:
I tried guy > girl through a 3rd party that has a connection inside the other subnet, but the 3rd party refused to NAT the connection

Rob says:
Ohhhh so you were stuck on the 192.168 subnet while she was way out there
Using a proxy is a very good method of traversal though
Man in the middle attacks are a potential problem though

Dave says:
I doubt it, this was a trusted proxy, but it refused to pass on the connection, said I have to do it directly

Rob says:
Ahh I see
And the proxy refused an encrypted HTTP/S transfer?

Dave says:
I wanted the proxy to anonomise the source, and just send a status request, but it refused

Rob says:
Connection rest by peer?
*reset

Dave says:
unwilling to forward query packet

Rob says:
HTTP error status 305 I think you'll find.

Dave says:
thanks

Rob says:
Eurgh I'm tired

Dave says:
I'm SO saving this conversation

Rob says:
You blatantly have to post it

Dave says:
The trouble with a direct connection is that theres a bandwidth throttle, you can only go at a certain speed before packets get lost and the message gets garbled, but without a response to the status request, you don't know what speed that is

Rob says:
Certainly makes communication awkward. I'm also concerned that the TCP/IP "fix" in Service Pack 2 might have limited your concurrent lines of conversation.

Dave says:
currently I can only establish a connection via the msn protocol, which is certainly limiting

Rob says:
Is there no implementation of Zeroconf - like uPNP or Bonjour - installed? Could make acertaining the status easier

Dave says:
not that I'm aware of, and I don't know of any peripheral devices on the subnet that could provide me a backdoor to find that information
I don't want to run a portscan to find additional supported protocols, as I don't want to risk being blocked as a DoS attack

Rob says:
A wise move, as the client typically has a distributed blacklist net which would see you blocked by all clients of that type.
I've heard of an exploit by the name of Alcohol ... it typically functions as a rootkit on the client, masking true intentions

Dave says:
I've heard of that too, but I believe it requires physical proximity to the device, which isn't easy to obtain due to distance, and lack of common peripherals with which to bring it closer, the one single connection is that 3rd party proxy, which is unwilling to forward packets either way along this connection

Rob says:
Back to the original problem, I see.

Dave says:
indeed, I think the problem is stuck in an infinite loop
I need to add a breakpoint, but thats tricky with the only access being via the msn protocol, to add it without crashing the whole system

Rob says:
THe boolean condition of exiting the loop doesn't appear to ever be fired
Could a more accessible client be more appropriate in the long run, perhaps as an intermediate step in securing a reliable connection to the former client?

Dave says:
are you suggesting I find a different target device for training purposes?

Rob says:
Somewhat; a means to an end. The original target device must remain in your sights, but the software vendor may have released updates you simply cannot check behind your subnet

Dave says:
hmm... I don't like opening too many ports on my firewall at once, really, only one device can be connected at a time in that way
I don't want to risk a buffer overrun

Rob says:
But you're in a connection deadlock, we've established this. So by disposing the connection you can re-establish it via a new route. And perhaps one of the intermediate nodes will be a more suitable target device than originally expected

Dave says:
there are currently no known compatible intermediate nodes, I think I'll keep probing via the msn protocol for a while, see if I can get anything that way, it has after all, only been a few days since the device showed up on my packet monitor

Rob says:
Very well. Can you connect a VNC server for remote status updates? So I can be informed of general progress

Dave says:
sure, Paul's already connected and monitoring the situation

Rob says:
Be sure of one thing, Dave. The client has flooding protection enabled. Don't write a bot to facilitate communication.

Dave says:
I know that doesn't work from experience



------------------------------------------------------------------------
Found it in one of the neowin blogs and it's damn funny

__________________
Please don't click here

X-Caliber

Bravo !!!

nucleusfermi

I like it much, Thanks!

Gigacore

that was really funny

Strider

The proxies used to work, but now a days keeping the source anonomise is difficult. Even trusted proxies starts monitoring traffic logs and analyzing data packets sent. Suspicious packets used to filtered out or getting forwarded to system admins.

__________________
Want to ask a question? Try This! A guide on how to post a question, reply to a post etc.