OpenWRT AR7 platform

Talk about anything you like here: as long as it's technical, doesn't fit into the other categories and is within the rules. Questions and discussions about operating systems, programming, websites, hosting, ADSL etc. are particularly welcome here.
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

OpenWRT AR7 platform

Post by mstombs » Thu Mar 11, 2010 8:57 pm

thechief wrote:While this is all very interesting, may I suggest that the discussion be moved into a more appropriate place (e.g., free chat technical)?
Done:

Have you tried an OpenWRT image yet? - it is cool to see an up-to-date Linux kernel boot on your router, but I have yet to see a new web gui!
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: DSL-2640T updated like a charm

Post by geekgirl » Thu Mar 11, 2010 11:35 pm

mstombs wrote:Re the 0x90 gap - its just the Ti single image standard header. mtd1 points to the kernel offset, take one of the old RouterTech firmware distros and compare in a hex editor the separate kernel image with the single image at offset 0x90.
Thank you!
mstombs wrote:Have you tried an OpenWRT image yet? - it is cool to see an up-to-date Linux kernel boot on your router, but I have yet to see a new web gui!
Be patient, I'm still a n00b ;) Probably later tonight will go for it when I have the net all to myself for testing purposes.

As to the web-interface.. LuCI, the webif of choice for OpenWRT developers, seems very powerful, very expandable feature list (see all luci-app-* package names in the AR7 Package list of the latest stable - 8.09.2 stable branch, for instance)
LuCI is based on Lua, a powerful, fast, lightweight, embeddable scripting language, which is why OpenWRT devs decided to move away from the shell-script-based (though simpler) X-WRT. From a little research, seems LuCI has undergone major improvements over last summer. Read here and prepare to get stunned.. More about luci on the project trac page

Sadly, it's hard to find screenshots of LuCI, let alone up-to-date ones. Here's a link to some basic screenshots from Kamikaze 8.09.1 (one update behind latest stable as of date)
Edit: two more screenies (Realtime stats & QoS page)

Gargoyle on the other hand, draws away from the complexities of LuCI/X-WRT in favor of a much more user-friendly interface, at the expense of less features available. Keep in mind its still a fairly new project, but the current gargoyle screenshots speak for themselves..
See for example the QoS screenshots (15 & 16). Also see screenshot #14 "Bandwidth Quotas", that is just superb. Makes the task of bandwidth allotment by Volume (rather than only rate-limiting) very straightforward for the average end-user, something that even (the dreaded) DD-WRT commercial versions do not offer afaik :mrgreen:

All this, while adhering to real GPL spirit. See the following FAQ section for more on Gargyole's GPL licensing, the minor clarification/exception and the philosophy behind it:
http://www.gargoyle-router.com/wiki/dok ... e_projects
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: DSL-2640T updated like a charm

Post by geekgirl » Sat Mar 13, 2010 2:02 am

OK. now i've tried OpenWRT (8.09.2 / latest stable) with a 2.6.26.8 kernel:

