Two networking geeks discussing on how to propose a girl
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
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
