Re: [OpenWrt-Devel] [PATCH] Update mjpeg-streamer package
It works fine for me on x86 and ixp4xx. I'm using a logitech sphere (the controls work fine too) and another cheap logitec cam (I do not remember the model). R. On 16/09/2011 06:50, Otto Solares Cabrera wrote: On Tue, Sep 13, 2011 at 08:20:45AM +0200, Roberto Riggio wrote: It is the output of svn diff. Rev 150 was from the experimental branch so I was not sure how stable it was (considering the mjpeg streamer is pretty volatile). Just FYI I was having problems in many cams with stable and experimental r150 coupled with Linux 2.6.39 or 3.0 fixed my problems in ar71xx devices so IMO is worth a shot if you have issues. - Otto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Roberto Riggio, Ph.D. CREATE-NET Network Security Solutions for Pervasive Computing Systems (iNSPIRE) Senior Researcher Via alla Cascata 56/D - 38123 Povo Trento (Italy) e-mail: roberto.rig...@create-net.org Tel: (+39) 0461 408400 - interno/extension 708 Fax: (+39) 0461 421157 www.create-net.org/~rriggio The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited according to the Italian Law 196/2003 of the Legislature. If you received this in error, please contact the sender and delete the material from any computer. Le informazioni contenute in questo messaggio di posta elettronica e nei file allegati sono da considerarsi strettamente riservate. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalita' indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla cancellazione del messaggio stesso dal Vostro sistema. Trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita' diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs. 196/2003. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
On 16 September 2011 01:40, Alexander Gordeev lasa...@lvk.cs.msu.su wrote: В Fri, 26 Aug 2011 04:30:43 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: This method is much more stable than reading dd's output via stdin. What kind of problems do you have with piping dd's output to stdin? It outputs garbage very frequently and maccalc fails to convert the mac (and as a consequence uci-default script fails to set the real mac address). Try dd without piping to maccalc and you'll see. I've noticed this bug on ramips platform and can't say anything about other boards. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Fri, 16 Sep 2011 17:41:37 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: On 16 September 2011 01:40, Alexander Gordeev lasa...@lvk.cs.msu.su wrote: В Fri, 26 Aug 2011 04:30:43 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: This method is much more stable than reading dd's output via stdin. What kind of problems do you have with piping dd's output to stdin? It outputs garbage very frequently and maccalc fails to convert the mac (and as a consequence uci-default script fails to set the real mac address). Try dd without piping to maccalc and you'll see. I've noticed this bug on ramips platform and can't say anything about other boards. Well, then this is probably a bug in dd? Or uClibc? Or kernel? Ok, I'll try to reproduce it. Can you please tell me what exactly is happening? -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
On Friday 16 September 2011 16:51:16 Alexander Gordeev wrote: В Fri, 16 Sep 2011 17:41:37 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: On 16 September 2011 01:40, Alexander Gordeev lasa...@lvk.cs.msu.su wrote: В Fri, 26 Aug 2011 04:30:43 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: This method is much more stable than reading dd's output via stdin. What kind of problems do you have with piping dd's output to stdin? It outputs garbage very frequently and maccalc fails to convert the mac (and as a consequence uci-default script fails to set the real mac address). Try dd without piping to maccalc and you'll see. I've noticed this bug on ramips platform and can't say anything about other boards. Well, then this is probably a bug in dd? Or uClibc? Or kernel? Ok, I'll try to reproduce it. Can you please tell me what exactly is happening? What happens if you insert some proper fflush() in maccalc? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: add set-macs uci-default script
Hi,
Your patch is mangled (by your e-mail client most likely).
Also I'm currently working on moving set-macs to network script entirely
(inspired by your patch :)). This is more natural because both scripts
work with the same config and also network script needs rework too.
It's for devices that have a full-blown switch. I have on that has only
one ethernet port. I think setting leds should be done in the same way,
not spreading through per-board files.
В Fri, 26 Aug 2011 04:33:30 +0300
Roman Yeryomin leroi.li...@gmail.com пишет:
Signed-off-by: Roman Yeryomin ro...@advem.lv
Index: target/linux/ramips/base-files/etc/uci-defaults/nw718
===
--- a/target/linux/ramips/base-files/etc/uci-defaults/nw718 (revision
28007)
+++ b/target/linux/ramips/base-files/etc/uci-defaults/nw718 (working copy)
@@ -3,30 +3,6 @@
# Copyright (C) 2011 OpenWrt.org
#
-nw718_set_macs() {
- local part
- local lan_mac
- local wan_mac
-
- [ -z $(which maccalc) ] return
-
- . /etc/functions.sh
-
- part=$(find_mtd_part factory)
- [ -z $part ] return
-
- lan_mac=$(dd bs=1 skip=4 count=6 if=$part 2/dev/null | maccalc
bin2mac)
- [ -z $lan_mac ] return
-
- wan_mac=$(maccalc add $lan_mac 1)
-
- uci batch EOF
-set network.lan.macaddr='$lan_mac'
-set network.wan.macaddr='$wan_mac'
-commit network
-EOF
-}
-
nw718_set_leds() {
uci batch EOF
set system.usb_led=led
@@ -45,5 +21,4 @@
if [ ${board} == nw718 ]; then
nw718_set_leds
- nw718_set_macs
fi
Index: target/linux/ramips/base-files/etc/uci-defaults/set-macs
===
--- a/target/linux/ramips/base-files/etc/uci-defaults/set-macs (revision 0)
+++ b/target/linux/ramips/base-files/etc/uci-defaults/set-macs (revision 0)
@@ -0,0 +1,52 @@
+#!/bin/sh
+#
+# Copyright (C) 2011 OpenWrt.org
+#
+
+set_macs() {
+ local mtdname=$1
+ local seek=$2
+ local part
+ local lan_mac
+ local wan_mac
+
+ [ -z $(which maccalc) ] echo set-macs: maccalc not found!
return
+
+ . /etc/functions.sh
+
+ part=$(find_mtd_part $mtdname)
+ [ -z $part ] echo set-macs: partition $mtdname not found!
return
+
+ dd bs=1 skip=$seek count=6 if=$part of=/tmp/mac.bin 2/dev/null
+ lan_mac=$(maccalc bin2mac /tmp/mac.bin)
+ [ -z $lan_mac ] echo set-macs: can't extract mac address
from $part return
+
+ wan_mac=$(maccalc add $lan_mac 1)
+
+ echo Setting LAN mac address to: $lan_mac
+ echo Setting WAN mac address to: $wan_mac
+
+ uci batch EOF
+set network.lan.macaddr='$lan_mac'
+set network.wan.macaddr='$wan_mac'
+commit network
+EOF
+}
+
+. /lib/ramips.sh
+
+board=$(ramips_board_name)
+
+case $board in
+ f5d8235-v2)
+ set_macs u-boot 262148
+ ;;
+ argus-atp52b | \
+ nw718)
+ set_macs factory 4
+ ;;
+ *)
+ echo set-macs: don't know where to get mac address on
this board
+esac
+
+uci commit network
Property changes on: target/linux/ramips/base-files/etc/uci-defaults/set-macs
___
Added: svn:executable
+ *
--
Alexander
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
On 16 September 2011 17:51, Alexander Gordeev lasa...@lvk.cs.msu.su wrote: В Fri, 16 Sep 2011 17:41:37 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: On 16 September 2011 01:40, Alexander Gordeev lasa...@lvk.cs.msu.su wrote: В Fri, 26 Aug 2011 04:30:43 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: This method is much more stable than reading dd's output via stdin. What kind of problems do you have with piping dd's output to stdin? It outputs garbage very frequently and maccalc fails to convert the mac (and as a consequence uci-default script fails to set the real mac address). Try dd without piping to maccalc and you'll see. I've noticed this bug on ramips platform and can't say anything about other boards. Well, then this is probably a bug in dd? Or uClibc? Or kernel? Ok, I'll try to reproduce it. Can you please tell me what exactly is happening? Two different reads: root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0 u���6+0 records in 6+0 records out root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0 u���6+0 records in 6+0 records out I don't think this is the bug in dd/kernel/uclibc - it would probably expose when writing to a file too. Maybe it's something with busybox. I'm not sure of cause. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] package asterisk18-chan-sccp-b
Please apply and allow subversion dir package maintenance rights to user
zandbelt.
This adds chan-sccp-b support to Asterisk 1.8.x.
Chan_SCCP is a replacement Channel Driver for chan_skinny in the Asterisk
Channel
Driver Library. It delivers better performance, scalability, interoperability
and
functionality than either chan_skinny or chan_sip on a SCCP capable phone.
See: http://chan-sccp-b.sourceforge.net
Signed-off-by: Diederik de Groot dkgr...@talon.nl
Signed-off-by: Hans Zandbelt hans.zandb...@gmail.com
---
Index: asterisk-chan-sccp-b/files/sccp.openwrt.conf
===
--- asterisk-chan-sccp-b/files/sccp.openwrt.conf(revision 0)
+++ asterisk-chan-sccp-b/files/sccp.openwrt.conf(revision 0)
@@ -0,0 +1,89 @@
+[general]
+servername = Openwrt
+keepalive = 60
+debug = core
+context = default
+dateformat = D/M/Y
+bindaddr = 192.168.1.1
+port = 2000
+disallow=all
+allow=ulaw
+allow=alaw
+allow=gsm
+firstdigittimeout = 16
+digittimeout = 6
+autoanswer_ring_time = 1
+musicclass=default
+language=en
+deny=0.0.0.0/0.0.0.0
+permit=192.168.1.0/255.255.255.0
+protocolversion=17
+
+hotline_enabled=yes
+hotline_context=default
+hotline_extension=111
+
+[SEP001122334455]
+type = device
+description = Phone Number One
+devicetype = 7940
+button = line, 111
+button = line, 113@01:shared
+button = speeddial,Phone 2 Line 1, 112, 112@hint
+
+[SEP00a1a2a3a4a5]
+type = device
+description = Phone Number Two
+devicetype = 7960
+button = line, 112
+button = line, 113@01:shared
+button = speeddial,Phone 1 Line 1, 111, 111@hint
+
+[111]
+id = 1000
+type = line
+pin = 1234
+label = Phone 1 Line 1
+description = Line 111
+mailbox = 10111
+cid_name = Phone 1 CID
+cid_num = 111
+accountcode=79111
+callgroup=1
+pickupgroup=1
+context = default
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
+[112]
+id = 1001
+type = line
+pin = 1234
+label = Phone 2 Line 1
+description = Line 112
+mailbox = 10112
+cid_name = Phone 2 CID
+cid_num = 112
+accountcode=79112
+callgroup=1
+pickupgroup=1
+context = default
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
+[113]
+id = 1002
+type = line
+pin = 1234
+label = SharedLine 1
+description = Line 113
+mailbox = 10113
+cid_name = Shared
+cid_num = 113
+accountcode=79113
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
Index: asterisk-chan-sccp-b/patches/200-register-file-version.patch
===
--- asterisk-chan-sccp-b/patches/200-register-file-version.patch
(revision 0)
+++ asterisk-chan-sccp-b/patches/200-register-file-version.patch
(revision 0)
@@ -0,0 +1,19 @@
+--- a/src/chan_sccp.h
b/src/chan_sccp.h
+@@ -172,15 +172,7 @@
+ #define CHECK_LEAKS()
+ #endif
+
+-#define SCCP_FILE_VERSION(file, version) \
+- static void __attribute__((constructor)) __register_file_version(void) \
+- { \
+- pbx_register_file_version(file, version); \
+- } \
+- static void __attribute__((destructor)) __unregister_file_version(void)
\
+- { \
+- pbx_unregister_file_version(file); \
+- }
++#define SCCP_FILE_VERSION(file, version)
+
+ #define DEV_ID_LOG(x) x ? x-id : SCCP
+
Index: asterisk-chan-sccp-b/Makefile
===
--- asterisk-chan-sccp-b/Makefile (revision 0)
+++ asterisk-chan-sccp-b/Makefile (revision 0)
@@ -0,0 +1,68 @@
+#
+# Copyright (C) 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:=asterisk18-chan-sccp-b
+# associated with asterisk version
+PKG_VERSION:=1.8.4.4
+# chan-sccp-b version
+PKG_RELEASE:=V4.0.0
+
+# SVN
+PKG_REV=2797
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=https://chan-sccp-b.svn.sourceforge.net/svnroot/chan-sccp-b/trunk
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=$(PKG_REV)
+PKG_SOURCE_PROTO:=svn
+
+PKG_FIXUP:=libtool
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/asterisk18-chan-sccp-b
+ SUBMENU:=Telephony
+ SECTION:=net
+ CATEGORY:=Network
+ TITLE:=SCCP channel provider for asterisk
+ URL:=http://chan-sccp-b.net.sourceforge.net/
+ MAINTAINER:=Diederik de Groot ddegr...@users.sourceforge.net
+ DEPENDS:= asterisk18
+endef
+
+define Package/asterisk18-chan-sccp-b/description
+ SCCP channel provider for asterisk. It delivers extended functionality for
SCCP phones over chan_skinny delivered
+ by asterisk by default.
+endef
+
+define Build/Configure
+ (cd $(PKG_BUILD_DIR); \
+ $(TARGET_CONFIGURE_OPTS) \
+ ./configure \
+ --prefix=/usr \
+--target=$(GNU_TARGET_NAME) \
+--host=$(GNU_TARGET_NAME) \
+--build=$(GNU_HOST_NAME) \
+
[OpenWrt-Devel] Ath9k/hostapd connection dropping problems
Some of this is speculation. I wish I had more precise details. This is true of all trunk versions in last few weeks, when I started using my G300H (v2) as an AP. This includes upto version r28254, which includes yesterday's mac80211 patches, but not today's spam fixes. I have two Linux machines connecting to it. After some amount of time - or what seems more likely, data, the WiFi connections will drop. If left alone, they will come back after about 5 minutes. But it's usually faster to reboot the router. I believe that: * LAN side is unaffected. * It happens after a certain about of traffic, rather than time, since it'll be fine during the night when not much is happening, but be triggered during a download etc during the day. * Attempts to reproduce by running large amounts of traffic with iperf from WiFi - Wired LAN have been inconsistent. * In one case where I saw it triggered, I restarted hostapd, and it seemed to come back, although NetworkManager on Ubuntu become confused, so I'm not certain. * There is nothing of consequence in kernel logs, apart from regular messages from hostapd about group key handshake. So, I'm after ideas about more precise information I can gather, debug I can turn on, etc, etc. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ath9k/hostapd connection dropping problems
Peter, on your Linux machine, you can connect from the command line using wpasupplicant and get much more detailed info about what is going on. On Sep 16, 2011 1:26 PM, Peter Naulls pe...@chocky.org wrote: Some of this is speculation. I wish I had more precise details. This is true of all trunk versions in last few weeks, when I started using my G300H (v2) as an AP. This includes upto version r28254, which includes yesterday's mac80211 patches, but not today's spam fixes. I have two Linux machines connecting to it. After some amount of time - or what seems more likely, data, the WiFi connections will drop. If left alone, they will come back after about 5 minutes. But it's usually faster to reboot the router. I believe that: * LAN side is unaffected. * It happens after a certain about of traffic, rather than time, since it'll be fine during the night when not much is happening, but be triggered during a download etc during the day. * Attempts to reproduce by running large amounts of traffic with iperf from WiFi - Wired LAN have been inconsistent. * In one case where I saw it triggered, I restarted hostapd, and it seemed to come back, although NetworkManager on Ubuntu become confused, so I'm not certain. * There is nothing of consequence in kernel logs, apart from regular messages from hostapd about group key handshake. So, I'm after ideas about more precise information I can gather, debug I can turn on, etc, etc. ___ 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] Ath9k/hostapd connection dropping problems
On 09/16/2011 11:26 AM, Peter Naulls wrote: * In one case where I saw it triggered, I restarted hostapd, and it seemed to come back, although NetworkManager on Ubuntu become confused, so I'm not certain. * There is nothing of consequence in kernel logs, apart from regular messages from hostapd about group key handshake. I believe this is coincident with the connection dropping: Sep 16 11:33:34 OpenWrt daemon.info hostapd: wlan0: STA 00:14:a5:80:84:02 WPA: group key handshake completed (RSN) Sep 16 11:33:34 OpenWrt daemon.info hostapd: wlan0: STA 00:14:a5:80:84:02 WPA: received EAPOL-Key 2/2 Group with unexpected replay counter Sep 16 11:33:34 OpenWrt daemon.info hostapd: wlan0: STA 00:14:a5:80:84:02 WPA: received EAPOL-Key 2/2 Group with unexpected replay counter And also that restarting hostap in a second case resolved the matter. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ath9k/hostapd connection dropping problems
On Fri, Sep 16, 2011 at 2:54 PM, Peter Naulls pe...@chocky.org wrote: On 09/16/2011 11:26 AM, Peter Naulls wrote: * In one case where I saw it triggered, I restarted hostapd, and it seemed to come back, although NetworkManager on Ubuntu become confused, so I'm not certain. * There is nothing of consequence in kernel logs, apart from regular messages from hostapd about group key handshake. I believe this is coincident with the connection dropping: Sep 16 11:33:34 OpenWrt daemon.info hostapd: wlan0: STA 00:14:a5:80:84:02 WPA: group key handshake completed (RSN) Sep 16 11:33:34 OpenWrt daemon.info hostapd: wlan0: STA 00:14:a5:80:84:02 WPA: received EAPOL-Key 2/2 Group with unexpected replay counter Sep 16 11:33:34 OpenWrt daemon.info hostapd: wlan0: STA 00:14:a5:80:84:02 WPA: received EAPOL-Key 2/2 Group with unexpected replay counter And also that restarting hostap in a second case resolved the matter. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel With the G300NH, I've had problems with certain Apple hardware, but other stations (Linux, Win7 and even iTouches) are fine. The iMac station will be disconnected 3 or 4 times in a row, and then it is fine for at least a day and sometimes more. Other stations remain connected. I guess what I'm getting at is that you might want to put a few different wireless chipsets and drivers connected to the AP, and see if they are affected as well. Unfortunately, I still have fairly minimal testing with the G300NH2 when compared to the G300NH. -M ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ath9k/hostapd connection dropping problems
On Fri, 16 Sep 2011 15:08:15 -0400, Mark Deneen wrote: With the G300NH, I've had problems with certain Apple hardware, but other stations (Linux, Win7 and even iTouches) are fine. The iMac station will be disconnected 3 or 4 times in a row, and then it is fine for at least a day and sometimes more. Other stations remain connected. I guess what I'm getting at is that you might want to put a few different wireless chipsets and drivers connected to the AP, and see if they are affected as well. Unfortunately, I still have fairly minimal testing with the G300NH2 when compared to the G300NH. -M I reported a similar issue a couple weeks ago with my D-Link DIR-825 (also uses the ath9k driver). Devices that dropped here included android phones, Nook 1st generation e-readers, Dell Toshiba laptops, and a PS3. The Dell laptops run openSUSE 11.4, the Toshiba runs Windows 7. The Dell laptops include one with a Broadcom chipset and one with an Intel chipset. In my case, when the wireless would quit working, dhcp wouldn't hand out addresses on the wireless connection. The wired stations on the router had no problems at all. In the end, I ended up reverting to build 27572, which I knew worked prior to the upgrade. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ath9k/hostapd connection dropping problems
On 09/16/2011 12:53 PM, Jim Henderson wrote: On Fri, 16 Sep 2011 15:08:15 -0400, Mark Deneen wrote: In the end, I ended up reverting to build 27572, which I knew worked prior to the upgrade. I reverted the mac80211 package only to 27572 earlier today, and it seems to now be working correctly. Felix? ;-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
