Usenetserver rejected login

[LawnMower2]

Hello all, great forum!

I'm having a persistent (i.e. ever since I've used Newsbin and Usenetserver -- about a year and a half) problem with Usenetserver rejecting logins from Newsbin. I'm not alone in this: See http://forums.newsbin.com/viewtopic.php?f=43&t=30557 and http://forums.newsbin.com/viewtopic.php?f=43&t=30298 and http://forums.newsbin.com/viewtopic.php?f=43&t=31627 and http://forums.newsbin.com/viewtopic.php?f=43&t=28817.

*Every* time, and I do mean EVERY time I go to download headers or bodies, Newsbin reports two or more rejected login attempts, always insisting "It's not our fault". Yesterday, just for example, I tried downloading headers for one moderately populated group, and every login attempt was rejected for 12 minutes. When I use either a Newsbin search or an imported NBZ, Usenetserver ALWAYS rejects at least two and as many as 7-8 login attempts. On body retrieval, however, they are retried and eventually connect, up to the 12 connections I have configured. Obviously, the login information is correct; obviously, my account is alive, otherwise it would never connect.

So yesterday, just for gits and shiggles, I installed a two year old release of Agent and configured it for one SSL connection to Usenetserver. Then I asked it to retrieve headers in the same group I mentioned above. It connected instantly and had the headers in a matter of minutes. I then re-tried it again with Newsbin and.... error after error. Out of curiosity, I let it run, throwing non-connect errors every 30 seconds, and 12 minutes later, it connected and retrieved the headers.

Finally, as one last experiment I installed BNR2 and THAT worked on the first try too. That's obviously connecting in the clear since it doesn't support SSL.

Newsbin guys: The only reasonable conclusion is that there is something dodgy with the way Newsbin submits credentials to Usenetserver. If Agent and BNR2 get it right on the first try, why can't you? Why does EVERY body-download cause a handful of connect errors, followed by eventual connection up to the number configured?

Here's what the problem is NOT:

> My Internet connection. I have 75/10 service from a very reliable ISP that never, ever, has high latency or dropped packets. No one else in the house was using the connection at any time these problems occur.
> My account at Usenetserver is paid and active.
> Once connected, connections NEVER drop out. I never (seriously) get dropped connections errors in Newsbin. Once it's settled down and retrieving, it's always smooth sailing.
> I use SSL to Usenetserver
> No one else uses my account at Usenetserver.
> My "router" is Untangle. It has packet rules that bypass SSL traffic to/from Usenetserver around all filtering.
> My gigabit LAN is hardwired. There is WiFi, but only for the Rokus. I never have latency or packet loss internally.
> My IP never changes. It's been the same from my ISP for three years.
> My ISP does not mess with packet inspection. They don't even mess with peer to peer. They're really good like that.
> My ISP does not have bandwidth caps or bandwidth throttling. You get what you pay for, 24/7.
> Latency to Usenetserver from here is typically under 15ms. 8 hops. When all connections are running, Usenetserver normally achieves 9+MB/sec rates. Anything less is very unusual and seems to be related to old (1600 days, for example) posts.

I have Newsbin on two different machines, both with Win7 Pro x64 fully patched. Both have 16GB RAM and i7 processors. Neither machine has any known problems. Newsbin/Usenetserver behavior is the same WRT/this login issue on both.

So how about it.... I know that Usenetserver tech support has heard this same complaint often because they already told me "We get this now and then with Newsbin, and it's not us." Big surprise, but understandable since eventually Newsbin DOES connect. So how about you get a test login at Usenetserver and put Wireshark to work on the login process, or something similar. There MUST be a reason for what's going on, and we users are in no position to troubleshoot it. And needless to say, a 12+ minute wait for a header download isn't any fun.

Thanks!

[itimpi]

For comparison, did you try configuring Newsbin for 1 connection (to make it comparable) to see if the problem occurs?

A common cause of that error is the server considering the number of connections allowed is being exceeded as the reason it rejects the connection attempt. This can be caused by the server being slow to reset closed connections for re-use. Just to clarify - how many connections does your account allow, and what is Newsbin currently set to use?

[dexter]

I've got an account with Usenetserver and I have personally never seen this. I also do not run max connections. There is no need to run more connections than it will take to attain your full download speed. For example I run 8 connections to UNS and get 30mbps download.

I think what you are seeing is that some intermittent connectivity issue makes a connection drop out to UsenetServer and Newsbin reconnects before UNS realizes the original connection is gone. Since you are running at (or close) to UNS max allowed connections, you are getting pushed over the edge and UNS starts rejecting connections.

