Traverse Viking ADSL-2+ Card Problem
-
Don't know–the information that came with the card is so minimal, e.g., it gives card jumper settings for Ethernet v. PCI LAN connection configurations but fails to include a diagram identifying the location of the jumpers on the card!
-
I would have thought you're basically connecting to the same thing. The on-board ethernet connects to the modem/router SoC directly instead of via the cable magnetics etc.
Steve
-
I just tried to configure the card via the PCI connection. I could ping the card, but I could not telnet to it or reach it via its GUI in my browser. I'll have to try the Ethernet port, however, the jumper configuration given seems to then imply I have to power the card via its onboard power connection, which appears to be a 5-pin connector for which I don't have a matching connector (or is it the 4-pin connector?). Also, a flag went up with me when I saw that pfSense recognized the interface chip on the card as rl1, but as a Realtec 8139 instead of a Realtec RTL8100CL!!! Sigh!
On further thought, it does not look like I will need to use the on-board power connector–I'll try changing the jumpers tomorrow--too tired right now and when I try to do things when I am tired I tend to break things.
-
You don't need to power it externally at all no, the PCI bus will still power it even if you have it set up to access it over ethernet. I suspect that if you could power it directly you could set it up as a standalone device, no PC required at all - if you smashed open your ISP provided modem and thought "that's weird, the circuit board inside it has a PCI connector that doesn't plug in to anything" that's the kind of thing I'm thinking. I hope that made sense.
Does your documentation match the scans on that link I posted? Please double check this as I am doing this from memory and the photograph isn't fantastic, but it should be a matter of changing all 5 jumpers in the block highlighted in red from [12]3 to 1[23] and swapping the two marked in orange to switch between PCI and ethernet mode. Why one jumper wasn't sufficient to do this I don't know.
After that you should be able to get to the webGUI via the card's ethernet port with a crossover cable and a PC with a statically assigned IP in the 192.168.0.0/24 range.
Edit - I attached the wrong picture, this one should be correct.
-
Thanks for your input and thanks especially for the picture, as I had figured out the first five jumper locations but was unsure of one of the two single jumper locations; and it is good to know that the jumpers don't effect the way the card can be powered. The manufacturer of the card should have used dip switches instead of jumpers–that would have made changing the card's configuration easier for the user.
Trying to configure the card via the PCI bus, even if that was possible via telnet, is actually more of an ordeal for me than using the card's Ethernet port: since my router's address is in the 192.168.0 subnet (i.e., the same as the card), I would have to temporarily reconfigure the subnet of my computer, IPMI, and pfSense to do it--I tried this this morning and still could not telnet to the card--oh well, I gave it the "old college try" anyway--I will do the jumper thing this evening--thanks again.
-
Hmm, odd. Would be nice to know what J7 and J8 do.
Looks like it probably has 3.3V serial on CN4. The header isn't populated though. Fun. ;)Steve
-
O.K., so I finally got the LinITX card working!
I switched the jumpers to enable the Ethernet port and configured the modem in bridge mode after I disabled DCHP on its LAN (when I discovered it conflicted with my router). I went through the settings and hooked up the card to my DSL line to make sure it was connecting properly. I then switched the jumpers back to PCI mode and configured pfSense to work with the card (which, for some reasons, it still identifies as having a REL 8139 chip, even though it does not–must be the BSD rl0 driver).
Some initial observations about the LinITX card: it is not made as solid, with attention to detail, as the Viking card; the five jumpers in the same row were difficult to remove after they were set for Ethernet mode, as there is little room to grab them with a pair of long-nose pliers; most importantly, however, the LinITX card does not use a standard (i.e., U.S. Bell System standard) RJ11 jack--I had to push the line plug upward, once it was inserted in the jack, to establish a good connection--I'll have to find a fix for this issue.
I'll be testing the LinITX card over the next week and report back as to its performance and stability.
Thanks all!
-
however, the LinITX card does not use a standard (i.e., U.S. Bell System standard) RJ11 jack–I had to push the line plug upward, once it was inserted in the jack, to establish a good connection
Really? Interesting, I don't recall having any problem except the time I managed to wedge mine in the wrong way round.
I'll have to find a fix for this issue.
Bluetack? I'm going to have to have another look at mine when I get home.
Glad to hear you got it working, and I hope it is stable for you.
-
So I have had my LinITX card running for over a day now with no freezes/reboots required. I, however, am getting a lot of WAN disconnects, to wit:
Aug 16 07:23:49 apinger: alarm canceled: WAN(12.8.72.1) *** down ***
Aug 16 07:23:49 apinger: ALARM: WAN(12.8.72.1) *** down ***I have had these WAN disconnects before with other modems, perhaps not as often; the log, however, shows no PPPoE disconnects. I have my apinger frequency set to every 5 seconds when the disconnects occur. I reset my apinger frequency back to once every second and the log now shows no more WAN disconnects, but now I show a lot more packet loss on my WAN (see image below). I suppose it is possible that the loose-fitting rj11 connector may be causing the problem. Any suggestions otherwise?
-
I'm sorry I never experienced anything like that.
-
Yup, it looks like it might be a bad connection at the jack, as the packet loss increased after I jiggled the plug at ca. 1:30 pm. I'll have to try a new line cord when I can get around to moving all of the boxes under the table on which my router sits so I can have access to my wall jack. I might also clean the contacts with some Caig Deoxit. I first became aware of this kind of problem about 14 years ago when I first had DSL: although my modem was in sync, I could not establish a reliable connection. My ISP asked me if I was using the line cord that came with the modem. I was not. It seems that, at high frequencies, a line cord plug or jack that is slightly out of spec (i.e., too small or too large, respectively) will not allow its conductors to make a good, solid connection–the modem will sync, but the signal will be subject to constant drop outs. The problem is not so noticeable when using a telephone at voice frequencies.
-
Can you get line stats from the modem?
Steve
-
A little Caig Deoxit on a Q-tip does wonders for oxidation on electrical contacts. I have not, as yet, replaced my line cord, but I used Deoxit once to clean the RJ11 contacts on the LinITX modem card–I'm not quite where I want to be, likely because I still had to jiggle the RJ11 plug to achieve sync, but as you can see looking at the graph below, things have improved somewhat--I'll have to try a second cleaning. The modem card probably sat on the shelf at the dealer for several years and there was no silica gel (to prevent oxidation) in its package when I received it.
The LinITX modem stats (checked when I initially configured the card) are similar to those achieved by my prior modem, with ca. 17.5Mb/s/1.0Mb/s speed and 11.5/11 dB S/N--the only difference being the downstream attenuation, which was ca. 33 dB instead of ca. 27 dB--the difference may have been due to the oxidized RJ11 contacts (although it has been my experience that different DSL modems sometimes report different stats). I have not tried accessing the stats via pfSense as yet--that will come after I find a complete solution for my line cord problem. My little secret, however, is that I actually work for my ISP in the town in which I live, so I can look at my stats by accessing the DSLAM at my workplace. I'll keep you updated on my progress.
-
My little secret, however, is that I actually work for my ISP in the town in which I live, so I can look at my stats by accessing the DSLAM at my workplace.
Ah, well that would help. ;)
Thanks for the tip on Deoxit I've not tried it. Could be a US only product?Can you access the modem via telnet/ssh? Are there further line stats or error rates etc there? Could be useful for anyone who doesn't have access to their DSLAM. :)
Steve
-
So now I've cleaned both ends of my RJ11 cable plugs and jacks with Deoxit, however, I still have some residual packet loss. I don't think it is the cable, as I experimented with various ones a couple of years back when I also replaced my NID (yes, I did it myself–so I know it was done right), installed a Tii ADSL2+/POTS splitter in the NID, and re-terminated all my phone and DSL wiring (cat 5e) in my house inside a sealed box with punch-down blocks. The residual packet loss problem, therefore, is likely in my ISP's wiring outdoors. I can try lowering my DSL speed, but I somehow don't think that will solve the problem. I likely have the most tweaked DSL line in town, but I'll try to get on my ISP's case about finding a bad splice outdoors.
The major telephone companies here in the Colonies, as you may already be aware, have in recent years shifted their focus entirely from copper landlines to wireless services. The copper is left to degrade on the poles--some of the lines are as old as 70 years (as in the lead cable my ISP recently retired in my town)! The companies just won't spend money to replace their aging copper plants. My ISP has an excellent FTTH service, but it has not deployed it in my town and has halted deploying the service in areas in which it has not already done so in favor of spending all of its money on wireless projects--it is really a rather pitiful situation that our government tolerates in the name of Capitalism.
The DSLAM shows occasional CBC and UBC errors on my line--most often when my telephone rings. I'll keep you posted on my progress.
Oh, and I discovered that I had not fully seated my RJ11 plug in my LinITX modem's RJ11 jack--it's now fully seated and it fits o.k.--sorry for my mistake jonesr!
Here follows a graph of my remaining residual packet loss as it stands this morning:
-
I lowered my DSL download speed this morning at ca. 9:08 am from ca. 15 Mbs to ca. 10 Mb/s to see if it would reduce my packet loss, however, the speed change had the opposite effect–it significantly increased my packet loss (by over an average factor of two)! I wonder what could cause this increase when the speed change served to increase my S/N by ca. 6 dB? Perhaps the source of my packet loss is not my telephone line after all?
-
It could be an issue with apinger itself. Quite a few people have reported that though mostly with ridiculous figures like >100% packet loss!
Do you see packet loss if you just run a ping test?Steve
-
I'm still collecting data, then I'll try the ping test. Here is a graph of when I lowered my download speed to ca. 5 mb/s, attaining a ca. 21.5 dB S/N. Note the continued increase in packet loss as I lower the speed and thereby raise the S/N.
-
Steve:
Doing repeated simple pings to my DSLAM (IP address changed below to disguised it) I get no packet loss:
PING 12.9.74.1 (12.9.74.1): 56 data bytes
64 bytes from 12.9.74.1: icmp_seq=0 ttl=127 time=16.261 ms
64 bytes from 12.9.74.1: icmp_seq=1 ttl=127 time=16.658 ms
64 bytes from 12.9.74.1: icmp_seq=2 ttl=127 time=16.686 ms–- 12.9.74.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.261/16.535/16.686/0.194 ms -
Back to ca. 15 Mb/s with increased power and S/N, both downstream and upstream; this can't be right–it's got to be an apinger problem. Yup, restarting apinger tames its readout:
