Geek pop quiz!
Oct. 29th, 2008 11:43 amI fell incredibly stupid today.
Ubuntu server. Running a brand new Perforce server, listening on port 1666.
Perforce clients on the server can see the Perforce server.
Perforce clients anywhere else cannot connect. They *could* connect very briefly when I first started the server but now they can't.[1] No, I didn't change anything.[2]
Nmap from the server says port 1666 is open on the server.
Nmap from anywhere else says port 1666 is not open on the server.
Telnet confirms this: It's listening to 1666 from localhost but not from anywhere else.
There is no software firewall running on the server. The hardware firewall is set to forward port 1666 from any LAN address to the server.
This has to be an incredibly simple thing. What the FUCK am I doing wrong, here?
[1]: I could connect as "Perforce", the superuser, because that was what I tried first. I went to connect as a different user, but before I did that the thing *stopped listening on that port at all*.
[2]: No, really. Literally I confirmed that the superuser worked, clicked "back" to change the username to a different user, and connections no longer worked at all.
EDIT: Changed the fucking port and it works. What the fucking fuck is wrong with fucking 1666 that isn't fucking wrong with 11666?
Ubuntu server. Running a brand new Perforce server, listening on port 1666.
Perforce clients on the server can see the Perforce server.
Perforce clients anywhere else cannot connect. They *could* connect very briefly when I first started the server but now they can't.[1] No, I didn't change anything.[2]
Nmap from the server says port 1666 is open on the server.
Nmap from anywhere else says port 1666 is not open on the server.
Telnet confirms this: It's listening to 1666 from localhost but not from anywhere else.
There is no software firewall running on the server. The hardware firewall is set to forward port 1666 from any LAN address to the server.
This has to be an incredibly simple thing. What the FUCK am I doing wrong, here?
[1]: I could connect as "Perforce", the superuser, because that was what I tried first. I went to connect as a different user, but before I did that the thing *stopped listening on that port at all*.
[2]: No, really. Literally I confirmed that the superuser worked, clicked "back" to change the username to a different user, and connections no longer worked at all.
EDIT: Changed the fucking port and it works. What the fucking fuck is wrong with fucking 1666 that isn't fucking wrong with 11666?
(no subject)
Date: 2008-10-29 03:50 pm (UTC)Then I'd move it to a different backbone.
Then I'd change out the NIC.
I'm going to /guess/ that there's a broken rule, or a hidden rule, somewhere on the hardware firewall that's killing 1666 - like, a traffic squelch rule or a QoS rule or an IDS rule that the Perforce traffic is tripping. or something.
(no subject)
Date: 2008-10-29 03:52 pm (UTC)(no subject)
Date: 2008-10-29 03:53 pm (UTC)Also, check the default route. See if the perforce server settings are telling it to only bind to localhost. Also, is it listening only on localhost or is it also listening on the host address?
(no subject)
Date: 2008-10-29 03:57 pm (UTC)(no subject)
Date: 2008-10-29 03:57 pm (UTC)The 10% chance is that the NIC is broken and doesn't like particular bit patterns and barfs on them, and TCP/UDP packets with a destination port of 1666 are the lucky winner of the "first to show up obviously as bad" lottery. This only because you mention that it worked /briefly/ and then not-at-all.
(no subject)
Date: 2008-10-29 03:57 pm (UTC)Perforce server settings are *not* set to bind only to localhost.
Local clients *can* connect by IP and servername as well as "localhost".
And changing the port worked, but I don't know why.
(no subject)
Date: 2008-10-29 03:58 pm (UTC)(no subject)
Date: 2008-10-29 04:00 pm (UTC)(no subject)
Date: 2008-10-29 04:01 pm (UTC)(no subject)
Date: 2008-10-29 04:02 pm (UTC)I really need to get this file uploaded!
...I already tried that!
What's taking so long!
(no subject)
Date: 2008-10-29 04:06 pm (UTC)(no subject)
Date: 2008-10-29 04:21 pm (UTC)(no subject)
Date: 2008-10-29 04:29 pm (UTC)(no subject)
Date: 2008-10-29 04:36 pm (UTC)Any hints in /var/log/messages or syslog? Anything useful in the perforce logs?
If memory serves from about 2 years ago, the binary license also defines a number of server parameters on start.
(no subject)
Date: 2008-10-29 04:36 pm (UTC)The port and/or switch, on the other hand, is entirely possible depending on the complexity of said switch. A munged ARP table or cache, misconfiguration, a failing physical port -- all of these things can cause certain protocols and ports to get blocked. If the switch is complicated enough, then it could be kicking port 1666 into a nonexistent VLAN.
If, on the other hand, your switches are pretty stupid -- or if God help you your network uses hubs -- then check to see if you have a broadcast storm on your LAN. Give enough traffic, and you can see specific ports end up being rejected even as others pass straight through.
If on the other other hand you're essentially not doing LAN traffic at all, but instead are just passing through a router to the internet, check to see if your ISP interdicts port 1666 for some reason. I know Rogers does weird crap sometimes.
(no subject)
Date: 2008-10-29 09:51 pm (UTC)(no subject)
Date: 2008-10-29 10:44 pm (UTC)Settings: All correct, which is the problem.
Manual: Hahahahahahahaitistolaugh.
Firmware: For *what*? Neither client nor server is an embedded device. This is software!
(Something else on port 1666: No, I checked that. But that's a good thought!)
Just a guess as to why 11666 is better than 1666.
Date: 2008-10-29 11:07 pm (UTC)We know that ports below 1024 are reserved for superuser binding on some OSen.
1024 is a 4-digit number.
So, in our Enterprise application, we should block use of any port numbers that are 4 or fewer digits, just to be safe.
And then not bother to document it, because only a certified professional would be using Enterprise software.
Re: Just a guess as to why 11666 is better than 1666.
Date: 2008-10-30 12:33 am (UTC)(no subject)
Date: 2008-10-30 12:50 am (UTC)(no subject)
Date: 2008-10-30 02:38 am (UTC)tcp ports
Date: 2009-10-19 11:21 am (UTC)