If you run no more than 1/2 max allowed connections, you shouldn't have this problem and should still get your full datarate.

[Quade]

Newsbin guys: The only reasonable conclusion is that there is something dodgy with the way Newsbin submits credentials to Usenetserver. If Agent and BNR2 get it right on the first try, why can't you? Why does EVERY body-download cause a handful of connect errors, followed by eventual connection up to the number configured?

News servers are pretty dumb. They're basically mail servers that have been re-purposed to serve chunks of text at high speed. A news server has only one way to throttle a user. Deny the password. That means it's the first thing it does whenever anything goes wrong. It shouldn't even be considered an error as long as the other connections work. It's basically a warning meaning:

"Hey, you've popped over the connection limit, be a bit before we allow you to re-connect".

In your case that's all it means. There are no other errors in the protocol they can send with more information. These errors simply don't exist because when Usenet was designed, there was no authentication. The idea that people would use it like it's used today didn't really occur to them. So, there's nothing wrong with the auth process or talking to the server or anything like that. The only potential fix in Newsbin is to see that message, then sleep for a couple minutes and try again.

The main issue is that when the connection is closed in Newsbin, it takes a couple minutes for the server to realize it's closed. It might take anywhere from 2-5 minutes before the connection is released to the "available connection" pool in the server. Again, I think this is a legacy of the mail server roots. During this limbo time, between the disconnect and the connections return to the free connection pool, the server will deny the password. Then when enough time passes, the connections are permitted once again.

As the others were saying, one way to stop this would be to reduce the total connection count. That keeps more connection in the "free" pool so, when you disconnect and re-connect one of the free pool connections is used and eventually the disconnected connection goes back into the free pool.

[LawnMower2]

I've got an account with Usenetserver and I have personally never seen this. I also do not run max connections. There is no need to run more connections than it will take to attain your full download speed. For example I run 8 connections to UNS and get 30mbps download.

I think what you are seeing is that some intermittent connectivity issue makes a connection drop out to UsenetServer and Newsbin reconnects before UNS realizes the original connection is gone. Since you are running at (or close) to UNS max allowed connections, you are getting pushed over the edge and UNS starts rejecting connections.

If you run no more than 1/2 max allowed connections, you shouldn't have this problem and should still get your full datarate.

Let's see...
My account allows 20 connections. I never use more than 12, and often adjust downward when I don't want it chewing up all 75Mbits. As it happens, it was set for 12 when I tried this header retrieval. I am NOT running at/close to max allowed connections. On posts aged <200 days, Usenetserver can saturate my pipe with four or five connections -- it's that fast. With new posts, I've adjusted number of connections as low as 2-3 just to limit the bandwidth used. Older posts apparently take more time to retrieve and benefit from more connections that spread the wait time around.

Intermittent connectivity: Then why, once all available connections are connected (due to automatic retires), that none of them EVER (that's not an exaggeration, they really do not) drop? If connectivity were intermittent, I'd be griping about that, which I am not, since it doesn't happen. This occurs ONLY at initial login.

I have tried many times logging in for body retrieval with <10 connections configured, and the rejected login problem still occurs, so that theory does not hold water.

[LawnMower2]

Newsbin guys: The only reasonable conclusion is that there is something dodgy with the way Newsbin submits credentials to Usenetserver. If Agent and BNR2 get it right on the first try, why can't you? Why does EVERY body-download cause a handful of connect errors, followed by eventual connection up to the number configured?

News servers are pretty dumb. They're basically mail servers that have been re-purposed to serve chunks of text at high speed. A news server has only one way to throttle a user. Deny the password. That means it's the first thing it does whenever anything goes wrong. It shouldn't even be considered an error as long as the other connections work. It's basically a warning meaning:

"Hey, you've popped over the connection limit, be a bit before we allow you to re-connect".

In your case that's all it means. There are no other errors in the protocol they can send with more information. These errors simply don't exist because when Usenet was designed, there was no authentication. The idea that people would use it like it's used today didn't really occur to them. So, there's nothing wrong with the auth process or talking to the server or anything like that. The only potential fix in Newsbin is to see that message, then sleep for a couple minutes and try again.

The main issue is that when the connection is closed in Newsbin, it takes a couple minutes for the server to realize it's closed. It might take anywhere from 2-5 minutes before the connection is released to the "available connection" pool in the server. Again, I think this is a legacy of the mail server roots. During this limbo time, between the disconnect and the connections return to the free connection pool, the server will deny the password. Then when enough time passes, the connections are permitted once again.

As the others were saying, one way to stop this would be to reduce the total connection count. That keeps more connection in the "free" pool so, when you disconnect and re-connect one of the free pool connections is used and eventually the disconnected connection goes back into the free pool.

No no no no no.

The rejection(s) happen instantly on the FIRST connection attempts. Once five-seven (whatever) get rejected, then it decides "Oh, this is okay, we can connect" and normal downloading starts. Eventually when the failed connections timeout and are retried, they connect too and STAY connected.

It is nowhere near the number of connection limits. The problem occurs even with three or four out of 20 allowed.

HOWEVER..... "itimpi" may have hit on something, at least as header retrieval goes. I just tried header retrieval with ONE connection configured and..... IT WORKED PERFECTLY! So folks, there's a Really Good Clue.

But, after that, I let the connection time out and while set at 1 and tried retrieving bodies and.......

[14:19:23] ERROR NNTPSocket - NNTP Perform Auth - secure.usenetserver.com-The server rejected your login - contact your news service's support department. It's not a Problem with Newsbin : 502 Authentication Failed

Aargh!

So it looks (at least in two trials) that 1) there's no login problem with header retrieval as long as there's only one connection allowed, and 2) the "rejected login" problem has NOTHING to do with # connections, since it occurred with only 1 configured.