- DSL works just as well, though there's a minor bug in 8.09.2, paricularly w/ PPPoA, that wan interface doesn't auto-start on init, but fixable via a simple patch (affects three files), or manually started via `ifup wan`. The fix (r17527) described in #2781 is most likely committed to latest snapshot, but I doubt it will be backported to 8.09.2 (r18961) as this was allegedly the last update to the 8.09.x release.
- Switch not (yet) natively supported, of course, so cannot setup VLANs through switch page in LuCI.
- Wireless not picked up by default, though seems to be detected by acx driver in init (will investigate this more later):
root@OpenWrt:~# dmesg | grep -i acx
acx: this driver is still EXPERIMENTAL
acx: reading README file and/or Craig's HOWTO is recommended, visit http://acx100.sf.net in case of further questions/discussion
acx: compiled to use 32bit I/O access. I/O timing issues might occur, such as non-working firmware upload. Report them
acx: running on a little-endian CPU
acx: PCI/VLYNQ module v0.3.37 initialized, waiting for cards to probe...
acx: found TI TNETW1350-based wireless network card at vlynq0, irq:80, phymem:0x4000000, mem:0xa4000000
acx: eCPU is already running. reset_dev() FAILED
Default openwrt-ar7-squashfs.bin leaves about 1.4MB of space for jffs partition, of which about 200kb are used (leaving 1.2MB Free allowing to install packages with opkg)
Installed qos-scripts package (which pulls all its dependancies), luci-app-qos (frontend for qos), and a few other packages like luci-app-firewall, luci-app-statistics (pulls rrdtool1 and collectd w/ a few collectd-mod-* packages), luci-app-initmgr, and luci-app-p2pblock (just to see what it does)
Oh, not to forget, 5.6M free on /tmp (tmpfs) and minimum 2.5MB FREE as reported by `free` command (and /proc/mem +988kb inactive) after several hours of uptime with all the above installed / running / actively being used. :mrgreen:

Code: Select all

root@OpenWrt:~# uname -a
Linux OpenWrt 2.6.26.8 #1 Wed Dec 2 15:14:35 UTC 2009 mips unknown
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                    1.6M      1.6M         0 100% /
/dev/root                 1.6M      1.6M         0 100% /rom
tmpfs                     6.2M    596.0k      5.6M   9% /tmp
tmpfs                   512.0k         0    512.0k   0% /dev
/dev/mtdblock4            1.4M      1.2M    220.0k  85% /jffs
mini_fo:/jffs             1.6M      1.6M         0 100% /
root@OpenWrt:~# free
              total         used         free       shared      buffers
  Mem:        12684        10168         2516            0          160
 Swap:            0            0            0
Total:        12684        10168         2516
P2P block, which I later disabled cuz I don't think it will really help if a torrent client started using encryption (or port 80) to bypass blocks:
http://i41.tinypic.com/1586wex.jpg

Default qos config in /etc/config/qos looks pretty good (elegantly simplified in LuCI interface in Network -> QoS):
http://i40.tinypic.com/2w4wwg5.jpg

QoS works WONDERS... My throughput actually increased; prior to using QoS on OpenWRT, I could only get max of 90-94kb/sec download while having severe lags + quite high latencies, now get 106-108kb/sec stable downloads, with negligible increase in latency. De-prioritizing p2p/bittorrent traffic to "bulk" class is also comforting to know I have. Bottom line: Standard Linux QoS (with HFSC+SFQ+IMQ) / Fair queuing is working very very well, and can be setup fairly easily from LuCI as you could see above in the screenshot.

However, I'm still clueless as to how to set (hard) rate limits for certain clients. As the qos-scripts package uses tc along with HFSC+SFQ, I'm unsure how to do this as I would with HTB. `qos-stat` command-line output is quite complex, and re-learning everything will mean a steep curve.

Another thing is, OpenWRT doesnt have a ipt-account package like RouterTech does, and I could not find any decent/recent info on how to accomplish a similar task, without too much pain. To my disappointment, luci-app-statistics isn't much useful (for all the dependencies and the space usage tradeoff):
http://i40.tinypic.com/4vhbph.jpg
http://i39.tinypic.com/fc2m4i.jpg

So I have to say, RouterTech firmware is definitely much more attractive in that regard (and working wifi) :)

Gargoyle in the other hand is much more promising in terms of features/control over bandwidth/QoS, as it offers many options that match some of the very useful features of routertech firmware (like ip accounting usage stats in quota page, and web usage similar to darkstat, etc..)

But... Installing gargoyle is not as straightforward for us people who are on AR7 hardware. While the available binaries in gargoyle for bcm-2.4 should still be mipsel-based - and therefore compatible, I think there is at least one caveat (iirc, something about a virtual kernel package 2.4.35.4-brcm-2.4-1). Also, even though gargoyle's docs on installing it as packages with opkg (on top of currently installed OpenWRT) should take about ~800kb for broadcom-based hardware, even with skipping wireless/ddns/upnp packages, I quickly ran out of the 1.2MB available space and was unable to install the final package (gargoyle) and its dependencies. The reason for that is qos-scripts alone pulls so many packages and takes up its fair share for space on the jffs partiton. I actually had to do `mtd erase mtd4`, reboot, and reconfig my router to get back all the space lost , due to jffs crashing when it reaches very near to 100% usage (opkg remove doesnt actually remove files in this case, it actually end up using more space to say the files are no longer available - since jffs is really only an overlay to the read-only squashfs root)

So I'm probably going to have to look into building OpenWRT (probably latest trunk) + Gargoyle from scratch, for now.. I'm sure Gargoyle project could use 1 more (even semi-) supported architecture.

Hope that satisfies your curiosity, mstombs (it sure did mine) :mrgreen:
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: DSL-2640T updated like a charm

Post by mstombs » Sat Mar 13, 2010 10:46 am

geekgirl wrote:OK. now i've tried OpenWRT (8.09.2 / latest stable) with a 2.6.26.8 kernel:
...
Hope that satisfies your curiosity, mstombs (it sure did mine) :mrgreen:
Wow! The latest svn for OpenWRT AR7 (with atm/dsp 7.05) builds without problem - but I haven't loaded any version on a router for quite a while - and when I did before serial console was necessary to bring the Ethernet port up before could access by network. By pre-selecting essential packages to go into the squashfs image on a self-build you should free up more space in the flash for optional bits. I suspect it is now a 2.6.30+ kernel, but will have to load to check!

dd-wrt and a Tomato mod now both have working wireless on newer Broadcom routers with Linux 2.6 kernel so Openwrt brcm-2.4 is now behind the times (and stuck due to OpenSource Ideals).

[edit] latest OpenWRT svn does not compile for me...
a_big_friend
Novice
Novice
Posts: 14
Joined: Fri Oct 12, 2007 6:33 pm
Location: Italy

Re: DSL-2640T updated like a charm

Post by a_big_friend » Sat Mar 13, 2010 11:09 am

mstombs wrote:
geekgirl wrote:OK. now i've tried OpenWRT (8.09.2 / latest stable) with a 2.6.26.8 kernel:
...
Hope that satisfies your curiosity, mstombs (it sure did mine) :mrgreen:
Wow! The latest svn for OpenWRT AR7 (with atm/dsp 7.05) builds without problem - but I haven't loaded any version on a router for quite a while - and when I did before serial console was necessary to bring the Ethernet port up before could access by network. By pre-selecting essential packages to go into the squashfs image on a self-build you should free up more space in the flash for optional bits. I suspect it is now a 2.6.30+ kernel, but will have to load to check!

dd-wrt and a Tomato mod now both have working wireless on newer Broadcom routers with Linux 2.6 kernel so Openwrt brcm-2.4 is now behind the times (and stuck due to OpenSource Ideals).
I loaded into my D-link G62T the latest OpenWRT from SVN trunk. Also wifi works (Wep only). Se attached kernel log
Attachments
kernellog.zip
Openwrt rev 20118 - Kernel log
(4.22 KiB) Downloaded 717 times
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: DSL-2640T updated like a charm

Post by geekgirl » Sat Mar 13, 2010 3:00 pm

a_big_friend wrote:I loaded into my D-link G62T the latest OpenWRT from SVN trunk. Also wifi works (Wep only). Se attached kernel log
Ah, you have the TNETW1130 ? I thought the 1130 was fully supported in acx-mac80211 (with WPA)?
The 1350 on the other hand, someone claims to have also got it to work with WEP with the acx100 driver, but wasn't able to build acx-mac80211
The wiki status page for the AR7 port says that wireless works in STA mode, so I guess it's still a bit before we can use it in master mode in OpenWRT?
My question now is, if acx-mac80211 could be built successfully (and work these chips), wouldn't it be possible to get the chip(s) working in master mode with hostpad, as a temp workaround?
a_big_friend
Novice
Novice
Posts: 14
Joined: Fri Oct 12, 2007 6:33 pm
Location: Italy

