Re: [OpenWrt-Devel] [OpenWrt-Commits] r31561 - in packages/net/xl2tpd: . files patches
On Fri, 2012-05-04 at 23:29 -0600, Philip Prindeville wrote:
I'd combine all of these as:
local device server username password ...
Hm. I was just trying to copy local style, which in ppp.sh had each one
with its usage. Which makes slightly more sense to me; it makes it
simpler to add and remove options.
+ [ $peerdns -eq 1 ] {
+ peerdns=usepeerdns
+ } || {
+ peerdns=
+ add_dns $config $dns
+ }
Not clear how this is better than:
if [ $peerdns -eq 1 ]; then
peerdns=userpeerdns
else
peerdns=
add_dns $config $dns
fi
Not sure, but again that's what's in ppp.sh. Perhaps something to do
with shell compatibility, but I don't know which shells couldn't cope
with your version (which is how I'd write it myself).
I'd have done:
cat __EOF__ ${optfile}
${keepalive:+lcp-echo-interval $interval lcp-echo-failure ${keepalive%%[, ]*}}
...
__EOF__
That was my first thought too. I can't remember now why I didn't do it
that way. Perhaps I thought that some of those individual echo commands
might be conditional. But yeah, cat EOF would be cleaner.
+
+ xl2tpd-control remove l2tp-${config}
+ # Wait and ensure pppd has died.
+ while [ -d /sys/class/net/l2tp-${config} ]; do
+ sleep 1
+ done
If there's a bug, this might never exit... Maybe add a counter?
Makes sense.
Use of quotes around ${optfile} is inconsistent.
Hm, true. I think they're fairly pointless quotes, but I should at least
be consistent about it.
}
I'd try to match the current indent style.
This is a patch from elsewhere; not a local one. It's from the Fedora
package, and also been pushed upstream I believe. So I'd rather not mess
with it (except to remove the modprobe invocation).
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r31565 - in trunk/package/pptp: . files
On Fri, 2012-05-04 at 23:35 -0600, Philip Prindeville wrote:
-find_gw() {
- route -n | awk '$1 == 0.0.0.0 { print $2; exit }'
+find_route() {
+ ip route get $1 | sed -e 's/ /\n/g' | \
+sed -ne '1p;/via/{N;p};/dev/{N;p};/src/{N;p};/mtu/{N;p}'
I'd (a) use ip -4 -o instead of piping through sed to remove
newlines, and (b) use awk munge the fields into the output.
Care to express that in 'diff -up' form? Note that it's not ip -4;
this doesn't just work for Legacy IP. It works when the VPN server is on
IPv6 too, and I've tested it that way (in the openconnect incantation at
least; I haven't done PPTP).
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Working with patches
Hi! I'm working on submitting a patch for the appweb package by following the Wiki page http://wiki.openwrt.org/doc/devel/patches#edit.an.existing.patch The specific patch I'm working on is this one for appweb https://github.com/embedthis/appweb-3/commit/3c1a8e11ddef0b3c771dc8b09f0fe8c52b4f97f2#build/make/Makefile.top (mixed implicit and normal rules - as per this change to gnu make http://osdir.com/ml/bug-make-gnu/2011-04/msg00011.html regarding backward incompatibility ) Whilst I realise I could *probably* just submit the upstream patch, I thought it best to follow the Wiki as my first submission, particularly as I'd like to keep local changes in a formal way as documented by OpenWRT. However I've got a 'little' stuck at the section of the wiki regarding how to 'move the new patch file over to the buildroot, run update on the package' make package/example/update V=99 In my case, this is make package/appweb/update V=99 generates make[2]: *** No rule to make target `update'. Stop. So I'm wondering if I'm holding it wrong or whether the wiki page is incorrect. Hoping someone's able to handhold me through this step in case I want or need to do the procedure again elsewhere. Regards, Pete. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r31565 - in trunk/package/pptp: . files
On Sat, 2012-05-05 at 13:14 +0200, Felix Fietkau wrote: As long as it works, it's not worth putting in effort to clean this up. This code will be going away soon (replaced by the to-be-written netifd based script). The new code will not need iproute2 or such tricks at all. OTOH vpnc-script upstream could benefit from it too :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] this patch adds initial support for linux 3.3 to brcm47xx
On 03/29/2012 01:24 PM, Hauke Mehrtens wrote: On 03/22/2012 09:05 PM, Peter Wagner wrote: Signed-off-by: Peter Wagner tripo...@gmx.at Hi Peter Wagner, my current plan is to leave kernel version 3.3 out and directly go to 3.4 if someone adds the rc to OpenWrt trunk. If I would add 3.3 support I had to apply my changes for both kernel versions 3.2 and 3.3 and I do not want to do so, or does kernel version 3.3 add some new features you need? Hauke Hi Peter Wagner, as kernel 3.3 will be our new stable kernel I updated brcm47xx now to that kernel. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel test
One more last question: which serial/jtag cable do you use? (if it is cheap, better) thanks! On Wed, May 2, 2012 at 5:55 PM, Jonathan Bennett jbscienc...@gmail.com wrote: On Sat, Apr 28, 2012 at 9:22 AM, Alberich de megres alberich...@gmail.com wrote: Hi, @Jonathan, how get access to the bootloader? do you send it to the router by streaming, or write it and then boot it? Get a serial port and watch the output as you turn it on. Normally there will be a message about how to interrupt the boot loader. Then you send your image to ram, either over tftp or the serial connection. then you just boot from where you loaded it in ram. ___ 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] Add Lua bindings for libgps
On 2012-04-16 3:31 PM, Dave Taht wrote: On Mon, Apr 16, 2012 at 2:37 AM, Christian Gagneraud ch...@techworks.ie wrote: On 05/04/12 16:19, Dave Taht wrote: I note that I have been tracking the latest gpsds closely (with the new api) A problem is that it requires that scons support be added to the mainline openwrt build. Got patches for all that, could use some more testing... Hi Dave, I'm interesting as well to see gpsd updated to the latest stable version, would you mind to share your patches? I'll be happy to give them a try! The newly released gpsd 3.5 is currently living in the ceropackages repository, and has only been tested on the wndr3700v2 (and not quite 3.5 was tested - 3.5 was released saturday) It also requires that chkpath and scons support be added to the main openwrt . (aformentioned scons support is also required for things like xorp) you can either add the ceropackages repo to your feeds.conf src-git cero git://github.com/dtaht/ceropackages.git ./scripts/feeds uninstall gpsd ./scripts/feeds install cero gpsd or extract the latest gpsd package from: https://github.com/dtaht/ceropackages/tree/master/net As for the scons and chrpath support, patches are at: http://huchra.bufferbloat.net/~cero1/for_openwrt/ I'm sure eric would love to see gpsd 2.x retired from openwrt (and I'd love the lua interface you just did) (hat off to swalker for packaging this stuff up and eric for taking the openwrt related patches into his mainline) I merged scons build support in r31618. I was just about to merge chrpath too, but it didn't build on my OSX box. When I found out what chrpath is used for in the build system, I decided to not merge it at all. If I understand the code that uses it in the gpsd build system correctly, it seems to be an unnecessary hack that should be patched out entirely. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH/RFC] add kernel-accelerated PPtP support
On 2012-05-04 6:55 PM, Daniel Golle wrote: PPtP right now works with a pure userland implementation though there is perfectly working support for kernel-accelerated PPtP. Having this as a seperate package is a bit ugly, I think it should be a patch on top of the ppp package adding ppp-mod-pptp...? Signed-off-by: Daniel Golle dgo...@allnet.de Any package that adds a protocol handler script now needs to have netifd support (netifd will be enabled by default soon, once the remaining scripts have been ported). Today I finished porting over the existing pptp script. The netifd version is quite simple, you can use it as template. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add Lua bindings for libgps
On 2012-05-05 8:49 PM, Eric S. Raymond wrote: Felix Fietkau n...@openwrt.org: I merged scons build support in r31618. I was just about to merge chrpath too, but it didn't build on my OSX box. When I found out what chrpath is used for in the build system, I decided to not merge it at all. If I understand the code that uses it in the gpsd build system correctly, it seems to be an unnecessary hack that should be patched out entirely. It's necessary for dynamic linking. It replaces the elaborate stuff libtool does in an autotools-based build. I really don't think we need it in OpenWrt, so I'm going to patch it out. chrpath seems to need some ELF related stuff that isn't part of our host build yet, and I think it is completely pointless to add all of this for a piece of functionality that we don't need or want in OpenWrt at all. After fixing some madness wrt. scons platform detection (I'm beginning to dislike scons even more than autoconf now), I tried my patched gpsd package and it seemed to find its libraries just fine. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add Lua bindings for libgps
On 05/05/2012 01:17 PM, Felix Fietkau wrote: On 2012-05-05 8:49 PM, Eric S. Raymond wrote: Felix Fietkaun...@openwrt.org: I merged scons build support in r31618. I was just about to merge chrpath too, but it didn't build on my OSX box. When I found out what chrpath is used for in the build system, I decided to not merge it at all. If I understand the code that uses it in the gpsd build system correctly, it seems to be an unnecessary hack that should be patched out entirely. It's necessary for dynamic linking. It replaces the elaborate stuff libtool does in an autotools-based build. I really don't think we need it in OpenWrt, so I'm going to patch it out. chrpath seems to need some ELF related stuff that isn't part of our host build yet, and I think it is completely pointless to add all of this for a piece of functionality that we don't need or want in OpenWrt at all. Works for me. After fixing some madness wrt. scons platform detection (I'm beginning to dislike scons even more than autoconf now) That would be hard to imagine, but I feel your pain, I do, I do. , I tried my patched gpsd package and it seemed to find its libraries just fine. Awesome. I note that there was a great deal of churn happening after the 3.5 release, I don't know if eric considers it 3.5 stable enough or not. Notably there was some stuff going by about endianness on the list that appeared to be ibm360 related, which I know is not a target platform (yet) for openwrt. Does this mean I can retire the ceropackages version? I note that the xorp package therein needed scons too. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: Updated patch for ramips_esw.c swconfig supoprt
This patch adds swconfig support for ramips_esw:
So far I've developed and tested the patch mostly on the D-LINK DIR-300 B1.
I've made sure that in the enable_vlan=0 case it behaves like a dumb switch,
so external switches should work fine with vlans.
Also I've taken some more care than before to make sure it doesn't change the
pre-existing behaviour in case swconfig is not available or an external switch
is used.
The current state shown by swconfig is always read directly from HW registers,
new settings only show after 'swconfig dev rt305x set apply'.
Note that I have renamed RT305X_ESW_REG_POC[123] to RT305X_ESW_REG_POC[012] to
better match the datasheet (which has a typo on POC0, which probably lead to
the confusing POC[123] naming).
Default on D-LINK DIR-300 B1 after first boot:
|root@OpenWrt:/# swconfig dev rt305x show
|Global attributes:
|enable_vlan: 1
|Port 0:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:0 link:down
|Port 1:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:1 link:down
|Port 2:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:2 link:down
|Port 3:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:3 link:up speed:100baseT full-duplex
|Port 4:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 0
|pvid: 2
|link: port:4 link:up speed:100baseT full-duplex
|Port 5:
|disable: 1
|doubletag: 0
|untag: 1
|led: -1
|lan: 1
|pvid: 1
|link: port:5 link:down
|Port 6:
|disable: 0
|doubletag: 0
|untag: 0
|led: -1
|lan: -1
|pvid: 1
|link: port:6 link:up speed:1000baseT full-duplex
|VLAN 1:
|ports: 0 1 2 3 6t
|VLAN 2:
|ports: 4 6t
With enable_vlan=0:
|Global attributes:
|enable_vlan: 0
|Port 0:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:0 link:down
|Port 1:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:1 link:down
|Port 2:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:2 link:down
|Port 3:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:3 link:up speed:100baseT full-duplex
|Port 4:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 0
|pvid: 0
|link: port:4 link:up speed:100baseT full-duplex
|Port 5:
|disable: 0
|doubletag: 0
|untag: 1
|led: -1
|lan: 1
|pvid: 0
|link: port:5 link:down
|Port 6:
|disable: 0
|doubletag: 0
|untag: 1
|led: -1
|lan: -1
|pvid: 0
|link: port:6 link:up speed:1000baseT full-duplex
|VLAN 0:
|ports: 0 1 2 3 4 5 6
Closes: https://dev.openwrt.org/ticket/11327
Signed-off-by: Tobias Diedrich ranma+open...@tdiedrich.de
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl351.c
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl351.c
(revision 31538)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl351.c
(working copy)
@@ -98,7 +98,7 @@
ARRAY_SIZE(wl351_gpio_buttons),
wl351_gpio_buttons);
// external rtl8366rb
- rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_BYPASS;
+ rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_NONE;
rt305x_esw_data.reg_initval_fct2 = 0x0002500c;
rt305x_esw_data.reg_initval_fpa2 = 0x1f003fff;
rt305x_register_ethernet();
Index:
target/linux/ramips/files/arch/mips/include/asm/mach-ralink/rt305x_esw_platform.h
===
---
target/linux/ramips/files/arch/mips/include/asm/mach-ralink/rt305x_esw_platform.h
(revision 31538)
+++
target/linux/ramips/files/arch/mips/include/asm/mach-ralink/rt305x_esw_platform.h
(working copy)
@@ -13,7 +13,6 @@
enum {
RT305X_ESW_VLAN_CONFIG_NONE = 0,
- RT305X_ESW_VLAN_CONFIG_BYPASS,
RT305X_ESW_VLAN_CONFIG_W,
RT305X_ESW_VLAN_CONFIG_W,
};
Index: target/linux/ramips/files/drivers/net/ethernet/ramips/Kconfig
===
--- target/linux/ramips/files/drivers/net/ethernet/ramips/Kconfig
(revision 31538)
+++
Re: [OpenWrt-Devel] [PATCH] ramips: Updated patch for ramips_esw.c swconfig supoprt
Thou shalt build against up-to-date vanilla svn before posting a patch
Of course 1) the serial bugfix crept in and 2) I was lazily
rebuilding and while I updated ramips_esw.c the header file still
had the RT305X_ESW_VLAN_CONFIG_BYPASS and I never noticed that I
forgot to remove it from the switch-statement...
So, once more rediffed against up-to-date svn.
This patch adds swconfig support for ramips_esw:
So far I've developed and tested the patch mostly on the D-LINK DIR-300 B1.
I've made sure that in the enable_vlan=0 case it behaves like a dumb switch,
so external switches should work fine with vlans.
Also I've taken some more care than before to make sure it doesn't change the
pre-existing behaviour in case swconfig is not available or an external switch
is used.
The current state shown by swconfig is always read directly from HW registers,
new settings only show after 'swconfig dev rt305x set apply'.
Note that I have renamed RT305X_ESW_REG_POC[123] to RT305X_ESW_REG_POC[012] to
better match the datasheet (which has a typo on POC0, which probably lead to
the confusing POC[123] naming).
Default on D-LINK DIR-300 B1 after first boot:
|root@OpenWrt:/# swconfig dev rt305x show
|Global attributes:
|enable_vlan: 1
|Port 0:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:0 link:down
|Port 1:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:1 link:down
|Port 2:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:2 link:down
|Port 3:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 1
|link: port:3 link:up speed:100baseT full-duplex
|Port 4:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 0
|pvid: 2
|link: port:4 link:up speed:100baseT full-duplex
|Port 5:
|disable: 1
|doubletag: 0
|untag: 1
|led: -1
|lan: 1
|pvid: 1
|link: port:5 link:down
|Port 6:
|disable: 0
|doubletag: 0
|untag: 0
|led: -1
|lan: -1
|pvid: 1
|link: port:6 link:up speed:1000baseT full-duplex
|VLAN 1:
|ports: 0 1 2 3 6t
|VLAN 2:
|ports: 4 6t
With enable_vlan=0:
|Global attributes:
|enable_vlan: 0
|Port 0:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:0 link:down
|Port 1:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:1 link:down
|Port 2:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:2 link:down
|Port 3:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 1
|pvid: 0
|link: port:3 link:up speed:100baseT full-duplex
|Port 4:
|disable: 0
|doubletag: 0
|untag: 1
|led: 0
|lan: 0
|pvid: 0
|link: port:4 link:up speed:100baseT full-duplex
|Port 5:
|disable: 0
|doubletag: 0
|untag: 1
|led: -1
|lan: 1
|pvid: 0
|link: port:5 link:down
|Port 6:
|disable: 0
|doubletag: 0
|untag: 1
|led: -1
|lan: -1
|pvid: 0
|link: port:6 link:up speed:1000baseT full-duplex
|VLAN 0:
|ports: 0 1 2 3 4 5 6
Closes: https://dev.openwrt.org/ticket/11327
Signed-off-by: Tobias Diedrich ranma+open...@tdiedrich.de
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl351.c
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl351.c
(revision 31618)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl351.c
(working copy)
@@ -98,7 +98,7 @@
ARRAY_SIZE(wl351_gpio_buttons),
wl351_gpio_buttons);
// external rtl8366rb
- rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_BYPASS;
+ rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_NONE;
rt305x_esw_data.reg_initval_fct2 = 0x0002500c;
rt305x_esw_data.reg_initval_fpa2 = 0x1f003fff;
rt305x_register_ethernet();
Index:
target/linux/ramips/files/arch/mips/include/asm/mach-ralink/rt305x_esw_platform.h
===
---
target/linux/ramips/files/arch/mips/include/asm/mach-ralink/rt305x_esw_platform.h
(revision 31618)
+++
target/linux/ramips/files/arch/mips/include/asm/mach-ralink/rt305x_esw_platform.h
(working copy)
@@ -13,7 +13,6 @@
enum {
RT305X_ESW_VLAN_CONFIG_NONE =
Re: [OpenWrt-Devel] [PATCH] Add Lua bindings for libgps
On 2012-05-05 10:20 PM, dave taht wrote: On 05/05/2012 01:17 PM, Felix Fietkau wrote: On 2012-05-05 8:49 PM, Eric S. Raymond wrote: Felix Fietkaun...@openwrt.org: I merged scons build support in r31618. I was just about to merge chrpath too, but it didn't build on my OSX box. When I found out what chrpath is used for in the build system, I decided to not merge it at all. If I understand the code that uses it in the gpsd build system correctly, it seems to be an unnecessary hack that should be patched out entirely. It's necessary for dynamic linking. It replaces the elaborate stuff libtool does in an autotools-based build. I really don't think we need it in OpenWrt, so I'm going to patch it out. chrpath seems to need some ELF related stuff that isn't part of our host build yet, and I think it is completely pointless to add all of this for a piece of functionality that we don't need or want in OpenWrt at all. Works for me. After fixing some madness wrt. scons platform detection (I'm beginning to dislike scons even more than autoconf now) That would be hard to imagine, but I feel your pain, I do, I do. , I tried my patched gpsd package and it seemed to find its libraries just fine. Awesome. I note that there was a great deal of churn happening after the 3.5 release, I don't know if eric considers it 3.5 stable enough or not. Notably there was some stuff going by about endianness on the list that appeared to be ibm360 related, which I know is not a target platform (yet) for openwrt. Does this mean I can retire the ceropackages version? Committed the gpsd update in r31621 I note that the xorp package therein needed scons too. That one doesn't build for me yet but comes close (something pthread related when linking), maybe I'll look into it some other day. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Working with patches
Try 'refresh' instead. On 5/5/12 2:29 AM, Peter Lawler wrote: Hi! I'm working on submitting a patch for the appweb package by following the Wiki page http://wiki.openwrt.org/doc/devel/patches#edit.an.existing.patch The specific patch I'm working on is this one for appweb https://github.com/embedthis/appweb-3/commit/3c1a8e11ddef0b3c771dc8b09f0fe8c52b4f97f2#build/make/Makefile.top (mixed implicit and normal rules - as per this change to gnu make http://osdir.com/ml/bug-make-gnu/2011-04/msg00011.html regarding backward incompatibility ) Whilst I realise I could *probably* just submit the upstream patch, I thought it best to follow the Wiki as my first submission, particularly as I'd like to keep local changes in a formal way as documented by OpenWRT. However I've got a 'little' stuck at the section of the wiki regarding how to 'move the new patch file over to the buildroot, run update on the package' make package/example/update V=99 In my case, this is make package/appweb/update V=99 generates make[2]: *** No rule to make target `update'. Stop. So I'm wondering if I'm holding it wrong or whether the wiki page is incorrect. Hoping someone's able to handhold me through this step in case I want or need to do the procedure again elsewhere. Regards, Pete. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Updated patch for ramips_esw.c swconfig supoprt
Tobias Diedrich wrote: So far I've developed and tested the patch mostly on the D-LINK DIR-300 B1. I've made sure that in the enable_vlan=0 case it behaves like a dumb switch, so external switches should work fine with vlans. Meh, for some reason on the WL-351 the doubletag bits don't take. More investigation is needed... -- Tobias PGP: http://8ef7ddba.uguu.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, better answer late, than never.. To conclude: We won't get to a common opinion on that I guess. I just wanted to draw your attention (from time to time, maybe once a year) onto that this 0,52% IPv6-stuff isn't real life, honestly. 99,48% are v4-only, thats just a fact, there is no v6 outside Testbeds and Freaks (and I count myself as freak, but I don't use it productive because I cannot spend 12hrs a day with all the problems it implies) Am 23.04.2012 11:26, schrieb Gert Doering: Hi, On Mon, Apr 23, 2012 at 01:49:18AM +0200, Michael Markstaller wrote: Appreciate your work really but just my 5ct: noone needs IPv6 if not in search for troubles or many new (security)-problems. Welcome to the 21st century. There are ISPs in Asia today(!) that *will* *not* give you an IPv4 address, because they have none left. Thats egostic now but: is this my problem? No, my problems are everyday stuff in common and existing IPv4 networks.. So with a workload of 110% an IPv6 migration will make things better? Won't guess ;) I love the --disable-ipv6 switch, please keep it working without this experiment, I guess there are many other fields to work on - with more relationship to real-life :o IPv6 is most relevant to real-life. see above, which real life, sorry, I still havent any customer asking for, that *is* real life. Things are made by business and money - I don't like that though, I'd rather prefer to get the time to migrate anyone I know to IPv6 but thats not the truth of life.. As soon as an v4 /24 costs more than migrating a large network to v6, I'd agree that it is real life Many of the problems we see in IPv6 deployments are caused exactly by this attitude - instead of *using* it and fixing the problems that are still left, disabling it and hoping that it won't be needed before personal retirement. This won't get any of the issues fixed, and one day you'll find yourself in need of IPv6, and the problems are still there. I understand your concerns and share them absolutely! It was right after we met (many) years ago, I started v6 internally, but honestly, I can only do this as a hobby (and I *do*) - for production I have to make sure things work 24x7, my customers dont care if I use v4, v6 or NetBEUI - if it works :p And just to givean example: after upgrading to Windows 12.04 on my Notebook last week, I had to disable v6 to make Wlanlan work concurrently as it detected duplicated v6-IPs with the mac of the wlan (no v6 active at all in this net) - there are still many things broken. On this Friday morning I just had to work, not chase v6-issues.. - - I'll file a bug for that surely (and first search 30min if it doesn't exist already) but that takes some minutes to qualify that. So, finally please understand also, that there is a 99,48%-world besides v6 which has to work as it is. Michael P.S.: I promise to put up v6 again and report what I find, I just ask to remind the latest point ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+lvNAACgkQaWRHV2kMuAJgKACgup/C4J+wyDh6loclYRyyyO2N s8sAoIc3TFQkENInSRarqYBqLi1JBzL7 =Eg4i -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So, finally please understand also, that there is a 99,48%-world besides v6 which has to work as it is. Finally, please understand that your IPv6 discussion in this thread is pointless, off topic and and unproductive. It draws attention away from the main objective, which is eliminating bottlenecks in the packet processing path. Neither has the proposed patch set anything to do with any - --disable-ipv6 switch nor has it any implications on IPv6 security or deployment scenarios. If you have specific problems with IPv6 being enabled then feel free to discuss it in a separate thread. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+lvpAACgkQdputYINPTPMYuQCff/26OhJyiDodcEeg+aI0fGto vT0Anj4QLjSdcGp5TU3kLkLCdfdzHRwE =99oq -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Updated patch for ramips_esw.c swconfig supoprt
Third time's a charm. This patch adds swconfig support for ramips_esw: Tested on both D-LINK DIR-300 B1 and Sitecom WL-351 (external rtl8366rb on internal port 5). I've made sure that in the enable_vlan=0 case it behaves like a dumb switch, so external switches should work fine with vlans and verified this on the WL-351. Also I've taken some more care than before to make sure it doesn't change the pre-existing behaviour in case swconfig is not available or an external switch is used. The current state shown by swconfig is always read directly from HW registers, new settings only show after 'swconfig dev rt305x set apply'. Note that I have renamed RT305X_ESW_REG_POC[123] to RT305X_ESW_REG_POC[012] to better match the datasheet (which has a typo on POC0, which probably lead to the confusing POC[123] naming). Default on D-LINK DIR-300 B1 after first boot: |root@OpenWrt:/# swconfig dev rt305x show |Global attributes: |enable_vlan: 1 |alternate_vlan_disable: 0 |Port 0: |disable: 0 |doubletag: 0 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 2185 |pvid: 1 |link: port:0 link:up speed:100baseT full-duplex |Port 1: |disable: 0 |doubletag: 0 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 1 |link: port:1 link:down |Port 2: |disable: 0 |doubletag: 0 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 1 |link: port:2 link:down |Port 3: |disable: 0 |doubletag: 0 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 1 |link: port:3 link:down |Port 4: |disable: 0 |doubletag: 0 |en_vlan: 1 |untag: 1 |led: 0 |lan: 0 |recv_bad: 0 |recv_good: 0 |pvid: 2 |link: port:4 link:up speed:100baseT full-duplex |Port 5: |disable: 1 |doubletag: 0 |en_vlan: 1 |untag: 1 |led: ??? |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 1 |link: port:5 link:down |Port 6: |disable: 0 |doubletag: 0 |en_vlan: 1 |untag: 0 |led: ??? |lan: ??? |recv_bad: ??? |recv_good: ??? |pvid: 1 |link: port:6 link:up speed:1000baseT full-duplex |VLAN 1: |ports: 0 1 2 3 6t |VLAN 2: |ports: 4 6t With enable_vlan=0: |Global attributes: |enable_vlan: 0 |alternate_vlan_disable: 0 |Port 0: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 2381 |pvid: 0 |link: port:0 link:up speed:100baseT full-duplex |Port 1: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 0 |link: port:1 link:down |Port 2: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 0 |link: port:2 link:down |Port 3: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 0 |link: port:3 link:down |Port 4: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: 0 |lan: 0 |recv_bad: 0 |recv_good: 0 |pvid: 0 |link: port:4 link:up speed:100baseT full-duplex |Port 5: |disable: 1 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: ??? |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 0 |link: port:5 link:down |Port 6: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: ??? |lan: ??? |recv_bad: ??? |recv_good: ??? |pvid: 0 |link: port:6 link:up speed:1000baseT full-duplex |VLAN 0: |ports: 0 1 2 3 4 5 6 Default on Sitecom WL-351 after boot: |root@OpenWrt:~# swconfig dev rt305x show |Global attributes: |enable_vlan: 0 |alternate_vlan_disable: 0 |Port 0: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 0 |link: port:0 link:down |Port 1: |disable: 0 |doubletag: 1 |en_vlan: 1 |untag: 1 |led: 0 |lan: 1 |recv_bad: 0 |recv_good: 0 |pvid: 0 |link: port:1 link:down |Port 2: |disable: 0 |
[OpenWrt-Devel] [PATCH] daemonlogger package Makefile
Daemonlogger is a packet logger and soft tap developed by Martin Roesch. This patch adds a Makefile to build it as an OpenWRT ipk package. Note: the patch is against trunk, but it also builds cleanly on Backfire. Signed-off-by: Robert Vineyard viney...@tuffmail.com --- Index: feeds/packages/net/daemonlogger/Makefile === --- feeds/packages/net/daemonlogger/Makefile(revision 0) +++ feeds/packages/net/daemonlogger/Makefile(revision 0) @@ -0,0 +1,49 @@ +# +# Copyright (C) 2007-2011 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=daemonlogger +PKG_VERSION:=1.2.1 +PKG_RELEASE:=1 + +PKG_SOURCE:=463 +PKG_SOURCE_URL:=http://www.snort.org/downloads/ +PKG_CAT:=zcat +PKG_MD5SUM:=acb64aa6cd5777e297569f100b5c39ee + +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)/$(PKG_NAME)-$(PKG_VERSION) + +PKG_INSTALL:=1 + +include $(INCLUDE_DIR)/package.mk + +define Package/daemonlogger + SECTION:=net + CATEGORY:=Network + DEPENDS:=+libpcap + DEPENDS:=+libdnet + TITLE:=Software Network Tap + URL:=http://www.snort.org/snort-downloads/additional-downloads +endef + +CONFIGURE_VARS += \ + BUILD_CC=$(TARGET_CC) \ + HOSTCC=$(HOSTCC) + +MAKE_FLAGS := CCOPT=$(TARGET_CFLAGS) INCLS=-I. $(TARGET_CPPFLAGS) + +define Build/Configure + $(call Build/Configure/Default) +endef + +define Package/daemonlogger/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/daemonlogger $(1)/usr/bin/ +endef + +$(eval $(call BuildPackage,daemonlogger)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] dnsmasq: add support for set: and tag: pairs
On my network, I have a variety of machines and appliances, some of which need
different configuration issues than the default options.
For example:
config host
option name 'client'
option mac '00:01:02:03:04:05'
option ip '192.168.1.20'
option tag 'acme'
config tag
option name 'acme'
option force '1'
list dhcp_option 'option:router,192.168.1.253'
list dhcp_option 'option:domain-name,acme.com'
list dhcp_option 'option:domain-search,acme.com,redfish-solutions.com'
which allows me to override the default router for my client's host, as well as
its domain-name, and its domain-search.
this causes the following config lines:
dhcp-host=00:01:02:03:04:05,set:acme,192.168.1.20,client
dhcp-option-force=tag:acme,option:router,192.168.1.253,option:domain-name,acme.com,option:domain-search:acme.com,redfish-solutions.com
This could be useful elsewhere, for instance, if you have an IP CCTV that you
don't want to have a default-route, etc.
Index: trunk/package/dnsmasq/files/dnsmasq.init
===
--- trunk/package/dnsmasq/files/dnsmasq.init(revision 31572)
+++ trunk/package/dnsmasq/files/dnsmasq.init(working copy)
@@ -224,16 +224,37 @@
config_get name $cfg name
config_get ip $cfg ip
- [ -n $ip ] || [ -n $name ] || return 0
+ [ -n $ip -o -n $name ] || return 0
macs=
config_get mac $cfg mac
for m in $mac; do append macs $m ,; done
[ -n $macs ] || return 0
- xappend
--dhcp-host=$macs${networkid:+,net:$networkid}${ip:+,$ip}${name:+,$name}
+ config_get tag $cfg tag
+
+ xappend
--dhcp-host=$macs${networkid:+,net:$networkid}${tag:+,set:$tag}${ip:+,$ip}${name:+,$name}
}
+append_option() {
+ append options $1 ,
+}
+
+dhcp_tag_add() {
+ local cfg=$1
+
+ config_get tag $cfg name
+ [ -n $tag ] || return 0
+
+ options=
+ config_list_foreach $cfg dhcp_option append_option
+
+ config_get force $cfg force 0
+ [ $force = 0 ] force=
+
+ xappend --dhcp-option${force:+-force}=tag:$tag,$options
+}
+
dhcp_mac_add() {
local cfg=$1
@@ -435,6 +456,7 @@
echo $CONFIGFILE
config_foreach dhcp_boot_add boot
config_foreach dhcp_mac_add mac
+ config_foreach dhcp_tag_add tag
config_foreach dhcp_vendorclass_add vendorclass
config_foreach dhcp_userclass_add userclass
config_foreach dhcp_circuitid_add circuitid
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] daemonlogger package Makefile
Comments... On 5/5/12 8:02 PM, Robert Vineyard wrote: Daemonlogger is a packet logger and soft tap developed by Martin Roesch. This patch adds a Makefile to build it as an OpenWRT ipk package. Note: the patch is against trunk, but it also builds cleanly on Backfire. Signed-off-by: Robert Vineyard viney...@tuffmail.com --- Index: feeds/packages/net/daemonlogger/Makefile === --- feeds/packages/net/daemonlogger/Makefile (revision 0) +++ feeds/packages/net/daemonlogger/Makefile (revision 0) @@ -0,0 +1,49 @@ +# +# Copyright (C) 2007-2011 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=daemonlogger +PKG_VERSION:=1.2.1 +PKG_RELEASE:=1 + +PKG_SOURCE:=463 +PKG_SOURCE_URL:=http://www.snort.org/downloads/ +PKG_CAT:=zcat +PKG_MD5SUM:=acb64aa6cd5777e297569f100b5c39ee + +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)/$(PKG_NAME)-$(PKG_VERSION) + +PKG_INSTALL:=1 + +include $(INCLUDE_DIR)/package.mk + +define Package/daemonlogger + SECTION:=net + CATEGORY:=Network + DEPENDS:=+libpcap + DEPENDS:=+libdnet Please combine these on a single line... + TITLE:=Software Network Tap + URL:=http://www.snort.org/snort-downloads/additional-downloads +endef + +CONFIGURE_VARS += \ + BUILD_CC=$(TARGET_CC) \ + HOSTCC=$(HOSTCC) + +MAKE_FLAGS := CCOPT=$(TARGET_CFLAGS) INCLS=-I. $(TARGET_CPPFLAGS) + +define Build/Configure + $(call Build/Configure/Default) +endef I think this is the default, isn't it? + +define Package/daemonlogger/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/daemonlogger $(1)/usr/bin/ +endef + +$(eval $(call BuildPackage,daemonlogger)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel test
https://www.adafruit.com/products/70 is a great serial cable. It's used for ttl level serial. (If you have to solder to the board, it's probably ttl. If there is an actual serial port, then it's 12 v serial. Different device) On Sat, May 5, 2012 at 9:16 AM, Alberich de megres alberich...@gmail.com wrote: One more last question: which serial/jtag cable do you use? (if it is cheap, better) thanks! On Wed, May 2, 2012 at 5:55 PM, Jonathan Bennett jbscienc...@gmail.com wrote: On Sat, Apr 28, 2012 at 9:22 AM, Alberich de megres alberich...@gmail.com wrote: Hi, @Jonathan, how get access to the bootloader? do you send it to the router by streaming, or write it and then boot it? Get a serial port and watch the output as you turn it on. Normally there will be a message about how to interrupt the boot loader. Then you send your image to ram, either over tftp or the serial connection. then you just boot from where you loaded it in ram. ___ 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
