Reply to thread

Message: <blockquote data-quote="bird123" data-source="post: 909323" data-attributes="member: 51098">Two networking geeks discussing on how to propose a girlRob 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 workDave says:hehRob says:Think... samba.Dave says:ahhhRob says:Girl > Girl communication is fineGirl > Guy communication is supported unofficiallyThrough a third party, unsupported compatibility layerDave 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 thereUsing a proxy is a very good method of traversal thoughMan in the middle attacks are a potential problem thoughDave says:I doubt it, this was a trusted proxy, but it refused to pass on the connection, said I have to do it directlyRob says:Ahh I seeAnd 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 refusedRob says:Connection rest by peer?*resetDave says:unwilling to forward query packetRob says:HTTP error status 305 I think you'll find.Dave says:thanks Rob says:Eurgh I'm tiredDave 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 isRob 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 limitingRob says:Is there no implementation of Zeroconf - like uPNP or Bonjour - installed? Could make acertaining the status easierDave 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 informationI don't want to run a portscan to find additional supported protocols, as I don't want to risk being blocked as a DoS attackRob 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 intentionsDave 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 connectionRob says:Back to the original problem, I see.Dave says:indeed, I think the problem is stuck in an infinite loopI need to add a breakpoint, but thats tricky with the only access being via the msn protocol, to add it without crashing the whole systemRob says:THe boolean condition of exiting the loop doesn't appear to ever be firedCould 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 subnetDave 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 wayI don't want to risk a buffer overrunRob 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 expectedDave 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 monitorRob says:Very well. Can you connect a VNC server for remote status updates? So I can be informed of general progressDave says:sure, Paul's already connected and monitoring the situationRob 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</blockquote>

Verification: Dawasata paya keeyak thibeda?

Top Bottom