Re: [OpenWrt-Devel] gpio-led bug
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
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
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
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
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
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