Guys.... I know this seems painful to you, but really, there IS something screwy going on with authentication.

[Quade]

It's not painful for me. I'm just not convinced you've actually found an issue in Newsbin. Authentication is about dead simple. It's clear text and only secure if you use SSL. Dex uses Usenetserver and doesn't see this. I use 2 other servers and don't see this there. Might be worth changing your password at the server end and then in Newsbin. These kind of symptoms could also suggest someone else is using your account.

I know it's happening to you but, the only question there is why you? What it is about your setup that's different than Dex's?

Nobody else has reported connection failures up front, what Dex, Itimpi and I are talking about are auth errors after it's been running awhile. Auth errors up front with a good password, honestly you might be the first one to report this here.

[LawnMower2]

It's not only me -- have a look at the other posts at the top of my first message. Same symptoms.

Well, as far as what's different... Kind of hard to say. Both machines where Newsbin is installed are pretty fast -- i7s on both. The one I use most often is an Asus P8Z77-V with an i7-3770K, 16GB RAM @ 1866MHz. Normally there's little to nothing else running, with the possible exception of Firefox sitting there. This machine runs 24/7 and reboots only for Windows Updates. It's not unusual to see uptimes of 40+ days. Network is hard-wired, Intel NICs all around, except on the HP notebook where I'm stuck with a RLT chip. That's an i7-3610QM also with 16GB memory @ 1600MHz. Problem is the same. Untangle is on an older Socket-775 board with Intel NICs. All with up to date Win7 x64 Pro. There's no known problems or other misbehavior. Everything here is rock solid, to the best of my knowledge.

I have no issues logging into any of my mail servers -- five of them, using the old Qualcomm Eudora. That's not SSL of course. In fact, I have no issues logging into anything. Any web pages where Firefox stores the credentials or supplies them automatically, such as from Yahoo Messenger work 100% reliably.

The Internet connection is also rock-solid. Among the best, most trouble-free I've ever seen. I get 75-78Mbits/sec down all day long, even at "peak" times. Latency to/from UNS is normally very low, usually under 20msec and often under 10msec.

Honestly, I can't point my finger at any hardware or network issues. If there *were* issues, I'd have been on them already. But everything just....... works.

Is it possible that (this is a stretch, I know) that it's TOO fast? That something comes back from UNS before Newsbin is ready for it?

Maybe if I have a chance in the near future, I'll set up an old Atom 330 board on the bench and put Win7x86 on it. And Newsbin. Wonder what will happen. That's certainly not overpowered and will have a 32-bit o/s.

You know...... since we seem to have a work-around for headers (though it would be nice to have multiple connections for that), maybe a good temporary solution to the failed logins is just to disable the critical warning pop-up.

[Quade]

Dex and I were kicking around some ideas:

1 - Dex pointed out to me that TOR would cause this issue too. Any proxy where the exit point IP Address is sort of random per connection won't work with usenet. Servers lock you down to a single IP address so, changing IP's due to the exit node will cause this to happen.

2 - DHCP between your router and ISP. If the ISP hops your IP to a different one, the server won't like it and it'll take awhile to permit the next set of connections. Giganews gives an error, I don't know how usenetserver handles it.

3 - Running a different client, exiting, then starting Newsbin. It's basically has the same effect as a connection failure. Your connection pool is still busy.

4 - Running on one PC, exiting then running on the second or running it on 2 PC's at once.

I don't believe it's your PC. Probably isn't you network. I suspect you're doing something unusual and that's what's triggering it. I have pretty much the fastest PC you can buy. I doubt speed has anything to do with this.

I'd probably re-install 6.42 and see if anything changes.

[LawnMower2]

1 & 2: No IP addresses change. My WAN IP has been the same for years. Non-static LAN IPs are assigned by MAC and do not change either.

3 & 4: I never have Newsbin running on more than one machine at a time. This problem occurs on all body downloads -- typically I start up Newsbin and either use Search or load a nzb and tell it to retrieve something. Then it barfs. It's as simple as that. I do not use any other News clients, with the sole exception being the tests I described. Besides, there's no need to since Newsbin does everything!

If I'm doing something unusual, it's entirely accidental. As far as Options settings go, I changed only those that were necessary to make Newsbin work.

Hold on a sec... I just thought of something: Newsbin's target drive/folders are on a disk that powers-down. Do you suppose that having the disk temporarily unavailable (its resume latency is about 5 sec, but I don't know when in the process it announces that it's available) could be the underlying cause? I'll test it when I have a chance, with the understanding that this is hardly a definitive test, but it could be the variable we've been looking for.

[Quade]

Hold on a sec... I just thought of something: Newsbin's target drive/folders are on a disk that powers-down. Do you suppose that having the disk temporarily unavailable (its resume latency is about 5 sec, but I don't know when in the process it announces that it's available) could be the underlying cause? I'll test it when I have a chance, with the understanding that this is hardly a definitive test, but it could be the variable we've been looking for.

Can't hurt. Typically though only one thread writes to disk and the ones that can't connect download to memory. Still, not being able to access a spun down disk might totally stall out Newsbin.

[LawnMower2]

Well, the spun-down disk wasn't it. I tested the theory on both computers. On the first by changing power options so that the disks were kept alive, and on the second where there's only one disk, an SSD, which is always alive. Results were the same. On body retrieval, on both machines, the first 3-7 fetches result in rejected credentials. And, as always, those failed connections eventually timeout and then connect successfully. And they stay connected until the download is finished.

I can't think of anything else that could be causing this, so I'm giving up for the time being.

[Quade]

Try 6.50. Can't hurt...well I don't think it can.

[LawnMower2]

Try 6.50. Can't hurt...well I don't think it can.

Haha. Well, if there weren't pain, there wouldn't be Betas, right? Think I'll hold off on 6.5 until it hits released status. Learned my lesson much too long ago about Betas, thank you very much. If this issue resolves itself at some point in the future I'll update this thread.

You know what's funny though -- I've browsed through many postings on the support fora and do not recognize more than one or two of the problem reports. IOW, except for this login annoyance, Newsbin is essentially trouble-free in my experience. Any other minor issues that crop up are usually due to bad posts or something else exogenous to Newsbin.

[newsie]

I've been following this thread for a couple of years and also have to confirm some things.

I also use usenetserver. ssl on, proxy on.

before 6.6 (like OP) everything worked fine, all connections (8). When i first installed 6.6, i had 502 problems, couldn't do anything. Tried to look into it, followed this thread, nothing worked. I went back to 6.5, it worked fine.

Now, i put a new firmware on the router, merlin. I also tried 6.6 again, it works for 2-3 connections, the rest have errors, 502 with something about simultaneous ip's (2).

I'm going to go back to 6.5 and see what happens, because in this most recent case, it could also be the new router firmware.

[Quade]

I'm pretty sure Dex uses Usenetserver. He's not reporting any problems like that.

I also use usenetserver. ssl on, proxy on.

First think I'd do is bypass the proxy and go direct. What security software are you using? Kaspersky will stomp on your connection to the news server. I've seen it dozens of times now. In particular it breaks header downloads but the fact it's doing a man in the middle attack on your SSL connections means there's no telling what it's doing during the rest of the download. I recommend making any security software ignore Newsbin's connections to the server.

If your proxy does any kind of address hopping it will break your connections to the news servers. Most news servers only permit a single IP address to access the server per account meaning if you have 10 connections to the server and you proxy splits that out over a couple exit nodes, it simply won't work. That's why you can't use Tor together with Usenet unless you restrict it to a single connection.

News servers are slow to give back connections when a connection drops out. That's why it's a bad idea to run max connections to the server.

The biggest changes in connections to the servers in Newsbin is that SSLV2 and V3 have been deprecated. They're hopelessly broken (The protocol, not how Newsbin uses them). In Newsbin you can still use V2 because people have asked for it but I understand Servers are starting to disable access using SSLV2.