[OpenWrt-Devel] DVB tuners
Hi, I am looking into set-top-box applications and wondered if you guys were aware of any devices with DVB functionality. I'm particularly interested in whether there are any Linux SoC devices with interfaces capable of handling multiple DVB tuners. I would guess this could be handles using USB interfaces, but hoped there might be exampled of better ways to achieve it. Thanks in advance, Charlie ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6: network segmentation, use of vlan and IPsec
Hi Gnutella, This is likely not the correct mailing list for general network questions like this, and I'd suggest you go to somewhere like ##networking on Freenode to talk about this, however I'll try to answer your questions :) Firstly, your question seems to lack the clear distinction that should be made between Ethernet (layer2) and IPv6 (layer3). Please ensure that you are clear about the difference and the way in which they interact. For example you talk about MAC addresses in frames, but this is just a basic feature of the underlying Ethernet and is unavoidable when using this medium but would be unnecessary if using a different medium, such as PPP. While IPv6 has no broadcast addresses, it does have a large number of multicast addresses, including some that reach all nodes on a network. Therefore, if the decision to segment a network is based on having too much broadcast traffic (which takes a lot of nodes on a gigabit network to be a problem) then this is unlikely to change with IPv6 due to a similar volume of multicast traffic. Another common reason to segment a network is for security and firewalling, and the choice of layer 3 protocol does not change this. Nodes on the same layer 2 network (VLAN) will communicate with each other directly, whereas those on different layer 2 networks will communicate via a router, which is where firewalling would usually take place. You talk about filtering on a switch. This is usually considered a last resort when it is not practical to segment a network into separate subnets / VLANs. However as far as I know, the process for filtering traffic through a Linux switch is the same for IPv6 as it would be in IPv4, and Linux supports filtering bridged traffic with iptables (and I assume iptables6 though I have never tested this). MAC address filtering - unfortunately, I think this question is lacking some understanding of the interaction between layers. Clients can always use a fake MAC address, but this only affects the local LAN. MAC addresses are always stripped from packets when they pass through a router. It's possible that you aren't talking about MAC addresses at all, but "EUI-64" IP addresses based on MAC addresses. In this case, you will find that most clients by default will use their MAC to generate their primary IP when using SLAAC but will also use additional random "privacy" addresses. It would probably not be a good idea to try to modify (NAT) people's IPs as they pass through a router, though it's certainly possible. I don't know enough about IPsec to answer your last question. I hope some of this is helpful :) Charlie On 27/03/15 07:33, Jean-Michel Pouré - GOOZE wrote: Dear friends, I am studying IPv6 networks and would like to share some ideas with the community. At present, I am not sure to understand how to filter traffic and split networks. Here are a few questions: vlan: IPv6 has no broadcast. Do we still need vlans to segment traffic? Would you recommend using vlans together with IPv6? Filtering a switch: When a device includes a switch, how to filter ipV6 traffic on the switch? Do we need to use Brouting and ebtable or can it be done with iptables6? Mac address filtering: ipv6 embeds MAC address in frames. Clients may generate fake MAC addresses. Is there a way to hide MAC addresses on the router itself? IPsec: IPv6 allows to use IPsec in IPv6 frames. Can it be done already with a combination of FreeRadius, StrongSwan and IPv6. Do you know working configurations in OpenWRT? Kind regards, Gnutella ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On 09/03/15 20:02, valent.turko...@gmail.com wrote: Main issue is that wifi chip manufacturers don't offer open source wifi drivers. If Atheros and Broadcom understood Open source as Intel does then you would get absolutely top speed and reliability from OpenWrt wifi drivers. You don't get top notch performance with OpenWrt because Atheros and Broadcom are choosing not release quality open source drivers. I think you'll get a lot of opposition to the concept that Atheros don't contribute and support this project and Linux in general. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports
I'm also very interested in implementing a switchdev driver (seems to be a good direction for this type of work), so I'd like to see any efforts in this direction so far which I can use as a base for my driver. I was waiting for the switch to Linux 3.19 for the initial code be be easily available. Charlie On 26/02/15 19:58, Alexandru Ardelean wrote: Fully agree on converging. I missed Rafal's switchdev effort. Before starting on this work, I first tried to look into net/dsa in the Linux kernel. I did notice your patches there and started on that. I got to a decent point, but then I was stuck at some issues. I later found out that I needed to adjust the MTU and manually pad potential runt packets. I also found out the switchdev API, which seems like it's in an rather infant state. In any case, I think DSA is the better approach, so my vote is for b53 + DSA (or DSA-like) in the kernel. For this swconfig effort, the reasoning is that our current firmware is @ kernel 3.10, and most of our current target setup logic relies on swconfig; I backported DSA, but because of time/effort constraints to also port, test & validate any b53 PHY setup logic in DSA, we decided that it's easier to adapt the current b53 driver, and later re-visit DSA. And because we have time constraints, there's no telling if we'll have the time to port b53 to DSA, so this patchset is at least meant to share our effort/findings regarding the b53 + LAN ports + Broadcom tag. If things get settled/more calm, I might try to do an effort to do b53 + DSA (if nobody does that before me). Regarding this patchset, I have no objections regarding whether it gets accepted/dropped. Either way, we'll keep it in our tree for a while, and re-evaluate any other DSA (or DSA-like) frameworks later. Thanks Alex On Thu, Feb 26, 2015 at 8:24 PM, Florian Fainelli mailto:f.faine...@gmail.com>> wrote: On 25/02/15 07:24, Alexandru Ardelean wrote: > Feature implemented and tested on BCM53128. > > Slave devices logic copied from the Linux kernel from Marvell's DSA > driver ( linux/net/dsa/ ). > Also the logic for the Broadcom tag processing has been copied from there. There are different efforts here going on, and I would like to at least 3 different people (you, Rafal and myself) can converge to an identical solution that fits everybody here. What net-next supports today is: - broadcom tags in net/dsa/tag_brcm.c, 4-bytes format, identical to yours AFAICT - HW bridging support for bcm_sf2 (roboswitch successor) What's missing: - adding VLAN configuration, which is what Rafal has been doing using here: http://thread.gmane.org/gmane.linux.network/351503 There are a number of things that I want to rework in DSA such that we can almost immediately leverage OpenWrt's switch drivers, where the entry point is a phy_driver, and have them register as switches (DSA or something wider) eventually [1], such that DSA handles the slave devices creation, and also handles the transmission/reception of Broadcom tags for us. This is work in progress, but I expect the patches would be ready by the end of this week. [1]: http://www.spinics.net/lists/netdev/msg295942.html > > OpenWRT's eth_mangle_rx/tx() patch/code is being used to tap into > the packets to/from the ethernet chip since it's convenient. > > This code will create lanX (X = 1..B53_N_PORTS) devices. > All traffic from the ethX device will be forwarded the proper lanX device. > So, sw_port0_traffic == lan1_traffic and so on. > > The slave devices logic has been put into it's own file. > Should this logic be desired to be extended to swconfig or other > switch chips, it should be convenient to just move the slave.c/h files. > > Note: if enable_vlan == 1, be sure to configure VLAN per lanX device > in '/etc/config/network' > > Signed-off-by: Alexandru Ardelean mailto:ardeleana...@gmail.com>> > --- > .../generic/files/drivers/net/phy/b53/Makefile| 2 +- > .../generic/files/drivers/net/phy/b53/b53_common.c | 3 + > .../generic/files/drivers/net/phy/b53/b53_hdr.c | 114 +++- > .../generic/files/drivers/net/phy/b53/b53_priv.h | 2 + > .../generic/files/drivers/net/phy/b53/slave.c | 196 + > .../generic/files/drivers/net/phy/b53/slave.h | 38 > 6 files changed, 352 insertions(+), 3 deletions(-) > create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.c > create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.h > > diff --git a/target/linux/generic/files/drivers/net/phy/b53/Makefile b/target/linux/generic/files/drivers/net/phy/b53/Makefile > index 6c809f9..c74f82b 100644 > --- a/target/linux/generic/files/drivers/net/phy/b53/Makefile >
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
On 17/02/15 15:00, Michael Richardson wrote: The situation which I wanted was to have a port with three or four tagged interfaces visible to the kernel. Of those tagged LANs, I then wanted to have some of the visible on another physical port, untagged. The tagged port goes into a (cisco) SOHO switch, and talks to a bunch of VMs, etc. The untagged ports get wired to a couple of other "critical" systems: the other AP in the house, a VoIP phone (via PoE injector). This lets me put the 3800, and phone on a UPS seperate from the switch and VM hosts. This sounds like a pretty standard VLAN tagging setup, the type of thing that should be well supported by swconfig. It's quite common to have several VLANs, all tagged on the CPU port, and potentially on another trunk ports, then untagged on other ports for connection to different devices. You might configure it like this: swconfig dev switch0 vlan 1 set ports "0t 1t 2" swconfig dev switch0 vlan 2 set ports "0t 1t 3" swconfig dev switch0 vlan 3 set ports "0t 1t 4" swconfig dev switch0 vlan 4 set ports "0t 1t 5" Where port 0 connects to the CPU and has everything tagged. Port 1 connects to your VM trunk, and ports 2,3,4,5 are each on a single untagged VLAN. I hope I'm understanding the use case correctly. Charlie ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
On 16/02/15 21:34, Dirk Neukirchen wrote: There might be 2 interesting posts regarding current/future state and development direction of In-Kernel drivers: 1) rejected in 2013: "net: phy: add Generic Netlink switch configuration API" link: http://lwn.net/Articles/571390/ The thread might be of (historical)/implementation interest That thread mentions some other infrastructure in Kernel (Marvell DSA) (that is not appropriate for OpenWrt according to devs) 2) since November 2014 there is a new switchdev api: introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload link: http://lwn.net/Articles/619446/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Thank you very much. The existence of the 'switchdev' driver / framework is what lead me to think about this, so I might get to work on trying it this way. The hardware NAT issue seems much more complicated, as there seem to be a lot of questions to be answered about integration (or not) with netfilter. I have no particular opinion on this, and will be focusing 100% on the layer2 functionality to begin with. I'll look closely at the "bridge fdb offload" post you mentioned as this seems like a cool integration to start with. Thanks for the links! Charlie ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
Hi David, On 16/02/15 21:03, David Lang wrote: A work-around for many of the items other than the basic VLAN membership and tagging is to force the traffic between the different switch ports to go through the CPU by putting the different ports on different VLANs and then using the kernel bridging/firewalling/etc features. You can't do this between switch ports that are trunked (exposeing the VLAN tags), but other than the cpu load and admin confusion, it works very well to just do this in the kernel. How much of the "functions that requrie active involvement of the CPU" end up being a variation of this? It can certainly be done this way. In fact with my current driver, I could give every port on the switch a different VLAN, tag them all on the CPU port, and do all the real work in the kernel. However this has one serious drawback: poor throughput. A hardware switch can easily do multiple Gbps, whereas the CPU can probably only handle a couple of hundred Mbps. With regard to "functions that requrie active involvement of the CPU", this is where it gets interesting. There is a huge difference in performance between the kernel managing the switch's MAC address table (telling it which port to send a particular destination MAC address to), or having the CPU manage the STP port status, and caching that for a period of time vs sending all the packets in full through the CPU. I am curious as to what other switch device frameworks are out there. Specifically, there is the new "switchdev" framework which I was recommended to look at, and looks good, but doesn't seem to be used much yet, and also openvswitch, which is a little different, but may be an option for some purposes. It's worth noting that the vast majority of OpenWRT devices have a single switch in them, and that switch is typically not the fanciest (although the march of technology mens that every year it's going to be better than it used to be) My thought is that the switch chips in devices are quickly improving, with many supporting a lot of functionality that currently goes unused. I understand this is often because it's unnecessary in a home/office router, or a primarily wireless device, but I think OpenWrt is a great platform and a great base to work on these primarily wired devices as well. David Lang Thanks :) Charlie ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] General questions about the direction of switch drivers
I'm writing a driver for a family of 24 port gigabit switches, with a wide array of interesting hardware features. Creating basic VLAN membership and tagging functionality under the swconfig framework has been quite easy, and this framework has been excellent for this. However, I would like to support a lot more of the functionality of this hardware, and see other devices with advanced layer2 and layer3 switching supported in the future, so I wanted some opinion on the direction things are taking. Specifically I am looking for opinion on whether the swconfig framework is suitable for more advanced functionality, or whether there was likely to be a move to any other upstream framework for switch devices, particularly those with more advanced functionality. The types of functionality I am currently interested in supporting are: * VLAN membership an tagging * Packet and byte counters * Security settings and filtering rules * STP * Layer 3 functionality (hardware IPv4 and IPv6 routing tables) * Hardware NAT / firewall Some of this functionality may simply require configuration, where other functions require the active involvement of the CPU. Thanks, Charlie Charlie Smurthwaite aTech Media tel. 01202 901 222 (ext. 603) email. char...@atechmedia.com<mailto:char...@atechmedia.com> web. atechmedia.com<http://atechmedia.com> aTech Media Limited is a registered company in England and Wales. Registration Number 5523199. Registered Office: Unit 9 Winchester Place, North Street, Poole, Dorset, BH15 1NX. VAT Registration Number: GB 868 861 560. This e-mail is confidential and for the intended recipient only. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] byte counters for IP address using IPTABLES
Is this router doing SNAT? If so, these packets are likely being mangled by connection tracking before they get matched by the filter. Charlie On 04/02/15 13:48, INYO L wrote: hi, I have some trouble about the openwrt system, and the linux kernelver-3.10.49 , iptables version 1.4.21 (barrier_breaker r44257) iptables -I FORWARD -s 192.168.2.226 -j ACCEPT iptables -I FORWARD -d 192.168.2.226 -j ACCEPT iptables -nxv -L FORWARD When I sufing the Internet, the kernel can't get the bytes from source(0.0.0.0/0) to destination(192.168.2.226) . Why ? root@WirelessRouter:/tmp/logs# iptables -nxv -L FORWARD Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 00 ACCEPT all -- * * 0.0.0.0/0 192.168.2.226 14 896ACCEPT all -- * * 192.168.2.226 0.0.0.0/0 101 4724 delegate_forward all -- * * 0.0.0.0/0 0.0.0.0/0 But, I used the kernel-ver-3.10.36 (barrier_breaker r40976), it works! Attachment is a few screenshot. thanks a lot. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] RouterBOARD CRS125-24G-1S
Hi,
Newbie disclaimer: I'm new to this list, and to kernel development, so I
apologise if any of my questions are stupid.
I have taken on the task of porting to the RouterBOARD CRS125-24G-1S. I
have a few specific questions so far and hoped someone would be willing
to provide me with some pointers:
1) This device has an SPI LCD touchscreen. I am unsure where to put a
driver for this, as I couldn't find any existing devices with LCD
screens. This is a particularly interesting feature that I hope to get
working.
2) How might I determine the appropriate partition layout for this
device. I assume this needs to match the Mikrotik layout in order for
their bootloader to work, and to avoid overwriting data needed for WiFi
drivers in the wireless version of the product. Unfortunately, my
understanding of this part is currently very limited.
3) This device has a speaker connected to a GPIO. I am able to make this
click using the LED driver, but is there a driver available to make this
beep, play Auld Lang Syne, etc?
Currently I have NAND and LEDs working, Ethernet working 50% (it won't
receive, not sure why not yet, but I will investigate further when I
start work on the Ethernet switch). I've attached my basic code so far.
Thanks,
Charlie
/*
* MikroTik Cloud Router Switch CRS125G support
*
* Copyright (C) 2012 Stijn Tintel
* Copyright (C) 2012 Gabor Juhos
* Copyright (C) 2015 Charlie Smurthwaite
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published
* by the Free Software Foundation.
*/
#define pr_fmt(fmt) "crs125g: " fmt
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "common.h"
#include "dev-eth.h"
#include "dev-m25p80.h"
#include "dev-nfc.h"
#include "dev-usb.h"
#include "dev-spi.h"
#include "dev-wmac.h"
#include "machtypes.h"
#include "routerboot.h"
#include "dev-leds-gpio.h"
#define CRS125G_GPIO_NAND_NCE 14
/* Partitions are copied from RB2011 and therefore likely incorrect. */
static struct mtd_partition crs125g_nand_partitions[] = {
{
.name = "booter",
.offset = 0,
.size = (256 * 1024),
.mask_flags = MTD_WRITEABLE,
},
{
.name = "kernel",
.offset = (256 * 1024),
.size = (4 * 1024 * 1024) - (256 * 1024),
},
{
.name = "rootfs",
.offset = MTDPART_OFS_NXTBLK,
.size = MTDPART_SIZ_FULL,
},
};
/* NAND works, copied from RB2011. Part: TC58DVG02D5TA00 */
static void crs125g_nand_select_chip(int chip_no)
{
switch (chip_no) {
case 0:
gpio_set_value(CRS125G_GPIO_NAND_NCE, 0);
break;
default:
gpio_set_value(CRS125G_GPIO_NAND_NCE, 1);
break;
}
ndelay(500);
}
static struct nand_ecclayout crs125g_nand_ecclayout = {
.eccbytes = 6,
.eccpos = { 8, 9, 10, 13, 14, 15 },
.oobavail = 9,
.oobfree= { { 0, 4 }, { 6, 2 }, { 11, 2 }, { 4, 1 } }
};
/* Copied from RB2011. Don't know if this is necessary. */
static int crs125g_nand_scan_fixup(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd->priv;
if (mtd->writesize == 512) {
/*
* Use the OLD Yaffs-1 OOB layout, otherwise RouterBoot
* will not be able to find the kernel that we load.
*/
chip->ecc.layout = &crs125g_nand_ecclayout;
}
return 0;
}
void __init crs125g_nand_init(void)
{
gpio_request_one(CRS125G_GPIO_NAND_NCE, GPIOF_OUT_INIT_HIGH, "NAND nCE");
ath79_nfc_set_scan_fixup(crs125g_nand_scan_fixup);
ath79_nfc_set_parts(crs125g_nand_partitions,
ARRAY_SIZE(crs125g_nand_partitions));
ath79_nfc_set_select_chip(crs125g_nand_select_chip);
ath79_nfc_set_swap_dma(true);
ath79_register_nfc();
}
/* GPIO CS for LCD display. This device uses a shared MOSI/MISO Pin
* nCS: 4
* DCX: 5
* SCK: 6
* I/O: 7
*/
static struct ath79_spi_controller_data ath79_spi0_cdata =
{
.cs_type = ATH79_SPI_CS_TYPE_GPIO,
.cs_line = 4,
.is_flash = false
};
/* Set to spidev for now, I haven't got a driver yet. */
static struct spi_board_info ath79_spi_info[] = {
{
.bus_num = 0,
.chip_select = 0,
.max_speed_hz = 15 * 1000 * 1000,
.modalias = "spidev",
.mode = SPI_MODE_0,
.controller_data = &ath79_spi
