Traverse Viking ADSL-2+ Card Problem
-
I am pretty much at my wit's end with the Viking card. I even tried contacting the person who wrote the original BSD driver for the Realtec 8139C+ chip, however, he could only offer a hopeless, albeit amusing, response; for which I, nevertheless, did thank him:
"Of all the gin joints in all the towns in all the world, [Nonsense] had to walk into mine at 11:20:29 on Friday 01 August 2014 and say:
Mr. Paul:
Not knowing where else to go with this problem, I thought I would go to the top.Well, think again. I haven't been a FreeBSD developer on about 10 years now. I can't help you.
-Bill"
So, I have decided to either purchase the LinITX card or use an ISP-provided modem (the latter of which, if possible, I would like to locate at my NID in my garage and power it with PoE so as to attempt to improve DSL S/N).
-
Thanks for the information–please keep it coming--I read your configuration post:
1. Interesting arrangement with the Ethernet port on the card--makes it easier to do initial configuration.
2. I assume that the default logon/password for the card is blank.
Actually I think it was admin, and something like "password" or "1234". It will be in the documentation you receive with the card.
3. My (UTM and LLC) VPI/VCI settings are 0/35 and I will be using the unit in ADSL2+ mode (my ISP is using an Adtran TA-5000 DSLAM). I am unsure of the other DSL settings, or even if they will need to be set, but I can look into the matter. I will be using the router as a simple dumb bridge and let pfSense do all of the other work, including PPPoE.
The default VPI/VCI is 0/38 if I recall, so it won't "just work". Some of the other settings are set to auto, so it may pick it up on its own but I am sure you can configure it for your ISP.
4. I am hoping I will not have to completely reconfigure pfSense. I have saved my current configuration file, however, the Viking card is configured as an re0 device while the new card, according to your information, is configured as a rl0 device. I am hoping that pfSense will recognize the change without having to reset all of my other configuration parameters.
I'm not sure as I have never had to do this, but I think pfSense treats the "WAN" (or any other) interface as more of a configuration profile, and this interface is assigned to a "device". So in theory you would just assign WAN to rl0 rather than re0. I may be using the wrong terminology but you get the idea.
I would research that a bit more as what happened to me in the past was I was forced to redo my interfaces at next boot because the previous device was missing, which as I was without the internet to investigate I ended up doing manually. You may be able to unassign WAN from your re0 before turning your pfSense off to swap cards, or associate WAN temporarily to another device (a VLAN virtual device perhaps, if you are able to), or have both devices available and swap them live, anything to avoid pfSense booting up with a "missing" device that has an interface assigned. For me, hindsight or having more than one PCI slot would have helped me avoid this.
5. I can endure having to reboot pfSense--due to ISP issues--once every couple of weeks or once a month, but having to reboot two to four times per day with the Viking card is getting old.
Yes.. I just had to google increasing pfSense's MBUF last week as I kept having to reboot twice a week.
6. Were you ever able to access the card's GUI from inside of pfSense? It might be convenient for checking line stats. You should still be able to do this with the card set in bridge mode. Steven described a way of doing it with a pfSense configuration to me some time ago. I tried his suggestion with the Viking card, but every time I attempted to access the card, for some strange reason, it completely reset itself and I had to reconfigure the card!
stephenw10 has helped me out directly or indirectly, he's a good'un isn't he? I never tried this, by the time I had it working I hadn't the heart to spend any more time on it. But don't let me dissuade you, as I say I personally learned a lot at the time, you have already done this with your Viking card so I imagine you will have no problems.
7. I am going to contact the vender and see what would be involved in obtaining a brand-new card here in the Colonies.
8. By the way, the documentation and support on the Viking card is also virtually non-existent. Transverse Technologies no longer makes it and is not very good about answering e-mail. I purchased the card from a vendor in Belgium, so it is not as if I can just pick up a phone and chat with him.
This is the card, down to the scanned in minimalist documentation - http://tjworld.net/wiki/Linux/Embedded/Infineon/Danube/ADSL2PCI
The manufacturer's website isn't working for me at the moment but that link provides more information than I ever received in the box! And it says right there in fact, default password is "admin"
Thanks Again!
No problem.
-
I forgot to add, the PC case for the original pfSense box I was using was quite awkward. Intending to pull it out but expecting some resistance, I reached in and grabbed the card with a firm grip.
This is how I discovered the thing gets surprisingly hot. Although I never had a problem with it I jury rigged an 80mm case fan anyway. You can get PCI bracket fans but I'm not sure about low profile PCI as I would need - there is no low profile bracket for the modem before you ask, I just took the entire bracket off.
-
I just received my new LinITX ADSL2+ PCI modem card in the mail yesterday, so I will be configuring and installing it this week. It took twice as long for the U.S. Postal Service to transport it to me from its processing center within 30 miles of my home than it took Royal Mail to ship it from England to the United States.
Back when I was younger, I would have had the card installed and running by now, but I defer to taking my time and doing things patiently and methodically these days–most of the time.
My Supermicro motherboard is mounted in a Supermicro 1U chassis, which features two fans; I installed an ARCI-901A PCI to PCI-e riser card in its PCI-e slot to work with my original Viking PCI modem card--the Viking card also got hot, so I tried to keep a lot of air flowing through the case. I recall that my Viking card came with both full- and half-profile brackets. I forgot which one I used--but my chassis claims it supports the full-profile bracket--I guess I will find out soon enough.
The only hassle I anticipate is having to mount the card so it has power before I configure it via its Ethernet port, and then un-mount it to change its jumper settings, and then mount it again--all due to the fact that the card mounts upside down inside the chassis.
-
Can you not configure it via the pci network connection?
Steve
-
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:
