Traverse Viking ADSL-2+ Card Problem



  • I have been running the 64-bit nanobsd version of pfSense via a Supermicro Atom motherboard in a 1U Supermicro chassis for the past two-and-a-half years now.  When I built the box, I purchased a Traverse Technologies Viking ADSL-2+ card to install in the Supermicro's PCI-e slot via a riser card (at a considerable cost via an overseas retailer).  I made the box this way as an elegant solution for using pfSense as a router/firewall with my 15/1 Mb DSL line.  I am currently running the latest nanobsd version of pfSense.  The problem I have been having, since day one of putting the box together, is that I will randomly lose my WAN connection and the only way to regain it is to do a reboot of pfSense.  It is an odd problem–sometimes I can go as many as 12 days at a time without having to do a reboot, but other days I have to reboot 3-4 times per day.

    The only way I could figure out how to trigger the problem in a controlled experiment was to run an online speed test via speedtest.net--my pfSense box would crash every time I ran the upload test.  I, however, solved the speed test crashing problem by reducing my MTU from 1500 to 1452, but reducing the MTU in this way did not eliminate my random everyday-use crash problem.

    I, of course, have explored this problem, ad nauseam, with my ISP.  When I use an ISP-provided DSL modem, the problem (all but) goes away.  I had originally thought that the matter must be related to a PPPoE issue, so I went down that road in a previous thread in this forum to no avail.  I have just lived with the problem since that time.

    I, however, recently made some improvements to my pfSense box and have decided to once again try to troubleshoot this problem in earnest.  After searching through the pfSense forums and other online resources, I am now suspicious that the problem I am having may have something to do with the Realtec 8139C+ chip on the Viking ADSL-2+ card.  I, of course, have the card configured in pfSense as a WAN re0 device.  I have discovered in my forum reading that the Realtec chip has a history of (BSD driver) problems in pfSense, some of which have been patched in the latest pfSense versions.  Also, I read that the Realtec 8139C+ chip/driver becomes unstable with MTUs set at 1500--that was a clue to me that I had been having a chip problem all along (see above).

    The most informative thread I have discovered concerning the Realtec 8139C+ issue is located here:

    https://forum.pfsense.org/index.php?topic=15669.0

    Firebox pfSense users, thus, have struggled the most with the Realtec 8139C+ chip problem.  The thread I cite, however, is an old one, and I am wondering if anyone has any updated information about fixes for Realtec 8139C+ problems that may be applicable to the latest version of pfSense?  I have solved all of my other issues with pfSense and would like to find a final solution to this one, otherwise, I  may just have to permanently remove my Viking card from my pfSense box and use an external modem instead.

    Any insights . . . Stephen or others?


  • Netgate Administrator

    Personally I've not seen a single issue on my X700 box, just luck I suppose!  ::)
    Like it says in that thread the best guess we ever got to was that the driver/hardware combination was unable to nicely handle odd sized frames. That could include jumbo packets of some sort (>1500) or fragmented packets. The switch it was connected to seemed to make a difference. That's not really an option for you though.

    Have you tried the suggested tweak?:
    @https://forum.pfsense.org/index.php?topic=15669.msg143936#msg143936:

    …setting TCP Offload Engine (not the BCE one) in Systems > Advanced > Tunables to 0 (disabled) has allowed them both to run without issue...

    Steve



  • Thanks for your help.  One of the issues I face is that only one interface in my pfSense box has the Realtec device (my Viking card) while my other interfaces (on my Supermicro motherboard) have Intel devices.

    I'm in the process of trying the tweaks now.  Last night I tried the specific tweak you suggested, "setting TCP Offload Engine (not the BCE one) in Systems > Advanced > Tunables to 0 (disabled)," and this seemed to get rid of the "watchdog timeout" messages in the system log when using the gui interface for too long a period of time, so I was encouraged that maybe the problem was solved; however, the box froze again an hour later and my son rebooted it before I had a chance to look at the system log to see what had happened!

    I'm trying the "disable hardware checksum" tweak now and will let you know what happens.



  • Hi Nonsense,

    You sent me a PM about a different card - http://linitx.com/viewproduct.php?prodid=12181

    I got an email notification but for some reason I can't find the message itself in my PM inbox..

    I am at work so I'm replying in a hurry, but as luck would have it I am upgrading to fibre in a few weeks and will have no need of my card. I would be happy to send it to you in return for a donation to the pfSense project.

    In the meantime please send me the equivalent link of this page for your own ISP - http://support.zen.co.uk/kb/KnowledgebaseArticle.aspx?articleid=11160

    Kind regards.



  • Jonesr:

    Thanks for your offer; however, I wouldn't mind buying a new card.  Basically, I was looking for information concerning your experience with your card, to wit I wrote:

    How has your experience been with your LinITX PCI ADSL card???  Have you had any problems at all with compatibility with pfSense.  I purchased a Viking card some time ago and it has been nothing but a headache (you should be glad you did not purchase it) as the particular Realtec chip in it (different than the one in your card) does not work well with the BSD driver in pfSense (I have random disconnects).  If the card you use works without random disconnects, I'd like to buy one.  I live in the USA, so I would probably have to order it from GB.  Do you know who manufactures the LinITX card?  How easy or hard was it to configure the card?  Did you have to make any special changes to the pfSense advanced settings to accommodate it?

    Lucky you getting a fiber connection!

    Thanks.



  • Expect a non rushed answer over the weekend, sorry.

    How has your experience been with your LinITX PCI ADSL card???

    Very good.

    Have you had any problems at all with compatibility with pfSense.

    Not that I recall.

    I purchased a Viking card some time ago and it has been nothing but a headache (you should be glad you did not purchase it) as the particular Realtec chip in it (different than the one in your card) does not work well with the BSD driver in pfSense (I have random disconnects).  If the card you use works without random disconnects, I'd like to buy one.

    I don't recall it being a problem - I have had several disconnects but nothing to blame on the card, my ISP provided modem/router behaved the same.

    I live in the USA, so I would probably have to order it from GB.  Do you know who manufactures the LinITX card?

    I think I did find their site once, I don't recall who it was but the documentation is almost non existent, I think my other thread you found gave the majority of it, jumper settings etc. LinITX can tell you who makes it, but when I called they agreed that documentation was minimal - the document that comes with it is just enough.

    How easy or hard was it to configure the card?

    Bit of a learning curve for me personally but that doesn't reflect on the card itself :)
    Most of the hard work and time was having to reboot between "PCI Device Mode" and "Standalone Mode" every time I changed something, as I described in the other thread.

    Did you have to make any special changes to the pfSense advanced settings to accommodate it?

    Not that I recall.

    If you get one I have no problem advising you on it. Best advice is do the bare minimum until you get an ADSL sync with your ISP, then let pfSense handle the rest.



  • Stephen:

    I've tried both tweaks now with the Viking card, but I am still getting seemingly random "watchdog timeout."  I am getting tired of manually having to "kick the dog" by rebooting pfSense every time this happens.  I don't think there is anything wrong with my modem card settings–there is little to set besides VPI/VCI, so I don't think the card configuration is causing the packet issue.  I might just go ahead and purchase the other card.



  • Jonesr:

    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.

    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.

    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.

    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.

    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!

    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.

    Thanks Again!


  • Netgate Administrator

    I'm out of suggestions.  :-
    If it were me and I absolutely had to use the card I would start trawling the FreeBSD mailing lists for patch suggestions and try compiling my own driver.
    You could try disabling all the hardware features at the command line. Usually I would suggest putting a switch into the connection but that's not possible here.

    Steve



  • 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.


  • Netgate Administrator

    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!


  • Netgate Administrator

    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.


  • Netgate Administrator

    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.



  • Netgate Administrator

    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.




  • Netgate Administrator

    @Nonsense:

    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?



  • Netgate Administrator

    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:





  • Netgate Administrator

    Try setting apinger to use a different remote address. Preferably something close to you.

    Steve



  • I tried a different IP address in apinger and basically got the same packet loss results.  On the other hand, I tried running the ping tests at dslreports.com and saw no packet loss.  Also, all ISP tests on my DSL line indicate it is stable.  I am trying another, off site, ping test to my IP address and will report back on it when I obtain the data.



  • A 24-hour Ping Test (via dslreports.com) shows zero packet loss in tabulated data and graph (notch down in graph shows transition from Interleaved mode to Fastpath mode):




  • I'll go home and check, I'm not sure if you'd be interested trying a different PCI ADSL modem as I have a case of ones that I use to sell and get a pretty penny for on eBay. I actually just fig them out planning on selling them again for some extra dough. I'll post the model and if your interested cover shipping and one is yours.



  • The card I've got is a Songoma S518 ADSL Card 2005  Rev. C (low profile model with full size bracket), about 3 years ago I was getting over $100 each for them. Your welcome to one if you want to try a different adapter, just cover S&H.


  • Netgate Administrator

    The Sangoma S518 is a real modem, rather than a router/modem on a PCI card. As such it requires a specific driver and I'm not sure one exists for FreeBSD. There is a Linux driver though so it may have been ported.

    Edit: Not listed on the main support site but there is a FreeBSD driver: ftp://ftp.sangoma.com/FreeBSD/wanpipe/
    Not sure if anything newer than FreeBSD 6 exists though.

    Steve


Log in to reply