[OpenWrt-Devel] [PATCH] cifs depends on kmod-crypto-hash
Signed-off-by: Layne Edwards ledwa...@astrumtech.net Index: package/kernel/modules/fs.mk === --- package/kernel/modules/fs.mk(revision 26505) +++ package/kernel/modules/fs.mk(working copy) @@ -44,6 +44,7 @@ define KernelPackage/fs-cifs SUBMENU:=$(FS_MENU) TITLE:=CIFS support + DEPENDS:=+kmod-crypto-hash KCONFIG:=CONFIG_CIFS FILES:=$(LINUX_DIR)/fs/cifs/cifs.ko AUTOLOAD:=$(call AutoLoad,30,cifs) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] user.info sysinit: RTNETLINK errors
I have some log snips below from a WNDR3700v2. I'm curious what is causing the following errors, it seems to happen one time and never again. This is from r26504: Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: No such file or directory Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.info sysinit: RTNETLINK answers: Invalid argument Mar 27 02:54:00 OpenWrt user.info sysinit: We have an error talking to the kernel Mar 27 02:54:00 OpenWrt user.notice ifup: Allowing Router Advertisements on wan (eth1) dmesg follows: Linux OpenWRT 2.6.37.6 #1 Wed Apr 6 23:51:41 CDT 2011 mips GNU/Linux root@gate:~# dmesg Linux version 2.6.37.6 (wrtdev@openwrt-dev) (gcc version 4.3.3 (GCC) ) #1 Wed Apr 6 23:51:41 CDT 2011 prom: fw_arg0=0006, fw_arg1=a3f6bfb0, fw_arg2=a3f6c450, fw_arg3=0010 MyLoader: sysp=5554, boardp=5554, parts=5554 bootconsole [early0] enabled CPU revision is: 00019374 (MIPS 24Kc) Atheros AR7161 rev 2, CPU:680.000 MHz, AHB:170.000 MHz, DDR:340.000 MHz Determined physical RAM map: memory: 0400 @ (usable) Initrd not found or empty - disabling initrd Zone PFN ranges: Normal 0x - 0x4000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x4000 On node 0 totalpages: 16384 free_area_init_node: node 0, pgdat 802c3460, node_mem_map 8100 Normal zone: 128 pages used for memmap Normal zone: 0 pages reserved Normal zone: 16256 pages, LIFO batch:3 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: board=WNDR3700v2 mtdparts=spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,1024k(kernel),14848k(rootfs),64k(art)ro,15872k@0x7(firmware) rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table
[OpenWrt-Devel] [PATCH] Version bump Minidlna 1.0.19
Version bump minidlna to 1.0.19. I didn't find an official changelog. Reading a diff looks like a change in license from GPL v2 or later to strict GPL v2, as well as bug fixes and translation updates. It's streaming as expected. Two patches were rebased. Signed-off-by: Ian Leonard antonla...@gmail.com --- Index: feeds/packages/multimedia/minidlna/patches/002-makefile-tweaks.patch === --- feeds/packages/multimedia/minidlna/patches/002-makefile-tweaks.patch (revision 26496) +++ feeds/packages/multimedia/minidlna/patches/002-makefile-tweaks.patch (working copy) @@ -1,45 +0,0 @@ a/Makefile -+++ b/Makefile -@@ -13,9 +13,21 @@ - #CFLAGS = -Wall -O -D_GNU_SOURCE -g -DDEBUG - #CFLAGS = -Wall -g -Os -D_GNU_SOURCE - CFLAGS = -Wall -g -O3 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 \ -- -I/usr/include/ffmpeg \ -- -I/usr/include/libavutil -I/usr/include/libavcodec -I/usr/include/libavformat \ -- -I/usr/include/ffmpeg/libavutil -I/usr/include/ffmpeg/libavcodec -I/usr/include/ffmpeg/libavformat -+ -I$(STAGING_DIR)/usr/include \ -+ -I$(STAGING_DIR)/usr/include/FLAC \ -+ -I$(STAGING_DIR)/usr/include/libavcodec \ -+ -I$(STAGING_DIR)/usr/include/libavformat \ -+ -I$(STAGING_DIR)/usr/include/libavutil \ -+ -I$(STAGING_DIR)/usr/include/libexif \ -+ -I$(STAGING_DIR)/usr/include/uuid \ -+ -I$(STAGING_DIR)/usr/include/vorbis \ -+ -I$(ICONV_PREFIX)/include \ -+ -I$(INTL_PREFIX)/include -+LDFLAGS = -L$(STAGING_DIR)/usr/lib \ -+-L$(ICONV_PREFIX)/lib \ -+-L$(INTL_PREFIX)/lib \ -+-Wl,-rpath=$(STAGING_DIR)/usr/lib \ -+-Wl,-rpath-link=$(STAGING_DIR)/usr/lib - #STATIC_LINKING: LDFLAGS = -static - CC = gcc - RM = rm -f -@@ -36,7 +48,7 @@ BASEOBJS = minidlna.o upnphttp.o upnpdes - - ALLOBJS = $(BASEOBJS) $(LNXOBJS) - --LIBS = -lpthread -lexif -ljpeg -lsqlite3 -lavformat -lid3tag -lFLAC -lvorbis -+LIBS = -liconv -lpthread -lexif -ljpeg -lsqlite3 -lavformat -lid3tag -lFLAC -lvorbis -luuid - #STATIC_LINKING: LIBS = -lvorbis -logg -lm -lsqlite3 -lpthread -lexif -ljpeg -lFLAC -lm -lid3tag -lz -lavformat -lavutil -lavcodec -lm - - TESTUPNPDESCGENOBJS = testupnpdescgen.o upnpdescgen.o -@@ -58,7 +70,7 @@ install: minidlna - $(INSTALL) -d $(ETCINSTALLDIR) - $(INSTALL) --mode=0644 minidlna.conf $(ETCINSTALLDIR) - --minidlna: $(BASEOBJS) $(LNXOBJS) $(LIBS) -+minidlna: $(BASEOBJS) $(LNXOBJS) - @echo Linking $@ - @$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(BASEOBJS) $(LNXOBJS) $(LIBS) - Index: feeds/packages/multimedia/minidlna/patches/020-makefile-tweaks.patch === --- feeds/packages/multimedia/minidlna/patches/020-makefile-tweaks.patch (revision 0) +++ feeds/packages/multimedia/minidlna/patches/020-makefile-tweaks.patch (revision 0) @@ -0,0 +1,46 @@ +--- a/Makefile b/Makefile +@@ -13,9 +13,22 @@ + #CFLAGS = -Wall -O -D_GNU_SOURCE -g -DDEBUG + #CFLAGS = -Wall -g -Os -D_GNU_SOURCE + CFLAGS = -Wall -g -O3 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 \ +- -I/usr/include/ffmpeg \ +- -I/usr/include/libavutil -I/usr/include/libavcodec -I/usr/include/libavformat \ +- -I/usr/include/ffmpeg/libavutil -I/usr/include/ffmpeg/libavcodec -I/usr/include/ffmpeg/libavformat ++ -I$(STAGING_DIR)/usr/include \ ++ -I$(STAGING_DIR)/usr/include/FLAC \ ++ -I$(STAGING_DIR)/usr/include/libavcodec \ ++ -I$(STAGING_DIR)/usr/include/libavformat \ ++ -I$(STAGING_DIR)/usr/include/libavutil \ ++ -I$(STAGING_DIR)/usr/include/libexif \ ++ -I$(STAGING_DIR)/usr/include/uuid \ ++ -I$(STAGING_DIR)/usr/include/vorbis \ ++ -I$(ICONV_PREFIX)/include \ ++ -I$(INTL_PREFIX)/include ++LDFLAGS = -L$(STAGING_DIR)/usr/lib \ ++ -L$(ICONV_PREFIX)/lib \ ++ -L$(INTL_PREFIX)/include \ ++ -Wl,-rpath=$(STAGING_DIR)/usr/lib \ ++ -Wl,-rpath-link=$(STAGING_DIR)/usr/lib ++ + #STATIC_LINKING: CFLAGS += -DSTATIC + #STATIC_LINKING: LDFLAGS = -static + CC = gcc +@@ -37,7 +50,7 @@ BASEOBJS = minidlna.o upnphttp.o upnpdes + + ALLOBJS = $(BASEOBJS) $(LNXOBJS) + +-LIBS = -lpthread -lexif -ljpeg -lsqlite3 -lavformat -lavutil -lavcodec -lid3tag -lFLAC -logg -lvorbis ++LIBS = -liconv -lpthread -lexif -ljpeg -lsqlite3 -lavformat -lavutil -lavcodec -lid3tag -lFLAC -logg -lvorbis -luuid + #STATIC_LINKING: LIBS = -lvorbis -logg -lm -lsqlite3 -lpthread -lexif -ljpeg -lFLAC -lm -lid3tag -lz -lavformat -lavutil -lavcodec -lm + + TESTUPNPDESCGENOBJS = testupnpdescgen.o upnpdescgen.o +@@ -62,7 +75,7 @@ install: minidlna + $(INSTALL) -d $(ETCINSTALLDIR) + $(INSTALL) --mode=0644 minidlna.conf $(ETCINSTALLDIR) + +-minidlna: $(BASEOBJS) $(LNXOBJS) $(LIBS) ++minidlna: $(BASEOBJS) $(LNXOBJS) + @echo Linking $@ + @$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(BASEOBJS) $(LNXOBJS) $(LIBS) + Index:
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
On 06/04/11 16:18, Yeoh Chun Yeow wrote: UBNT RS has two ports connected to eth1, port 0 and port 1. If you connect your Ethernet cable to port 0 without first connecting Ethernet cable to port 1, it won't work. You will see a lot of messages Trying 100/FULL, Trying 10/HALF, Trying 10/HALF. Once you connect port 1 with Ethernet cable, you will only see the message eth1: link up (100Mbps/Full duplex) and the port 0 will function properly. Do you know why? So the two ports 0 and 1 are attached to the switch chip ports with those numbers? It seems to me this is some interesting interaction between the switch chip driver and the drivers for your System-on-Chip containing the Ethernet MACs. Those messages about 10/HALF etcetera are, AFAIK, related to querying the PHYs connected to an Ethernet MAC for link state. But if the ADM6996 switch driver is queried for link state, it will invariably return 100 Mbit/s full duplex and link up (function adm6996_read_status). This was already the case before I implemented VLAN functionality, by the way. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
On 05/04/11 08:52, Yeoh Chun Yeow wrote: Untagged packet receive by port 1 is drop. But VLAN 1 and VLAN 2 tagged packet for port 0 is working perfertly. config 'switch_vlan' option 'device' 'eth1' option 'vlan' '1' option 'vid' '1' option 'ports' '0t 1 5t' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '2' option 'vid' '2' option 'ports' '0t 1 5t' It works for me; I just tried it. But it is a curious setup. Did you do it just to test the functionality? Having untagged membership of two VLANs is a nice corner case that might have some use, but is definitely not normal. Since it does work on the M chip, I left it in for those cases where it might be useful. But if it doesn't work on the FC chip, I would just throw the possibility out in the driver once we can differentiate between the two chips. Working for both VLAN tagged and untagged packet. config 'switch_vlan' option 'device' 'eth1' option 'vlan' '1' option 'vid' '1' option 'ports' '0t 5t' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '2' option 'vid' '2' option 'ports' '1 5t' Good to hear a more usual setup does work. I assume this is with the patch you sent earlier? In that case the common case where a port has both untagged and tagged memberships fails, right? Watch out for the primary VLAN ID; pvid property of the port. swconfig dev eth1 show is your friend. The PVID might not always be what you expect. Seeing where untagged packets go is something that needs to be tested for the FC chip. The M chip is configured such that untagged packets coming in on a port are only accepted if the port is a member of its PVID, and sent out to other members of that VLAN. If a port is not a member of the VLAN that is in its PVID, the packets are dropped (i.e., source port filtering, both for tagged and untagged packets). Note that it doesn't matter if a port is a tagged or untagged member of a VLAN, just if it is a member at all. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
Hi Jonas, On 06/04/11 13:34, Jonas Gorski wrote: On 5 April 2011 14:00, Jonas Gorski jonas.gorski+open...@gmail.com wrote: Probably you should dump the (default) register values of the FC and the M and compare them and try to find a difference (best if it's some RO register). Good candidates are the Queue Weight/IGMP registers 0x25 to 0x27 - The bits 12 to 15 are read only on the FC, but writable on the M, so a test if they can be modified should tell whether it's a FC. Also the registers default to 0x2000/4000/8000 on the FC, while the default on the M is 0x1000 for all three. Thank you! Now we're really getting somewhere! I must say: they can create 4 billion Chip Identifiers in a 32-bit ID, did ADMtek /really/ have to use the same ID for the two chips? ;) Any chance that you can get a datasheet for the FC chip? It would help implementing FC functionality a lot. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ifxmips add initial support for wippies homebox
On Wed, Nov 24, 2010 at 8:57 PM, ngp ngp ngp.em...@gmail.com wrote: This patch adds initial support for arv4510 boards (bewan ibox, wippies homebox, elisa) Hi, I have just got a Tele2Box (an ISP in Belgium), which is based on the ARV4510, any idea on how to load openwrt on it? Do I need to flash uboot as a bootloader? http://www.zoobab.com/tele2box Best, -- Benjamin Henrion bhenrion at ffii.org FFII Brussels - +32-484-566109 - +32-2-4148403 In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ifxmips add initial support for wippies homebox
On 07/04/11 12:06, Benjamin Henrion wrote: On Wed, Nov 24, 2010 at 8:57 PM, ngp ngp ngp.em...@gmail.com wrote: This patch adds initial support for arv4510 boards (bewan ibox, wippies homebox, elisa) Hi, I have just got a Tele2Box (an ISP in Belgium), which is based on the ARV4510, any idea on how to load openwrt on it? Do I need to flash uboot as a bootloader? http://www.zoobab.com/tele2box Best, Hi, the flash is not fully supported yet on this board yet. some times this unit already runs uboot. if not you will need to install a custom uboot or reuse the uboot made by wippies. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
On Thursday 07 April 2011, Peter Lebbing wrote: On 06/04/11 16:18, Yeoh Chun Yeow wrote: UBNT RS has two ports connected to eth1, port 0 and port 1. If you connect your Ethernet cable to port 0 without first connecting Ethernet cable to port 1, it won't work. You will see a lot of messages Trying 100/FULL, Trying 10/HALF, Trying 10/HALF. Once you connect port 1 with Ethernet cable, you will only see the message eth1: link up (100Mbps/Full duplex) and the port 0 will function properly. Do you know why? So the two ports 0 and 1 are attached to the switch chip ports with those numbers? It seems to me this is some interesting interaction between the switch chip driver and the drivers for your System-on-Chip containing the Ethernet MACs. Those messages about 10/HALF etcetera are, AFAIK, related to querying the PHYs connected to an Ethernet MAC for link state. But if the ADM6996 switch driver is queried for link state, it will invariably return 100 Mbit/s full duplex and link up (function adm6996_read_status). This was already the case before I implemented VLAN functionality, by the way. Peter. As I understand it on the Routerstation there are two ports on the AR7130 both of which are connected to the switch. eth0 is connected to the port on the switch which just connects to one external RJ54, the upstream WAN port, and then eth1 is connected to the two LAN RJ45s. For reference there is rather simple overview at http://ubnt.com/wiki/RouterStation. So the idea would be to make the two LAN RJ45s individually configurable, as by default they operate quite well as a switch sharing a common config. It would also be useful to be able to sense link up/down transitions. David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Enable Realtek R8169 not only for x86
This enables support for Realtek 8169 based network cards for other platforms than x86. I have a mini-PCI card on ixp4xxx running here. Maybe for the other cards in netdevices.mk a @DEPENDS change from @TARGET_x86 to @PCI_SUPPORT makes also sense. Signed-off-by: Christoph König christoph.koe...@ikt.uni-hannover.de --- Index: package/kernel/modules/netdevices.mk === --- package/kernel/modules/netdevices.mk(revision 26391) +++ package/kernel/modules/netdevices.mk(working copy) @@ -224,7 +224,7 @@ define KernelPackage/r8169 SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:=RealTek RTL-8169 PCI Gigabit Ethernet Adapter kernel support - DEPENDS:=@TARGET_x86 + DEPENDS:=@PCI_SUPPORT KCONFIG:=CONFIG_R8169 \ CONFIG_R8169_NAPI=y \ CONFIG_R8169_VLAN=n ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
Al 04/04/2011 20:21, En/na Luca Olivetti ha escrit: Al 04/04/11 20:17, En/na Luca Olivetti ha escrit: Al 04/04/11 19:57, En/na Felix Fietkau ha escrit: On 2011-04-04 7:51 PM, Luca Olivetti wrote: Al 04/04/11 19:48, En/na Luca Olivetti ha escrit: The following patch adds ath9k support to the arv7518 board. I forgot to say that it needs this patch in mac80211 http://patchwork.midlink.org/patch/727/ without it, initialization of the card would fail (no other harm should be done). I think we should make the endian check unconditional in ath9k. No need to add another field to ath9k_platform.h Well, I cannot say, I just wanted to avoid to breaking working devices. Which I probably did (since I didn't patch, e.g., ar71xx, to add the field) :( Well, what's the final decision? The new field or the unconditional check? (And why atheros made it conditional in the first place?). Also, I checked and the endianness of the various ar71xx devices using ath9k should be the same as mine, so I don't understand why it works on those devices (does it?) and it doesn't on mine. Note that, in the fixup code, the same magic as the ar71xx (0xa55a) works, while I had to change __raw_writel(val, mem + reg); to __raw_writel(cpu_to_le32(val), mem + reg); I'm quite confused. Next we can discuss the performance problem (maybe the root cause is the same, e.g. I'm doing something stupid without realizing). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
So the two ports 0 and 1 are attached to the switch chip ports with those numbers? UBNT RS has three port. From the Left is LAN port 1, LAN port 0 and WAN port. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
But it is a curious setup. Did you do it just to test the functionality? Yes, mainly for testing purpose. Good to hear a more usual setup does work. I assume this is with the patch you sent earlier? Yes, using the patch I posted before. In that case the common case where a port has both untagged and tagged memberships fails, right? Yes, port untagged and tagged membership fails. Watch out for the primary VLAN ID; pvid property of the port. swconfig dev eth1 show is your friend. The PVID might not always be what you expect. Seeing where untagged packets go is something that needs to be tested for the FC chip. The M chip is configured such that untagged packets coming in on a port are only accepted if the port is a member of its PVID, and sent out to other members of that VLAN. If a port is not a member of the VLAN that is in its PVID, the packets are dropped (i.e., source port filtering, both for tagged and untagged packets). Note that it doesn't matter if a port is a tagged or untagged member of a VLAN, just if it is a member at all. Is this mechanism worked for M chip? Anyone can confirm whether FC chip has such capabilities? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
Watch out for the primary VLAN ID; pvid property of the port. swconfig dev eth1 show is your friend. The PVID might not always be what you expect. Seeing where untagged packets go is something that needs to be tested for the FC chip. The M chip is configured such that untagged packets coming in on a port are only accepted if the port is a member of its PVID, and sent out to other members of that VLAN. If a port is not a member of the VLAN that is in its PVID, the packets are dropped (i.e., source port filtering, both for tagged and untagged packets). Note that it doesn't matter if a port is a tagged or untagged member of a VLAN, just if it is a member at all. Is this mechanism worked for M chip? Anyone can confirm whether FC chip has such capabilities? It works as I described on the M chip. It was suggested (by Jonas I believe) that the FC might not have the possibility to use both untagged and tagged membership on the same port. With regard to the filtering capabilities, no idea. I plan to implement identification of M and FC chips and having the driver behave differently for the chips. I suggest I initially submit a driver for inclusion in OpenWRT that only works for the M chip. I feel I have sufficiently tested that target that it ought to work for people with an M chip. It is unfortunate that nobody else appears to have it :). And then, I could have the driver support the FC chip in a manner where a port is either member of one or more tagged VLANs or member of exactly one untagged VLAN, since that is a configuration that appears to work for you, with your patch. You could then test that driver. I don't really feel comfortable submitting a driver for inclusion in OpenWRT for a device I do not have myself, but obviously you or someone else is free to submit that version. It's GPL after all :). Apparently there are a lot more people with FC chips. Having this functionality I intend to implement is already a great start, I suppose. Perhaps the FC can be coaxed to do more stuff as well. If somebody has better ideas on how to handle this properly and to everybody's satisfaction, feel free to offer a suggestion. Peter. PS: Not sure on how long it will take me to produce the two versions of the driver. We'll just have to see when it's ready. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] enable MPPE again, got broken in r26296
Since r26296 mppe.ko could not be loaded, kernel gives device missing error. According to KConfig cypther-ecb is required. Signed-off-by: Sven Roederer mailinglists.sven_at_roederer.dhs.org Index: package/kernel/modules/netsupport.mk === --- package/kernel/modules/netsupport.mk(Revision 26440) +++ package/kernel/modules/netsupport.mk(Arbeitskopie) @@ -526,7 +526,7 @@ define KernelPackage/mppe SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=Microsoft PPP compression/encryption - DEPENDS:=kmod-ppp +kmod-crypto-core +kmod-crypto-arc4 +kmod-crypto-sha1 + DEPENDS:=kmod-ppp +kmod-crypto-core +kmod-crypto-arc4 +kmod-crypto-sha1 +kmod-crypto-ecb KCONFIG:= \ CONFIG_PPP_MPPE_MPPC \ CONFIG_PPP_MPPE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] enable MPPE again, got broken in r26296
On 2011-04-07 8:59 PM, Sven Roederer wrote: Since r26296 mppe.ko could not be loaded, kernel gives device missing error. According to KConfig cypther-ecb is required. Signed-off-by: Sven Roederermailinglists.sven_at_roederer.dhs.org Applied in r26507, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] ipt-debug: create bundle of netfilter modules for debugging
Add a bundle for including commonly useful modules for IPtables debugging and development. For now, it just contains xt_TRACE.ko Signed-off-by: Philip Prindeville phil...@redfish-solutions.com Index: include/netfilter.mk === --- include/netfilter.mk(revision 26505) +++ include/netfilter.mk(working copy) @@ -278,6 +278,10 @@ $(eval $(call nf_add,IPT_ULOG,CONFIG_IP_NF_TARGET_ULOG, $(P_V4)ipt_ULOG)) +# debugging + +$(eval $(call nf_add,IPT_DEBUG,CONFIG_NETFILTER_XT_TARGET_TRACE, $(P_XT)xt_TRACE)) + # tproxy $(eval $(call nf_add,IPT_TPROXY,CONFIG_NETFILTER_XT_MATCH_SOCKET, $(P_XT)xt_socket)) @@ -337,6 +341,7 @@ IPT_BUILTIN += $(IPT_NATHELPER-y) IPT_BUILTIN += $(IPT_NATHELPER_EXTRA-y) IPT_BUILTIN += $(IPT_ULOG-y) +IPT_BUILTIN += $(IPT_DEBUG-y) IPT_BUILTIN += $(IPT_TPROXY-y) IPT_BUILTIN += $(EBTABLES-y) IPT_BUILTIN += $(EBTABLES_IP4-y) Index: package/kernel/modules/netfilter.mk === --- package/kernel/modules/netfilter.mk (revision 26505) +++ package/kernel/modules/netfilter.mk (working copy) @@ -262,6 +262,23 @@ $(eval $(call KernelPackage,ipt-ulog)) +define KernelPackage/ipt-debug + TITLE:=Module for debugging/development + KCONFIG:=$(KCONFIG_IPT_DEBUG) + FILES:=$(foreach mod,$(IPT_DEBUG-m),$(LINUX_DIR)/net/$(mod).ko) + AUTOLOAD:=$(call AutoLoad,45,$(notdir $(IPT_DEBUG-m))) + $(call AddDepends/ipt) +endef + +define KernelPackage/ipt-debug/description + Netfilter modules for debugging/development of the firewall + Includes: + - TRACE +endef + +$(eval $(call KernelPackage,ipt-debug)) + + define KernelPackage/ipt-led TITLE:=Module to trigger a LED with a Netfilter rule KCONFIG:=$(KCONFIG_IPT_LED) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/1] solos: various upstreamed solos patches
These patches were submitted to netdev and will likely be out in 2.6.38.3.
In the meantime, they're needed in 2.6.37.6.
Index: target/linux/generic/patches-2.6.37/282-solos-debug_skbuff.patch
===
--- target/linux/generic/patches-2.6.37/282-solos-debug_skbuff.patch
(revision 0)
+++ target/linux/generic/patches-2.6.37/282-solos-debug_skbuff.patch
(revision 0)
@@ -0,0 +1,51 @@
+commit 18b429e74eeafe42e947b1b0f9a760c7153a0b5c
+Author: Philip A. Prindeville phil...@redfish-solutions.com
+Date: Wed Mar 30 12:59:26 2011 +
+
+atm/solos-pci: Don't include frame pseudo-header on transmit hex-dump
+
+Omit pkt_hdr preamble when dumping transmitted packet as hex-dump;
+we can pull this up because the frame has already been sent, and
+dumping it is the last thing we do with it before freeing it.
+
+Also include the size, vpi, and vci in the debug as is done on
+receive.
+
+Use port consistently instead of device intermittently.
+
+Signed-off-by: Philip Prindeville phil...@redfish-solutions.com
+Signed-off-by: David S. Miller da...@davemloft.net
+---
+ drivers/atm/solos-pci.c |9 -
+ 1 files changed, 8 insertions(+), 1 deletions(-)
+
+diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
+index 2c4146a..968f022 100644
+--- a/drivers/atm/solos-pci.c
b/drivers/atm/solos-pci.c
+@@ -697,7 +697,7 @@ void solos_bh(unsigned long card_arg)
+ size);
+ }
+ if (atmdebug) {
+- dev_info(card-dev-dev, Received: device
%d\n, port);
++ dev_info(card-dev-dev, Received: port
%d\n, port);
+ dev_info(card-dev-dev, size: %d VPI: %d
VCI: %d\n,
+size, le16_to_cpu(header-vpi),
+le16_to_cpu(header-vci));
+@@ -1018,8 +1018,15 @@ static uint32_t fpga_tx(struct solos_card *card)
+
+ /* Clean up and free oldskb now it's gone */
+ if (atmdebug) {
++ struct pkt_hdr *header = (void *)oldskb-data;
++ int size = le16_to_cpu(header-size);
++
++ skb_pull(oldskb, sizeof(*header));
+ dev_info(card-dev-dev, Transmitted: port
%d\n,
+port);
++ dev_info(card-dev-dev, size: %d VPI: %d
VCI: %d\n,
++ size, le16_to_cpu(header-vpi),
++ le16_to_cpu(header-vci));
+ print_buffer(oldskb);
+ }
+
+
Index: target/linux/generic/patches-2.6.37/283-solos-vccs_release.patch
===
--- target/linux/generic/patches-2.6.37/283-solos-vccs_release.patch
(revision 0)
+++ target/linux/generic/patches-2.6.37/283-solos-vccs_release.patch
(revision 0)
@@ -0,0 +1,107 @@
+commit c031235b395433350f25943b7580a5e343c7b7b2
+Author: Philip A. Prindeville phil...@redfish-solutions.com
+Date: Wed Mar 30 13:17:04 2011 +
+
+atm/solos-pci: Don't flap VCs when carrier state changes
+
+Don't flap VCs when carrier state changes; higher-level protocols
+can detect loss of connectivity and act accordingly. This is more
+consistent with how other network interfaces work.
+
+We no longer use release_vccs() so we can delete it.
+
+release_vccs() was duplicated from net/atm/common.c; make the
+corresponding function exported, since other code duplicates it
+and could leverage it if it were public.
+
+Signed-off-by: Philip A. Prindeville phil...@redfish-solutions.com
+Signed-off-by: David S. Miller da...@davemloft.net
+---
+ drivers/atm/solos-pci.c | 26 +-
+ include/linux/atmdev.h |1 +
+ net/atm/common.c|1 +
+ 3 files changed, 3 insertions(+), 25 deletions(-)
+
+diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
+index 968f022..cd0ff66 100644
+--- a/drivers/atm/solos-pci.c
b/drivers/atm/solos-pci.c
+@@ -165,7 +165,6 @@ static uint32_t fpga_tx(struct solos_card *);
+ static irqreturn_t solos_irq(int irq, void *dev_id);
+ static struct atm_vcc* find_vcc(struct atm_dev *dev, short vpi, int vci);
+ static int list_vccs(int vci);
+-static void release_vccs(struct atm_dev *dev);
+ static int atm_init(struct solos_card *, struct device *);
+ static void atm_remove(struct solos_card *);
+ static int send_command(struct solos_card *card, int dev, const char *buf,
size_t size);
+@@ -384,7 +383,6 @@ static int process_status(struct solos_card *card, int
port, struct sk_buff *skb
+ /* Anything but 'Showtime' is down */
+ if (strcmp(state_str, Showtime)) {
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
Hi, Peter You have any clue which datasheet for FC chip should be referred to. For me, it seems that it is not similar to F chip or not totally same with M chip. Regards, Chun Yeow On Thu, Apr 7, 2011 at 10:54 PM, Peter Lebbing pe...@digitalbrains.comwrote: It works as I described on the M chip. It was suggested (by Jonas I believe) that the FC might not have the possibility to use both untagged and tagged membership on the same port. With regard to the filtering capabilities, no idea. I plan to implement identification of M and FC chips and having the driver behave differently for the chips. I suggest I initially submit a driver for inclusion in OpenWRT that only works for the M chip. I feel I have sufficiently tested that target that it ought to work for people with an M chip. It is unfortunate that nobody else appears to have it :). And then, I could have the driver support the FC chip in a manner where a port is either member of one or more tagged VLANs or member of exactly one untagged VLAN, since that is a configuration that appears to work for you, with your patch. You could then test that driver. I don't really feel comfortable submitting a driver for inclusion in OpenWRT for a device I do not have myself, but obviously you or someone else is free to submit that version. It's GPL after all :). Apparently there are a lot more people with FC chips. Having this functionality I intend to implement is already a great start, I suppose. Perhaps the FC can be coaxed to do more stuff as well. If somebody has better ideas on how to handle this properly and to everybody's satisfaction, feel free to offer a suggestion. Peter. PS: Not sure on how long it will take me to produce the two versions of the driver. We'll just have to see when it's ready. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/1] ipt-debug: create bundle of netfilter modules for debugging
Add a bundle for including commonly useful modules for IPtables debugging and development. For now, it just contains xt_TRACE.ko Respun with DEFAULT:=n Signed-off-by: Philip Prindeville phil...@redfish-solutions.com Index: include/netfilter.mk === --- include/netfilter.mk(revision 26505) +++ include/netfilter.mk(working copy) @@ -278,6 +278,10 @@ $(eval $(call nf_add,IPT_ULOG,CONFIG_IP_NF_TARGET_ULOG, $(P_V4)ipt_ULOG)) +# debugging + +$(eval $(call nf_add,IPT_DEBUG,CONFIG_NETFILTER_XT_TARGET_TRACE, $(P_XT)xt_TRACE)) + # tproxy $(eval $(call nf_add,IPT_TPROXY,CONFIG_NETFILTER_XT_MATCH_SOCKET, $(P_XT)xt_socket)) @@ -337,6 +341,7 @@ IPT_BUILTIN += $(IPT_NATHELPER-y) IPT_BUILTIN += $(IPT_NATHELPER_EXTRA-y) IPT_BUILTIN += $(IPT_ULOG-y) +IPT_BUILTIN += $(IPT_DEBUG-y) IPT_BUILTIN += $(IPT_TPROXY-y) IPT_BUILTIN += $(EBTABLES-y) IPT_BUILTIN += $(EBTABLES_IP4-y) Index: package/kernel/modules/netfilter.mk === --- package/kernel/modules/netfilter.mk (revision 26505) +++ package/kernel/modules/netfilter.mk (working copy) @@ -262,6 +262,24 @@ $(eval $(call KernelPackage,ipt-ulog)) +define KernelPackage/ipt-debug + TITLE:=Module for debugging/development + KCONFIG:=$(KCONFIG_IPT_DEBUG) + DEFAULT:=n + FILES:=$(foreach mod,$(IPT_DEBUG-m),$(LINUX_DIR)/net/$(mod).ko) + AUTOLOAD:=$(call AutoLoad,45,$(notdir $(IPT_DEBUG-m))) + $(call AddDepends/ipt) +endef + +define KernelPackage/ipt-debug/description + Netfilter modules for debugging/development of the firewall + Includes: + - TRACE +endef + +$(eval $(call KernelPackage,ipt-debug)) + + define KernelPackage/ipt-led TITLE:=Module to trigger a LED with a Netfilter rule KCONFIG:=$(KCONFIG_IPT_LED) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
