Re: [OpenWrt-Devel] gpio-led bug

2009-12-24 Thread Nuno Gonçalves
CPU 0 Unable to handle kernel paging request at virtual address , epc =c
Oops[#1]:
Cpu 0
$ 0   :  8030  0001
$ 4   : 81ef3000 80dd7a00 adc7 001e7ddd
$ 8   : 00987553 0059 9f4e c4653600
$12   : 3b9aca00  80d73800 0048
$16   : 80dd7a00 0100 801c283c 802b9e50
$20   : 80306fe8 80306de8 80306be8 803069e8
$24   :  80071854
$28   : 802b8000 802b9e20 00200200 801c28cc
Hi: 001e7ddd
Lo: 6647e889
epc   :  (null)
Not tainted
ra: 801c28cc netdev_trig_timer+0x90/0x1b0
Status: 1000fc03KERNEL EXL IE
Cause : 1088
BadVA : 
PrId  : 00019374 (MIPS 24Kc)
Modules linked in: ohci_hcd nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrao
Process swapper (pid: 0, threadinfo=802b8000, task=802ba170, tls=)
Stack : 0059 1e6601aa 802bdbf0  803061e0 803061e0 0100 800862b0
0002 0001 8028621c 800709d0 802b9e50 802b9e50 0100 803060b0
 0004 000a 8030 80281c64 802be320 803060ac 80081714
802c01c4 0007 802fb66d 81ff8000 81ff8000 81fe58a0  802f0e5c
802fb66d 81ff8000 81ff8000 81fe58a0  81ff8000  800817f4
...
Call Trace:
[<800862b0>] run_timer_softirq+0x14c/0x1d8
[<800709d0>] c0_compare_interrupt+0x50/0x60
[<80081714>] __do_softirq+0x90/0x128
[<81fe58a0>] usb_hcd_poll_rh_status+0xc8/0x160 [usbcore]
[<81fe58a0>] usb_hcd_poll_rh_status+0xc8/0x160 [usbcore]
[<800817f4>] do_softirq+0x48/0x6c
[<8006082c>] ret_from_irq+0x0/0x4
[<80060a00>] r4k_wait+0x0/0x40
[<81fe58a0>] usb_hcd_poll_rh_status+0xc8/0x160 [usbcore]
[<8006af74>] ar71xx_gpio_get_value+0x0/0x20
[<8006c3a8>] cpu_idle+0x24/0x4c
[<80060a20>] r4k_wait+0x20/0x40
[<802d4a0c>] start_kernel+0x324/0x33c
[<802d4370>] unknown_bootoption+0x0/0x304
[<81fe6020>] usb_hcd_submit_urb+0x7c/0x8a0 [usbcore]


Code: (Bad address in epc)

Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 3 seconds..�

U-Boot 1.1.5 (Apr  6 2009 - 13:54:11)

DRAM:  ar7100_ddr_initial_config(237) enter!
ar7100_ddr_initial_config(269) exit!

-- 
\ Nuno Gonçalves
/
\ Bugs? Features!
/
\ nuno...@gmail.com
/ PORTUGAL


> Message: 2
> Date: Thu, 24 Dec 2009 11:38:34 +0100
> From: Felix Fietkau 
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] gpio-led bug
> Message-ID: <4b3344aa.2020...@openwrt.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 2009-12-23 9:19 PM, Stefan Bethke wrote:
>> Am 23.12.2009 um 12:48 schrieb Nuno Gon?alves:
>>
>>> The follow commands cause a reboot on a WRT160NL:
>>>
>>> cd $1 && echo netdev > trigger && echo $2 > device_name && echo $3 > mode
>>
>> I've noticed similar problems on an TP-Link tl-wr941nd.
> Do you guys have a serial console connected? Do you get a kernel crash
> log when the system reboots?
> If so, then please rebuild with "Compile the kernel with symbol table
> information" enabled under "Global build settings" and send over all the
> kernel messages that you're receiving.
>
> - Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ePoint HotSpot package

2009-12-24 Thread Daniel A. Nagy
Hi Felix,

Thank you for the thorough review!

Following up on our discussion at #openwrt-devel, I have opened up our SVN for
reading. Maybe it would indeed be better to keep it as a separate feed on our
server, referenced from OpenWrt; we are planning several other packages related
to each other and it would be less of a hassle for everyone if we did the
maintenance ourselves.

Nonetheless, your remarks are quite valid. Let me reflect to them one by one:

Felix Fietkau wrote:
>> Index: net/epoint/files/CONTROL/postinst
>> ===
>> --- net/epoint/files/CONTROL/postinst(revision 0)
>> +++ net/epoint/files/CONTROL/postinst(revision 0)
>> @@ -0,0 +1,57 @@
>> [...]
> preinst, postinst, prerm, conffiles, etc. files should be defined inline
> in the package makefile using something like this:
> 
> define Package//postinst
> [...]
> endef

Interesting. Could you point me to some documentation where this is explained or
give a brief description why is that needed? I am not questioning it, just
wondering about how it works.

>> +
>> +grep -q epoint $IPKG_INSTROOT/etc/services || \
>> +echo 'epoint 8080/tcp' >> $IPKG_INSTROOT/etc/services
>> +
>> +if [ -n "$IPKG_INSTROOT" ]; then
>> +touch $IPKG_INSTROOT/etc/epoint_firstboot
>> +
>> +CONF="$IPKG_INSTROOT/etc/opkg.conf"
>> +# XXX This is ugly hack. We should force offline installation of opkg
>> +# to happen before us, or fetch and modify opkg.conf somehow.
>> +if [ -f "$CONF" ]; then
>> +grep -q epoint "$CONF" || \
>> +echo 'src epoint http://www.epointsystem.org/openwrt/packages' 
>> >>
>> "$CONF"
>> +else
>> +cat > "$CONF" <> +src/gz snapshots 
>> http://downloads.openwrt.org/kamikaze/8.09.1/brcm-2.4/packages
>> +src epoint http://www.epointsystem.org/openwrt/packages
>> +dest root /
>> +dest ram /tmp
>> +lists_dir ext /var/opkg-lists
>> +option overlay_root /jffs
>> +EOF
>> +fi
>> +
>> +mkdir -p $IPKG_INSTROOT/etc/uci-defaults
>> +cat > $IPKG_INSTROOT/etc/uci-defaults/epoint <> +#!/bin/sh
>> +
>> +uci batch <<-EOF
>> +set luci.main.mediaurlbase=/luci-static/epoint
>> +commit
>> +EOF
>> +DATA
>> +chmod 755 $IPKG_INSTROOT/etc/uci-defaults/epoint
>> +fi
>> +
>> +if [ -z "$IPKG_INSTROOT" ]; then
>> +. /etc/functions.sh
>> +for m in /etc/modules.d/*ipt*; do
>> +load_modules `basename $m`
>> +done
>> +
>> +rm -f /tmp/luci-indexcache
>> +rm -f /tmp/luci-modulecache/*
>> +rm -rf /tmp/luci-templatecache/*
>> +
>> +/etc/init.d/xinetd enable
>> +/etc/init.d/xinetd restart
>> +/etc/init.d/matrixhttps enable
>> +/etc/init.d/matrixhttps start
>> +/etc/init.d/epoint enable
>> +/etc/init.d/epoint start
>> +
>> +ACTION=ifup /etc/hotplug.d/iface/40-hotspot-dns
>> +fi
>> +exit 0
> Some of this is probably easier to handle by installing a script into
> /etc/uci-defaults, which will make it run on first boot only (or on the
> next reboot if you're installing it on the device).
> You could then also trigger the uci-defaults apply in the postinst
> script of the package by calling . /etc/functions.sh; uci_apply_defaults

Yes, that would probably be cleaner. Could you point to some other package that
changes configuration in a similar manner?

>> Index: net/epoint/files/CONTROL/prerm
>> ===
>> --- net/epoint/files/CONTROL/prerm   (revision 0)
>> +++ net/epoint/files/CONTROL/prerm   (revision 0)
>> @@ -0,0 +1,8 @@
>> [...]
> See above.
> 
>> Index: net/epoint/files/www/epoint-static/epoint.png
>> ===
>> Cannot display: file marked as a binary type.
>> svn:mime-type = application/octet-stream
> This will have to be handled separately once we've decided whether we
> will merge this package into OpenWrt, or you guys maintain a separate
> feed for your packages.

After some pondering, I am inclined to have us maintain a separate public feed.
It seems to be easier for everyone involved. The only coordination that we need
to do in this case is making sure that in OpenWrt releases, the source of our
feed is not the trunk of our SVN but a tag that stays unchanged so that a
well-tested release is not broken by us changing something in our trunk.

Our latest public release is at
https://www.epointsystem.org/svn/vending_machine/hotspot/tags/hotspot12/

>> Index: net/epoint/files/etc/ssl/privkey.pem
>> Index: net/epoint/files/etc/ssl/cert.pem
> You may want to generate these either on the device or at least on the
> host, if you're using these in a place where security matters.

I am not. These are for an SSL certificate, so nothing is encrypted using this
key; it merely signs the ephemeral D-H key during the SSL handshake, when
accessing LuCI via https. This signature does not secure anything, as it is not
a certified site, just an encrypted http connection.

[OpenWrt-Devel] [PATCH] dnsmasq: bump default EDNS0 size

2009-12-24 Thread Francis Dupont
In dnsmasq the default EDNS0 max UDP size is limited to the conservative
value of 1280 bytes. I have two concerns about this:
 - the 1280 value can be still too low for coming DNSSEC (the root
  will be signed next year so we can expect at least 4 time larger
  DNS response)
 - in theory it is not the role of dnsmasq at all to constraint
  clients to a conservative maximum size, i.e., if a client takes
  the risk of the usual fragmentation issues it should be allowed
  to do it.
So I asked dnsmasq author to look at for a better defaut in next
releases but as it is a command line option the best is to fix this
directly in the config.

Regards

francis.dup...@fdupont.fr

PS: the patch itself (from 8.09 svn local copy):

Index: package/dnsmasq/files/dhcp.conf
===
--- package/dnsmasq/files/dhcp.conf (revision 18800)
+++ package/dnsmasq/files/dhcp.conf (working copy)
@@ -9,6 +9,7 @@
option nonegcache   0
option authoritative1
option readethers   1
+   option ednspacket_max   4096
option leasefile'/tmp/dhcp.leases'
option resolvfile   '/tmp/resolv.conf.auto'
#list server'/mycompany.local/1.2.3.4'

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] New Enhancement Ticket (with patch) for RT210W support

2009-12-24 Thread Felix Fietkau
On 2009-12-23 6:52 PM, Spudz76 wrote:
> (Reminder Copy of original message)
>  Forwarded Message 
>> From: Spudz76 
>> Reply-to: spud...@gmail.com
>> To: OpenWrt Development List 
>> Subject: New Enhancement Ticket (with patch) for RT210W support
>> Date: Fri, 18 Dec 2009 16:02:48 -0600
Applied both of your patches.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ePoint HotSpot package

2009-12-24 Thread Felix Fietkau
On 2009-12-21 1:28 AM, Daniel A. Nagy wrote:
> I would like to contribute a package to OpenWrt that we have developed and
> successfully use commercially. I believe that having it included in official
> OpenWrt distribution would benefit both projects.
> 
> With this package, an OpenWrt-based router provides time-restricted internet
> access in exchange for single-use codes. Tickets with these codes (called 
> ePoint
> RANDs) can be printed from the administrative web interface. Accounting is 
> also
> included. More on ePoint HotSpot here:
> https://www.epointsystem.org/trac/vending_machine/wiki/HotSpot
> 
> The package depends on two other packages (qrencode and code128b) responsible
> for generating bar codes that appear on the tickets. Patches for those will
> follow immediately.
> 
> A minor problem with building the package is that it shows up in menuconfig
> after selecting zlib, libgcrypt, libopencdk and xinetd *in this particular
> order*. If these same packages are selected in a different order, our package
> may not show up in menuconfig.
> 
> Signed-off-by: Daniel A. Nagy 
Hi Daniel,

Some comments about issues that I found during superficial review:

> Index: net/epoint/files/CONTROL/postinst
> ===
> --- net/epoint/files/CONTROL/postinst (revision 0)
> +++ net/epoint/files/CONTROL/postinst (revision 0)
> @@ -0,0 +1,57 @@
> [...]
preinst, postinst, prerm, conffiles, etc. files should be defined inline
in the package makefile using something like this:

define Package//postinst
[...]
endef

> +
> +grep -q epoint $IPKG_INSTROOT/etc/services || \
> +echo 'epoint 8080/tcp' >> $IPKG_INSTROOT/etc/services
> +
> +if [ -n "$IPKG_INSTROOT" ]; then
> +touch $IPKG_INSTROOT/etc/epoint_firstboot
> +
> +CONF="$IPKG_INSTROOT/etc/opkg.conf"
> +# XXX This is ugly hack. We should force offline installation of opkg
> +# to happen before us, or fetch and modify opkg.conf somehow.
> +if [ -f "$CONF" ]; then
> +grep -q epoint "$CONF" || \
> +echo 'src epoint http://www.epointsystem.org/openwrt/packages' >>
> "$CONF"
> +else
> +cat > "$CONF" < +src/gz snapshots 
> http://downloads.openwrt.org/kamikaze/8.09.1/brcm-2.4/packages
> +src epoint http://www.epointsystem.org/openwrt/packages
> +dest root /
> +dest ram /tmp
> +lists_dir ext /var/opkg-lists
> +option overlay_root /jffs
> +EOF
> +fi
> +
> +mkdir -p $IPKG_INSTROOT/etc/uci-defaults
> +cat > $IPKG_INSTROOT/etc/uci-defaults/epoint < +#!/bin/sh
> +
> +uci batch <<-EOF
> +set luci.main.mediaurlbase=/luci-static/epoint
> +commit
> +EOF
> +DATA
> +chmod 755 $IPKG_INSTROOT/etc/uci-defaults/epoint
> +fi
> +
> +if [ -z "$IPKG_INSTROOT" ]; then
> +. /etc/functions.sh
> +for m in /etc/modules.d/*ipt*; do
> +load_modules `basename $m`
> +done
> +
> +rm -f /tmp/luci-indexcache
> +rm -f /tmp/luci-modulecache/*
> +rm -rf /tmp/luci-templatecache/*
> +
> +/etc/init.d/xinetd enable
> +/etc/init.d/xinetd restart
> +/etc/init.d/matrixhttps enable
> +/etc/init.d/matrixhttps start
> +/etc/init.d/epoint enable
> +/etc/init.d/epoint start
> +
> +ACTION=ifup /etc/hotplug.d/iface/40-hotspot-dns
> +fi
> +exit 0
Some of this is probably easier to handle by installing a script into
/etc/uci-defaults, which will make it run on first boot only (or on the
next reboot if you're installing it on the device).
You could then also trigger the uci-defaults apply in the postinst
script of the package by calling . /etc/functions.sh; uci_apply_defaults

> Index: net/epoint/files/CONTROL/prerm
> ===
> --- net/epoint/files/CONTROL/prerm(revision 0)
> +++ net/epoint/files/CONTROL/prerm(revision 0)
> @@ -0,0 +1,8 @@
> [...]
See above.

> Index: net/epoint/files/www/epoint-static/epoint.png
> ===
> Cannot display: file marked as a binary type.
> svn:mime-type = application/octet-stream
This will have to be handled separately once we've decided whether we
will merge this package into OpenWrt, or you guys maintain a separate
feed for your packages.


> Index: net/epoint/files/etc/ssl/privkey.pem
> ===
> --- net/epoint/files/etc/ssl/privkey.pem  (revision 0)
> +++ net/epoint/files/etc/ssl/privkey.pem  (revision 0)
> @@ -0,0 +1,15 @@
> +-BEGIN RSA PRIVATE KEY-
> +MIICXAIBAAKBgQCtLD47gEHZbkW0PZvZm2J+1XbQL/qLP+cojfKNDdunwpdTDdEN
> +QCXeZ1dHh0Uy+aS5dHpqsDDO/bCpD7qLT30l6WhZvuNvDcdbr8rD7SR3uoP12F+3
> +vgeLyGKtdJhQL73Ya55zPHcIRKUuGQwgSbdP22IX1Yeb/mGnkGWP2xboTQIDAQAB
> +AoGAU2X9SpaIH/i1ZQpOpkvo8YBIShbxKGLMJoHGEBxebrqOOhdrWGBOXH+UTwRc
> +VSJZLF9mHT9hIi6XB7RleHX9pJtKsS4fVcn3pm52NhH7UYFB4Y0AHhEWk6Wtcz64
> +uu+WPV1zh6kvCuGyTTFIlO9mbIafaJ5ON9DEewGUCYe+VIECQQDflxfGDbmtL1r3
> +/BTAYWeQc3K5m9B7bAtU/ZSgdQbHpQ/9H/r2g

Re: [OpenWrt-Devel] gpio-led bug

2009-12-24 Thread Felix Fietkau
On 2009-12-23 9:19 PM, Stefan Bethke wrote:
> Am 23.12.2009 um 12:48 schrieb Nuno Gonçalves:
> 
>> The follow commands cause a reboot on a WRT160NL:
>> 
>> cd $1 && echo netdev > trigger && echo $2 > device_name && echo $3 > mode
> 
> I've noticed similar problems on an TP-Link tl-wr941nd.
Do you guys have a serial console connected? Do you get a kernel crash
log when the system reboots?
If so, then please rebuild with "Compile the kernel with symbol table
information" enabled under "Global build settings" and send over all the
kernel messages that you're receiving.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel