Help, Asend Pipeline 75 ISDN router problem

[rsales]

Last week the internet connection part stopped working. Phone part still works ok. It's not the ISP's isdn since an isdn modem I have works on the connection. Sunday I decided to try reflashing the firmware and it fixed it. Work fine until today when it started doing the same thinkg. I try flashing it again but it didn't fix it this time. I can ping the router and it trys to create the isdn connection when a computer on the network puts in a request for the internet connection. If you run the software that shows information on the router it shows it's not creating the 128k connection but it is trying to dial it up. I have version 8.0-101 for the firmware. Any ideas?

 

[Lord Evermore]

Can you get an error message or error number? They're generally referred to as "cause codes".

Is your ISP service just a plain old ISDN dialup, or a dedicated ISDN line? Do you dial a full phone number to connect or only 3 or 4 digits?

 

[rsales]

The router dials up the isp with the full phone number. I also issued the fatal history command and got nothing. I haven't seen any error messages or numbers. Perhaps I need to look somewhere I am not aware of.

Watching the software that connects via the serial cable I can see the router dial and connect in one window, but zero shows for speed in the other window that shows speed and quality of the connection. I would always get a 128k connection with good quality. Like I said everything works fine with the isdn modem but I like using the router for the other computers on the network.

 

[Lord Evermore]

It sounds like maybe the configuration of the router has been changed somehow.

You should be able to call your ISP and have them watch their equipment to see if they're even receiving the call from your router. If the call isn't getting through to them at all, then it may be either the configuration having been screwed up somehow, or the router being damaged. If they're seeing the call but the connection isn't being completed, then it could be the same things. If the connection gets made, but you're never assigned an IP, they should be able to check whether your router ever sends authentication information. (Assuming your router doesn't have a manually set static IP address for the WAN side.) The connection will probably normally time out and disconnect if authentication isn't passed within a short time.

I don't remember enough of using Ascend routers to know for sure where to look for errors. If you telnet into the router during the dialout, you should be able to see a large box on the left side of the screen, and 8 small boxes on the right side. One of those boxes will have 3 rows labelled D, B1 and B2 (I think). To the right of each label, is normally a dash when it's disconnected. The D channel's status should be an asterisk I think, indicating that the D channel is connected, but I'm not real sure with a non-dedicated ISDN line.

When the dialout happens, the B1 channel's status should change to a small letter d. When the connection is made, it should change to an asterisk indicating the connection is made. If it then changes back to a dash immediately, then for some reason you're being disconnected from the other side.

One of the other small windows may show status messages. I think you should see something like "M31 Call Disconnected" or something like that. The M31 indicates the message number 31. You can hit the tab key to move to different boxes, and the down arrow when that box is highlighted will scroll the messages. One of them may give you a cause code or error. If you don't see the message window at all, you can go to any of the smaller windows, and the left arrow key will back through the options for what can be displayed. You should eventually be able to find the message log window.

Windows Hyperterminal sometimes has problems telnetting into Ascend routers. You may want to use some other product like SecureCRT, or a command line telnet program. Also, connecting via a direct connect with the serial port will work too, you just set the terminal program to do so. Telnet is just easier to do.

 

[rsales]

Ok I use the telnet alot to see if I am connected ok and how the router is setup. Now I understand what you mean by message codes. I always wondered what all the M# things were. When it trys to connect one of the M numbers shows connected but it is only one channel. I noticed when it did work it connects one channel then the other. Some time passes but I never see the "DYN STAT" window show "Good Quality 128K" and "2 Channels". After maybe 30 seconds to one minute it disconnects. I tried it just before posting this and after it disconnected I stepped thru all the M codes looking for ones that said anything about "call disconnected". The ones that said "call disconnected" were: M14, M9, M27, M30, M26 and M29. I think I did see one M31 but after the disconnect I didn't see it scrolling thru the codes. None said anything like error. Some had incoming or outgoing number.

So can I find a list of these codes somewhere?

As for the IP address it should be getting if from the ISP. I only assigne one to the router on the LAN side. I suppose I should check to make sure it didn't change.

It's too bad it quite working correctly since it is faster than this USB isdn modem and it's nice to be able to access the isdn from any computer on the LAN.

 

[Lord Evermore]

Well you could set up ICS on the computer to act as a gateway for the USB ISDN connection.

Search for "ISDN cause codes" and you'll find a list of the actual cause codes. However the messages like M29 aren't exactly cause codes. Cause codes are numbers specifically stating why a call was disconnected, like "remote disconnect" or "normal disconnect".

From what you say, I don't know the exact progression of the messages. What happens between the "outgoing call" which should show the phone number, and the "disconnected" message? It sounds like the other side isn't receiving authentication information and is timing out the call.

You may want to find out if your ISP changed equipment recently. At my last job, after we took over a company, the ISDN equipment was consolidated, and customers that dialled into one type before were now dialling into a different type, and some settings needed to change (but I can't remember which ones). Your USB ISDN adapter may be using settings that worked either way. That's a stretch for an idea though.

 

[rsales]

Well I think the problem has been solved since the ISDN router has been connecting ok lately. I had thought there was something wrong with the router so I picked up a used one off eBay. The replacement did the same thing so I called the ISP. They sent a message about the problem to MegaPop, the dialup provider for the ISP, and after 3-4 days it started to work like it use to. I suspect you hunch was right that they must have changed equipment. MegaPop asked for my configuration setting from the ISP so I forwarded the information. Figured it might be good to get input from them on the settings.

Now I can go back to my lower priority concern of some of the computers asking for the internet connection automatically. I only want it connecting when I want to use the internet. This machine didn't use to do this. I use to only have this problem with the WinXP Pro machine. Tried a sniffer on the WinXP Pro machine without any success in finding it. Thing is I loaded ZoneAlarm on the Win98se one to see what is asking for the internet. After turning off acess to everything ZoneAlarm saw asking for acess it still does it and I am not seeing the culprit. If I lock out the internet with Zonealarm it doesn't cause the router to connect. Strange. Have to try a sniffer and see if I can see it. I even went through all the loaded programs and stopped loading anything that wasn't needed. Also ran Spybot to remove any spy software. Also checked for viruses. Could it be the router is confusing normal operating system network traffic with a request for the internet? Replacement router is version 6 and the old one is version 8. Any ideas?

 

[rsales]

I ran across this on a setup page for the Pipeline. Maybe this is what is going on with the Pipeline connecting when I don't think it should be connecting.

"The Pipeline will sometimes open a session to a remote site unnecessarily due to broadcast messages on your local network (which is often seen in AppleTalk environments). If you notice the WAN light on the front of the Pipeline going on when you think it should not, refer to the User's Guide for information about Filters. You can use a call filter to suppress unneeded connections."