lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Mar 2012 11:47:15 -0400
From: Valdis.Kletnieks@...edu
To: Peter Maxwell <peter@...icient.co.uk>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: is my ISP lying or stupid?

On Sun, 18 Mar 2012 12:49:49 -0000, Peter Maxwell said:
> On 16 March 2012 19:11, Dave <iryshman@...il.com> wrote:
> > Your ISP probably has their users are on different networks than their
> > servers.  Sounds like maybe they meant the switch you are on, not the
> > servers switch.  Need to troubleshoot, use a smart phone or some other OOB
> > capable device to test access to the ISP servers.  If you can access OOB,
> > then maybe they aren't lying.  Just a guess, you didnt provide much detail.

> Unlikely, usually these switches are quite large and when a user has OOB it
> usually means console access to the server, i.e. nothing to do with network
> topology.

I strongly suspect that what Dave meant was:

1) There's a switch at the ISP's central site that the services live on.
2) There's *another* switch that you and the other subscribers in your
area are connected to.
3) If you can reach the mail server via other means (IP-capable cellphone,
wireless from the local McDonalds, etc), it's more likely switch (2) than (1).

The real troubleshooting fun starts when you throw things like load balancers
and ethernet bonding into the the config.  Nice things if they work, but can be
a bear to diagnose.  If they're doing round-robin, they can end up hosing every
N'th connection (which is loads of fun when N is in the hundreds).  The other
common failure mode is hashing each inbound's address to determine which back
end to go to and certain hash values end up in the bit bucket - so it all works
great unless your DHCP-supplied IP address is (when treated as a 32-bit number)
equal to 17 mod 39 or some siimilarl wierdness.  The troubleshooting fun gets
even worse if the hash contains both the IP and the ephemeral port number - this
can result in intermittent issues that will take *month* to find and diagnose, because
most users will just hit reload, and since the ephemeral port on their end changed,
it works for them and they never report it...

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