09 Jan, 2009, quixadhal wrote in the 21st comment:
We usually try to start around 7pm, although frequently folks don't show up until a bit later. There have been occasions where nobody manages to be not-idle at the same time, at all – and there have been times we chattered on for 3 or 4 hours. Nothing formal, suit, tie, pants optional. :)
Feel free to swing on by and if you can poke someone into responding, we'll chat! I'm typically online, but if I get wrapped up in something *cough*MMO*cough*, I may not notice for a bit.
I do try to start the log a bit before 7pm, just so if you guys log in and actually have a useful discussion without me, it can get posted later. If you chat about the record-breaking season the Lions had, that might get posted too… *grin*
25 Jan, 2009, quixadhal wrote in the 26th comment:
Just an FYI for today, 1/25/2009. I probably won't be able to make it this week, as I'm heading out of town this morning and might not make it back early enough to be here. However, I will make sure the mud is still running before I leave, and turn the log on as well…. so if you guys want to plan a coup or something, I'll be able to post the results later. *grin*
Hopefully THIS week I'l be able to sit down and hammer some stuff out. The ban code looks pretty good (not quite the way I was headed, but just as good – and already done!), and the language code also looks promising. I'll work on merging some of that into the official branch. :)
26 Jan, 2009, quixadhal wrote in the 28th comment:
Let me know if you hear anything. I am seeing the connection attempt, but nothing beyond that. So, at least part of the connection is getting through, but perhaps data on the return end is being rejected by something.
One thing to note (for your network admins), it IS a dynamic IP address from my ISP and will resolve to a different hostname by lookup than the one you used to get there. It's possible your sysadmins might reject traffic for that reason, since it technically could be a spoofing attempt.
Otherwise, I'm hoping they'll find something, as if it IS on my end, I'd like to know so I can try poking around my firewall rules and such.
I'd be rather surprised if that were the case, since when you connect out, you don't pass along the hostname, and when response packets come back, they're tagged by IP, not by host, so the network doesn't know they're coming from somewhere they're not supposed to be coming from.
27 Jan, 2009, quixadhal wrote in the 31st comment:
Actually, that depends on how strict their network policiing is. It would be highly unusual for that level of paranoia at a university, but it's quite possible. You do have to go the extra mile for it though… essentially have your caching nameserver working with your firewall, so if a name lookup resolves to an ip, and then that ip resolves to a different name (in a different domain) toss a block rule on the IP.
Since his connection IS getting through, I doubt that's what's being done. However, I can't for the life of me, imagine what the problem actually is. My firewall would drop the packets before they got in to my server if it were on my end, and since it's a connected tcp stream, it's not like FTP where you can block one side but have the other still go through.
My own setup is NAT, and as such there are only a very tiny number of hand-blocked ip addresses on outbound traffic… mostly things like hacking attempts I notieced in the logs, or that one commercial company that started poisoning the DNS a few years ago.
Of course, I have no knowledge of (or control over) what my "wonderful" ISP does. The whole reason you guys get to suffer with weird https or http on other ports to get to me is because they block incoming port 80 requests (as well as port 25 – which is more of a pain since you can't specify alternate SMTP ports in DNS).
If it did that, it would break a huge number of websites. It is very common for a name to map to an IP, whose canonical hostname is completely different.
Note that it's just his connection attempt that's getting through. It's unclear if that mean the TCP/IP connection was fully established; I guess it depends on the underlying implementation. Some implementations might be optimistic and register the connection on the server side before it's fully established, so that the server can start processing as the handshake completes. (note that this is a common DoS vector)
It shouldn't matter much if he's NATted, because it's supposed to automagically handle this kind of stuff.
I think the best bet is to ask the network people if they know what's going on – they might be blocking something at some level. At which point you're SOL unless they're willing to accommodate you.