1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Tomato for ARM routers

Discussion in 'Tomato Firmware' started by kthaddock, Feb 28, 2014.

  1. MrDoh

    MrDoh Networkin' Nut Member

    I was seeing instablity on 2.4GHz. wireless last night on my laptop after having v122 up a couple of days, going between 3 and 4 bars (out of 5), the connection speed going down to 7Mbps, up to 144Mbps, kind of randomly moving around. Never seen that before...I should mention that my Asus USB-AC56 wireless network adapter is only about 3 feet away from the router, so it always gets a strong signal. I figured that I'd reboot the router and see if that would stabilize the 2.4GHz. wireless. Big mistake, I couldn't get the ping time stabilized again. Since it was late at night and the rest of my family needs their internet early in the morning, I went back to Netgear firmware, which is where I am now. And 2.4GHz. wireless is perfectly stable again.

    Don't know what happened there, but I rebooted a bunch of times, and tried the "draining the power" thing mentioned over in the other thread, and the ping times to the router from a wired computer never did stabilize.

    I'll probably try it all again, and see what happens, but this ping thing is really an issue for me. I see that it isn't for others, they're lucky *smile* (or have the right router). Sounds like the Asus routers may not see this problem, don't know if the above postings are anecdotal or indicative *smile*. I certainly hope that this gets fixed, I really love using tomato firmware, much better than stock firmware.

    Update: Back on v122, I'll see how it goes. As long as I don't have to reboot, things will likely be fine.
     
    Last edited: Sep 3, 2014
  2. Image This

    Image This Reformed Router Member

    Unstable 2.4GHZ is known for the AC56U. I only have the thing for a day now, however I read in many reports and review that it is / was due to the Broadcom Drivers and has never been fixed for some. Maybe you're fell in that honeycomb? I'm not using 2.4GHZ so I can't really tell you how it performs for me.
     
  3. MrDoh

    MrDoh Networkin' Nut Member

    The fact that I don't see this with either stock firmware or DD-WRT, both of which use Broadcom wireless drivers makes me question this. Although stock, dd-wrt, and tomato firmware all use different versions of the Broadcom wireless drivers, so that could be it, I guess *smile*. Anyways, all I'm using 2.4GHz. is for clients that don't support 5GHz., everything else is 5GHz. So I don't have a big investment in 2.4GHz. performance, either.
     
    Last edited: Sep 3, 2014
  4. Image This

    Image This Reformed Router Member

    Well I have to say my 5.8GHZ Transfer Speed sucked as well in Wireless Ethernet Bridge Mode.
    20cm Distance to the Router and below 40% signal with like 144 MBit/s speed instead of 7xx MBit/s +

    I switched back to the Stock Firmware for the meantime. Is DD-WRT running any better?
    If yes, which build are you using ?
     
  5. zatoom

    zatoom Addicted to LI Member

    R7000 with Tomato Firmware 1.28.0000 -122 K26ARM USB AIO-64K And the owncloud 7
    question about ownCloud on the R7000
    Hi, I can not figure out to increase the upload. He now stands at 2 MB? I'm testing to see if everything works.
    The root of my ownCloud is 192.168.2.1/mnt/data/owncloud/
    Where is the variable to adjust that value .. or is it in the apache server .. I do not have an idea.
    Can someone help me on my way ..
    Thanks.
     
  6. MrDoh

    MrDoh Networkin' Nut Member

    If you're asking me, I tried the latest dd-wrt (24865M) build which now has IPv6. However, the IPv6 implementation didn't work for me, so I went back to the latest stock firmware where IPv6 does work for me. Latest stock firmware stayed up for about 2 weeks, and I only took it down to flash Shibby v122, which I'm back on at the moment. IPv6 also works on this *smile*. Still seeing weirdness on 2.4GHz., but I'm not letting it bother me since it doesn't really affect anything that I do where I care about performance.

    The most reliable version of dd-wrt that I found was 24345M with "OLDD". That stayed up for a month while I was on vacation and my router was being used by housesitters and family.
     
  7. shibby20

    shibby20 Network Guru Member

    I know it and working on it :)
     
  8. zatoom

    zatoom Addicted to LI Member

    Thank you, The limit of ownCloud is 10 GB > lib/base.php
     
  9. Dean Peak

    Dean Peak Network Newbie Member

    Is the Network Monitoring now working in Tomato V122?
     
  10. shibby20

    shibby20 Network Guru Member

    network monitor? You mean bandwidth and/or iptraffic monitor? No, not yet.
     
  11. Dean Peak

    Dean Peak Network Newbie Member

    Yes... that is what I was referring to. Thanks for the response!
     
    Bruce Kelley likes this.
  12. jsmiddleton4

    jsmiddleton4 Network Guru Member

    "Is DD-WRT running any better?"

    The pre-musl builds, ones with OLD and NEWDD, of DD-WRT were more like a final releases and stable while the post-musl builds are still more like beta's.

    I suggest going to the kong DD-WRT forum however. This is for Tomato variants.....
     
  13. MrDoh

    MrDoh Networkin' Nut Member

    Kong doesn't have a dd-wrt forum thread any more, but yes, the dd-wrt forum is the appropriate place for the latest full information. I just mentioned my experience, hoped it wasn't too much. So it goes.
     
  14. jsmiddleton4

    jsmiddleton4 Network Guru Member

  15. Marcel Tunks

    Marcel Tunks Networkin' Nut Member

  16. k-man

    k-man Network Newbie Member

    A question regarding USB 3.0 speeds. I searched the forum and didn't really find anything regarding this. I have the AC68U and with Merlin (with wifi interference disabled) the write speed were ~50mb/s. With Shibby 1.22, the max write speed I get is ~15MB/s. I can't find a similar option to disable any interference that affects the usb 3.0 speeds.

    As per the log I notice:

    tomatousb kern.info kernel: [xhci-hub] usb2mode:[0]

    Any help will be appreciated.
     
  17. spykos

    spykos Addicted to LI Member

    Hello everyone.

    Are the wireless status leds on your R7000 working with shibby or raf builds ?
    Do we know the cause of the ping issue ?
     
  18. Dave_iou1

    Dave_iou1 LI Guru Member

    Hi
    I have just purchased a RT-AC68U and i would like the router to automaticly switch off the wireless between defined times at night.

    Could anyone tell me which of the third party firmwares Tomato, Merlin, Kong or DD-WRT has this feature.

    Thank you
     
  19. RMerlin

    RMerlin Network Guru Member

    Both stock and my firmware have a built-in wireless scheduler. No idea about Tomato or DD-WRT, but you could also implement it through a cron job on these two.
     
  20. jnitis

    jnitis Reformed Router Member

    Hi Folks,

    Longtime (6 yrs?) user (and financial supporter) of tomato and tomato shibby here through a whole range of routers going back to the WRT54 and up through three Asus routers with the current model I have in use being the AC68U.

    I absolutely love the firmware but I'm very frustrated with the direction it's been taking in the past 6mo or so. In my experience the WLAN drivers and/or associated components just haven't been stable, period. It started with the whole debacle with the 5GHz radio disappearing from the GUI and only being brought back by taking specific steps. More recently it's been the 80MHz bandwidth option for the 5GHz radio either missing outright in the GUI or not working when selected. Add to this the fact that the router locks up and needs a hard reset while playing around with some of the basic 2.4 or 5GHz radio settings and I've just had it: I've moved back to Merlin's even though I miss the GUI of tomato dearly (the default Asus one is atrocious, I don't know why Merlin touts it as a benefit of his firmware).

    The only time the firmware works 100% is after a thorough NVRAM wipe with all the default radio settings. The second you go in and even so much as change the SSID and password to your own preferred settings the problems begin. Radios disappear (although not recently I must admit), options for the radios disappear and when they haven't disappeared they don't work when selected, and the router locks up. Going back to the main Status page after even setting the SSID and password the bandwidth decreases dramatically. All manner of fiddling with the Advanced settings including the country of operation do little or nothing to alleviate the confusion. The only thing that worked reliably is something along the lines of this which I'd discovered 6mo or so. We should not have to go to those lengths to get basic SSID and password settings sorted out upon a thorough NVRAM wipe.

    While I'm on the subject here's a mini-rant related to those locale settings. Since these are aftermarket firmwares not accountable to any company or government body why aren't these un-crippling options enabled by default? And before you get into patronizing me by explaining RF engineering, machinations of various government regulatory bodies for RF, and etc. please don't bother: I'm a hobbyist electronics and RF guy and spend quite a bit of time playing with software defined radio, antennas, and know the definition of EIRP, etc. I don't care what locale you're in (and I've used these routers recently in three different countries, so have experience to boot) a 500mW little WiFi router isn't going to cause any trouble. If you don't believe me get yourself a waterfall tool and walk around your router and see how quickly the signal fades. Yes I'm aware that generally speaking different bands are reserved for different things in different locales but I don't care what military/weather radar or smart electrical meters from the power company or whatever are nearby, the rules from the regulatory bodies in this respect are far too conservative in general and a WiFi router generally won't interfere. I think it's unreasonable to set rules based on the <1% use cases where they could potentially interfere crippling everyone else's use of the bands. (End rant.)

    Anyway, back to my original question with regards to tomato: What's going on here? My gut feeling is everything went to hell in a hand basket after moving from MIPS to ARM.
     
  21. jerrm

    jerrm Network Guru Member

    I don't know what you expect from the rant. It's obvious from all forum traffic that Tomato ARM still has some issues. Problems with Tomato on ARM should be expected and are documented. Ranting about it is pointless. Tomato has two people working separately on support, on a free time only basis. Their priorities are not likely to be your priorities. It will get better as they have time. Tomato is lucky to have any ARM version at all.
     
    Toastman and Bruce Kelley like this.
  22. jnitis

    jnitis Reformed Router Member

    What I want out of the rant: I'd like to either see a) those settings implemented by default (we are aftermarket hackers accountable to no one after all), or b) a thorough explanation and reasoning on why they aren't.

    And to address the latter portion of your note I guess we have different perspectives. What I see are a ream of unanswered and unaddressed issues posted by users looking for help and subsequently receiving either no reply or a cryptic "yeah, I know about it" or "it was already mentioned" reply which does nothing to help. The result is the user community bumping around in the dark trying to discover solutions alone which is unacceptable (and generally a waste of time).

    A proper solution would be to have a bug tracking database searchable by the community where every feature request, enhancement request, or bug is listed. That way the community doesn't have to waste time fumbling around in the dark when they come across an issue, they can simply search the database and find all relevant info. Other happy byproducts of a bug tracker: a) each item in the database has a priority level associated giving a general idea of when the item will be addressed, and b) it allows the developers to interact with the community in a focused manner about individual bugs. Solutions I'd suggest: bugzilla, google code pages, etc.

    I also don't get the strong deference to the tomato contribs as if we should simply take it or leave it and how dare we raise issues or request information. Free and open source software is nothing new and just because it's free is no reason to sit back and be happy with unstable code or being in the dark about what's being worked on and when it will be released. I could list hundreds or even thousands of FOSS projects as examples where the devs are few, the time they have limited (which is nearly by definition nearly all FOSS projects), the project is free (duh), but the level of support, information and updates provided, and general involvement with the community is absolutely fantastic.

    Keep in mind my background: I am a financial supporter of this project, I've run my own projects, and have contributed bug fixes to many.

    I think we can start with the bug tracking database. From there we can identify the most painful bugs that affect the greatest number of people and then prioritize them and actively involve the community in resolving them. Examples of this would be having people test different builds with potential bug fixes, giving rudimentary debugging instructions to the community so they can work on fixing the problem themselves, etc.

    I'm a lifetime IT guy with reasonable debugging skills, I'd be happy to contribute time to resolve the bugs if basic instructions were provided to assist in narrowing down the workload required (ie, so I don't have to spend hours figuring out where specifically to look for bugs, how to generate debugging output to later analyze, etc.). How to capture kernel panics and save the dumps over the network (or on local flash) would be a good start. Next we'd need some tips on how to debug, troubleshoot, and generally get inside BRCM's wlan drivers. BTW, all of this information is already in the hands of the devs, they just need to document and share it so we can help.
     
    The Master likes this.
  23. jerrm

    jerrm Network Guru Member

    Constructive criticism and bug reports are welcome. Your post contained neither.

    If you want the defaults changed, then make specific suggestions and start a conversation of the pros and cons. No one is going to respond to "the defaults suck," nor should they.

    "We need a bug tracker" posts go back for years. Obviously, it is not something the current devs want to put time into. If you want to start and maintain a bug tracking system, then do it. Shibby had a bug tracker at one point. Admittedly, it was an awful tracker, but there was so much noise that it was useless. Someone needs to step up, get one started, and most importantly maintain it for it to be useful.

    The forums have always worked pretty well for me, I pretty much always get an answer (not always the one I want). I've never felt as if I was bumping around in the dark.

    "Their projects are better than this project" claims are pointless. The grass is always greener...

    I will say we are well past the time for the ARM sources to be in a public repository. I understand it's easier to keep things close when so much is in motion at the beginning, but we've had releases for six months now, and I don't know if so much as a tarball of the ARM sources are available. @shibby20 was quick to point out @bwq518 needed to post sources, it's time to do the same.

    It's not really reasonable to expect instructions on basic debugging practices. Tomato's source is reasonably well laid out. It's Linux, tons of documentation is out there. Get started and ask questions, generally you will get answers, but don't expect a lot of hand holding.
     
    Toastman likes this.
  24. jnitis

    jnitis Reformed Router Member

    My post contained loads of both. Your comment here however accomplishes absolutely nothing other than a personal attack. Now what does that say about your communication style?

    So, basically you agree with everything I said and just have issues with my communication style. That's all well and good but we're not here to discuss communication style, we're here to get things done.

    Defaults: my request still stands as originally worded. Their only effect is to needlessly cripple hardware consumers have already spent good money on. What's happening instead is people are installing the router and firmware, experiencing it not functioning to their expectations or to the best of its inherent abilities, then having to dig around in forums in order to discover a solution. The corporations designing, manufacturing, and marketing these products have to meet (IMO mostly ungrounded) regulatory approvals: aftermarket firmware does not. (Yes, theoretically everyone who is a citizen of any nation with RF regulatory laws also needs to abide by those laws, but I'm simply not getting into that line of discussion as it's a red herring.)

    Alternatively: fix the basic radio settings so enacting the aforementioned defaults isn't required to obtain a basic working router. (This is still a substandard solution given my comments about the RF regulations above but is indeed a compromise. I hate compromises.)

    Bug tracker: one that's setup and maintained by the community alone won't work, the developers involved have to buy in. It's trivial to set one up on Google's infrastructure, we need folks to actually use it as you say. I'm looking for the devs to create one themselves or give a nod that they'll use one someone else creates. Someone creating an empty database is a trivial effort but nonetheless a waste of time.

    Debugging: I believe you misunderstood. I'm not asking for fundamental problem solving tutorials, I'm asking for pointed instruction on how best to debug specific issues people are having with these specific platforms. Each platform has its quirks and the regular developers already have a debug environment that works reliably up and running and can help others to get up to speed quickly by sharing that environment. Furthermore pointed advice on where specifically to look when having issues with regards to this platform. People trying to implement various well known open source software packages generally excluded, I'm talking about issues specifically related to the BRCM wlan drivers and associated platform hardware and quirks.
     
  25. jerrm

    jerrm Network Guru Member

    The original post only restates issues that are all reported already, no new insights or details. What was constructive got lost in the attitude

    Again, the bug tracker discussion goes back years. There are two Tomato devs, for the most part working separately, odds are they aren't going to start it up on their own at this point. Whether the devs buy in is a chicken and egg problem. I'm pretty sure they won't if they think it's more trouble than it's worth. The only chance is to get it going to a point that it is a useful tool for them. If you're willing to commit, ask and make a case for it.

    For debugging, there can't be specific answers without specific questions. I'm pretty sure their entire environment is in the tree - if we ever get the ARM tree.
     
    Toastman and koitsu like this.
  26. jnitis

    jnitis Reformed Router Member

    Attitude, ah yes a little thing that goes a long way indeed. Personality is a good thing. Unless direct personal attacks are involved I don't see anything wrong with everyone bringing their own perspective (including frustration) to the table.

    I believe I made a very clear case (now several posts long) already.

    Questions were clearly outlined in my original note (and two formerly unanswered posts). To repeat myself and for the sake of being pedantic they are as follows:
    1. What is the root cause of, what is being done to resolve, when will it be resolved, and how can any users help to resolve the issues with regards to the WLAN driver which were:
      1. Why is the 5GHz radio disappearing? (appears to be resolved)
      2. Why was the router locking up cold on a frequent basis while in WDS mode? (appears to be resolved)
    2. And are currently:
      1. Why is the state of the wlan driver so perfect upon a fresh flash but immediately degrades the second you try to change any basic wlan radio settings? (Perfect = all radios operating at the widest possible bandwidth at the highest allowable speed as reported by the Status page)
      2. Why does the firmware randomly crash while making basic wlan radio changes?
        1. Furthermore what debugging can be done from a user perspective on this item? What is happening exactly when the firmware locks up? Is it a standard kernel panic? If so, where is the dump file written? Where is the option to change where it's written? If it's not configured by default to write one, where do we enable that option? If it can't write it to the local flash can it be written to a remote debug server over the network or are the BRCM network ICs in a failed state once the kernel panics so that's pointless? or maybe just over an Ethernet connection but not a wireless connection? Is it possible to connect a TTY based serial console to the AC68 (even if soldering is involved) so that we can catch the kernel panics there? Is it not kernel panics causing this in the first place but something else entirely? Can we encapsulate or wrap (trap) the wlan driver in some debugging mode so we catch it crashing and can see its state and re-start it without having a complete router lock-up? If we can get crash dumps (and the debugging symbols) what are some basic things to look for in GDB stack traces when we go to analyze what happened?
      3. Why do the channels and bandwidths of both the radios (but especially the 5GHz one) appear completely inconsistent in the GUI and in operation other than in the virgin NVRAM cleared state?
     
  27. jsmiddleton4

    jsmiddleton4 Network Guru Member

    I'm not a life time IT guy and would not be able to do any serious debugging beyond, "That works, that doesn't". So take this for what its worth.

    Some of what you seeing with the Tomato variant is due to the nature of the beast. The developers can't mess with the Broadcom driver. They have to work with it as it is given to them. Unlike DD-WRT the Tomato variants have not paid for the licensing fees to have full access to the wireless drivers. So whatever they get, they have to live with. I can only imagine trying to build a car around an engine but you can't touch the timing, fuel mixture, orientation, etc., of the engine or even look under the hood.

    But that is a reasonable illustration of what the Tomato variants have to do. My understanding of what is coming with some of the new routers that are a mini-computer within the router are going to make it even harder to deal directly with the engine.

    If you want to get into full debugging I'd say getting involved with DD-WRT community would more likely get you into the depth and details of what it appears you would like to do. And DD-WRT does do more debugging tracking, etc., on-line, maybe more "formal" kind of tracking. Although I'm not sure "formal" is the right word.
     
  28. koitsu

    koitsu Network Guru Member

    I can't speak specifically about ARM in this regard, so take what I'm saying below with regards to MIPS:

    1. Very little debugging can be done by the end-user aside from being meticulous in noting exactly what they do (physical actions).

    2. Router lock-ups (as in you can't even telnet into the unit, for say, a full linear 10 minutes) are even more difficult to debug -- these are often called deadlocks in the kernel world, and they're pretty much the bane of debugging. Programmers dread them because there's nothing to clue them in to what may have been going on (at the kernel level) at that specific moment in time. A lot goes on under the hood that people don't know or think about, and it's all going on simultaneously.

    3. A kernel panic in TomatoUSB causes two things to happen:

    1) a stack trace printed to serial console -- which is not helpful because the firmwares are built with zero debugging symbols in place, thus all you get is a dump of hexadecimal values which cannot easily be correlated with any particular driver or anything within kernel space -- and this is done because debugging symbols increases the size of the firmware by a massive amount
    2) the router will automatically reboot.

    4. There is no dump file written anywhere -- there is no place to write it to. Historically speaking on Linux desktops or servers (these are very different than embedded devices -- I cannot stress this point enough), a kernel panic results in all contents of system memory written to whatever the configured swap device is. It is written in a very "raw" and borderline rude method -- because when a kernel panics, basically you cannot trust the state of any device driver, so there's no guarantee your storage subsystem is even usable (I've witnessed this more times than I can count). So things like swap-on-USB on an embedded firmware might not even work for kernel panics.

    Secondly, again back to Linux desktops/servers, the way a kernel panic is recovered is done by init scripts upon boot -- before enabling swap, either the kernel or a userland process (I forget which -- it's savecore(8) on BSD) scans raw bytes within the start of swap to see if there is a header located there that indicates there's a kernel panic/dump that should extracted from swap. The same program/code begins extracting the raw data from swap, writing it to a file usually somewhere in /var (I don't know where this is on Linux, but on BSD it's under /var/crash). Sometimes the file gets compressed. Once this completed, swap is enabled (like usual) and the system overwrites whatever was previously stored there (usually zeroing out the header that indicated a panic). The system then continues booting and you end up with a crash dump you can analyse with kgdb or similar tools (which also require debugging symbols), along with the need for Linux kernel source code to correlate a location with, hopefully, a line number in a module or piece of kernel source). All of this usually has to be done on the same physical system which crashed -- offloading crash dumps to a third-party system does not often work reliably.

    Now a data point: TomatoUSB does not have any kind of init scripts in place to deal with analysing swap or extracting a panic and writing a dump to a filesystem. TomatoUSB consists of a lot of hard-coded programs thrown together and tied together using duct tape (so-to-speak) to make it all work. Meaning: it's somewhat monolithic and **VERY** little is commented. But my point is there is no systemd, there is no upstart, there is no classic rc.d or SysV init script system like on a desktop or server distro. Welcome to embedded development!

    The one firmware which might offer this is OpenWRT, which has a very solid thought process/baseline mentality of making what feels more like a Linux distro for routers. However, all of the above issues/complexities (esp. debugging symbols) apply there as well. So back to square one.

    5. A kernel panic/crash dump cannot be written to a remote system -- see what I said about device drivers not being reliable if the kernel panics. There is very "legacy" code in place to dump raw system memory to swap. You get to read Linux kernel documentation to figure this out, and I've no idea if it works on MIPS. The place it gets written to is swap. That's just how *IX systems work.

    6. For serial console access: yes, this is possible on some routers, but it requires that 1) you likely void your warranty on your router, and 2) that your router PCB actually have serial header support (in most cases these are just solder points). I've written documentation in the past on how to wire a WRT54GL unit for serial console, but it varies per every single model of router, and some do not even have the headers. Furthermore, it is not an "obvious" serial port like on a PC -- the voltage is different, which requires a voltage regulation chip like the MAX232 be used to deal with this. What comes across the serial port is often low-level, including CFE bootup information (this is pre-kernel, and even "pre-boot" stages -- you can really brick your router messing around in the CFE). The CFE is not documented officially. All of this is "black box" material in a lot of ways. None of this is the fault of any TomatoUSB maintainer/developer.

    7. The Broadcom wireless driver does not support debugging. All such capabilities are removed/taken out from the driver by Broadcom. As others have said (now repeatedly): wl.ko is a binary blob and is tied to a very specific version of Linux kernel version. Maybe ARM is different, but at least on MIPS with Broadcom hardware, there is no documentation for any of it. Even the command-line utility wl that Broadcom provides is not documented, nor is its usage syntax well-written either -- go look at it sometime. Yes, this is what actual corporations push out to the masses. Send your complaints to Broadcom (they will fall on deaf ears, ones dampened with dollar bills).

    8. If you were able to get a firmware loaded with debugging symbols, and a serial port working -- and all of this is assuming you're experiencing a kernel panic and not a deadlock -- you would see function names of code printed. It may be possible to enable the kernel debugger (which is interactive) and work from there live, but I have no experience with that (on BSD yes, on Linux no). You then get to grep through TomatoUSB's Linux kernel source code and try to figure out what exactly happened and why. The possibilities here are nearly endless/limitless. Kernel debugging is not for the meek, and there is no "walkthrough" for how to do it because the scenarios are unpredictable barring "oh, my code did something stupid". Userland debugging is a lot easier because you have a working system/kernel that's available -- if the kernel craps out, you have nothing but yourself. :)

    P.S. -- The next time I see you say something like "... all of this information is already in the hands of the devs, they just need to document and share it so we can help ..." you can safely assume I will never, ever respond to a post of yours again. If you truly think all of this "is in the hands of the devs" you are sadly mistaken. Instead, most of this is just the nature of embedded environments -- debugging is something usually done within the company that makes the product, not by end-users. The desktop/server realm is completely different. None of this has anything to do with any TomatoUSB maintainer or developer.

    And when it comes to wireless drivers, you can blame the companies who design the chips for keeping them closed-source + never releasing documentation + and only offering binary blobs. And then there are times where even open-source doesn't help (case in point, re: certain Atheros wireless chips and the driver on FreeBSD). There are two areas which have been this way consistently for almost 20 years: wireless drivers, and graphics drivers. For whatever reason the companies engineering and designing the chips, ditto with writing said drivers, keep a stronghold on them in fear of their competition "learning" how their stuff works. Don't ask me why it's those two areas that seem to be kept this way, I don't know / don't particular care / don't want to pontificate (it just stresses me out), but the most obvious reason is money (fear of monetary loss, fear of stock price dropping, whatever). But likewise, as I said, even if it was all open-source and the documentation was available and everything was accessible/available, it still requires that someone in-the-know (i.e. an engineer at one of those companies) who has familiarity with the device and chip AND existing driver be involved. Reverse-engineering is painful even with source code, especially with proprietary ICs.

    I don't have anything else to say on the matter past this point, so you won't see any replies from me here on out.
     
    Last edited: Sep 7, 2014
  29. jnitis

    jnitis Reformed Router Member

    My perspective is that I've been a happy tomato user for ~6 years until ARM came along and then at least the portions related to the radio (wlan driver) became extremely unstable so while I'd like to feel it's the nature of the beast I have experience that says otherwise, at least until the platform was switched to ARM.

    To my knowledge WiFi routers going back to at least the mid-2000's were small embedded computers, it's just the CPUs that were embedded changed from MIPS to ARM based designs.

    Thanks for the note about DD-WRT. A housemate made use of it about 10 years ago and it appeared stable at the time but other than that I have no experience with it. My goal is actually not to become heavily involved with an OSS project but more to find out what's going wrong with this one and how we can get sane functionality of the wlan driver restored.
     
  30. jnitis

    jnitis Reformed Router Member

    Yay, a particularly helpful post! Thanks for explaining your perspective on embedded debugging, it's much appreciated. (although see my closing paragraph :()

    Based on the failure states I'm describing what is it most likely to be: deadlock or panic? Is there an easy way to differentiate between a deadlock and a panic? (eg, one allows frames to still be forwarded by the ICs whereas any OS level tasks don't work, etc.) One hint may be your note that a kernel panic will be followed by a reboot and in my experience the router never comes back from the dead. OTOH in my experience kernel panics aren't necessarily followed by a reboot, at least on non-embedded x86 servers. In fact they rarely, if ever, are.

    With regards to the closed source drivers: I don't have the data in front of me but weren't one of the previous generation BRCM drivers reverse engineered? If that's the case is it then possible to reverse engineer the current generation? I recall the reverse engineering process I read about making use of a desktop Linux box with the associated hardware and closed source driver installed. There was a method or tool that would watch any DMA calls (or perhaps any I/O actions of the driver to memory) and log them thus someone reverse engineering the driver could eg. send packets to the hardware and then watch what the driver did in memory and ultimately write code that replicated this behavior.

    Regarding dump data: at one point in my career I came across netdump (which is what I was alluding to earlier when I spoke of writing the dump files across a network). Is nothing like this available for ARM-based embedded Linux? If not, why? Also, another method I'm familiar with for debugging is having a PC connected out of band to the device you want to debug, eg via serial or USB and the dump would be displayed there. Is this not an option?

    I understand debugging in general is difficult work, but if we can obtain the kernel source and debugging symbols my thought is that perhaps we could at least get a hint of what caused the crash.

    Serial console: I have no issues voiding my warranty and regarding the voltage levels of the pins I have a Bus Pirate sitting around here somewhere which should do the trick. I've also got a DMM and scope to measure the voltages if need be. If there isn't documentation on this already perhaps this would be a good place for me to start. Can you link to your article wrt the WRT54GL? (I used that router myself for a number of years.)

    I've spent plenty of time with "wl" and you're right, it's not the most intuitive CLI tool ever written.

    I think we have a misunderstanding of what I meant when I pointed to what's "in the hands" of the devs. I did not mean they signed NDAs with BRCM or otherwise had access to proprietary source code or tools. What I meant was, and granted it is an assumption is that being tomato devs working through years of iterations of various WRT versions from OEMs, BRCM wlan drivers, and their own firmware builds across numerous generations of hardware that they have the necessary tools and processes in place to debug their work. IMO all of this code can't come from a vacuum without some form of trial/error. I'd like to better understand what level of debugging is available to the devs ie what tools and processes they make use of on a regular basis, and moreover how I can replicate those environments so I can help, too.

    With regards to your thread drive-by: that's fine, you're an individual and free to do as you please. That being said I find it really disappointing that someone with some background and knowledge on the subject would choose to not participate in an ongoing discussion about how to improve the state of the project and/or assisting others in getting up to speed with helping. Some quick Googling reveals you yourself felt there was a lack of documentation available for the project and shared some information about how to get a basic build environment up and running for an older release. This means you at least in part share my perspective and that's cool. What's behind your disinterest in helping now?

    In closing I have to say I can't help but read a tone of despair or "resistance is futile!" in your post. You go to great lengths to paint a bleak picture of how it's impossible to get anything done yet various aftermarket firmwares continue to be released (OpenWRT, DD-WRT, (shibby|victek|toastman) tomato, Merlin's, etc.) so something's working somewhere. I'd like to understand how and more to the point understand how I can help to resolve the problems I'm experiencing by digging a little deeper into the inner workings.
     
  31. ipse

    ipse LI Guru Member

    Let me bring the discussion back to Earth :)

    Can some kind soul tell me if 122 is better on R7000 then 121? I have ZERO problems (I don't even see the ping issue anymore) and I'm damn scared to screw up a perfectly good setup.
    I did go through the Changelog and could not find a compelling reason to upgrade. Must be getting old, as a while ago I would have just upgraded and then come here to whine :)
     
  32. thecodemonk

    thecodemonk Connected Client Member

    I'm not having any issues with mine so far. I believe that we can easily resolve the ping issue if you experience it. Both I and another user simply powered down the router, unplugged power, and then turned the power button on, completely draining all the capacitors. Once power was plugged back in, everything seemed to work fine. I haven't had any issues with it since, however I have not had a need to reboot.
     
  33. MrDoh

    MrDoh Networkin' Nut Member

    Note that this doesn't work for everyone, didn't work for me when I tried it. Glad that you have an easy way of dealing with the problem.

    Update: Just tried this again, to see if it was something I did. Didn't work again this time, ping times totally random as usual. Back to Netgear stock firmware. I'm really sorry that this doesn't work for me.
     
    Last edited: Sep 11, 2014
  34. JameZUK

    JameZUK Reformed Router Member

    Did you ever get a copy or compile it?
     
  35. ipse

    ipse LI Guru Member

    I'm probably out of my depth here...but by the looks of it and the fact that the same procedure works for some and not others, I would venture to guess it is hardware related....maybe trending based on mfg date/serial number might show something.
    Mine has been fine (with several reboots/power-cycles) after the initial 2 day freakfest (when the same procedure did not help one bit). Knock on wood, as I could not live with stock- been on Tomato for 10+years now.
     
  36. wit100

    wit100 Networkin' Nut Member

    So can you confirm that AC56U doesn't have the ping issue? Thank you for any more comments you can make.
     
  37. Netwet

    Netwet Reformed Router Member

    The ping issue is definitely a tomato problem and not hw related. When I tested latest shibby the ping issue was there, but have not been able to reproduce it with dd-wrt.
     
  38. MrDoh

    MrDoh Networkin' Nut Member

    That's true, stock firmware has never had the ping time issue here, as well as dd-wrt not having it, so it isn't inherent in the R7000 hardware *smile*. Tomato firmware (which I'm now using again *smile*) just isn't working quite right yet. Tomato core functionality is working well, once the ping time is stabilized after configuring or rebooting. Getting there takes some time, though.
     
    Last edited: Sep 12, 2014
  39. Quad5Ny

    Quad5Ny Connected Client Member

    • Measurements were taken using Wireless Survey Page on a RT-N66U in line of sight, about 12ft away and with no one in the room
    • No wireless clients were connected to the R7000 or 66U, so no beam forming or other variables this is just measuring the TX power of the beacon
    • Antennas of both Routers are in a 'W' shape (outer antennas angled at 45°)
    • Running Shibby's v122 VPN Build
    • 5GHz was -29dBm for every reading [5.180GHz, 80MHz Wide w/Singapore as Country]
    • Keep in mind that every +3dBm is a 2x more powerful signal

    I don't think I am going to do a 5GHz graph seeing as not every country works as expected in Tomato; this is especially true w/80MHz blocks and DFS. -- Just stick with Singapore unless there is some reason you need more than 2 80MHz blocks.

    ---

    [​IMG]
    The closer to 0dBm the stronger the signal

    Special notes: Japan uses dynamic TX power and Korea is listed as -99 because it has NO signal at all!
     
    Last edited: Sep 14, 2014
    Mr.CTT, crashnburn, koitsu and 6 others like this.
  40. AndreDVJ

    AndreDVJ Addicted to LI Member

    Awesome work @Quad5Ny. About Brazil, indeed the best reading I could get was around -30dBm from my WNR3500L V2 (I took measurement from a laptop with a Intel 5100 card). I will try United States later.
     
  41. ipse

    ipse LI Guru Member

    Dammit, I never knew that difference can be so significant between country regulations.
    Thanks for the effort...tested on 2.4GHz and stayed with Anguilla (had to Google it...) and verified the 3dB imp[rovement over US.
     
  42. thedak

    thedak Connected Client Member

    Thanks for the great release. V122 on my R7000 with two weeks uptime now.
     
    Last edited: Sep 22, 2014
  43. wit100

    wit100 Networkin' Nut Member

    So, is Shibby v122 more stable on R7000 or RT-AC68? At the moment, I have my hands on both R7000 and RT-AC68. If I were to put one into production, should I try R7000 or RT-AC68?

    Thank you for any insight!
     
  44. MrDoh

    MrDoh Networkin' Nut Member

    From what I've read here, I'd go with the R7000. I've seen several postings about instability problems on the RT-AC68U, while the only problem I've had with v122 with the R7000 is getting the ping time stabilized initially. Also, if you have to reboot the router, you may or may not have to stabilize the ping time again. But, like I said, once the ping time was stabilized (via reboots), it worked very well, no instability here. Including wireless-ac and IPv6.

    Since I don't have the Asus router, I can't say for sure, but this is what I've observed from reading postings here.
     
  45. WaLLy3K

    WaLLy3K Serious Server Member

    Curl doesn't appear in the nslu2-linux mbwe-bluering repo, yet I still have it on my Asus AC68U. I can only presume it is automatically installed when you install Optware.

    If it's worth anything, I've uploaded my copy here.

    As far as the RT-AC68U goes, it appears to be very stable in my home office environment. The only issues I've had is DHCP not assigning addresses server side, however I feel this is a conflict with Optware packages I have installed rather than the Tomato ARM build.
     

    Attached Files:

  46. LanceMoreland

    LanceMoreland Network Guru Member

    I have over 32 days of up time on two AC68U's running Shibby v122. Not a single problem.
     
  47. wit100

    wit100 Networkin' Nut Member


    Thanks. That's awesome to know. Does the bandwidth monitor work on the RT-AC68? I do need the daily/monthly/ bandwidth usage data.

    Thank you!
     
  48. wit100

    wit100 Networkin' Nut Member

    I have been messing with both R7000 and RT-AC68 and have noticed something that I thought I would share.

    Neither was running on Tomato when I noticed this but I don't think it matters as it appears to be a hardware design thing.

    With RT-AC68 at idle, the CPU temperature (800MHz stock speed) is about 75C. That seems extremely high for not doing anything.

    With R7000 at idle, the CPU temperature (1GHz stock speed) is about 50C or slightly lower. This seems more reasonable.

    This may explain why Asus underclocks the RT-AC68 CPU to 800Hz. It seems like a good idea for Asus to resign the cooling mechanism as to reduce the CPU temperature to improve stability in general.
     
  49. MrDoh

    MrDoh Networkin' Nut Member

    The RT-AC68U is not underclocked at 800MHz., that's the normal speed of the Broadcom chips being used. The R7000 chipset has a normal speed of 1000MHz.

    Just thought I'd mention that...while they both have Broadcom chips, they have different ones.
     
  50. Mad_Clown

    Mad_Clown LI Guru Member

    Is it possible to check the temperature on the R7000 that's running Tomato?
     
  51. Kick29

    Kick29 Network Newbie Member

    Yeah, you can put your hand on it.
     
    Toastman and koitsu like this.
  52. boghea

    boghea Reformed Router Member

    Over a Putty session you can run this command:
    cat /proc/dmu/temperature
    And it will display the temperature.

    It would be nice to have this under status \ overview
     
    Last edited: Oct 2, 2014
  53. rs232

    rs232 Network Guru Member

  54. The Doctor

    The Doctor LI Guru Member

    Mad_Clown and rs232 like this.
  55. Mad_Clown

    Mad_Clown LI Guru Member

    Thanks for the info, I just checked it and it's reading 56c while idle. I agree it would be nice if the temperature was displayed in the overview section.
     
  56. wit100

    wit100 Networkin' Nut Member

    You are right. Good catch! My mistake. Thanks.
     
  57. thedak

    thedak Connected Client Member

  58. RMerlin

    RMerlin Network Guru Member

    To elaborate: the RT-AC68U uses a BCM4708, while the R7000 uses a BCM4709 (same CPU used in the RT-AC87U).
     
  59. AlpineMan

    AlpineMan Network Guru Member

    Any special instructions for flashing R7000 AIO 121 firmware onto the Netgear R6300v2? My understanding is the following:
    1. Flash DD-WRT for R6300v2

    2. Access http://192.168.1.1,administrator -> Upgrade Firmware,and select the R7000 AIO 121 firmware; but do not click on "submit".

    3. Telnet to DD-WRT as root and type the following:
    nvram set http_passwd=admin
    nvram commit

    4. Go back to step #2, and "submit" it


    Thanks!
     
  60. Jack Freeman

    Jack Freeman Connected Client Member



    Yes, there are some issues you need to know, R7000 firmware is not works perfectly on r6300v2, wifi and wan status led is not work, you cannot reset to factory setting, cannot upgrade firmware again or even clean the nvram, unless you have a TTL cable.



    Sent from my iPhone using Tapatalk
     
  61. Nick G Rhodes

    Nick G Rhodes Networkin' Nut Member

    Kong seems to have IMQ and nat acceleration working with QoS

    http://desipro.de/ddwrt/K3-AC-Arm/Changelog:

    "DD-WRT Turboboost (NAT acceleration) with qos support. WAN-LAN routing speed in lab ~800Mbp"

    An lsmod shows xt_IMQ and IMQ devices.

    Running a newer kernel though...

    Cheers, Nick
     
    Last edited: Oct 8, 2014
  62. shibby20

    shibby20 Network Guru Member

    Ddwrt devs have an access to the broadcom sources well they can compile own wl driver with imq support and newer kernel version. We cant.
     
    Nick G Rhodes likes this.
  63. MrDoh

    MrDoh Networkin' Nut Member

    They've taken the HW NAT stuff back out of dd-wrt for the moment in the latest releases, since it was buggy and causing problems. Hopefully it'll be fixed and put back into dd-wrt at some point. Of course, that doesn't change your point that dd-wrt developers can do this kind of thing.
     
    Nick G Rhodes likes this.
  64. xdrag

    xdrag Addicted to LI Member

    A visual on the ping issue...

    [​IMG]

    luckily, I was able to reboot last night (@ 2am) and it seems to have gone away for the time being.
    (the past week, i haven't been able to..)

    Hopefully this is fixed soon. On regards with the dd-wrt dev.. so tomato doesn't have the license to use the source? how much is it?
     
  65. kamaaina

    kamaaina Serious Server Member

    The AC68U seems to run hotter for sure. It seems to be able to run at 1000Mhz, but gets closer to 80C then. The R7000 easily runs 1200 and sometimes even 1400 and stays at a much lower temperature with "normal" household web traffic. I have been running the OpenVPN client on the R7000 for all LAN traffic for a few months now at 1400. No extra fan needed. I recall reeding that Kong hardware stress tested the R7000 and said at 1200 it was fine while at 1400 he was getting errors, so he recommended 1200 as max OC traffic. I still run 1400 (since Tomato ARM came out).
     
  66. kamaaina

    kamaaina Serious Server Member

  67. MrDoh

    MrDoh Networkin' Nut Member

    Just gave it a try...after configuration, rebooted 5 times, ping time didn't get to be stable, so reverted to Netgear stock *sigh*.
     
  68. sandspike

    sandspike LI Guru Member

    What Tool are you using to make that graph? I plan to upgrade to 1.23 and I need to stabilize the ping.
     
  69. Mad_Clown

    Mad_Clown LI Guru Member

    It's very strange that this ping problem is so persistant for some R7000 users. I just updated to v123 and the ping is still good on my R7000.
     
  70. xdrag

    xdrag Addicted to LI Member

    i have an 24/7 ping tool from dslreports (WAN). However, you can do this with any ping graph and run it on lan to your router.
     
  71. MrDoh

    MrDoh Networkin' Nut Member

    Well *smile*, from my point of view, it's very strange that you don't have the problem. Really glad that it's working for you and other R7000 owners that don't have this problem, though, hope that continues. I still have hope, but it's fading with each release.
     
    rs232 likes this.
  72. kamaaina

    kamaaina Serious Server Member

    Just learned there is even a R7500 router with dual-core 1.4 Ghz. I assume there is no Tomato etc. for it working yet. Since I am running a VPN client on my R7000, any extra CPU speed could help. I have the R7000 clocked at 1.4 Ghz, so if one could clock the R7500 at 1.6 or even 1.8 at some time this could be nice. Seems like they are speeding up the router CPUs. Very promising.
     
  73. jsmiddleton4

    jsmiddleton4 Network Guru Member

    Just like always checking out new version. Is the port status thing working? Just checking not complaining. The options/settings are staying visible. Isn't the also some kind of graphic for this thing?
     

    Attached Files:

  74. jsmiddleton4

    jsmiddleton4 Network Guru Member

    Wondering what ant strength/signal strength setting Quad5 was using to run his test? 0 so the radio set to country default? The FW default at 42?

    Yes I know the graph says MAX TX...... but what does that equate to? The setting requires a number......
     
  75. jsmiddleton4

    jsmiddleton4 Network Guru Member

    Based on reports of a few end users the R7500 is not a very good router.
     
  76. jsmiddleton4

    jsmiddleton4 Network Guru Member

    I had connectivity issues with some Apple devices with v122. With V123 all connections solid and fast. So far pings fast and stable. FW is very snappy.

    Seemed to take longer to boot and then reboot so that wireless channels finally showed up than I remember from previous FW versions. Everything did come up and works fine.
     
  77. Karoly

    Karoly Network Newbie Member

    Is there guide to install Optware for Asus RT-N18U?
     
  78. WaLLy3K

    WaLLy3K Serious Server Member

    Run a SSH session (Usually via something like Putty) and run "/usr/sbin/optware-install.sh". That script should guide you through the rest.

    As of Tomato v123, that script should also fix the issue where the NSLU2 repo wasn't being added, therefore being unable to install anything via IPKG. If you're running a prior version, it's probably easiest to upgrade first.

    I also always forget where the optware-install script is located! So if you've got a decent memory, you can run "find / -iname optware-install.sh" and you'll find it. Apparently for me that's easier than remembering it's in /usr/sbin :p
     
    Karoly likes this.
  79. jsmiddleton4

    jsmiddleton4 Network Guru Member

    Never mind....
     
  80. jsmiddleton4

    jsmiddleton4 Network Guru Member

    I don't have a UPS and don't do UPS monitoring. Is there a way to turn this off? Does this look right?
     

    Attached Files:

  81. jsmiddleton4

    jsmiddleton4 Network Guru Member

    .
    Last little thing.

    When I select WPA/WPA2 and TKIP/AES the wireless data flow is jerky. Wish I had a better way to describe it.

    With WPA2 and TKIP/AES no jerkiness, wireless data flow is fast and consistent.
     
  82. rs232

    rs232 Network Guru Member

    Right, I'm not usually the one compaining (e.g. cry until things are resolved by others), but I have to say the current ARM builds are not usable mainly due to the ping issue. Or better if you just browse internet you are probably not fussy about this, but that type of user unlikely needs tomato any ways.
    If you run latency sensitive application like VoIP and gaming ARM builds are pretty much unusable.

    It really surprises me that with so many brains here nobody has ever considered getting to the root cause of the problem, and of course I'm one of those!

    In a positive criticism to improve things: might I suggest a structured, distributed testing plan to see what protocol/function of the build does actually cause the problem? Some people says not to be affected by the ping issue many other (like me) yes. Configs are different can we compare?
    has anybody started this yet? Any contribution needed?

    Second point is: what's the point in releasing new builds, adding functionality but knowing that the above bug and other really basic function like bandwidth monitoring, jumbo frames are now working at all? Is it just me here thinking that ARM has to do what the old RT build was doing before even thinking to add anything else? The more you add the more difficult it is to troubleshoot.

    Third point, can we please make cristal clear to the users that ARM builds are still BETA!?! I see every second day new users registering to this forum just to post over and over again the very same questions about ping and bandwidth monitoring. I think it's fair to let users know this is work in progress thanks to the restless mod developers, however as it stands today the ARM build are not stable. This is not to put pressure on the developers at all, but to make sure people don't buy hardware thinking they can install tomato and do what they were doing yesterday as this is not the case.
    How about changing the title of the threads where ARMs are discussed?

    Fourth point: Bugtracker anywhere?

    my 2 cents
    (and sorry for the harsh Sunday morning tone)
    :)
     
    Bruce Kelley and Mercjoe like this.
  83. VoYaGeRTM

    VoYaGeRTM Reformed Router Member

    Hi all,
    I mostly read here and hardly reply.

    @rs232 I got the R7000, some how after flashing 1 or 2 reboots was enough to fix the ping issue.
    So atleast for me its stable enough to use on a daily basis :)
    And yes i do game, so its pretty important for me also.

    Pinging google from my windows box gives me an average of 16ms, with a max of 19 and min of 16.
    And that is over and IPv6 tunnel.
    Pinging from the same box to R7000 gives me allways less then 1ms, as it should be.

    We could compare configs if you want.

    Greets

    PS I do agree about saying its BETA, I see lots of people dont really read and just post before even searching in this forum.
     
  84. rs232

    rs232 Network Guru Member

    Thanks the offer however I think I'm in the same position where you are. Tomato ARM needs me every couple of days (ping issue) for series of reboots. This is not viable option for me as I spend longtime away from home and need a solid device. That's why I think ARM should be BETA.
     
  85. jerrm

    jerrm Network Guru Member

    Even the potential of needing one reboot renders is useless for my use. Stability and consistency is more important than CPU. AC wireless capability is completely irrelevant for us.

    We'll move on, and will really start looking at ARM at the first of the year, hopefully Tomato will be an option.

    Still wish we'd see entware for ARM.
     
  86. jsmiddleton4

    jsmiddleton4 Network Guru Member

    I'm back to Netgear stock FW. Started out fine with 123 but ended up with lags, etc. Thought it was my wireless security settings. Changed which then led to the router booting. As is normal when changing settings. It was the rebooting that cleared something out and then when back up seemed fine again.

    I don't know what it is, I'm not a programmer. Something gets messed up the longer it runs, memory leak, buffer getting filled up, something......

    All I know is performance in every way is great for about 18 hours. After 18 hours it starts to degrade and within a full 24 I needed to boot. After about 18 hours wireless clients on both 2.4 and 5 ghz channels start having intermittent connectivity issues, pages don't load, etc. Fixed for the time being with a boot.

    I do NOT have that experience with Netgear's stock FW.
     
  87. WaLLy3K

    WaLLy3K Serious Server Member

    It isn't the ARM port as a whole, though. I've got the Asus RT-AC68U and I can't say I've experienced any of the pinging issues that the Netgear R7000 users have. If you're able to link to a post that shows how to reproduce the issue, I'm happy to give it a go - but I do think it's a Netgear and/or R7000 specific issue.
     
  88. Nick G Rhodes

    Nick G Rhodes Networkin' Nut Member

    Are only R7000 users affected by the ping issue (if they get it) ?
     
  89. shibby20

    shibby20 Network Guru Member

    yes, only R7000 but not all users report this issue. My R7000 haven`t. My ping are stable.

    Ping from my NAS (readynas pro4) behind R7000 to Google DNS:

    I have to agree that the problem exists. I had ping issue but it disapear few versions back. Since then my ping is stable and the worst is that i don`t know how and why my ping is stable. :/
     
  90. thedak

    thedak Connected Client Member


    I have a R7000 and been using Shibby since 120. on 122 was up for 32 days without issues and stable ping times. Have since upgraded to v123 and after a few reboots and enabling CTF I have no issues with stable and low (1-2ms) ping times from wired and wireless clients.
     
  91. shibby20

    shibby20 Network Guru Member

    i have CTF disabled.
     
  92. rs232

    rs232 Network Guru Member

    Planned testing is the way forward. Can people take a look at the function matrix as per http://en.wikipedia.org/wiki/Tomato_(firmware)

    and report what function they are using and if they experiencingthe ping problem or not?

    Anything else that needs to be considered fro the list below?

    R7000 shibby 123
    Ping issue experienced: yes
    --------------------
    VLAN - y
    Guest SSID - y
    2.4GHz - y
    5.0GHz - y
    SSH - y
    FTP - n
    SNMP - n
    SD Card -n
    USB - n
    CTF - n
    IPv6 - y
    Captive Portal - n
    ipstat - y
    BW Limiter - n
    NFS Server - n
    BitTorrent Client - n
    PPPoE Server - y
    OpenVPN - y
    DDNS - y
    DNSCrypt - n
    UPnP - y
    QoS - n
    CPU overclock - n
    TOR Project - n
    Siproxd VoIP - n
    Web Server - n
    CIFS - y
    JFFS - n
    Stealth Mode - y (I know it makes no sense but I've found it enabled)

    external script if so what?
    -lean mean adblock
    -p2partisan
     
    Last edited: Oct 13, 2014
  93. MrDoh

    MrDoh Networkin' Nut Member

    Probably need a form for this, to make tracking the data easier, but I have the ping time problem, and have a very simple configuration:

    -Using 2.4 and 5GHz. bands.
    -Configure 5GHz. for wireless-ac (80MHz. channel width), but this last time didn't use it, just configured it. Only wireless-n was in use.
    -Set wireless channels on 2.4GHz. and 5GHz., don't use "Auto".
    -Am using default Comcast IPv6 (DHCPv6-PD). Have two firewall script lines for it, both simple and needed here.
    -CTF is not enabled.
    - Wireless specific settings:
    -----Locale 2.4/5GHz.: US
    -----Preamble: short
    -----Tx Power: 0
    -----SSID's are different for 2.4GHz. and 5GHz., and are broadcast.
    -UPnP disabled, no port forwarding.

    No external scripts, no guest network or added vlans, no VPN use, no CPU overclock, no bit torrents, etc. No use of USB storage, dlna, SD card, etc.

    Very vanilla. Thought about not enabling IPv6, but I doubt that matters.

    Here are the two IPv6 firewall script lines (for the record):

    Code:
    echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/forwarding
    ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i vlan2 -d ff02::1:ff00:0/104 -j DROP
     
    Last edited: Oct 16, 2014
  94. spykos

    spykos Addicted to LI Member

    The ping issue seems to be completely random. I just upgraded to 123 build and after the needed reboots for the 5GHz wireless the ping issue appeared. I also noticed that during the ping problem telnet to the router is very slow. Could this be because of a bad process or something ? Shibby do you know what could be causing this ? On dd-wrt it is working fine.
     
  95. jsmiddleton4

    jsmiddleton4 Network Guru Member

    It feels to me like the router CPU is tied up doing something else. So everything lags and we see long ping times.
     
  96. rs232

    rs232 Network Guru Member

    I'm wondering if this is related to packet loops e.g. between 2.4<->5.0 or anywhere else between interfaces.
    Time to open wireshark...
     
  97. Mr.CTT

    Mr.CTT Serious Server Member

    Sorry to interrupt, i thought my issues would be better put here than starting a new topic. If im in the wrong place please let me know and i will move it.


    Im having a lot of issues with the R7000 Shibby V122 AIO build... I dont think I'm pro but i kind of have some experience.

    First,

    Basic -> Network
    The invert ports button is not working. This totally messed me up and made my life miserable till i figured it out because some of my VLANs don't have dhcp and i was working with 1 laptop that would freeze up when i connected to the non dhcp port

    2nd thing im having a lot of problems with is the Virtual Wireless.
    I can create the virtual wireless access points on both the 2.4 and 5GHZ, but if i try to get more than 2 VLANS to them or anything beyond the setup of 1 VLAN to the physical interfaces, and 1 VLAN to the Virtual Interfaces, the Virtual interface breaks. I can see it but when anything tries to connect to it, it tries then fails giving no explanation and there is nothing in the logs to help that i can see.

    DHCP Info for VLANs
    Router IP Addresses & VLAN
    br0 (LAN0) - 10.10.7.1/24 (Admin)Wireless
    br1 (LAN1) - 10.10.17.1/24 (Net1)Wireless
    br2 (LAN2) - 10.10.27.1/24 (Net2)Wireless
    br3 (LAN3) - 192.168.0.254 (Public) Port 3 only, runs downstream to another router as its uplink

    DHCP Info
    br0 (LAN0) - 10.10.7.1 - 10.10.7.1 (Admin)
    br1 (LAN1) - 10.10.17.1 - 10.10.7.1 (Net1)
    br2 (LAN2) - 10.10.27.1 - 10.10.7.1 (Net2)
    br3 (LAN3) - DHCP Disabled on R7000 (Public)


    What im trying to do...(Working part)

    2.4GHZ
    Eth2(W0) on Br0(LAN0)
    W0.1 on Br1(LAN1)
    5.0GHZ
    Eth3(W1) on Br0(LAN0)
    W1.1 on Br1(LAN1)

    I Break it when I make it

    2.4GHZ
    Eth2(W0) on Br0(LAN0) (can see and connect)
    W0.1 on Br1(LAN1) (can see and connect)
    W0.2 on Br2(LAN2) (can see, cannot connect)
    5.0GHZ
    Eth3(W1) on Br0(LAN0) (can see and connect)
    W1.1 on Br1(LAN1) (can see and connect)
    W1.2 on Br2(LAN2) (can see, cannot connect)

    EDIT
    sorry, I am having trouble locating the new images, ill update on here later with them. Im having a lot more issues than this but i need to do more testing to figure out why everything on br3 cannot connect to the internet.
     
    Last edited: Oct 15, 2014
  98. mrkus

    mrkus Network Newbie Member

    Hi,

    Just want to add some info in regard to the Ping issue on R7000 ARM build, I had the problem and identified it by running smokeping from a wired server on the inside. But after 2-3 reboots it went down to a stable low non fluctuating ping.

    The added info I can give is that there is two strange things that are easily seen with my graphs.

    1. Doing a ping to the internal interface of the router adds up to approx 10ms on the rtt, there is almost no fluctuation above that.

    2. Doing a ping through the router to a fast / well connected server adds approx 20ms, therefore I presume that each interface adds 0-10ms. It looks almost like there is a timeout or queue problem that has a 10ms timeout.

    I have no QOS or BW limiting active, I didn't do any changes of the config between reboots. I only have a few port forwarding, and also using 5Ghz.

    [​IMG]

    [​IMG]

    If there is anything else I can check for or if anyone need any further info from the graphs please let me now.
     
  99. ilovebytes

    ilovebytes Network Newbie Member

    hi how are the chances that we someday say tomato again on linksys routers like the EA6900 - or should i just replace my EA6900 with an ac68u or R7000 ?
     
  100. Gitsum

    Gitsum LI Guru Member

    Anyone know if these ARM vesions will work on the Netgear R8000?
     

Share This Page