Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- agree on the current mess, and congratulations on working on it :) have you considered, to simplify backwards compatibility, to keep proto "batadv" as it currently is (hardif) and naming "batadv_mesh" the new proto? Am 24. Februar 2019 13:51:13 GMT-03:00 schrieb Sven Eckelmann : >batman-adv allows to configure three different objects: > >* batadv hardif > > - network interface used by batadv meshif to transport the batman-adv >packets > - its master interface is set to the batadv meshif > >* batadv (meshif/softif) > > - virtual interface that emulates a normal 802.3 interface on top > - encapsulates traffic and forwards it via the batadv hardifs > >* batadv vlan > > - potential VLAN ID on top of batadv meshif > - allows filtering of traffic from specific VIDs > >While batadv vlan objects were already represented as an own proto >"batadv_vlan", the batadv meshif could never be fully configured using >/etc/config/network. Instead, parts of its configuration were stored in >/etc/config/batman_adv and some in the interfaces with the "batadv" >proto. > >To increase the confusion, the "batadv" proto wasn't used to define the >batadv meshif but to identify batadv (slave) hardifs. The batman-adv >meshifs were also never created directly but only when a hardif was >configured. The actual modification of the configuration settings was >then >applied using a hotplug script hack. The batadv meshif network >interface >could therefore only be created when an hardif was available and not >manipulated with ifup/ifdown. Also `/etc/init.d/network reload` didn't >modify the batadv meshif interface configuration correctly. > >The "batadv" is now renamed to "batadv_hardif" and a new "batadv" proto >is >used to configure the main (meshif) network interface with all its >configuration. > >A simple network configuration with WiFi & ethernet interfaces and >static >IP on top of bat0 would look like: > > # batadv meshif bat0 > config interface 'bat0' > option proto 'batadv' > option routing_algo 'BATMAN_IV' > option aggregated_ogms 1 > option ap_isolation 0 > option bonding 0 > option fragmentation 1 > #option gw_bandwidth '1/2000' > option gw_mode 'off' > #option gw_sel_class 20 > option log_level 0 > option orig_interval 1000 > option bridge_loop_avoidance 1 > option distributed_arp_table 1 > option multicast_mode 1 > option network_coding 0 > option hop_penalty 30 > option isolation_mark '0x/0x' > ># add *single* wifi-iface with network bat0_hardif_wlan as hardif to >bat0 > config interface 'bat0_hardif_wlan' > option mtu '1536' > option proto 'batadv_hardif' > option master 'bat0' > # option ifname is filled out by the wifi-iface > > # add eth0 as hardif to bat0 > config interface 'bat0_hardif_eth0' > option proto 'batadv_hardif' > option master 'bat0' > option ifname 'eth0' > option mtu '1536' > > # configure IP on bat0 > config interface 'bat0_lan' > option ifname 'bat0' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > >Signed-off-by: Sven Eckelmann >--- >Cc: Matthias Schiffer >Cc: openwrt-devel@lists.openwrt.org >Cc: Gui Iribarren >Cc: Moritz Warning > >Changes depend on https://github.com/openwrt-routing/packages/pull/451 >--- > batman-adv/Makefile | 2 +- > batman-adv/files/etc/config/batman-adv| 20 > .../files/etc/hotplug.d/net/99-batman-adv | 12 -- > .../etc/uci-defaults/99-migrate-batadv_hardif | 97 +++ > batman-adv/files/lib/batman-adv/config.sh | 69 --- > batman-adv/files/lib/netifd/proto/batadv.sh | 112 +++--- > .../files/lib/netifd/proto/batadv_hardif.sh | 40 +++ > 7 files changed, 235 insertions(+), 117 deletions(-) > delete mode 100644 batman-adv/files/etc/config/batman-adv > delete mode 100644 batman-adv/files/etc/hotplug.d/net/99-batman-adv >create mode 100755 >batman-adv/files/etc/uci-defaults/99-migrate-batadv_hardif > delete mode 100644 batman-adv/files/lib/batman-adv/config.sh > create mode 100755 batman-adv/files/lib/netifd/proto/batadv_hardif.sh > >
[OpenWrt-Devel] RFC: merge LibreMesh packages into OpenWrt?
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello folks, we're always looking for ways to get LibreMesh "closer to upstream", and one (old) idea is merging somehow our packages into OpenWrt. (i remember briefly talking this with jow at battlemeshv8 in Porto, but in the end, we lime-devs never actually looked up on how that would happen, until now) Currently we maintain a custom feed git repo at https://github.com/libremesh/lime-packages and what we would like to achieve in the end is that those packages become available in the official downloads.openwrt.org servers, basically. as far as i understand, we have two options (in decreasing order of desirability): 1) make a proposal (PR against this[0]) to include a new feed in feeds.conf.default, uncommented so that the packages inside are by default compiled and published along with other packages (luci, routing, telephony...) 2) alternatively, make a series of pull requests adding each of "our" packages to the standard "packages" feed https://git.openwrt.org/feed/packages.git is there any other option i'm missing, or caveat regarding those two that would help us decide? (i.e. would a PR against feeds.conf.default be acceptable?) [0]: https://github.com/openwrt/openwrt/blob/master/feeds.conf.default --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc2
On 15/06/15 00:15, Luiz Angelo Daros de Luca wrote: Guys, I'm no svn-git mirror expert but is there any chance of having 15.05/openwrt.git branch with full history? Is there a technical limitation/reason for it? The git mirror of svn is a dead-end. I get history only until the branch commit. For example, the first commit in 14.07/openwrt.git is create branch for barrier breaker (from trunk r41863). It would be nice to keep full git history (so the first commit in any branch would be New repository initialized by cvs2svn. I did a ugly workaround creating myself a git branch on openwrt.git at the branch point and merging xx.yy/openwrt.git back into it whenever it gets updated (leaving merge-commits on the way). a cleaner way is using .git/info/grafts http://wiki.openwrt.org/doc/howto/buildroot.exigence#merged_main_repository_into_a_single_git_repository just replace BB with CC and so on (i wasn't aware of this git feature until i came across that openwrt howto) cheers! Also, for a git repo, a branch would be just fine instead of a full git repo (but separated repos is no problem if they share the same history). If it is only a matter of smaller downloads, git clone --depth 1 might do it just fine. Cheers, --- Luiz Angelo Daros de Luca, Me. luizl...@gmail.com mailto:luizl...@gmail.com 2015-06-14 7:09 GMT-03:00 Daniel Golle dan...@makrotopia.org mailto:dan...@makrotopia.org: On Sat, Jun 13, 2015 at 04:21:55PM +0200, Steven Barth wrote: ** Highlights since Barrier Breaker ** ... * Platform and Driver Support ... - New sunxi target for AllWinner A10/A13/A20 family and various boards Please also mention: - New oxnas target for Oxford/PLXTECH NAS782x family and various boards Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kernel changes on recompilation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/10/14 14:31, Baptiste Jonglez wrote: When you activate/deactivate packages in menuconfig, it may modify what gets compiled into the kernel, to add/remove support for the various subsystems needed by the packages you build. This will cause the kernel to be rebuilt with a different package number. If you just rebuild the image without changing anything in menuconfig, I think the kernel package will not be rebuilt. Not sure though, just try and see for yourself :) Hm.. i can contribute a datapoint: if you make a dirclean, without changing anything in the makeconfig or anything else (say, make dirclean ; make ; make dirclean; make) you'll end up with two different kernel-hashes (after step 2 and 4) so there's (in addition to selected-kernel-features and such) some kind of build-date being taken into account for calculating the hash, which gets lost when doing dirclean, somewhere inside build_dir i suppose. cheers! gui Baptiste On Wed, Oct 01, 2014 at 03:43:20PM +0530, Nishant Sharma wrote: Hello members, Although, I am compiling and using custom OpenWRT images since 8 months now, but I am still confused with this particular behaviour. I am using it primarily on x86 Alix APU devices. Everytime I run a make and kernel gets recompiled, it changes the hex value appended to the kernel package name which makes a lot of packages or new modules compiled uninstallable on existing systems through opkg. What is the best practice for doing these kind of things or is there any workaround? Thanks in advance. Regards, Nishant ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJULIsaAAoJEIJqNBvBfxrIX9wQAI987g9ibT2DYo2LoTdGKjrt 1w6m8AHT5xAKLJRlbOLZ0eDeArtryOh+s+rZzOdSAd/++Yh/8cjx3KlX6rI0tqQY cTW49Ghbm23VZaPhIq86y3pJOYN1VdYhk/ZYR4hTHER1lJwiJYl/Ikrhb4X7mhFv m2NXwye+aIAruXlTo4MJ5hGYxxV5XgeAtwgtuaZDW8MtkxBIiNceSziOyaoU6mC0 DBuslTnwNqZbkGoqRuZlkzJRjTtqKtG1CbkDRk9jWJmAhXCfEve5zqkI0wB5dwIi c1F7/+a4SKW8iEQLEDELPEFqW/8rSO5QJL7O+d98LqO/b7kJiYuRfsAeMAdITMGD TX4WPHyE47LSP5DdVolEOkX9YBwRMVFEiC594/unsHx7186k3h/84I0ZYtCs6WBo 106AuOzxcktnLycPPvR4Gj2pUbY0cGMeTgD+Z5+1sBAFDgKMwqUmVGy5NxCFQ39I Va1z0ihqVey1+Bh3YJ86mJ6L02kdaEvc7+vpbtdJnXSRQGSjSK8wmvNjzCkvslJO d3aQa39urJAgZ/flfk+SPvU1ZTr1ohjsmzcCwMq2KZFdr7wcBcQE2YZ1b77UhUcl jdDqGaSUFbjy504UpQaGscjMwZctwT8IWcbePnBsutlNue0a5A1kVnhQoSgPeFCi hxPIp54tbwYZ41YvJyPb =HY70 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] brctl showmacs oneliner
hello there,
i got bored of manually chasing a mac's location, in a big bridged
batadv network, without brctl showmacs command
(cf. http://ask.xmodulo.com/show-mac-learning-table-linux-bridge.html)
(it's not compiled in openwrt's busybox by default for some reason)
so i hacked up a oneliner which perfectly emulates the output
brctl_showmacs () { printf port no\tmac addr\t\tis local?\tageing
timer\n ; hexdump -v -e '5/1 %02x: /1 %02x /1 %x /1 %x 1/4
%i 1/4 \n' /sys/class/net/$1/brforward | awk '{ islocal = $3 ? yes
: no ; printf %3i\t%s\t%s\t\t%8.2f\n,$2,$1,islocal,$4/100 }' ; }
i hope this might be useful as is, for someone else reading this list
it can be copypasted in a running node, and used as
# brctl_showmacs br-lan
sample output: http://pastebin.com/
besides that... is there any slight, ugly chance of getting this
upstream, somewhere?
(maaaybe in /etc/profile alongside these other oneliners?)
[ -x /usr/bin/arp ] || arp() { cat /proc/net/arp; }
or, why is brctl showmacs not enabled by default?
(i'm aware it can be enabled by menuconfig in a custom build)
cheers,
gui
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] disappearing on-link route with RA
On 08/09/14 11:53, Steven Barth wrote: Yeah, the issue was in the tons of work-arounds needed to deal with Linux' onlink-route handling before 3.14. I added another one because they are so nice and likeable. This should hopefully do the trick again, until next time. this time, /me not forgetting to follow up :) Indeed, netifd_2014-09-08-46c569989f984226916fec28dd8ef152a664043e keeps the on-link route fine (versus netifd_2014-08-31-b2dcb02570939d98b92c7c55db1c328693a5d52a) so thanks a lot! gui Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] disappearing on-link route with RA
Hello fine folks, i'm testing bb-rc, compiled by myself from: git://git.openwrt.org/14.07/openwrt.git at exactly this commit: git-svn-id: svn://svn.openwrt.org/openwrt/branches/barrier_breaker@42398 so, a little bit more recent than the published bb-rc3 from http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ and i encounter a behaviour i'm already getting used to :P [0] with network.iface.proto=dhcpv6, the first RA that arrives creates the on-link route correctly (2001:db8::/64 on dev blah) and the second RA, makes it disappear :( leaving only the default route, and producing triangular routing between nodes on the same link-local you might not notice this immediately on a wired LAN, but on a geographically widespread batman-adv mesh network like DeltaLibre, it's the first thing i notice after sysupgrading, and ssh'ing into a node :) root@palmeras:~# ip -6 r default from :: via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 2a00:1508:1:f004::/64 dev br-lan proto static metric 256 fddf:ca97:c78b::/64 dev br-lan proto kernel metric 256 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth0-167 proto kernel metric 256 fe80::/64 dev wlan0_ap proto kernel metric 256 fe80::/64 dev wlan0_adhoc proto kernel metric 256 fe80::/64 dev wlan0_adhoc-167 proto kernel metric 256 root@palmeras:~# rdisc6 br-lan Soliciting ff02::2 (ff02::2) on br-lan... Hop limit : 64 ( 0x40) Stateful address conf.: No Stateful other conf. : No Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 1800 (0x0708) seconds Reachable time: unspecified (0x) Retransmit time : unspecified (0x) Prefix : 2a00:1508:1:f004::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 3600 (0x0e10) seconds Pref. time : 3600 (0x0e10) seconds MTU : 1500 bytes (valid) Source link-layer address: A0:F3:C1:86:04:25 Recursive DNS server : 2a00:1508:1:f004::1 DNS server lifetime : 1200 (0x04b0) seconds from fe80::a2f3:c1ff:fe86:425 root@palmeras:~# ip -6 r default from :: via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 fddf:ca97:c78b::/64 dev br-lan proto kernel metric 256 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth0-167 proto kernel metric 256 fe80::/64 dev wlan0_ap proto kernel metric 256 fe80::/64 dev wlan0_adhoc proto kernel metric 256 fe80::/64 dev wlan0_adhoc-167 proto kernel metric 256 root@palmeras:~# opkg list odhcp6c netifd odhcp6c - 2014-08-25-0300fe7589a1701361735ac068e4b57bb1a1896f root@palmeras:~# opkg list netifd netifd - 2014-08-31-b2dcb02570939d98b92c7c55db1c328693a5d52a [0]: i recall encountering a similar regression twice already, in the last couple of years or so, and in both cases it was promptly fixed by cyrus: much respect for your impressive work on ipv6! /me always thankful :) [0a] in fact, i was just looking for the last report https://lists.openwrt.org/pipermail/openwrt-devel/2014-February/023640.html and I don't recall specifically, but i guess it worked after that fix, (or i would have noticed). Anyway i'm not sure anymore :$ sorry for not following up that original thread, now it's gone from my memory happy to debug this further, provide pcaps, or anything else needed cheers! gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k regression (was: Barrier Breaker timeline?)
On 08/09/14 11:23, John Crispin wrote: On 08/09/2014 16:16, Aaron Z wrote: I am curious if there is a timeline for either RC4 or the final release for Barrier Breaker? The RC3 release announcement said ( https://forum.openwrt.org/viewtopic.php?pid=242292 ) on 31 Jul said Depending on how testing goes we will push the final or RC4 within the next 2 weeks. That is obviously past, any idea on a new timeframe? I need to setup a couple of WNR1043ND access points I need to setup and would prefer to go straight to the final if that is coming in the next week or so. Hi, the test build is done and we fixed the 2 problems that came up. SDK now works properly. all the packages from all feeds build (apart from old.packages which has a fallout of ~15 packages) currently we are waiting on a ath9k regression fix that is being tested just now. once Hi there, could you give some more details about the regression? I spotted today an issue with 1 ap + 1 adhoc VIFs over a single phy, on tl-wdr3500/3600, with mcast_rate=24000 on the adhoc wifi-iface, where the adhoc would not transmit unicast at 802.11n rates, instead staying at G rates or something like that. didn't put much time into it, and it resolved spontaneously at some point, or I issued a wifi reset, can't say for sure, but it was definitely reproduceable after reboot, so I'll dig into it later today or during the week, i'm asking, just in case it's the same issue / regression you're already dealing with? cheers! gui that is in the release branch i will restart the builders and generate BB-final. John Thanks Aaron Z A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert Heinlein, Time Enough for Loveove ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6-question / fe80 / linklocal / uniq?
On 22/07/14 06:50, Bastian Bittorf wrote: when reading http://en.wikipedia.org/wiki/IPv6#Link_local_address it seems to me, that the linklocal-address should be uniq, but here: root@box:~ ip neigh | grep ^'fe80::' | grep lladdr $mac fe80::1cfc:fe65:769:3784 dev wlan0 lladdr 84:b1:53:b2:b8:b3 STALE fe80::cea:3b47:5812:96be dev wlan0 lladdr 84:b1:53:b2:b8:b3 STALE different link-local addresses, same MAC address. nothing wrong about that try doing ip a add fe80::1234/64 dev eth0 in your laptop or wherever; voila! you have an extra, manually-set link-local address, that resolves to the same MAC address (when asked by icmpv6) the uniqueness of the link-local address you mention, means there should not be two different computers/devices with the same ipv6 address on the same collision domain. It does not mean that a host must have only 1 link-local address. why this? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to clone the barrier-breaker rc1 branch.
On 18/07/14 04:48, Alive wrote: Hello, Is there any convenient way to clone Barrier Breaker rc1 branch? Is it as simple as cloning trunk branch with `git clone git://git.openwrt.org/openwrt.git`? Does BB-rc1 have a different branch name, for example barrier-breaker.git or similar? (13:54:57) guii: about the frozen bb-rc tag, there is none AFAICT (13:55:12) guii: but compiling r41580 *should* yield a similar result (13:55:59) p4u: let's hope some core developer creates a tag or so :D (14:03:39) jow_laptop: p4u: branching is planned after rc2 Thanks in advance. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 17/07/14 21:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Hello, thanks for joining the conversation, you might have not spotted this email https://lists.openwrt.org/pipermail/openwrt-devel/2014-July/026813.html as it is now, the situation is actually the opposite of what you're describing, it's more like: Hey, my VoIP calls are failing, as well as PopcornTime videos, since I installed OpenWRT. They were working just fine with stock TPLink firmware Have you got any examples of stock firmware that blocks incoming traffic by default? In this discussion I have only seen talk of two that don't. cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 17/07/14 21:59, Fernando Frediani wrote: Perfect and well said. Really don't see why people still think leaving firewalls opened is a good idea. leaving *hosts* firewalls opened is a really bad idea. Agreed. But openwrt doesn't run on hosts, it runs on network equipment I.e. the building blocks of Internet. Carriers don't block traffic, ISP don't block traffic, and back in the day, CPE equipment didn't block traffic either (think of dialup, or dumb cablemodems which would simply act as a bridge) firewall was a software installed in the computer connected to the cablemodem Then, with the ever increasing quantity of devices vs the evident shortage of IPv4, people started to use NAT, or ISPs started to ship CPEs that would do NAT, which made two-way transparent communication impossible. I find it difficult to argue that NAT success was driven by a security concern, rather than by IP scarcity. :P [1] Fast-forward a few years, we have a new Internet Protocol being widely deployed that solves the address scarcity, and thus makes NAT unnecessary. Now CPEs can work again like transparent devices. ps. RFCs that argue that NAT resulted in a *reduction in security*... [0]: http://tools.ietf.org/rfc/rfc6092.txt , january/2011 Security Considerations The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly used IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks. As noted in the Security Considerations section of [RFC2993], the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here. In particular, it is worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end nodes, in conjunction with the [RFC4864] local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier. [1]: http://tools.ietf.org/rfc/rfc2993.txt , november/2000, 11. Summary NAT advantages - no item about security At the end it will bring more problems than solutions for those using OpenWRT and play against its good reputation. As mentioned before adjusting firewall for specific needs or using UPnP isn't the end of the world. Regards, Fernando On 18/07/2014 01:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
+1 to all benjamin arguments, default openwrt ipv4 firewall basically does: * deny all unsolicited traffic coming from WAN to the router (i.e. it's own host) * masquerade the LAN hosts behind a single, scarce, ipv4 address, on outgoing traffic. * allow *any possible traffic* that involves LAN hosts (LAN-LAN, LAN-Router, Router-LAN, LAN-WAN) There's *no* way to allow incoming unsolicited traffic coming from WAN to LAN hosts, since they have no public ips that can address them. So there hasn't been a decision or a policy so far regarding inbound traffic for LAN hosts, there was simply no such scenario. now, default openwrt ipv6 firewall basically does: * deny all unsolicited traffic coming from WAN to the router (i.e. it's own host) * allow *some* traffic involving LAN hosts (LAN-LAN, LAN-Router, Router-LAN, LAN-WAN) * in addition, deny all unsolicited traffic coming from WAN to any LAN host (i.e. taking a decision on behalf of other hosts) it is an error to consider this last point/decision in line with the ipv4 policy, since as stated, there's no such scenario in SOHO ipv4 nets in other words, i'd say the principle of least privilege has not been applied so far in ipv4 world to LAN hosts, (they were allowed to do everything they could possibly do) so if there was any principle so far, was something along full trust for LAN hosts. Now LAN hosts gained a new freedom, getting inbound traffic addressed at themselves. Following the full trust principle, why block that? (and worst: while at it, break ipv6 main 'selling point' - end-to-end internet!) cheers! gui On 16/07/14 05:53, Benjamin Cama wrote: Le mardi 15 juillet 2014 à 17:43 -0400, Justin Vallon a écrit : I don't think turning off the firewall is a sane default. I don't advise to turn it off for everything. I am trying to find a good compromise. Your arguments based on global addressability are false because IPv4 can be globally addressable, if you want. You can get static ip addresses (or a subnet), turn off NAT, and turn off the firewall - every internal network device will be on the public internet. Yes (even if I don't understand why you are talking about static addressing; it could work with DHCP the same) but you are talking about people who are able to be routed a public IPv4 prefix, which is very few people today, and will be almost nobody in the future because of IPv4 address space depletion. I assume almost every user of OpenWRT is a “home” user and I believe none of them are offered such a possibility by there ISP (well, I happen to have this possibility with my ISP, but it is a very tiny exception, and I don't even use it). You say: A general principle is that a service should not be bound on a globally reachable address if it is not meant to be globally accessible. If my desktop is given an IPv6 address, are all of my services now globally addressable? Yes. If yes, I have opened up all local services (oops). Well, if you didn't want them to be accessible, you have many possibilities: bind it on some non-global address (LL, ULA), restrict it locally (/etc/hosts.deny when appropriate, custom configuration that limit access to some range, etc), use some authentication, configure your firewall appropriately (on the targeted machine or on your router), … The thing here, is to find a _default_: you are imagining a case where every service should be blocked from outside access by default. But I would like my telephony programs, my P2P clients, my local daemons that I run for friends (local git repos, experimental web apps,…), my different servers that listen on different addresses, etc, to be accessible by default. It seems to me that there are far more use cases for allowed access by default than forbidden access. The thing is, these use cases are not very common today because there is no equivalent in IPv4 (practically): you cannot have “accessible by default” in today NATed IPv4. If no, do I need a locally addressable and globally addressable IPv6 space for each device service, so that I can choose which services I consider internal (my printer, my smb share) vs external (my web server)? Yes, this is one possibility. OpenWRT even have by default an ULA prefix configured for delegation on the local network! (BTW, there is a bug that make it configure the /60 on the lan by default, I couldn't trace its origin) Or you could use one of the means I listed. Comprising configuring OpenWRT's firewall. But what should be the default? Is your use case representing what would be globally the right solution? Of course, a lot of people on this ML are thinking in terms of “I can configure my firewall myself”, but this is not the case of the casual users. And I think that in the end, there are far more casual users of OpenWRT that one think if you take into account people that will use your router to access the Internet: these are the ones that will be blocked to
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
adding more wood to baptiste fire... :) On 16/07/14 06:15, Baptiste Jonglez wrote: 2/ Allow inbound traffic in the home gateway's firewall. In an ideal world, this is the best solution, since it leaves all the intelligence to end nodes (in accordance with the end-to-end principle). In practice, it is generally frowned upon for home networks, as people don't have any control on their own end-devices nowadays. This is quite sad, but that's a different story. Note that it is not a all-or-nothing solution: the initial proposition was to only allow UDP ports 1024 by default, not *any* traffic. What if we put it the other way around: enterprises who built end-devices have neglected investing in security measures, comforted by the fact that all these years the de-facto scenario was that inbound connections were technically impossible unless explicit rules were put in place. (port forwards) then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! http://www.networkworld.com/article/2223785/microsoft-subnet/unpatched-trendnet-ip-cameras-still-provide-a-real-time-peeping-tom-paradise.html http://www.forbes.com/sites/kashmirhill/2013/07/26/smart-homes-hack/ if we wanna do something good for the people that don't have any control on their own end-devices, that'd be: leveraging openwrt position to shift the de-facto landscape of SOHO networks, implementing open-by-default ipv6, and thus push the people who *do* have control of those end-devices (manufacturers) implement proper security. 3/ Use a firewall control protocol, so that end devices can request port forwarding. There are several protocols for this: UPnP, NAT-PMP, PCP. This is not ideal from an end-to-end perspective, since a state must be maintained in the home router. If the router reboots, all mappings are lost. Note that PCP deals with this in a mostly reasonable way [1], so it should not matter a lot in practice (not sure about UPnP and NAT-PMP). Additionally, it requires a modification to the applications, but it's not a big modification (we've been doing with IPv4 for years, using UPnP and NAT-PMP). to me, the logic is flawed here: why break existing functionality (free native flow of ipv6 traffic), then implement a control protocol to make it work again on the firewall side, and in the end modify applications to use that protocol? If you're going to modify applications in the first place, then simply bind the services to the correctly scoped ipv6 address. If the concern is about an hypothetic legacy application that assumes the local network is private and trusted, and is suddenly exposed by global ipv6 connectivity... i have yet to find such a case ;) all potentially vulnerable software i come across was a) either written from an ipv4-only perspective and doesn't actually bind to ipv6 addresses at all; or b) evolved to support both protocols but binds to ipv4-only by default ...just my end-2-end-cents, Cheers! gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 16/07/14 12:09, Gert Doering wrote: Hi, On Wed, Jul 16, 2014 at 08:41:50AM -0300, Gui Iribarren wrote: then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! This actually is a somewhat moot arguments. Devices travel today, and while your home network and office network might be behind a firewall, the hotspot you're using while waiting for your train might not be. So with todays devices, every device needs to be able to protect itself (i.e.: host firewall, services only accepting connection from local network, etc. - windows 7 doing a fairly good job with this today). The old model strong firewall, weak devices behind it is just a thing not matching reality anymore... Ah, sorry if irony blurred my position: your point, Gert, is exactly my point :) in other words, we're both on the same side: my arguments are in favour of openwrt having an open ipv6 firewall by default, so to put the policy back into end-devices hands (where it always should have been) Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. proprietary-software personal devices are a special case - granted. putting that aside, i think it's insightful to consider that a person that has admin access to all her mobile devices config (which carries every day), so to publish (or restrict) services at her own will, if and only if the network devices upstream (to which might have no control over) have a default-open firewall. in ipv4 world, there was no discussion: a default-open inbound policy in routers that would let end-hosts decide, was simply not possible. why carry that legacy restriction into the wonderful ipv6 world? chee::rs! gui gert ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to properly add an unreachable route?
On 12/07/14 20:10, Dave Taht wrote:
I have been trying to simplify my babel setup. I have
8 /27s out of a single /24 that I would like not
to have to expose to the universe.
I have 172.21.2.0/27, 172.21.2.64/27 etc
on each of the 8 devices I have.
But there is no need to export each /27, as these
are out of a single /24.
The way to do that is to setup /etc/babel.conf to only
let /24s out...
redistribute ip 0.0.0.0/0 le 24 allow
redistribute local deny
(this can also easily be expressed in the /etc/config/babeld
file)
And at the moment, I add this to /etc/firewall.user
to add the covering route locally.
ip route add unreachable 172.21.2.0/24 proto static
Boom, I go from exporting 16 routes to 1.
Where I'm stuck is on how to express the above line
inside of uci and luci. Luci demands both a specific
interface name and a numeric destination, if you are
trying this via the route method.
If you try the otherwise promising uci newfangled rule method
by adding something like this to /etc/config/network
config rule
option dest '172.21.2.0/24'
option action 'unreachable'
You end up bricking the router's network setup.
mmh..
this is how i set it up with ip on a debian system
ip -6 route add unreachable 2a00:1508:1:f000::/52
and then i add the smaller, more specific prefixes (/64) that i actually
use.
maybe adding a *rule* with action unreachable has an earlier precedence,
and more specific routes will never be read?
citing openwrt wiki: action unreachable: When reaching the rule,
respond with ICMP unreachable messages and abort route lookup
sadly, i don't see how an unreachable type route could be configured
via uci. It seems the config route section is limited to unicast
type routes.
$ ip -6 route help
Usage:
[snip]
ip route { add | del | change | append | replace } ROUTE
[snip]
TYPE := [ unicast | local | broadcast | multicast | throw |
unreachable | prohibit | blackhole | nat ]
so, going back to the rule way, maybe try adding first specific rules
that allow routes to be looked up, and add the unreachable action at
the end?
config rule
option dest '172.21.2.32/27'
option lookup 'main'
config rule
option dest '172.21.2.0/24'
option action 'unreachable'
i'm just hypothesizing, tho
cheers!!
http://wiki.openwrt.org/doc/uci/network#routing.actions
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uhttpd: Cert error sec_error_reused_issuer_and_serial
Hello hackers, so, we've been bumping lately into what seems to be a pretty well known bug, that noone cared enough to fix yet? the symptom of the issue is that after flashing several same-model routers with the same openwrt binary, then accessing them over https, and accepting the self-signed certificate, after a few iterations on different hosts, firefox refuses to connect due to a reused issuer and serial number on the certificate sent by the server (openwrt) the root of the issue is that openwrt generates certificates with px5g, which as far as i dug into, bases the generated serialNumber upon the epoch (with up-to-the-second-precision) same hardware, same binary, and with the same startup date at first boot... the chances of two different routers running the /etc/init.d/uhttpd start at the exact same second are pretty high (in our experience - at least 3 in a lot of 10) routers get the correct date afterwards, with ntpdate, but then it's too late: px5g already generated the certificate with identical serialNumber as the other routers. this is aggravated by a (particularly long standing) bug in firefox https://bugzilla.mozilla.org/show_bug.cgi?id=435013 which makes it impossible to remove such information (already seen issuer+serial) from the browser PKI internal database. chromium overreacts in a comparable way. the poor linksys customers complaining in mozilla's ticket are probably doomed, after 6 years seeing the issue Assigned To: Nobody; OK to take it and work on it :P but maybe we can do our part on openwrt? PX5G X.509 Certificate Generator Utility v0.1 Copyright (c) 2009 Steven Barth ste...@midlink.org Steven, do you think it would possible to add a bit of randomness to the serialNumber generation function? i understand entropy is scarce in embedded devices, especially on first boot, and my C coding skills are null, so i'm hoping someone can throw a pointer here? relevant snippet AFAIU: from feeds/luci/libs/px5g/src/library/x509write.c /* * CertificateSerialNumber ::= INTEGER */ srand((unsigned int) time(NULL)); serial = rand(); if ((ret = asn1_add_int(serial, chain-serial)) != 0) return ret; cheers! gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Few question about compiling your own firmware images
On 24/06/14 22:01, Damian Kaczkowski wrote: On 25 June 2014 01:07, Jonas Liepuonius thinker...@gmail.com mailto:thinker...@gmail.com wrote: 1. Is there a way to preset the default IP address? The default is 192.168.1.1 but I want to change it to something like 10.0.0.1, so that my compiled firmware’s IP address would be that. Yes. 2. Is there a way to pre-include files and folders? Yes. I'm still laughing out loud xD Jonas, one possible way: http://wiki.openwrt.org/doc/howto/obtain.firmware.generate#files.variable cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /var/state/wireless not being updated any more?
On 06/12/2014 09:13 PM, Shankar Unni wrote: Ping? How can I look up the current state of the various wireless interfaces using uci now? http://wiki.openwrt.org/doc/uci/network#determining.linux.interface.names The uci state vars are deprecated and not used anymore for network related information Quoting jow in the forum[0] Use /lib/functions/network.sh: source /lib/functions/network.sh if network_get_ipaddr addr wan; then echo IP is $addr fi [0]: https://forum.openwrt.org/viewtopic.php?pid=203787#p203787 you might also want to look into ubus http://wiki.openwrt.org/doc/techref/ubus cheers! Thanks in advance, On Jun 10, 2014, at 5:09 PM, Shankar Unni shankaru...@netscape.net wrote: I recently updated my tree to a very recent trunk SVN version (40995), and I noticed that my system no longer seems to maintain a /var/state/wireless (UCI state of the wireless interfaces - up/down, interface name, etc.). It used to do so as recently as 38990 (which was the last version I was using). I tracked down the place where it gets updated to the functions set_wifi_up() and set_wifi_down() in /sbin/wifi, but no one seems to actually invoke these functions. Is there a more current way of getting this info (the state of the wifi interface, and its real interface name), via UCI? (Or any other CLI method?) Thanks in advance, -- Shankar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Latest AA introduces a bug: not working as STA when AP is AirOS
On 20/05/14 05:25, Saverio Proto wrote: we upgraded the ninux firmware to the latest OpenWrt AA. We run into a possible bug. When STA is OpenWrt and AP is AirOS we are not able to associate to the Access Point. We tested with the same configuration and device the two versions of the firmware. Here the commits: Bad: 6deba98c3814ca9414ef5f2500c71942b210aa83 Good: 794897c318c3388db57bf0da34e61e0041cf0306 it is too many commits in between to quickly do git bisect. I append the logs and the configuration of the OpenWrt host. Is airMAX enabled on the AirOS side? i was unable to associate from an openwrt trunk r36140 acting as a STA to an airgrid with airOS v5.5.4 acting as AP until i disabled airMAX on the airOS authentication went fine according to logread, but association failed (similar to your logs) i didn't try with an older version tho, just disabled airMax and let it be. cheers! gui Please let me know what kind of information I can share to track down the bug. Anyone had similiar issues ? thanks Saverio May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.23] wlan0: authenticate with 00:15:6d:8e:a8:72 May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.24] wlan0: send auth to 00:15:6d:8e:a8:72 (try 1/3) May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.25] wlan0: authenticated May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.25] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), disabling WMM May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.27] wlan0: associate with 00:15:6d:8e:a8:72 (try 1/3) May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.27] wlan0: RX AssocResp from 00:15:6d:8e:a8:72 (capab=0x401 status=37 aid=15241) May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.28] wlan0: 00:15:6d:8e:a8:72 denied association (code=37) May 19 11:18:58 M5GalliaBramante kern.info kernel: [ 291.30] wlan0: deauthenticating from 00:15:6d:8e:a8:72 by local choice (reason=3) root@M5GalliaBramante:~# uci show wireless wireless.radio0=wifi-device wireless.radio0.type=mac80211 wireless.radio0.hwmode=11na wireless.radio0.distance=1000 wireless.radio0.macaddr=00:27: 22:38:d0:f1 wireless.radio0.ht_capab=SHORT-GI-40 TX-STBC RX-STBC1 DSSS_CCK-40 wireless.radio0.htmode=HT40+ wireless.radio0.noscan=1 wireless.@wifi-iface[0]=wifi-iface wireless.@wifi-iface[0].device=radio0 wireless.@wifi-iface[0].network=backbone wireless.@wifi-iface[0].mode=sta wireless.@wifi-iface[0].ssid=ninux.org wireless.@wifi-iface[0].bssid=00:15:6D:8E:A8:72 wireless.@wifi-iface[0].encryption=none root@M5GalliaBramante:~# This is the log in AirOS side: May 19 13:22:32 wireless: ath0 Sending assoc responce to 00:27:22:38:d0:f1. Status: The request has been declined (37). May 19 13:23:02 wireless: ath0 MLME-AUTH.indication(addr=00:27:22:38:d0:f1) May 19 13:23:02 wireless: ath0 Sending assoc responce to 00:27:22:38:d0:f1. Status: The request has been declined (37). May 19 13:23:32 wireless: ath0 MLME-AUTH.indication(addr=00:27:22:38:d0:f1) May 19 13:23:32 wireless: ath0 Sending assoc responce to 00:27:22:38:d0:f1. Status: The request has been declined (37). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [luci] Autologin if root password is empty, to improve UX flow on first access.
Current experience is at the very least confusing, first there's a (otherwise useful) warning dialog, with a link that (unless you login beforehand) only rewrites the url but shows the same login page; where you're supposed to just push enter, but with no instructions whatsoever. Get rid of this intermediate step, with a conditional javascript form.submit() Signed-off-by: nicoechaniz nicoecha...@altermundi.net Tested-by: Gui Iribarren g...@altermundi.net --- modules/admin-core/luasrc/view/sysauth.htm | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/modules/admin-core/luasrc/view/sysauth.htm b/modules/admin-core/luasrc/view/sysauth.htm index 7c39f0d..a3c7e69 100644 --- a/modules/admin-core/luasrc/view/sysauth.htm +++ b/modules/admin-core/luasrc/view/sysauth.htm @@ -13,7 +13,7 @@ You may obtain a copy of the License at %+header% -form method=post action=%=pcdata(luci.http.getenv(REQUEST_URI))% +form name=login method=post action=%=pcdata(luci.http.getenv(REQUEST_URI))% div class=cbi-map h2a id=content name=content%:Authorization Required%/a/h2 div class=cbi-map-descr @@ -50,6 +50,12 @@ You may obtain a copy of the License at input.focus(); //]]/script +%- if luci.sys.process.info(uid) == 0 and luci.sys.user.getuser(root) and not luci.sys.user.getpasswd(root) then -% +script type=text/javascript//![CDATA[ + document.login.submit() +//]]/script +%- end -% + % local uci = require luci.model.uci.cursor() local fs = require nixio.fs -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Decentralized Chat Application
On 03/25/2014 03:19 PM, Justyn wrote: Hello list, I'm currently running a few wireless nodes (Ubiquiti PicoStations) with OpenWrt to form an 802.11s mesh network. beware bandwidth degradation on single-radio mesh nodes. https://startpage.com/do/search?q=bandwidth+degradation+on+single-radio+mesh+nodes I'm also interested in writing a completely decentralized multicast chat application and interfacing it with LuCI. So I've saved up some questions that I'd appreciate if anyone skimmed over and could provide some help on a couple things: check out * http://bmx6.net sms plugin which piggybacks into bmx6 packets and does what you envision, but in a bmx6 mesh. * http://qmp.cat has a PoC implementation of your chat idea using bmx6 * alfred, which does something equivalent on a pure link-local (be it wired, made with batman-adv magic, or -hipotetically- 802.11s) http://www.open-mesh.org/projects/alfred/ cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dropbear: update to 2014.63
On 03/13/2014 03:15 AM, Catalin Patulea wrote:
ping??
+1
2014.63 also fixes the brown-paper-bag bug that prevented from doing ssh
to link-local addresses, since the '%' operator had been (incorrectly)
reassigned.
On Sat, Mar 1, 2014 at 4:05 AM, Catalin Patulea c...@vv.carleton.ca wrote:
ping
On Mon, Feb 24, 2014 at 1:02 AM, Catalin Patulea c...@vv.carleton.ca wrote:
Upstream changelog:
https://matt.ucc.asn.au/dropbear/CHANGES
This adds elliptic curve cryptography (ECC) support as an option, disabled
by default.
dropbear mips 34kc uClibc binary size:
before: 161,672 bytes
after, without ECC (default): 164,968
after, with ECC: 198,008
Signed-off-by: Catalin Patulea c...@vv.carleton.ca
---
package/network/services/dropbear/Config.in| 27 ++
package/network/services/dropbear/Makefile | 24 ++--
.../dropbear/patches/100-pubkey_path.patch |4 +--
.../dropbear/patches/110-change_user.patch |2 +-
.../dropbear/patches/120-openwrt_options.patch | 21 --
.../dropbear/patches/140-disable_assert.patch |2 +-
.../patches/150-dbconvert_standalone.patch |6 ++--
.../dropbear/patches/200-lcrypt_bsdfix.patch | 29
.../dropbear/patches/500-set-default-path.patch|2 +-
9 files changed, 63 insertions(+), 54 deletions(-)
create mode 100644 package/network/services/dropbear/Config.in
delete mode 100644
package/network/services/dropbear/patches/200-lcrypt_bsdfix.patch
diff --git a/package/network/services/dropbear/Config.in
b/package/network/services/dropbear/Config.in
new file mode 100644
index 000..e2a7610
--- /dev/null
+++ b/package/network/services/dropbear/Config.in
@@ -0,0 +1,27 @@
+menu Configuration
+ depends on PACKAGE_dropbear
+
+config DROPBEAR_ECC
+ bool Elliptic curve cryptography (ECC)
+ default n
+ help
+ Enables elliptic curve cryptography (ECC) support in key
exchange and public key
+ authentication.
+
+ Key exchange algorithms:
+ ecdh-sha2-nistp256
+ ecdh-sha2-nistp384
+ ecdh-sha2-nistp521
+ curve25519-sha...@libssh.org
+
+ Public key algorithms:
+ ecdsa-sha2-nistp256
+ ecdsa-sha2-nistp384
+ ecdsa-sha2-nistp521
+
+ Does not generate ECC host keys by default (ECC key exchange
will not be used,
+ only ECC public key auth).
+
+ Increases binary size by about 36 kB (MIPS).
+
+endmenu
diff --git a/package/network/services/dropbear/Makefile
b/package/network/services/dropbear/Makefile
index 02be761..692199e 100644
--- a/package/network/services/dropbear/Makefile
+++ b/package/network/services/dropbear/Makefile
@@ -8,26 +8,32 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=dropbear
-PKG_VERSION:=2013.59
+PKG_VERSION:=2014.63
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:= \
http://matt.ucc.asn.au/dropbear/releases/ \
https://dropbear.nl/mirror/releases/
-PKG_MD5SUM:=6c1e6c2c297f4034488ffc95e8b7e6e9
+PKG_MD5SUM:=7066bb9a2da708f3ed06314fdc9c47fd
PKG_LICENSE:=MIT
PKG_LICENSE_FILES:=LICENSE libtomcrypt/LICENSE libtommath/LICENSE
PKG_BUILD_PARALLEL:=1
+PKG_CONFIG_DEPENDS:=CONFIG_DROPBEAR_ECC
+
include $(INCLUDE_DIR)/package.mk
define Package/dropbear/Default
URL:=http://matt.ucc.asn.au/dropbear/
endef
+define Package/dropbear/config
+ source $(SOURCE)/Config.in
+endef
+
define Package/dropbear
$(call Package/dropbear/Default)
SECTION:=net
@@ -72,6 +78,20 @@ CONFIGURE_ARGS += \
TARGET_CFLAGS += -DARGTYPE=3 -ffunction-sections -fdata-sections
TARGET_LDFLAGS += -Wl,--gc-sections
+define Build/Prepare
+ $(call Build/Prepare/Default)
+ # Enforce that all replacements are made, otherwise options.h has
changed
+ # format and this logic is broken.
+ for OPTION in DROPBEAR_ECDSA DROPBEAR_ECDH DROPBEAR_CURVE25519; do \
+ awk 'BEGIN { rc = 1 } \
+ /'OPTION'/ { 0 = $(if $(CONFIG_DROPBEAR_ECC),,// )#define
'OPTION'; rc = 0 } \
+ { print } \
+ END { exit(rc) }' $(PKG_BUILD_DIR)/options.h \
+ $(PKG_BUILD_DIR)/options.h.new \
+ mv $(PKG_BUILD_DIR)/options.h.new $(PKG_BUILD_DIR)/options.h || exit
1; \
+ done
+endef
+
define Build/Compile
+$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
$(TARGET_CONFIGURE_OPTS) \
diff --git a/package/network/services/dropbear/patches/100-pubkey_path.patch
b/package/network/services/dropbear/patches/100-pubkey_path.patch
index c1802f5..456874b 100644
--- a/package/network/services/dropbear/patches/100-pubkey_path.patch
+++ b/package/network/services/dropbear/patches/100-pubkey_path.patch
@@ -1,6 +1,6 @@
--- a/svr-authpubkey.c
+++ b/svr-authpubkey.c
-@@ -209,17
[OpenWrt-Devel] [REGRESSION] netifd: IPv6 RA on-link route disappearing
Hello great devs, looks like something broke recently on trunk, regarding IPv6 RA handling (proto=dhcpv6) when an interface receives a router advertisement with on-link bit set, it correctly adds the default via, as well as a static route to the local (on-link) network but after some seconds (maybe a minute) that static route disappears, which makes the host use the default via (unnecessarily) to reach other hosts on the local segment. it worked fine with netifd_2013-12-29, albeit the routing table approach was different (it used a separate table) what follows is an insightful log taken from trunk r39428 root@OpenWrt:~# rdisc6 eth1 Soliciting ff02::2 (ff02::2) on eth1... Hop limit : 64 ( 0x40) Stateful address conf.: No Stateful other conf. : No Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 1800 (0x0708) seconds Reachable time: unspecified (0x) Retransmit time : unspecified (0x) Prefix : 2a00:1508:1:f004::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 3600 (0x0e10) seconds Pref. time : 3600 (0x0e10) seconds MTU : 1500 bytes (valid) Source link-layer address: 90:F6:52:BB:EC:AD Recursive DNS server : 2a00:1508:1:f004::1 DNS server lifetime : 1200 (0x04b0) seconds from fe80::92f6:52ff:febb:ecad root@OpenWrt:~# ip -6 r default from :: via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 2a00:1508:1:f004::/64 dev eth1 proto static metric 256 fd03:9cbd:8bca::/60 dev br-lan proto kernel metric 256 unreachable fd03:9cbd:8bca::/48 dev lo proto static metric 2147483647 error -128 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth1 proto kernel metric 256 ### wait a dozen seconds, no more than a minute, and check routing table again: root@OpenWrt:~# ip -6 r default from :: via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 fd03:9cbd:8bca::/60 dev br-lan proto kernel metric 256 unreachable fd03:9cbd:8bca::/48 dev lo proto static metric 2147483647 error -128 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth1 proto kernel metric 256 root@OpenWrt:~# opkg install /tmp/netifd_2013-12-29-7d79d0a8aa5a5b4c1ed987af119356438d98fe7b_ar71xx.ipk --force-downgrade Downgrading netifd on root from 2014-01-20-88b3e92933925c09cfb6e95e9c8645727654ddf7 to 2013-12-29-7d79d0a8aa5a5b4c1ed987af119356438d98fe7b... Configuring netifd. root@OpenWrt:~# reboot root@OpenWrt:~# rdisc6 eth1 Soliciting ff02::2 (ff02::2) on eth1... [snip] root@OpenWrt:~# ip -6 r s table 1004 default from :: via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 2a00:1508:1:f004::/64 dev eth1 proto static metric 256 With netifd_2013-12-29, that last rule is never dropped / removed, even after days of uptime Hope that helps chasing the bug, since the bisect window is small: only 3 commits, Add indicator-flags to ubus and hotplug update-events Remove automatically assigned IPv6 routing table # fishy, fishy, fishy fish? ;) Don't add unnecessary NOP policy rules cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ssh link-local fails with Servname not supported for ai_socktype
Am I the only one ssh'ing into link-local addresses from openwrt devices? I came across a recent regression that makes this impossible, and couldn't find any report on google / this list. It's bugging the hell out of me on recent trunks (last known good rev: r36140, first known broken: r38505, but didn't bisect further) root@OpenWrt_r38505:/# ssh fe80::f8d1:11ff:fea0:fc%wlan0 ssh: Exited: Error resolving 'fe80::f8d1:11ff:fea0:fc' port 'wlan0'. Servname not supported for ai_socktype root@OpenWrt_r38505:/# ssh [fe80::f8d1:11ff:fea0:fc%wlan0] ssh: Exited: Error resolving '[fe80::f8d1:11ff:fea0:fc' port 'wlan0]'. Servname not supported for ai_socktype root@OpenWrt_r38505:/# opkg list dropbear dropbear - 2013.59-1 while on r36140 I could perfectly do: root@OpenWrt_r36140:~# ssh fe80::6670:2ff:fe3d:a0f9%wlan1 root@fe80::6670:2ff:fe3d:a0f9%wlan1's password: root@OpenWrt_r36140:~# opkg list dropbear dropbear - 2012.55-2 Any pointers on this regression? or workarounds? I first thought this would be related to the busybox-menuconfig changes, but then i remembered this is actually dropbear, so unrelated... I dug around menuconfig, and checked dropbear Makefile, but there aren't many knobs to tweak It might perfectly be an upstream bug, so i'll poke around git logs and try to bisect a little Cheers! gui::/128 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [packages] aircrack-ng: add missing dependency +wireless-tools
Without this patch, airodump-ng, aireplay-ng and other interesting tools fail with Can't find wireless tools, exiting. Signed-off-by: Gui Iribarren g...@altermundi.net --- Some utilities have no such dependency (i.e. packetforge-ng) but the same logic applies to libpcap, which is needed only for some tools, and is a hard dependency currently. net/aircrack-ng/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/aircrack-ng/Makefile b/net/aircrack-ng/Makefile index e912dfe..380a7b3 100644 --- a/net/aircrack-ng/Makefile +++ b/net/aircrack-ng/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=aircrack-ng PKG_VERSION:=1.1 -PKG_RELEASE:=3 +PKG_RELEASE:=4 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://download.aircrack-ng.org/ \ @@ -24,7 +24,7 @@ include $(INCLUDE_DIR)/package.mk define Package/aircrack-ng SECTION:=net CATEGORY:=Network - DEPENDS:=+libpthread +libopenssl +libpcap + DEPENDS:=+libpthread +libopenssl +libpcap +wireless-tools TITLE:=next generation of aircrack with new features URL:=http://www.aircrack-ng.org/ SUBMENU:=wireless -- 1.8.4.rc3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] netifd macvlan support
I'm trying to get a macvlan interface brought up by netifd on last week openwrt trunk BARRIER BREAKER (Bleeding Edge, r38505) with netifd - 2013-10-19-566af724dad393fa127e07469dcc9ade62bd3a75 and i'm probably missing something very silly, but i'm not getting any reaction or error whatsoever. The whole network.lm_anygw=device is ignored root@48cf6b:~# uci show network network.loopback=interface network.loopback.ifname=lo network.loopback.proto=static network.loopback.ipaddr=127.0.0.1 network.loopback.netmask=255.0.0.0 network.lan=interface network.lan.type=bridge network.lan.proto=static network.lan.netmask=255.255.255.0 network.lan.ip6addr=2A00:1508:1:F820:0:0:48:CF6B/64 network.lan.ipaddr=192.168.11.107 network.lan.ifname=eth0 network.wan=interface network.wan.proto=dhcp network.wan6=interface network.wan6.ifname=@wan network.wan6.proto=dhcpv6 network.@switch[0]=switch network.@switch[0].name=switch0 network.@switch[0].reset=1 network.@switch[0].enable_vlan=1 network.@switch_vlan[0]=switch_vlan network.@switch_vlan[0].device=switch0 network.@switch_vlan[0].vlan=1 network.@switch_vlan[0].ports=0 1 2 3 4 network.lm_anygw=device network.lm_anygw.type=macvlan network.lm_anygw.name=anygw network.lm_anygw.ifname=eth1 network.lm_anygw.macaddr=aa:aa:aa:40:28:b5 root@48cf6b:~# ubus list log network network.device network.interface network.interface.lan network.interface.loopback network.interface.wan network.interface.wan6 service system i even tried the following, with same result (nothing) network.wan.ifname=eth1 network.lm_anygw.ifname=@wan no new / error messages in logread, nothing. daemon.notice netifd: Interface 'lan' is now up daemon.notice netifd: Interface 'loopback' is now up and i couldn't find how to turn netifd into something more verbose... any further help will be greatly appreciated, and i promise updating the wiki in return :) cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd macvlan support
On 10/29/2013 01:31 PM, Gui Iribarren wrote:
I'm trying to get a macvlan interface brought up by netifd
on last week openwrt trunk
BARRIER BREAKER (Bleeding Edge, r38505)
with netifd - 2013-10-19-566af724dad393fa127e07469dcc9ade62bd3a75
and i'm probably missing something very silly, but i'm not getting any
reaction or error whatsoever. The whole network.lm_anygw=device is ignored
root@48cf6b:~# uci show network
network.loopback=interface
network.loopback.ifname=lo
network.loopback.proto=static
network.loopback.ipaddr=127.0.0.1
network.loopback.netmask=255.0.0.0
network.lan=interface
network.lan.type=bridge
network.lan.proto=static
network.lan.netmask=255.255.255.0
network.lan.ip6addr=2A00:1508:1:F820:0:0:48:CF6B/64
network.lan.ipaddr=192.168.11.107
network.lan.ifname=eth0
network.wan=interface
network.wan.proto=dhcp
network.wan6=interface
network.wan6.ifname=@wan
network.wan6.proto=dhcpv6
network.@switch[0]=switch
network.@switch[0].name=switch0
network.@switch[0].reset=1
network.@switch[0].enable_vlan=1
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device=switch0
network.@switch_vlan[0].vlan=1
network.@switch_vlan[0].ports=0 1 2 3 4
network.lm_anygw=device
network.lm_anygw.type=macvlan
network.lm_anygw.name=anygw
network.lm_anygw.ifname=eth1
network.lm_anygw.macaddr=aa:aa:aa:40:28:b5
root@48cf6b:~# ubus list
log
network
network.device
network.interface
network.interface.lan
network.interface.loopback
network.interface.wan
network.interface.wan6
service
system
ah! i'm getting *somewhere*, although not sure where
root@48cf6b:~# ubus call network.device status '{ name: anygw }'
{
external: false,
present: true,
type: MAC VLAN,
up: false,
parent: eth1,
statistics: {
}
}
so it seems it is actually recognizing the config section, but not
bringing the device up for some reason?
right, i was missing a 'config interface' that would actually reference
the new device
i.e.
network.if_anygw=interface
network.if_anygw.ifname=anygw
network.if_anygw.proto=static
network.if_anygw.ip6addr=2A00:1508:1:F820:0:0::1/64
now..
root@48cf6b:~# ip a s anygw
8: anygw@eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc
noqueue state LOWERLAYERDOWN group default
link/ether aa:aa:aa:40:28:b5 brd ff:ff:ff:ff:ff:ff
inet6 2a00:1508:1:f820::1/64 scope global tentative
valid_lft forever preferred_lft forever
nice!
thanks a lot jow/nbd for the code, and the help!
cheers,
gui
i even tried the following, with same result (nothing)
network.wan.ifname=eth1
network.lm_anygw.ifname=@wan
no new / error messages in logread, nothing.
daemon.notice netifd: Interface 'lan' is now up
daemon.notice netifd: Interface 'loopback' is now up
and i couldn't find how to turn netifd into something more verbose...
any further help will be greatly appreciated, and i promise updating the
wiki in return :)
cheers!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update wifidog to 20130917 version
On 09/17/2013 06:18 PM, Etienne CHAMPETIER wrote: This update: -adds a ProxyPort option (to use a local transparent proxy) -changes http return code to 302 (was 307, but wifidog speaks http 1.0, and we really need 303) (it was causing some trouble with, for exemple, opera) -switch to github repo -correct a small typo -add drop, log, ulog target for FirewallRule This is only compile tested, but 3 people are asking for it https://github.com/wifidog/wifidog-gateway/issues/8 +1 compiles fine on trunk r36139 i guess it would be a good idea to move this into http://github.com/openwrt-routing/ feed, for easier development? cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Warnung vor Lötwasser beim TL-WDR4900
On 09/12/2013 07:39 AM, John Crispin wrote: On 12/09/13 12:32, Bastian Bittorf wrote: * Steffen Hoffmannhoff...@web.de [12.09.2013 12:29]: Thank you for the translation, but 3 doesn't correlate with 'dutzende', or you have another, undisclosed source for your information? 8-) i'am involved in this special case, so i know the real situation. (somebody tends to hype here) this is a very funny thread, especially for the non-germans i think 8-) bye, bastian i can recommend this stuff - i'd simply recommend not soldering at all; you can build your serial cable with pins at the end (the same square metal pins you've been soldering all this time) and insert them into the holes on the PCB. that gets very interesting when you have more than a couple of routers. in that case, you can even build a dumb cable (just pins on each side, no serial-to-usb circuit) and use it to connect two routers (i.e. one bricked, and one alive with package 'screen') , GND - GND / TX - RX / RX - TX and then you don't even need the serial-to-USB converter, you can see the console using screen /dev/ttyS0 115200 for example (you might have to remove an /etc/inittab line to prevent the ash --login command taking control of the serial) Cheers! gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel panic Process batadv.sh - Fatal
On 08/12/2013 09:43 PM, cmsv wrote: OpenWrt version: Attitude Adjustment (r37747) Recently there was someone (Lucaspost) on #batman with a problem caused by mixing the latest AA and Batman-adv 2013.3.0 and while i can't be sure the problem is exactly this one; here goes my testing with a D-link 615C1 maybe you're mixing module and kernel versions? try to make dirclean and rebuild batadv.sh only does this echo $mesh /sys/class/net/$iface/batman_adv/mesh_iface where $iface is something like wlan0 and $mesh is bat0 HTH, Gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multiple virtual wireless interfaces - mix adhoc and ap mode?
On 06/25/2013 11:09 AM, jonsm...@gmail.com wrote:
On Tue, Jun 25, 2013 at 8:25 AM, Conor O'Gorman i...@conorogorman.net wrote:
On Tue, 2013-06-25 at 00:20 -0400, jonsm...@gmail.com wrote:
Can this be made to work on Ralink? When I have the adhoc0 interface
up bringing up ap0 says interface busy.
Ralink is not good for supporting this type of setup. I had tried AP and
client mode, and after some hacking it sort-of worked.
Maybe I asked the wrong question
I want to run a mesh like batman. The examples on the batman site
should it being run in adhoc mode. Can I instead run it in mesh mode?
root@OpenWrt:/etc/config# iw list
Wiphy phy0
..
valid interface combinations:
* #{ AP, mesh point } = 8,
total = 8, #channels = 1
Nope, mesh mode in this context refers to 802.11s which implements a
mesh network in a lower layer than batman-adv,
already providing a layer2 link-local domain between all participating
nodes.
running batman-adv over that is redundant and probably troublesome
so: choose between batman-adv over adhoc interfaces,
*or* use plain mesh mode interfaces.
If you're deploying this today, in a non-experimental scenario, you
probably want to go the batman-adv way (and drop ralink :P); open11s is
a younger project and while i'm impressed by the development pace, still
lacks some key features (IMHO) like multi-interface support :(
Cheers!
gui
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Attitude Adjustment (r36608) Configuration config problems
On 05/15/2013 02:15 AM, cmsv wrote: I have encountered the following problems while compiling images: The reason being is for example that the network configuration file for a dlink is not fully the same as for example tp-link. Having any of these config files in buildroot dir/files/config/ will eventually brick routers that for example have a different switch configuration; will fail working properly for wireless and have functioning problems with system. These files exist in buildroot dir/package/base-files/files/etc/ and while building the image they get merged with the specifics of the hardware. My question is if we can have the same merging task done while having buildroot dir/files/ . Have you considered either...? a) use ./scripts/env to mantain a different set of /files for each model or b) use an /etc/uci-defaults/smart-template.sh : it can check the hardware model where it is running live, and apply the config based on that information Hope that helps ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question on conffiles define / nodogsplash
On 04/06/2013 02:55 PM, Saverio Proto wrote: Hello, I have a personal version of nodogsplash OpenWRT package and I noticed today I was missing this patch from the main tree: https://github.com/ninuxorg/ninux-openwrt-packages/commit/92f90fae6ef6e29f789c2c7a539c4a3efb31b70d when I added this: define Package/nodogsplash/conffiles /etc/nodogsplash/nodogsplash.conf endef did I made my system smarter so that the file /etc/nodogsplash/nodogsplash.conf is saved automatically when I do sysupgrade ? Yes, your guess is correct; it works like that. that ends up adding a file to the final package /lib/upgrade/keep.d/nodogsplash which makes sysupgrade save /etc/nodogsplash/nodogsplash.conf before reflashing cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] iputils: replace busybox symlinks for commands arping/ping/ping6 when installing the corresponding iputils alternatives
Add preinst/postrm hooks to iputils, so that there are no install-time
conflicts,
either when opkg installing, or embedding in a binary.
Symlink is restored on package removal.
---
package/network/utils/iputils/Makefile | 44 +++-
1 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/package/network/utils/iputils/Makefile
b/package/network/utils/iputils/Makefile
index ff7505b..e887331 100644
--- a/package/network/utils/iputils/Makefile
+++ b/package/network/utils/iputils/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=iputils
PKG_VERSION:=20101006
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-s$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=http://www.skbuff.net/iputils
@@ -170,6 +170,48 @@ define Package/iputils-traceroute6/install
$(INSTALL_BIN) $(PKG_BUILD_DIR)/traceroute6 $(1)/usr/bin/
endef
+define Package/iputils-arping/preinst
+#!/bin/sh
+echo Removing /usr/bin/arping symlink for busybox
+[ -h $${IPKG_INSTROOT}/usr/bin/arping ] rm -f
$${IPKG_INSTROOT}/usr/bin/arping
+exit 0
+endef
+
+define Package/iputils-arping/postrm
+#!/bin/sh
+echo Re-enabling /usr/bin/arping symlink for busybox
+ln -sf ../../bin/busybox $${IPKG_INSTROOT}/usr/bin/arping
+exit 0
+endef
+
+define Package/iputils-ping/preinst
+#!/bin/sh
+echo Removing /bin/ping symlink for busybox
+[ -h $${IPKG_INSTROOT}/bin/ping ] rm -f $${IPKG_INSTROOT}/bin/ping
+exit 0
+endef
+
+define Package/iputils-ping/postrm
+#!/bin/sh
+echo Re-enabling /bin/ping symlink for busybox
+ln -sf busybox $${IPKG_INSTROOT}/bin/ping
+exit 0
+endef
+
+define Package/iputils-ping6/preinst
+#!/bin/sh
+echo Removing /bin/ping6 symlink for busybox
+[ -h $${IPKG_INSTROOT}/bin/ping6 ] rm -f $${IPKG_INSTROOT}/bin/ping6
+exit 0
+endef
+
+define Package/iputils-ping6/postrm
+#!/bin/sh
+echo Re-enabling /bin/ping6 symlink for busybox
+ln -sf busybox $${IPKG_INSTROOT}/bin/ping6
+exit 0
+endef
+
$(eval $(call BuildPackage,iputils-arping))
$(eval $(call BuildPackage,iputils-clockdiff))
$(eval $(call BuildPackage,iputils-ping))
--
1.7.2.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iputils: replace busybox symlinks for commands arping/ping/ping6 when installing the corresponding iputils alternatives
This fixes this error: root@6470028f4363:~# opkg install iputils-arping_20101006-1_ar71xx.ipk Installing iputils-arping (20101006-1) to root... Installing libsysfs (2.1.0-2) to root... Configuring libsysfs. Collected errors: * check_data_file_clashes: Package iputils-arping wants to install file /usr/bin/arping But that file is already provided by package * busybox * opkg_install_cmd: Cannot install package iputils-arping. And in addition smooths out the install of ping/ping6, which currently give no errors, but /bin/ping6 is preferred by $PATH, so this patch disables that feature-less busybox version right away, giving a streamlined experience (?) like the following: root@6470028f4363:~# ping6 BusyBox v1.19.4 (2013-03-30 05:23:56 ART) multi-call binary. Usage: ping6 [OPTIONS] HOST Send ICMP ECHO_REQUEST packets to network hosts -c CNT Send only CNT pings -s SIZE Send SIZE data bytes in packets (default:56) -I IFACE/IP Use interface or IP address as source -q Quiet, only displays output at start and when finished root@6470028f4363:~# opkg install iputils-ping6_20101006-2_ar71xx.ipk Installing iputils-ping6 (20101006-2) to root... Configuring iputils-ping6. Removing /bin/ping6 symlink for busybox root@6470028f4363:~# ping6 Usage: ping6 [-LUdfnqrvVaAD] [-c count] [-i interval] [-w deadline] [-p pattern] [-s packetsize] [-t ttl] [-I interface] [-M pmtudisc-hint] [-S sndbuf] [-F flowlabel] [-Q tclass] [hop1 ...] destination ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2] [ar71xx] add support for TL-WDR3500
PATCHv2 changelog:
* got ethernet almost right: eth1 = wan, eth0 = lan ports, reversed
* added board to sysupgrade support
WDR3500 is similar to WDR3600 except it doesn't have gigabit ethernet,
and has only 1 USB port.
So, this patch (over r35162) adds a new board type, based on
mach-tl-wdr4300.c but replacing ethernet config with one franken-based
on mach-tl-wr841n-v8.c
a huge thanks goes out to Paul Fertser for hours of tireless advice!
Pending issues:
* Leds are not working at all (except power and wlan_5g)
* LAN switch ethernet ports are reversed with respect to case label.
[Label] - soft device
[LAN1] - eth0.4
[LAN2] - eth0.3
[LAN3] - eth0.2
[LAN4] - eth0.1
Anyone with experience fixing those details that cares to help, will
be much appreciated!
Thanks-to: Paul Fertser fercer...@gmail.com
Signed-off-by: Gui Iribarren g...@altermundi.net
---
target/linux/ar71xx/base-files/lib/ar71xx.sh |6 +
.../ar71xx/base-files/lib/upgrade/platform.sh |1 +
target/linux/ar71xx/config-3.7 |1 +
.../ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c | 153
target/linux/ar71xx/generic/profiles/tp-link.mk|4 +-
target/linux/ar71xx/image/Makefile |3 +-
.../610-MIPS-ath79-openwrt-machines.patch | 27 +++-
7 files changed, 185 insertions(+), 10 deletions(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 31b6dde..a11c1c3 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -123,6 +123,9 @@ tplink_board_detect() {
342000*)
model=TP-Link TL-MR3420
;;
+ 35*)
+ model=TP-Link TL-WDR3500
+ ;;
36*)
model=TP-Link TL-WDR3600
;;
@@ -366,6 +369,9 @@ ar71xx_board_detect() {
*TL-WA901ND v2)
name=tl-wa901nd-v2
;;
+ *TL-WDR3500)
+ name=tl-wdr3500
+ ;;
*TL-WDR3600/4300/4310)
name=tl-wdr4300
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 3d5efdb..a952a9b 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -158,6 +158,7 @@ platform_check_image() {
tl-wa7510n | \
tl-wa901nd | \
tl-wa901nd-v2 | \
+ tl-wdr3500 | \
tl-wdr4300 | \
tl-wr703n | \
tl-wr741nd | \
diff --git a/target/linux/ar71xx/config-3.7 b/target/linux/ar71xx/config-3.7
index a13cf98..80e0e81 100644
--- a/target/linux/ar71xx/config-3.7
+++ b/target/linux/ar71xx/config-3.7
@@ -63,6 +63,7 @@ CONFIG_ATH79_MACH_TL_MR3020=y
CONFIG_ATH79_MACH_TL_MR3X20=y
CONFIG_ATH79_MACH_TL_WA901ND=y
CONFIG_ATH79_MACH_TL_WA901ND_V2=y
+CONFIG_ATH79_MACH_TL_WDR3500=y
CONFIG_ATH79_MACH_TL_WDR4300=y
CONFIG_ATH79_MACH_TL_WR1041N_V2=y
CONFIG_ATH79_MACH_TL_WR1043ND=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
new file mode 100644
index 000..05fe83d
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
@@ -0,0 +1,153 @@
+/*
+ * TP-LINK TL-WDR3500 board support
+ *
+ * Copyright (C) 2012 Gabor Juhos juh...@openwrt.org
+ * Copyright (C) 2013 Gui Iribarren g...@altermundi.net
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/pci.h
+#include linux/phy.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/ath9k_platform.h
+#include linux/ar8216_platform.h
+
+#include asm/mach-ath79/ar71xx_regs.h
+
+#include common.h
+#include dev-ap9x-pci.h
+#include dev-eth.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-spi.h
+#include dev-usb.h
+#include dev-wmac.h
+#include machtypes.h
+
+#define WDR3500_GPIO_LED_USB1 11
+#define WDR3500_GPIO_LED_WLAN2G13
+#define WDR3500_GPIO_LED_SYSTEM14
+#define WDR3500_GPIO_LED_QSS 15
+
+#define WDR3500_GPIO_BTN_WPS 16
+#define WDR3500_GPIO_BTN_RFKILL17
+
+#define WDR3500_GPIO_USB1_POWER22
+
+#define WDR3500_KEYS_POLL_INTERVAL 20 /* msecs */
+#define WDR3500_KEYS_DEBOUNCE_INTERVAL (3 * WDR3500_KEYS_POLL_INTERVAL)
+
+#define WDR3500_MAC0_OFFSET0
+#define WDR3500_MAC1_OFFSET6
+#define WDR3500_WMAC_CALDATA_OFFSET0x1000
+#define WDR3500_PCIE_CALDATA_OFFSET0x5000
+
+static const char *wdr3500_part_probes[] = {
+ tp-link,
+ NULL,
+};
+
+static struct flash_platform_data wdr3500_flash_data
[OpenWrt-Devel] [PATCHv3] [ar71xx] add support for TL-WDR3500
PATCHv3 changelog:
* I hate whitespace. v2 is broken, sorry for the noise.
PATCHv2 changelog:
* got ethernet almost right: eth1 = wan, eth0 = lan ports, reversed
* added board to sysupgrade support
WDR3500 is similar to WDR3600 except it doesn't have gigabit ethernet,
and has only 1 USB port.
So, this patch (over r35162) adds a new board type, based on
mach-tl-wdr4300.c but replacing ethernet config with one franken-based
on mach-tl-wr841n-v8.c
a huge thanks goes out to Paul Fertser for hours of tireless advice!
Pending issues:
* Leds are not working at all (except power and wlan_5g)
* LAN switch ethernet ports are reversed with respect to case label.
[Label] - soft device
[LAN1] - eth0.4
[LAN2] - eth0.3
[LAN3] - eth0.2
[LAN4] - eth0.1
Anyone with experience fixing those details that cares to help, will
be much appreciated!
Thanks-to: Paul Fertser fercer...@gmail.com
Signed-off-by: Gui Iribarren g...@altermundi.net
---
target/linux/ar71xx/base-files/lib/ar71xx.sh |6 +
.../ar71xx/base-files/lib/upgrade/platform.sh |1 +
target/linux/ar71xx/config-3.7 |1 +
.../ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c | 153
target/linux/ar71xx/generic/profiles/tp-link.mk|4 +-
target/linux/ar71xx/image/Makefile |3 +-
.../610-MIPS-ath79-openwrt-machines.patch | 27 +++-
7 files changed, 185 insertions(+), 10 deletions(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 31b6dde..a11c1c3 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -123,6 +123,9 @@ tplink_board_detect() {
342000*)
model=TP-Link TL-MR3420
;;
+ 35*)
+ model=TP-Link TL-WDR3500
+ ;;
36*)
model=TP-Link TL-WDR3600
;;
@@ -366,6 +369,9 @@ ar71xx_board_detect() {
*TL-WA901ND v2)
name=tl-wa901nd-v2
;;
+ *TL-WDR3500)
+ name=tl-wdr3500
+ ;;
*TL-WDR3600/4300/4310)
name=tl-wdr4300
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 3d5efdb..a952a9b 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -158,6 +158,7 @@ platform_check_image() {
tl-wa7510n | \
tl-wa901nd | \
tl-wa901nd-v2 | \
+ tl-wdr3500 | \
tl-wdr4300 | \
tl-wr703n | \
tl-wr741nd | \
diff --git a/target/linux/ar71xx/config-3.7 b/target/linux/ar71xx/config-3.7
index a13cf98..80e0e81 100644
--- a/target/linux/ar71xx/config-3.7
+++ b/target/linux/ar71xx/config-3.7
@@ -63,6 +63,7 @@ CONFIG_ATH79_MACH_TL_MR3020=y
CONFIG_ATH79_MACH_TL_MR3X20=y
CONFIG_ATH79_MACH_TL_WA901ND=y
CONFIG_ATH79_MACH_TL_WA901ND_V2=y
+CONFIG_ATH79_MACH_TL_WDR3500=y
CONFIG_ATH79_MACH_TL_WDR4300=y
CONFIG_ATH79_MACH_TL_WR1041N_V2=y
CONFIG_ATH79_MACH_TL_WR1043ND=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
new file mode 100644
index 000..05fe83d
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
@@ -0,0 +1,153 @@
+/*
+ * TP-LINK TL-WDR3500 board support
+ *
+ * Copyright (C) 2012 Gabor Juhos juh...@openwrt.org
+ * Copyright (C) 2013 Gui Iribarren g...@altermundi.net
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/pci.h
+#include linux/phy.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/ath9k_platform.h
+#include linux/ar8216_platform.h
+
+#include asm/mach-ath79/ar71xx_regs.h
+
+#include common.h
+#include dev-ap9x-pci.h
+#include dev-eth.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-spi.h
+#include dev-usb.h
+#include dev-wmac.h
+#include machtypes.h
+
+#define WDR3500_GPIO_LED_USB1 11
+#define WDR3500_GPIO_LED_WLAN2G13
+#define WDR3500_GPIO_LED_SYSTEM14
+#define WDR3500_GPIO_LED_QSS 15
+
+#define WDR3500_GPIO_BTN_WPS 16
+#define WDR3500_GPIO_BTN_RFKILL17
+
+#define WDR3500_GPIO_USB1_POWER22
+
+#define WDR3500_KEYS_POLL_INTERVAL 20 /* msecs */
+#define WDR3500_KEYS_DEBOUNCE_INTERVAL (3 * WDR3500_KEYS_POLL_INTERVAL)
+
+#define WDR3500_MAC0_OFFSET0
+#define WDR3500_MAC1_OFFSET6
+#define WDR3500_WMAC_CALDATA_OFFSET0x1000
+#define WDR3500_PCIE_CALDATA_OFFSET0x5000
+
+static const char *wdr3500_part_probes[] = {
+ tp-link,
+ NULL
Re: [OpenWrt-Devel] [PATCH] Add support for TL-WDR3500
Well, seems like i managed to fulfill every item of http://www.kroah.com/log/linux/maintainer.html and it's not my first patch sent to this list, so I have no excuse :( OTOH, I succeeded in getting the ethernet ports straight, so i'll send a properly formatted, improved PATCHv2 Thanks for your gentle words Luka, Cheers! On Sun, Jan 20, 2013 at 10:58 AM, Luka Perkov l...@openwrt.org wrote: On Sat, Jan 19, 2013 at 09:55:44PM -0300, Gui Iribarren wrote: Inline patch, probably newline-broken :( Yes it is. Please fix your client or use git send-email for sending patches. Make sure to read official documentation: https://dev.openwrt.org/wiki/SubmittingPatches You can always send email to yourself and verify that you can apply it on a clean trunk. But the reason I'm writing this email is to tell that you don't send two mails with the same patch in the future ;) Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add support for TL-WDR3500
WDR3500 is similar to WDR3600 except it doesn't have gigabit ethernet, and has only 1 USB port. So, this patch (over r35162) adds a new board type, based on mach-tl-wdr4300.c but replacing ethernet config with one based on mach-tl-wr841n-v8.c a huge thanks goes out to Paul Fertser for hours of tireless advice! Pending issues: * Leds are not working at all * ethernet ports are all scrambled up: [Label] - soft device [WAN] - eth1.1 [LAN1] - eth1.4 [LAN2] - eth1.3 [LAN3] - eth1.2 [LAN4] - eth0 Anyone with experience fixing those details that cares to help, will be much appreciated! Signed-off-by: Gui Iribarren g...@altermundi.net Thanks-to: Paul Fertser fercer...@gmail.com tlwdr3500_support.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add support for TL-WDR3500
On Sat, Jan 19, 2013 at 8:22 PM, Gui Iribarren g...@altermundi.net wrote:
WDR3500 is similar to WDR3600 except it doesn't have gigabit ethernet,
and has only 1 USB port.
So, this patch (over r35162) adds a new board type, based on
mach-tl-wdr4300.c but replacing ethernet config with one based on
mach-tl-wr841n-v8.c
a huge thanks goes out to Paul Fertser for hours of tireless advice!
Pending issues:
* Leds are not working at all
* ethernet ports are all scrambled up:
[Label] - soft device
[WAN] - eth1.1
[LAN1] - eth1.4
[LAN2] - eth1.3
[LAN3] - eth1.2
[LAN4] - eth0
Anyone with experience fixing those details that cares to help, will
be much appreciated!
Signed-off-by: Gui Iribarren g...@altermundi.net
Thanks-to: Paul Fertser fercer...@gmail.com
Inline patch, probably newline-broken :(
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c(revision 0)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c(revision 0)
@@ -0,0 +1,139 @@
+/*
+ * TP-LINK TL-WDR3500 board support
+ *
+ * Copyright (C) 2012 Gabor Juhos juh...@openwrt.org
+ * Copyright (C) 2013 Gui Iribarren g...@altermundi.net
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/pci.h
+#include linux/phy.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/ath9k_platform.h
+#include linux/ar8216_platform.h
+
+#include asm/mach-ath79/ar71xx_regs.h
+
+#include common.h
+#include dev-ap9x-pci.h
+#include dev-eth.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-spi.h
+#include dev-usb.h
+#include dev-wmac.h
+#include machtypes.h
+
+#define WDR3500_GPIO_LED_USB111
+#define WDR3500_GPIO_LED_WLAN2G13
+#define WDR3500_GPIO_LED_SYSTEM14
+#define WDR3500_GPIO_LED_QSS15
+
+#define WDR3500_GPIO_BTN_WPS16
+#define WDR3500_GPIO_BTN_RFKILL17
+
+#define WDR3500_GPIO_USB1_POWER22
+
+#define WDR3500_KEYS_POLL_INTERVAL20/* msecs */
+#define WDR3500_KEYS_DEBOUNCE_INTERVAL(3 * WDR3500_KEYS_POLL_INTERVAL)
+
+#define WDR3500_MAC0_OFFSET0
+#define WDR3500_MAC1_OFFSET6
+#define WDR3500_WMAC_CALDATA_OFFSET0x1000
+#define WDR3500_PCIE_CALDATA_OFFSET0x5000
+
+static const char *wdr3500_part_probes[] = {
+tp-link,
+NULL,
+};
+
+static struct flash_platform_data wdr3500_flash_data = {
+.part_probes= wdr3500_part_probes,
+};
+
+static struct gpio_led wdr3500_leds_gpio[] __initdata = {
+{
+.name= tp-link:blue:qss,
+.gpio= WDR3500_GPIO_LED_QSS,
+.active_low= 1,
+},
+{
+.name= tp-link:blue:system,
+.gpio= WDR3500_GPIO_LED_SYSTEM,
+.active_low= 1,
+},
+{
+.name= tp-link:green:usb1,
+.gpio= WDR3500_GPIO_LED_USB1,
+.active_low= 1,
+},
+{
+.name= tp-link:blue:wlan2g,
+.gpio= WDR3500_GPIO_LED_WLAN2G,
+.active_low= 1,
+},
+};
+
+static struct gpio_keys_button wdr3500_gpio_keys[] __initdata = {
+{
+.desc= QSS button,
+.type= EV_KEY,
+.code= KEY_WPS_BUTTON,
+.debounce_interval = WDR3500_KEYS_DEBOUNCE_INTERVAL,
+.gpio= WDR3500_GPIO_BTN_WPS,
+.active_low= 1,
+},
+{
+.desc= RFKILL switch,
+.type= EV_SW,
+.code= KEY_RFKILL,
+.debounce_interval = WDR3500_KEYS_DEBOUNCE_INTERVAL,
+.gpio= WDR3500_GPIO_BTN_RFKILL,
+},
+};
+
+
+static void __init wdr3500_setup(void)
+{
+u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00);
+
+ath79_register_m25p80(wdr3500_flash_data);
+ath79_register_leds_gpio(-1, ARRAY_SIZE(wdr3500_leds_gpio),
+ wdr3500_leds_gpio);
+ath79_register_gpio_keys_polled(-1, WDR3500_KEYS_POLL_INTERVAL,
+ARRAY_SIZE(wdr3500_gpio_keys),
+wdr3500_gpio_keys);
+
+ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_PHY_SWAP);
+
+ath79_register_mdio(1, 0x0);
+
+ath79_init_mac(ath79_eth0_data.mac_addr, mac, -1);
+ath79_init_mac(ath79_eth1_data.mac_addr, mac, 0);
+
+/* GMAC0 is connected to the PHY0 of the internal switch */
+ath79_switch_data.phy4_mii_en = 1;
+ath79_switch_data.phy_poll_mask = BIT(0);
+ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
+ath79_eth0_data.phy_mask = BIT(0);
+ath79_eth0_data.mii_bus_dev = ath79_mdio1_device.dev;
+ath79_register_eth(0);
+
+/* GMAC1 is connected to the internal switch */
+ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
+ath79_register_eth(1
Re: [OpenWrt-Devel] support for TP-Link TL-WDR3500. Was: Re: [RFC] ar71xx: add support for the TP-Link TL-WDR4310 v1.0
Hi Stefan, we truly appreciate your tips and guidance, attached is the original bootlog from serial console, in case it's useful. I'm about to try adapting flashing a binary for wdr3600, Cheers!! On Sat, Dec 22, 2012 at 12:05 AM, Nicolás Echániz nicoecha...@codigosur.org wrote: On 12/21/2012 11:56 PM, Stefan Lippers-Hollmann wrote: Hi On Saturday 22 December 2012, Stefan Lippers-Hollmann wrote: On Thursday 20 December 2012, Nicolás Echániz wrote: TP-Link WDR3600 is supported since r33219. It has the same hardware as the WDR4300 with one less chain/antenna. However the model WDR3500, which is similar to WDR3600 is not yet supported. Outstanding differences in relation to WDR3600 are: For the TL-WDR3600, the situation was easy (once TL-WDR4300 was supported), because it's essentially the same device, with only minor differences for the 2.4 GHz radio (but still supported by the same driver, ath9k). Without knowing any details, I fear this might be slightly different with the TL-WDR3500. - no gigabit ethernet Yes, and this means there is a big chance that the switch chipset might be different. In contrast to wlan support, where you might be able to just risk it, missing ethernet/ switch support would have much bigger consequences. Given that The Atheros DB120 reference architecture, from which these TP-Link routers are closely derived, is quite well integrated and is specified with an Atheros AR8327N GBit/s switch, there is a significant chance that a different switch chipset might be used here - or eventually some completely different base board. O.k., after looking at the FCC pictures, which are not detailed enough to read all of the chips, it becomes clear that they're using a similar, but significantly different PCB for the TL-WDR3500 - so you really should make high resolution pictures and check bootlog/ GPL tarball before risking anything. While there still is a small chance that the differences are small enough that OpenWrt might just work for this device as well, it does look like there is a different solution in place for the networking switch, so it's more likely that some more involved source changes might be needed. Stephan, thanks a lot for your detailed explanation. I live in a small town with difficult local access to hardware but I'll have a WDR3500 delivered from Buenos Aires in the following weeks and then I'll get the high resolution images and original bootlog. I'll update as soon as I have this information. Cheers, NicoEchániz altermundi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel TLWDR3500_factory_serial_boot.log Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] support for TP-Link TL-WDR3500. Was: Re: [RFC] ar71xx: add support for the TP-Link TL-WDR4310 v1.0
On Fri, Dec 21, 2012 at 11:56 PM, Stefan Lippers-Hollmann s@gmx.de wrote: While there still is a small chance that the differences are small enough that OpenWrt might just work for this device as well, it does look like there is a different solution in place for the networking switch, so it's more likely that some more involved source changes might be needed. Hello Gabor, i'm adding you to CC since your email is in all board support files :) we're trying to get openwrt running on TPLink WDR3500, a close relative of WDR3600 lacking gigabit ethernet Stefan, your predictions were right, i tftp'ed an openwrt image (compiled for wdr3600) to the wdr3500, and everything Just Worked, except the ethernet! tested working OK the USB port and dual-band wifi. But there's no eth0 whatsoever, and corresponding leds do not light up when an ethernet cable is connected. Attached is the bootlog with openwrt trunk r33815, hope it helps. I made some hi-res pictures of the board, and upload them to the wiki, http://wiki.openwrt.org/toh/tp-link/tl-wdr3500 i'm not sure if it should be merged them in http://wiki.openwrt.org/toh/tp-link/tl-wdr3600 feel free to do so, if the gigabit difference is not worth a separate page :) I tried to dig into board support source files, to see if i could make a minor change, but the best i could decipher was juhosg email :P So, help will be much appreciated; and any further testing or information needed will receive prompt replies. Thanks for the guidance so far, it's been a charming welcome into the world of adding openwrt support for a new board! Gui On Tue, Jan 15, 2013 at 11:42 AM, Gui Iribarren g...@altermundi.net wrote: Hi Stefan, we truly appreciate your tips and guidance, attached is the original bootlog from serial console, in case it's useful. I'm about to try adapting flashing a binary for wdr3600, Cheers!! On Sat, Dec 22, 2012 at 12:05 AM, Nicolás Echániz nicoecha...@codigosur.org wrote: On 12/21/2012 11:56 PM, Stefan Lippers-Hollmann wrote: Hi On Saturday 22 December 2012, Stefan Lippers-Hollmann wrote: On Thursday 20 December 2012, Nicolás Echániz wrote: TP-Link WDR3600 is supported since r33219. It has the same hardware as the WDR4300 with one less chain/antenna. However the model WDR3500, which is similar to WDR3600 is not yet supported. Outstanding differences in relation to WDR3600 are: For the TL-WDR3600, the situation was easy (once TL-WDR4300 was supported), because it's essentially the same device, with only minor differences for the 2.4 GHz radio (but still supported by the same driver, ath9k). Without knowing any details, I fear this might be slightly different with the TL-WDR3500. - no gigabit ethernet Yes, and this means there is a big chance that the switch chipset might be different. In contrast to wlan support, where you might be able to just risk it, missing ethernet/ switch support would have much bigger consequences. Given that The Atheros DB120 reference architecture, from which these TP-Link routers are closely derived, is quite well integrated and is specified with an Atheros AR8327N GBit/s switch, there is a significant chance that a different switch chipset might be used here - or eventually some completely different base board. O.k., after looking at the FCC pictures, which are not detailed enough to read all of the chips, it becomes clear that they're using a similar, but significantly different PCB for the TL-WDR3500 - so you really should make high resolution pictures and check bootlog/ GPL tarball before risking anything. While there still is a small chance that the differences are small enough that OpenWrt might just work for this device as well, it does look like there is a different solution in place for the networking switch, so it's more likely that some more involved source changes might be needed. Stephan, thanks a lot for your detailed explanation. I live in a small town with difficult local access to hardware but I'll have a WDR3500 delivered from Buenos Aires in the following weeks and then I'll get the high resolution images and original bootlog. I'll update as soon as I have this information. Cheers, NicoEchániz altermundi.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel TLWDR3500_openwrt_r33815_serial_boot.log Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Batman-adv 2012.4.0 into attitude adjustment
IIRC the openwrt package uses the out-of-kernel-tree batman release, i.e. it doesn't depend on a particular kernel version. So manually updating the package version in the makefile of your openwrt AA build environment should work. You don't need to add batman-adv feed in this case - having the 'packages' official feed is enough. What follows is taken from trunk, to serve you as a reference. ~/openwrt/ $ head feeds/packages/net/batman-adv/Makefile PKG_VERSION:=2012.4.0 BATCTL_VERSION:=2012.4.0 PKG_MD5SUM:=24e922a64a507b146c32c585538407f2 BATCTL_MD5SUM:=79d5aa796ae8b008a9fa42c27d4da2c1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://downloads.open-mesh.org/batman/releases/batman-adv-$(PKG_VERSION) hope that helps, Cheers! On Fri, Jan 11, 2013 at 7:37 AM, HeXiLeD hexi...@nixbits.net wrote: Which batman-adv feed should i use if there is one available ? This (http://www.open-mesh.org/projects/batman-adv/wiki/Building-with-openwrt) takes me to git (batman-adv-devel) which i might not want need. Will change the revision help ? If i am not mistaken; unless batman-adv 2012.4.0 is moved by someone from openwrt trunk to openwrt attitude adjustment i am not able to find a feed that provides me what i need and build batman-adv 2012.4.0 with attitude adjustment (kernel 3.3) What are my options ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kmod-batman-adv: Use current /lib/functions/network.sh in hotplug.d scripts
In legacy ubnt2 devices, when trying to bring 3 VAPs, one in adhoc
mode managed with batman-adv, a race condition occurs and /var/state
doesn't get the .ifname updated quickly enough at boot time. Using
(the newer) ubus call infrastructure overcomes the race condition.
Signed-off-by: Gui Iribarren g...@altermundi.net
---
~/openwrt/trunk/feeds/packages$ svn diff net/batman-adv
Index: net/batman-adv/files/lib/batman-adv/config.sh
===
--- net/batman-adv/files/lib/batman-adv/config.sh (revision 34303)
+++ net/batman-adv/files/lib/batman-adv/config.sh (working copy)
@@ -44,6 +44,8 @@
bat_add_interface()
{
+ . /lib/functions/network.sh
+
local mesh=$1
local interface=$2
local interfaces
@@ -52,7 +54,7 @@
config_get interfaces $mesh interfaces
for iface in $interfaces; do
[ -f /sys/class/net/$iface/batman_adv/mesh_iface ] || {
- iface=$(uci -q -P/var/state get network.$iface.ifname)
+ network_get_physdev iface $iface
[ -f
/sys/class/net/$iface/batman_adv/mesh_iface ] || continue
}
@@ -62,6 +64,8 @@
bat_del_interface()
{
+ . /lib/functions/network.sh
+
local mesh=$1
local interface=$2
local interfaces
@@ -69,7 +73,7 @@
config_get interfaces $mesh interfaces
for iface in $interfaces; do
[ -f /sys/class/net/$iface/batman_adv/mesh_iface ] || {
- iface=$(uci -q -P/var/state get network.$iface.ifname)
+ network_get_physdev iface $iface
[ -f
/sys/class/net/$iface/batman_adv/mesh_iface ] || continue
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kmod-batman-adv: Use current /lib/functions/network.sh in hotplug.d scripts
On Fri, Nov 23, 2012 at 7:11 AM, Jonh Wendell jonh.wend...@gmail.com wrote: hi. why did you include that file twice? is there any reason to not do a single include in the beginning of the the script? Those two functions differ very little, and could probably be refactored into one, but first i'll see what the package maintainer thinks about it :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] iperf: add minimal init.d script
Starts iperf in server mode as a daemon, with IPv4 + IPv6 support enabled (-V)
Signed-off-by: Gui Iribarren g...@altermundi.net
Index: net/iperf/files/iperf
===
--- net/iperf/files/iperf (revision 0)
+++ net/iperf/files/iperf (revision 0)
@@ -0,0 +1,12 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2006-2012 OpenWrt.org
+
+START=98
+
+start () {
+ service_start /usr/bin/iperf -s -D -V
+}
+
+stop() {
+ killall iperf
+}
Property changes on: net/iperf/files/iperf
___
Added: svn:executable
+ *
Index: net/iperf/Makefile
===
--- net/iperf/Makefile (revision 32789)
+++ net/iperf/Makefile (working copy)
@@ -9,7 +9,7 @@
PKG_NAME:=iperf
PKG_VERSION:=2.0.5
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
@@ -77,6 +77,8 @@
define Package/iperf/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/iperf $(1)/usr/bin/iperf
+ $(INSTALL_DIR) $(1)/etc/init.d
+ $(INSTALL_BIN) ./files/iperf $(1)/etc/init.d/iperf
endef
Package/iperf-mt/install = $(Package/iperf/install)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq - bump version and add config option for ra_names
I can confirm this patch works as expected, applied on trunk compiled cleanly and yields dnsmasq 2.62 root@OpenWrt:~# dnsmasq -v Dnsmasq version 2.62 Copyright (c) 2000-2012 Simon Kelley Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack Thanks a lot Dominique! On Fri, Jul 6, 2012 at 3:27 AM, Dominique Martinet asmad...@codewreck.org wrote: so no further init script change needed! Agreed, nevertheless it could probably be handy at some point to submit another patch adding an option dns6 or something like that, to simplify config management. I might try to take a stab at it, but no promises. For the moment, using option6 sounds perfect. Regards, -- Asmadeus | Dominique Martinet late for work :D ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] dropbear: set DEFAULT_PATH for non-interactive logins
Set PATH in non-interactive logins to include /sbin paths, so to be consistent with what is currently set in /etc/profile for interactive shells. Signed-off-by: Gui Iribarren g...@altermundi.net --- Index: package/dropbear/patches/500-set-default-path.patch === --- package/dropbear/patches/500-set-default-path.patch (revision 0) +++ package/dropbear/patches/500-set-default-path.patch (revision 0) @@ -0,0 +1,11 @@ +--- /a/options.h 2011-11-08 09:48:15.0 -0300 /b/options.h 2012-07-05 12:45:49.296635776 -0300 +@@ -292,7 +297,7 @@ + #define DEFAULT_IDLE_TIMEOUT 0 + + /* The default path. This will often get replaced by the shell */ +-#define DEFAULT_PATH /usr/bin:/bin ++#define DEFAULT_PATH /bin:/sbin:/usr/bin:/usr/sbin + + /* Some other defines (that mostly should be left alone) are defined + * in sysoptions.h */ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq - bump version and add config option for ra_names
On Thu, Jul 5, 2012 at 3:38 PM, Dominique Martinet asmad...@codewreck.org wrote: Hi, (I just subscribed to the list, so sorry if my mail format isn't right somehow. I quickly glanced at the archive and don't think what I offer has been looked at, aside of a quick reference to the changelog when the feature wasn't available in a stable release of dnsmasq yet) ra_names is a feature introduced in dnsmasq 2.61, which is why I changed the rules to build something newer (and figured I might as well take it to 62) Basically, it: - does router-advertisment (not dhcpv6) - when it gets a request for RA, it looks up if there is an active ipv4 lease for the same host via its MAC address, and if there is it adds the to-be ipv6 to the local dns (assuming the host will take the dns) - when it gets a dhcpv4 release it takes off the ipv6 dns record as well (since RA is stateless and doesn't give the host name, I couldn't figure any better way without dhcpv6; I was about to hack something (with a very large axe and radvd) when I found out they've done it already :D) This is gorgeous Dominique, My planned hack involved ladvd and flooding the network with LLDP packets, then parse the info inside those packets and spew it in /tmp/dhcp.leases I was just waiting for ladvd dev to patch the source so that it can compile cleanly on OpenWrt. While that scheme doesn't depend on ipv4, ra_names is definitely more elegant and as long as double-stack is the standard, i'll buy it! There are also modes for router-advertisment only which I haven't looked at, and a dhcpv6 client implementation that I didn't try yet either. The option I added is in the dhcp field, a ra_name option with the prefix to announce in RAs, i.e. config dhcp 'lan' option interface 'lan' option ra_names '2001:dead:beef::' I understand this serves the double purpose of activating this feature, and at the same time making dnsmasq send RA, so no radvd is needed or does it depend on RA sent by radvd ? in the second case, wouldn't it make sense to get the prefix config directly from /etc/config/radvd instead of duplicating information? (Note: it doesn't seem to add the local dns with a fe80:: prefix) It shouldn't, AFAIU link-local addresses are not meant to be resolved, since they always need the interface scope suffix Attached is the patch in svn format, feel free to ask if you prefer git's (I personally do but didn't look hard enough for the git repository!) Please give any comment and include something similar if you like it. Rergards, -- Dominique Martinet | Asmadeus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq - bump version and add config option for ra_names
On Thu, Jul 5, 2012 at 5:18 PM, Dominique Martinet asmad...@codewreck.org wrote: Hi, Gui Iribarren wrote on Thu, Jul 05, 2012 : On Thu, Jul 5, 2012 at 3:38 PM, Dominique Martinet asmad...@codewreck.org wrote: config dhcp 'lan' option interface 'lan' option ra_names '2001:dead:beef::' I understand this serves the double purpose of activating this feature, and at the same time making dnsmasq send RA, so no radvd is needed or does it depend on RA sent by radvd ? in the second case, wouldn't it make sense to get the prefix config directly from /etc/config/radvd instead of duplicating information? It effectively makes radvd unneeded (but harmless, I just tried with both running with my previous radvd configuration), so it seems better to give the prefix here. Agree, great to know. I'm pretty sure it would be possible to have the same feature with announces only from radvd and dnsmasq passively listening, but I didn't find a way to do so and for what I've been using radvd it doesn't seem to change much. I'm currently using the config rdnss feature of radvd so that SLAAC hosts also get a DNS server entry, again independent of dhcpv4. I assume that's also possible with this new scheme, right? i could search about it on dnsmasq documentation , but you seem to have immersed in the subject much more than i could achieve right now. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