Re: DSL-2640T updated like a charm

Post by a_big_friend » Sat Mar 13, 2010 4:23 pm

geekgirl wrote:
a_big_friend wrote:I loaded into my D-link G62T the latest OpenWRT from SVN trunk. Also wifi works (Wep only). Se attached kernel log
Ah, you have the TNETW1130 ? I thought the 1130 was fully supported in acx-mac80211 (with WPA)?
The 1350 on the other hand, someone claims to have also got it to work with WEP with the acx100 driver, but wasn't able to build acx-mac80211
The wiki status page for the AR7 port says that wireless works in STA mode, so I guess it's still a bit before we can use it in master mode in OpenWRT?
My question now is, if acx-mac80211 could be built successfully (and work these chips), wouldn't it be possible to get the chip(s) working in master mode with hostpad, as a temp workaround?
I've not tried the kmod-acx-mac80211 driver (to select it among the kernel wireless drivers you've to enable in menuconfig the support for broken platforms / packages).
With standard kmod-acx driver my router indeed works also in AP mode, even if configuration of Wlan is still quite far from being user friendly:
1) To bridge Wlan with Lan there's still some bug, so you need an extra command to overcome this: "ifconfig br-lan hw ether <MAC ADDRESS of the WLAN device>"
2) LUCI Wlan setting page is buggy for the WEP configuration. If you edit the configuration with LUCI, then WEP will not work (or for better saying the real configuration won't be what you were expecting). You've to edit the wireless config file manually to properly configure the Wep key
To be honest I've only been using WEP, that is enough for me. I've not even tried WPA to see if it works or not.

The main reason I started to look into Openwrt is for the IPv6 support that it adds (today I still use a combination of the AR7 router as IPv4 router plus an external connected Linux PC as Ipv6 router and I would like to use only the AR7 router for both), but unless there are some specific functions you search and miss in Routertech, Routertech is indeed the best available choice today in terms of stability, easyness of use and functionalities.
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: OpenWRT AR7 platform

Post by mstombs » Sat Mar 13, 2010 8:31 pm

Well I managed to build and load the current svn

Code: Select all

BusyBox v1.15.3 (2010-03-13 18:17:10 GMT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r20176) ------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/# uname -a
Linux OpenWrt 2.6.32.9 #1 Sat Mar 13 18:48:30 GMT 2010 mips GNU/Linux
But still can't see an web gui, because the Ethernet port doesn't seem to work...
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: DSL-2640T updated like a charm

Post by geekgirl » Sat Mar 13, 2010 9:33 pm

a_big_friend wrote:but unless there are some specific functions you search and miss in Routertech, Routertech is indeed the best available choice today in terms of stability, easyness of use and functionalities.
Indeed.. It's still a tough call for me really..

Routertech supports all the hardware quite well, except for the ADM6996M switch, of course (which OpenWRT can't support yet either anyway.. afaik, switches in OpenWRT only supported under broadcom arch), and definitely the ease-of-use, and some cool functionality out-of-the-box that are not standard in any other firmware - like IP Accounting, Web Usage (darkstat), etc..

The only gripe for me right now is the lack of standard linux QoS, or any kind of QoS for that matter, because TI's proprietary QoS (priowrr) is not recommended for use on routers that dont have supported switch - in my (and your) case, an ADM6996M. Matter of fact, QoS menu item in the "Advanced" section is actually hidden - for obvious reasons. Moreover, someone claimed that playing around with priowrr on ADM6996 based router killed one of its ports :?:

To be honest, I don't really care much for TI's proprietary QoS anyhow, and so I cannot be bothered to try and add native support for the ADM6996M in a special build of RouterTech FW (possibly by porting the driver from D-Link's GPL sources). TI's QoS has some serious downfalls, like not being able to set a class to "bounded" to avoid "borrowing" bandwidth from other classes even when it could - as you would normally be able to in standard linux QoS, besides priowrr queues not being very easy to understand / intuitive / logical, as seen from the Mini QoS FAQ here about it. It's already hard enough to really understand - and work effectively with - the complexities of standard linux QoS and all its derivatives (HTB, CBQ, SFQ, RED, HFSC, etc..), even with so much documentation available on LARTC for instance, compared to TI's QoS stuff, not to forget the lack of Layer7 netfilter support for packet marking (via iptables) for QoS matching, which makes the network very vulnerable to super-congestion and high latencies (and the router's resources getting chewed up real fast) when there's an unrestrained p2p or bittorrent client (making lots of connections). :|

One thought I had was dropping TI's QoS support altogether, in favor of standard linux QoS, but that involves some major changes - kernel level, let alone re-adapting the web interface to the new QoS + added functionality, and I'd still be stuck with a 2.4.x kernel. And since memory management (as well as QoS) seems to be much better in 2.6.x (as I've seen from my limited tests with OpenWRT 8.09.2), I ask myself: why bother?

Sure, wireless AP support with acx is still a WiP, but I can live without it for a while. Other functionality such as IP accounting & Web Monitor could also be easily added to other firmwares, or even better, adapting OpenWRT+Gargoyle to AR7. The latter is what I'm still pondering, as there are two options:
1. Sticking with 2.4.x for the proprietary wifi driver from TI (like currently supported broadcom in gargoyle is still locked to 2.4.x also due to proprietary wifi driver)
2. Going with 2.6.x and possibly forgetting about wifi support altogether for now

Any Ideas / suggestions / corrections / criticism, all welcome :)
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12067
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Re: OpenWRT AR7 platform

Post by thechief » Sat Mar 13, 2010 10:37 pm

1. Build the 2.4 kernel with a modern compiler (e.g., a gcc4.x cross-compiler toolchain), and you'll get most of the size and memory optimisation benefits. However, this is not likely to be a trivial task.
2. Porting the ADM6996 driver from Dlink is also not likely to be a trivial exercise - particularly since the kernel code base has significant differences from the Acorp versions on which RT is based.

Either or both would be a worthwhile exercise - so if you're looking for a project to occupy your summer, this would be it!
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: DSL-2640T updated like a charm

Post by geekgirl » Sat Mar 13, 2010 11:38 pm

a_big_friend wrote: To be honest I've only been using WEP, that is enough for me. I've not even tried WPA to see if it works or not.
Only WEP is supported with the "plain" acx driver. WPA is not supported with acx, and you can be sure that it never will... See: http://acx100.sourceforge.net/wiki/ACX

I'd honestly rather not use wireless at all than use it with WEP, knowing that I could crack it within minutes, and knowing what wonderful ranges I can achieve with a tin-cantenna lol.. Though in this case, with the generic antenna on this router, I'm pretty sure its pretty safe given the quarter-arsed range of the thing, especially if you have walls between you and the neighbors :P

And I just realized, WPA support with acx-mac80211 development has only resumed like 2 months ago. It looks very promising, thanks to Oliver Winker, but only for 1100B & 1130 so far, well, and the 1450 (usb), see: http://sourceforge.net/mailarchive/foru ... x100-devel
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Sun Mar 14, 2010 3:31 am

mstombs wrote:But still can't see an web gui, because the Ethernet port doesn't seem to work...
Hmm.. Some questions:

1. What router (and HW version) are we talking about here?
2. What is your exact switch chip in the router?
3. Any particular messages from serial bootlog (like "No PHY Present" or something like that) ?
4. Does this help? https://dev.openwrt.org/ticket/5927 (Note that you can provide a kernel command line with "boot" in pspboot, see last section of "troubleshooting ar7")

I ask because ethernet worked out of the box for me, ADM6996M in DSL-2640T H.W. Ver. B1, on Kamikaze 8.09.2 (r18961). Just cannot configure switch Ports/VLANs of course, as this functionality is only supported on broadcom hardware.

This is the relevant section of my first boot log (over serial), the very first part of init section (right after preinit):

Code: Select all

Please press Enter to activate this console. br-lan: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
PHY: 0:00 - Link is Up - 10/Half
device eth0 entered promiscuous mode
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state
Last edited by geekgirl on Sun Mar 14, 2010 11:18 am, edited 1 time in total.
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Sun Mar 14, 2010 10:11 am

thechief wrote: 2. Porting the ADM6996 driver from Dlink is also not likely to be a trivial exercise - particularly since the kernel code base has significant differences from the Acorp versions on which RT is based.
Nuttin's trivial, brotha :) They both use 2.4.17 MontaVista Linux iirc, and probably same TI CPMAC ethernet driver (I haven't yet double checked, could be wrong). Yet, I don't expect anything to be straightforward. But porting the ADM6996 is not really a priority for me. If I do decide to give it a shot, it will primarily be for ability to setup the switch/VLANs.

I think you misunderstood what I'm trying to accomplish. What I'm trying to say here is that for many people, functional QoS / Traffic prioritization (as well as "bulk" traffic de-prioritization & maybe even limiting) is very important. Allow me to simplify:

1. Current (proprietary TI) QoS implementation does not provide any means to de-prioritize (or rate limit) P2P/bittorrent traffic, simply because these protocols are not limited to specific destination/source ports.

2. To workaround limitations such as #1 (and others related), we need Layer-7 Filtering/matching support in iptables and the kernel. This can be easily accomplished/adapted to RouterTech - by patching iptables, kernel sources, adding needed kernel config & mods. Though I'm not yet informed about any possible cons of L7-filter in 2.4.x when compared to 2.6.x kernel. Of course, there are other other cool stuff we can -optionally- do with this, once implemented, such as accounting by traffic type, think bandwidth graphs sorted by traffic types that you want to do accounting for, etc.. If interested to learn more about this, please review: http://l7-filter.sourceforge.net/HOWTO

3. To be able to do anything useful with the changes proposed in #2, such as bandwidth limiting of "bulk" traffic types, or simply de-prioritization of it, we'd need standard linux QoS. That includes the kernel/kmods (especially stuff like HTB/SFQ/RED), standard "tc" (traffic control) tool from "iproute2" package, and optionally "Ethernet bridging tables" in the kernel + "ebtables" tool if we also need shaping over bridge interfaces.

4. Accomplishing #3 would also solve several other issues, to name a few of which legume (Andy) kindly detailed in the Mini-FAQ QoS thread:
legume wrote:The QOS on routertech uses a TI qdisc priowrr that is not like normal Linux qdiscs. It doesn't actually rate limit so a class with 20% will use all the bandwidth if no other traffic needs it.
..
TI's priowrr qdisc is documented by comments in the source. It has 2 absolute prio - one hidden from the GUI as reserved for voip, but I assume it will work from a script.
..
I tried but couldn't get it to work properly - I don't know why, simple things work, but it's hard to tell without counters what's going on when it doesn't work.
i.e., With Standard Linux QoS:
a. We can allot "max bandwidth" and/or percentage to a class (for any type of traffic we want) to "bounded", so it does not use all bandwidth if no other traffic needs it. Yet, we can also assign other important traffic a "min bandwidth" (guaranteed) and optionally let it "borrow" from other classes, and we can even make very important (or dedicateD) traffic classes "isolated" (does not share).
b. Lots of good documentations/examples/support, no need to dig into proprietary source code and decode cryptic output to try and figure out why something isn't working or how its supposed to work.
c. Predictable results, given a good basic understanding.

A lot of what I mentioned is already implemented in Gargoyle. I actually gave it a dry-run from memdisk just to see how it looks live (though haven't yet actually tried building it for AR7 / testing its actual functionalities). Would love to see this (or similar) in Routertech. This could easily turn into a summer project, but I'm not really interested to invest so much time in this. Perhaps I may just attempt to add basic functionalities (via command line only), and report back with PoC patches/sources/binaries if I do succeed in getting any of this done.
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: OpenWRT AR7 platform

Post by mstombs » Sun Mar 14, 2010 12:24 pm

geekgirl wrote:
mstombs wrote:But still can't see an web gui, because the Ethernet port doesn't seem to work...
Hmm.. Some questions:

1. What router (and HW version) are we talking about here?
2. What is your exact switch chip in the router?
3. Any particular messages from serial bootlog (like "No PHY Present" or something like that) ?
4. Does this help? https://dev.openwrt.org/ticket/5927 (Note that you can provide a kernel command line with "boot" in pspboot, see last section of "troubleshooting ar7")

I ask because ethernet worked out of the box for me, ADM6996M in DSL-2640T H.W. Ver. B1, on Kamikaze 8.09.2 (r18961). Just cannot configure switch Ports/VLANs of course, as this functionality is only supported on broadcom hardware.

This is the relevant section of my first boot log (over serial), the very first part of init section (right after preinit):

Code: Select all

Please press Enter to activate this console. br-lan: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
PHY: 0:00 - Link is Up - 10/Half
device eth0 entered promiscuous mode
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state
I tried an old Linksys ADSL2MUE with updated pspboot bootloader from this site. It does not have a switch (or wifi so should be 'fully supported'!). it has a single Ethernet port, so I think those OpenWRT bugs are very relevant, I guess someone has patched it to assume a switch when the autodetect fails. It has worked before, and serial console is fine on this router - didn't work on another one before. There is a difference in the use of the Ti env var MAC_PORT in different firmwares.

Code: Select all

Fixed MDIO Bus: probed
cpmac-mii: probed
cpmac cpmac.1: no PHY present, falling back to switch mode
cpmac: device eth0 (regs: 08612800, irq: 41, phy: 0:01, mac: 00:12:17:73:00:00)
cpmac: device eth1 (regs: 08610000, irq: 27, phy: 1:1f, mac: 00:12:17:73:00:00)
Registered led device: status
vlynq0: regs 0x08611800, irq 29, mem 0x04000000
vlynq1: regs 0x08611c00, irq 33, mem 0x0c000000
TCP westwood registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
Freeing unused kernel memory: 136k freed
Please be patient, while OpenWrt loads ...
mini_fo: using base directory: /
mini_fo: using storage directory: /jffs
PHY: 0:01 - Link is Up - 100/Full
device eth0 entered promiscuous mode
br-lan: port 1(eth0) entering forwarding state
I can get an arp-response from the modem if I down eth0 and up eth1, confirming it has the hardware misconfigured - it also gets the MAC address wrong - I didn't add those zeros! If I take br-lan down I can get ping to work, and I can now see the web gui, but it crashes when looking at lan dhcp settings, presumably because the lan bridge down!

Guess need to try an older version so can raise an OpenWRT ticket for advice on how to select the correct single Ethernet interface. The last 'released' version kamikaze/8.09.2 works, so it is bug in the cpmac driver introduced since then.
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12067
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Re: OpenWRT AR7 platform

Post by thechief » Sun Mar 14, 2010 4:45 pm

geekgirl wrote:A lot of what I mentioned is already implemented in Gargoyle. I actually gave it a dry-run from memdisk just to see how it looks live (though haven't yet actually tried building it for AR7 / testing its actual functionalities). Would love to see this (or similar) in Routertech. This could easily turn into a summer project, but I'm not really interested to invest so much time in this. Perhaps I may just attempt to add basic functionalities (via command line only), and report back with PoC patches/sources/binaries if I do succeed in getting any of this done.
As always, all useful patches will be gratefully accepted ;)
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
Post Reply