DOCSLIB.ORG

Building Opensync with Openwrt

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Building OpenSync with OpenWrt DATE: December 23, 2019 Document number: 019-1223-31 Table of Contents Introduction 3 OpenSync on OpenWrt Platforms 4 Requirements 4 Integration Steps 5 Preparing the vendor repository 5 vendor-arch.mk 5 CERTIFICATES_PLACEHOLDER 5 target_ARMVIRT.h 5 “src” directory with C source code 5 Choosing the OpenWrt SDK 6 Customizing the build procedure for the OpenSync package 6 Deploying the Example ARMVIRT Target to QEMU 7 Vendor Layer 8 Creating Custom OpenWrt Targets 8 References [1] https://www.opensync.io/documentation/ ​ 2/8 Introduction OpenSync™ is a platform for building software defined networks (SDN). SDNs allow service ​ providers to virtualize network management along with wireless functions. This simplifies their service roll-out. Figure 1: OpenSync block diagram ​ Target layer is an adaptation layer that binds OpenSync managers with low-level SoC/Linux ​ drivers. We refer to the OpenSync compatible devices as targets. ​ ​ There are many different target layer flavors, which can be specific to a particular platform ​ ​ such as RDK or OpenWrt. The scope of this document is vanilla OpenWrt integration. For more information on OpenSync visit https://opensync.io. ​ ​ For more information on OpenWrt, visit https://openwrt.org. ​ ​ 3/8 OpenSync on OpenWrt Platforms The OpenSync OpenWrt meta-project includes components that allow you to create OpenSync ​ ​ ​ packages on OpenWrt based platforms. The OpenWrt meta-project includes: ● opensync/core OpenSync core repository, see OpenSync repository. ​ ​ ​ ​ ​ ● opensync/platform This component implements a common part of the target layer for OpenWrt-based platforms. The opensync/platform component also includes the OpenSync feed for ​ ​ OpenWrt. The repository is available online under the name opensync-platform-openwrt. ​ ​ ● opensync/vendor This repository provides all vendor-specific code, certificates, configuration files, etc. Vendor (Platform integrator) creates and maintains this component. OpenSync comes ​ ​ with a vendor repository template based on QEMU ‘armvirt’ target, available at GitHub under the name opensync-vendor-armvirt. More on customizing that repository template ​ ​ can be found in the following sections. ● Feeds ○ feeds/network/services/opensync/Makefile OpenWrt makefile for the OpenSync ​ ​ build ○ feeds/lang/python/python3-kconfiglib/Makefile OpenWrt makefile for the host-side kconfiglib dependency build Requirements To build OpenSync with OpenWrt, you need the OpenWrt SDK. Download the OpenWrt SDK ​ ​ and complete the below listed integration steps. Requirement: Download OpenWrt SDK and follow the Integration Steps ​ ​ ​ ​ 4/8 Integration Steps Preparing the vendor repository The content of opensync-vendor-armvirt repository is listed below. Vendor (platform integrator) ​ is obliged to modify files in this repository. The necessary modifications for each file are briefly explained below the listing. ├── LICENSE ├── NOTICE ├── README.md ├── build │ └── vendor-arch.mk ├── ovsdb​ │ └── static_configuration.json ├── rootf​s │ └── common │ └── usr │ └── plume │ └── certs │ └── CERTIFICATES_PLACEHOLDER └── src ​ └── lib └── target ├── inc │ └── target_ARMVIRT.h ├── over​ride.mk └── src └── entity.c ​ vendor-arch.mk This file is an element of OpenSync build system. The file enables/disables and configures ​ ​ builds for specific targets. When creating or modifying a new target, change all “armvirt/ARMVIRT” occurrences to the actual target name. ​ CERTIFICATES_PLACEHOLDER Replace files in rootfs/common/usr/plume/certs with appropriate certificates that allow the device to connect to the OpenSync cloud. For more information on how to obtain the certificates ​ ​ contact Plume. target_ARMVIRT.h Rename “target_ARMVIRT.h” to “target_<TARGET>.h”. “src” directory with C source code As mentioned above, you must implement a small Target API subset in the vendor component. ​ The opensync-vendor-armvirt comes with bare minimum that must be implemented to bring-up ​ 5/8 OpenSync connectivity. Use the entity.c file to implement the functions related to the model ​ identifications. Read more about the target layer APIs for the required OpenSync and OpenWrt structures in ​ the target (southbound) API document [1]. ​ ​ Choosing the OpenWrt SDK Let's suppose the package must be built for 18.06.4 OpenWrt on 32 bit armvirt target. The first step is to find an OpenWrt SDK file for that version and architecture. 1. Open https://downloads.openwrt.org/releases/ and navigate to 18.06.4 -> targets -> ​ ​ armvirt -> 32. ​ 2. Under "Supplementary Files", locate the openwrt-sdk-*.tar.xz file and copy the link to ​ that file: NOTE: You can also use search to locate the relevant file for your target. Customizing the build procedure for the OpenSync package ​ ​ OpenSync uses the standard OpenWrt package build procedure. Complete these steps: ​ 1. Add python3-kconfiglib to feeds.conf (build-time dependency): ​ ​ ​ ​ echo "src-link kconfiglib <path-to-this-repo>/feeds/lang" >> feeds.conf 2. Add the opensync feed to feeds.conf: ​ ​ 6/8 echo "src-link opensync <path-to-this-repo>/feeds/network" >> feeds.conf 3. Update and install the feeds: ./scripts/feeds update -a ./scripts/feeds install -a 4. To build the package, specify the following parameters: ​ package/opensync/compile OPENSYNC_SRC=<path-to-this-repo> TARGET=<target> See also the example/ directory for an ARMVIRT example. ​ ​ Deploying the Example ARMVIRT Target to QEMU Complete these steps to deploy the example package to QEMU: 1. Install qemu-system-arm. If you are using Ubuntu, run: ​ ​ sudo apt-get install qemu-system-arm 2. Assuming that you are using the 18.06.4 OpenWrt package, and 32-bit armvirt target, navigate to https://downloads.openwrt.org/releases/18.06.4/targets/armvirt/32/. ​ 3. See the Image Files section. Locate the zImage-initramfs image and copy the link ​ ​ to that file. 7/8 4. Next, run the following command (using the above link): make start_qemu IMAGE_URL=<URL_TO_ZIMAGE> Subsequent uses will not require the IMAGE_URL parameter. ​ ​ 5. Start the QEMU console with the internet connectivity setup. 6. From another terminal push the OpenSync ipk package to the /tmp directory, for ​ example: scp -o StrictHostKeyChecking=no \ out/opensync_1.0-1_arm_cortex-a15_neon-vfpv4.ipk \ [email protected]:/tmp 7. Get back to the QEMU console, and run the following commands: opkg update cd /tmp opkg install opensync_1.0-1_arm_cortex-a15_neon-vfpv4.ipk This installs and starts OpenSync. The logs can be dumped using logread, and OVSDB tables ​ ​ ​ ​ can be inspected using ovsh. ​ ​ Vendor Layer The vendor layer is a place for vendor specific utilities and configuration. Typically it contains utility scripts and certificates. Certificates allow the device to connect to the OpenSync cloud. ​ Contact Plume for more information on how to obtain the certificates. Creating Custom OpenWrt Targets To create a new target, it is best to use the vendor/armvirt tree as a template. ​ ​ Follow these steps for the basic bring-up of a new target: 1. Copy vendor/armvirt to vendor/<new_target> ​ ​ ​ 2. Modify build/vendor-arch.mk, replacing “ARMVIRT” and “armvirt” with the new name ​ ​ 3. Rename and adjust vendor/<new_target>/src/lib/target/inc/target_<new_target>.h ​ 4. Modify vendor/<new_target>/src/lib/target/entity.c so that the functions return ​ ​ the correct model name, id, etc. 5. Modify vendor/<new_target>/ovsdb/static_configuration.json according to ​ ​ actual Wi-Fi radios configuration 6. Copy certificates to vendor/<new_target>/rootfs/common/usr/plume/certs/ ​ 8/8 .
Recommended publications
  • A Letter to the FCC [PDF]

    A Letter to the FCC [PDF]

    Before the FEDERAL COMMUNICATIONS COMMISSION Washington, DC 20554 In the Matter of ) ) Amendment of Part 0, 1, 2, 15 and 18 of the ) ET Docket No. 15­170 Commission’s Rules regarding Authorization ) Of Radio frequency Equipment ) ) Request for the Allowance of Optional ) RM­11673 Electronic Labeling for Wireless Devices ) Summary The rules laid out in ET Docket No. 15­170 should not go into effect as written. They would cause more harm than good and risk a significant overreach of the Commission’s authority. Specifically, the rules would limit the ability to upgrade or replace firmware in commercial, off­the­shelf home or small­business routers. This would damage the compliance, security, reliability and functionality of home and business networks. It would also restrict innovation and research into new networking technologies. We present an alternate proposal that better meets the goals of the FCC, not only ensuring the desired operation of the RF portion of a Wi­Fi router within the mandated parameters, but also assisting in the FCC’s broader goals of increasing consumer choice, fostering competition, protecting infrastructure, and increasing resiliency to communication disruptions. If the Commission does not intend to prohibit the upgrade or replacement of firmware in Wi­Fi ​ ​ devices, the undersigned would welcome a clear statement of that intent. Introduction We recommend the FCC pursue an alternative path to ensuring Radio Frequency (RF) compliance from Wi­Fi equipment. We understand there are significant concerns regarding existing users of the Wi­Fi ​ spectrum, and a desire to avoid uncontrolled change. However, we most strenuously advise against prohibiting changes to firmware of devices containing radio components, and furthermore advise against allowing non­updatable devices into the field.
  • Network Devices Configuration Guide for Packetfence Version 6.5.0 Network Devices Configuration Guide by Inverse Inc

    Network Devices Configuration Guide for Packetfence Version 6.5.0 Network Devices Configuration Guide by Inverse Inc

    Network Devices Configuration Guide for PacketFence version 6.5.0 Network Devices Configuration Guide by Inverse Inc. Version 6.5.0 - Jan 2017 Copyright © 2017 Inverse inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". The fonts used in this guide are licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http:// scripts.sil.org/OFL Copyright © Łukasz Dziedzic, http://www.latofonts.com, with Reserved Font Name: "Lato". Copyright © Raph Levien, http://levien.com/, with Reserved Font Name: "Inconsolata". Table of Contents About this Guide ............................................................................................................... 1 Other sources of information ..................................................................................... 1 Note on Inline enforcement support ................................................................................... 2 List of supported Network Devices ..................................................................................... 3 Switch configuration .......................................................................................................... 4 Assumptions ............................................................................................................
  • Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix

    Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix

    Debian \ Amber \ Arco-Debian \ Arc-Live \ ASLinux \ BeatriX \ BlackRhino \ BlankON \ Bluewall \ BOSS \ Canaima \ Clonezilla Live \ Conducit \ Corel \ Xandros \ DeadCD \ Olive \ DeMuDi \ \ 64Studio (64 Studio) \ DoudouLinux \ DRBL \ Elive \ Epidemic \ Estrella Roja \ Euronode \ GALPon MiniNo \ Gibraltar \ GNUGuitarINUX \ gnuLiNex \ \ Lihuen \ grml \ Guadalinex \ Impi \ Inquisitor \ Linux Mint Debian \ LliureX \ K-DEMar \ kademar \ Knoppix \ \ B2D \ \ Bioknoppix \ \ Damn Small Linux \ \ \ Hikarunix \ \ \ DSL-N \ \ \ Damn Vulnerable Linux \ \ Danix \ \ Feather \ \ INSERT \ \ Joatha \ \ Kaella \ \ Kanotix \ \ \ Auditor Security Linux \ \ \ Backtrack \ \ \ Parsix \ \ Kurumin \ \ \ Dizinha \ \ \ \ NeoDizinha \ \ \ \ Patinho Faminto \ \ \ Kalango \ \ \ Poseidon \ \ MAX \ \ Medialinux \ \ Mediainlinux \ \ ArtistX \ \ Morphix \ \ \ Aquamorph \ \ \ Dreamlinux \ \ \ Hiwix \ \ \ Hiweed \ \ \ \ Deepin \ \ \ ZoneCD \ \ Musix \ \ ParallelKnoppix \ \ Quantian \ \ Shabdix \ \ Symphony OS \ \ Whoppix \ \ WHAX \ LEAF \ Libranet \ Librassoc \ Lindows \ Linspire \ \ Freespire \ Liquid Lemur \ Matriux \ MEPIS \ SimplyMEPIS \ \ antiX \ \ \ Swift \ Metamorphose \ miniwoody \ Bonzai \ MoLinux \ \ Tirwal \ NepaLinux \ Nova \ Omoikane (Arma) \ OpenMediaVault \ OS2005 \ Maemo \ Meego Harmattan \ PelicanHPC \ Progeny \ Progress \ Proxmox \ PureOS \ Red Ribbon \ Resulinux \ Rxart \ SalineOS \ Semplice \ sidux \ aptosid \ \ siduction \ Skolelinux \ Snowlinux \ srvRX live \ Storm \ Tails \ ThinClientOS \ Trisquel \ Tuquito \ Ubuntu \ \ A/V \ \ AV \ \ Airinux \ \ Arabian
  • Comparing Embedded Linux Build Systems and Distros

    Comparing Embedded Linux Build Systems and Distros

    Comparing embedded Linux build systems and distros Drew Moseley Solutions Architect Mender.io Session overview ● Review of embedded Linux development challenges. ● Define build system and criteria. ● Discuss a few popular options. ● Give me an opportunity to learn about some of the other tools. Goal: Help new embedded Linux developers get started About me Drew Moseley Mender.io ○ 10 years in Embedded Linux/Yocto development. ○ Over-the-air updater for Embedded Linux ○ Longer than that in general Embedded Software. ○ Open source (Apache License, v2) ○ Project Lead and Solutions Architect. ○ Dual A/B rootfs layout (client) [email protected] ○ Remote deployment management (server) https://twitter.com/drewmoseley https://www.linkedin.com/in/drewmoseley/ ○ Under active development https://twitter.com/mender_io Challenges for Embedded Linux Developers Hardware variety Storage Media Software may be maintained in forks Cross development Initial device provisioning Simple Makefiles don't cut it (anymore) Facts: ● These systems are huge ● Dependency Hell is a thing ● Builds take a long time ● Builds take a lot of resources ● Embedded applications require significant customization ● Developers need to modify from defaults Build System Defined _Is_ _Is Not_ ● Mechanism to specify and build ● An IDE ○ Define hardware/BSP ● A Distribution components ● A deployment and provisioning ○ Integrate user-space tool applications; including custom ● An out-of-the-box solution code ● Need reproducibility ● Must support multiple developers ● Allow for parallel
  • Presentación De Openwrt Por Jorge Vargas En

    Presentación De Openwrt Por Jorge Vargas En

    OPENWRT POR JORGE VARGAS OPENWRT Distribución de linux para dispositivos embebidos Proviene de Linksys WRT54G Empezo en el 2004 OPENWRT Los nombres de las versiones son bebidas alcoholicas: White Russian Kamikaze Backre Attitude Adjustment Barrier Breaker Chaos Calmer Designated Driver OPENWRT El espacio de usuario es ash, uClibc o musl, y busybox con muchos scripts en lua Manejador de paquetes opkg Unied Conguration Interface (UCI) Conguras todo en un solo lugar - /etc/cong Puedes usar un editor de texto, CLI o GUI Sencillo hacer backups de tu conguracion PROYECTOS SIMILARES DD-WRT Tomato LibreCMC DebianWRT CONTRAS DD-WRT: Es muy dicil realizar contribuciones. Tomato: La licencia de la interfaz de usuario es restrictiva. LibreCMC: OpenWrt sin blobs binarios. DebianWRT: Es Debian. PROFUNDIZANDO Bootloader Arquitecturas Memoria Flash BOOTLOADER En dispositivos embebidos, un "bootloader" inicializa el hardware y luego carga el kernel. Bootloader -> Kernel. Comparado con una PC, que es BIOS -> Grub -> Kernel Das U-Boot (GPL) es el bootloader mas comun BOOTLOADER Los fabricantes tienden a modicar el bootloader Limites de tamano de kernel arbitrarios Valores magicos necesitan estar presentes en el kernel Requieren un formato de rmware especial No soportan ELF Ver http://wiki.openwrt.org/doc/techref/bootloader ARQUITECTURAS La mayoria de los routers son de arquitectura MIPS Tienen una buena relacion rendimiento/costo/poder Tambien soporta ARM, PowerPC y x86 Ver https://dev.openwrt.org/wiki/platforms MEMORIA FLASH Maneja dos formatos principalmente: SquashFS JFFS2 SQUASHFS SquashFS es un sistema de archivos de solo lectura comprimido con LZMA En este tipo de imagen, OpenWrt guarda todo el sistema en una partion de SquashFS, y usa una particion JFFS2 para sobreponer cambios JFFS2 JFFS2 es de lectura/escritura y tambien esta comprimido con LZMA, pero SquashFS es 20-30% mas pequeno SQUASHFS En mi opinion, usar la imagen de SquashFS es la mejor opcion ya que utiliza ambos sistemas de archivos, lo que te permite hacer un "factory reset" COMO EMPEZAR 1.
  • Μvirt: Virtualization on Openwrt

    Μvirt: Virtualization on Openwrt

    μVirt: Virtualization on OpenWrt Mathew McBride <[email protected]> @mcbridematt Why virtualize? ● “Universal CPE” concept ○ Telco point of view: Standardized (“whitebox”) CPE, (Truck)roll once, deploy many ○ Often as a method of extending private cloud to customer “edge” https://www.sdxcentral.com/articles/contributed/understanding-use-universal-cpe/2017/07/ Image from article (ADVA Optical Networking / SDxcentral) Goals ● Demonstrator for small virtualization on ARM64 ● Particular emphasis on “Universal CPE” use case ○ Customer sites with “appliance” spec boxes (typical 4-16GB RAM, <=256GB SSD) ○ Typical setup: Firewall, VoIP, IDS/IPS, SD-WAN VM’s ● Easy to use - works standalone ○ vs OpenStack, Industry (MANO) or commercial NFV stacks. ● Playground for end-to-end solutions ○ Working towards a demonstrator involving central management, SD-WAN/VPN, remote IPMI and full life cycle provisioning via LTE ● Would like to make advanced acceleration techniques available while still integrating with existing OpenWrt config structures Other use cases ● Deploying value add applications to existing fleet ○ E.g Home automation / Smart Home, media servers for residential CPE ○ Some carriers’ residential CPE are in the “micro” uCPE class already ● Multi-tenant virtualized router for MDUs ● Home router and server in a box ○ e.g OpenWrt + NextCloud ● Run software too complex for OpenWrt ● Isolation via VMs Why on OpenWrt? ● Small footprint ○ Fitting inside unmanaged flash (NOR/NAND) provides BOM savings ■ 128MB,1G,64GB,> 128GB price/technology barriers
  • Network Devices Configuration Guide

    Network Devices Configuration Guide

    Network Devices Configuration Guide PacketFence v11.0.0 Version 11.0.0 - September 2021 Table of Contents 1. About this Guide . 2 1.1. Other sources of information . 2 2. Note on Inline enforcement support. 3 3. Note on RADIUS accounting . 4 4. List of supported Network Devices. 5 5. Switch configuration . 6 5.1. Assumptions . 6 5.2. 3COM . 6 5.3. Alcatel . 12 5.4. AlliedTelesis . 16 5.5. Amer . 21 5.6. Aruba. 22 5.7. Avaya. 24 5.8. Brocade. 25 5.9. Cisco . 28 5.10. Cisco Small Business (SMB) . 61 5.11. D-Link. 63 5.12. Dell . 65 5.13. Edge core . 70 5.14. Enterasys . 71 5.15. Extreme Networks. 74 5.16. Foundry . 78 5.17. H3C . 80 5.18. HP . 83 5.19. HP ProCurve . 84 5.20. Huawei . 94 5.21. IBM . 97 5.22. Intel. 98 5.23. Juniper . 98 5.24. LG-Ericsson . 104 5.25. Linksys . 105 5.26. Netgear . 106 5.27. Nortel . 108 5.28. Pica8. 110 5.29. SMC . 111 5.30. Ubiquiti. 112 6. Wireless Controllers and Access Point Configuration . 116 6.1. Assumptions. 116 6.2. Unsupported Equipment . 116 6.3. Aerohive Networks . 117 6.4. Anyfi Networks . 135 6.5. Avaya . 138 6.6. Aruba . 138 6.7. Belair Networks (now Ericsson) . 158 6.8. Bluesocket . 158 6.9. Brocade . 159 6.10. Cambium . 159 6.11. Cisco. 163 6.12. CoovaChilli. 204 6.13. D-Link. 206 6.14. Extricom . 206 6.15. Fortinet FortiGate . 207 6.16. Hostapd .
  • Virtual Router Performance

    Virtual Router Performance

    SOFTWARE DEFINED NETWORKING: VIRTUAL ROUTER PERFORMANCE Bachelor Degree Project in Network and System Administration Level ECTS Spring term 2016 Björn Svantesson Supervisor: Jianguo Ding Examiner: Manfred Jeusfeld Table of Contents 1Introduction..........................................................................................................................................1 2Background...........................................................................................................................................2 2.1Virtualization................................................................................................................................2 2.2Hypervisors...................................................................................................................................2 2.3VMware ESXi................................................................................................................................2 2.4Software defined networking.......................................................................................................3 2.5The split of the data and control plane........................................................................................3 2.6Centralization of network control................................................................................................4 2.7Network virtualization..................................................................................................................4 2.8Software routers..........................................................................................................................6
  • Openwrt Docs Documentation Release

    Openwrt Docs Documentation Release

    Openwrt docs Documentation Release People on the internet Nov 12, 2017 Contents 1 Why use LEDE? 3 2 Download LEDE 5 3 LEDE wants you! 7 4 Contents 9 4.1 LEDE Project Information........................................9 4.2 LEDE Documentation.......................................... 14 5 Endorsements 31 i ii Openwrt docs Documentation, Release The LEDE Project (“Linux Embedded Development Environment”) is a Linux operating system based on OpenWrt. It is a complete replacement for the vendor-supplied firmware of a wide range of wireless routers and non-network devices. See the Table of Hardware for supported devices. For more information about LEDE Project organization, see the About LEDE page. Contents 1 Openwrt docs Documentation, Release 2 Contents CHAPTER 1 Why use LEDE? People install LEDE because they believe it works better than the stock firmware from their vendor. They find it is more stable, offers more features, is more secure and has better support. • Extensibility: LEDE provides many capabilities found only in high-end devices. Its 3000+ application packages are standardized, so you can easily replicate the same setup on any supported device, including two (or even five) year old routers. More about extensibility... • Security: LEDE’s standard installation is secure by default, with Wi-Fi disabled, no poor passwords or back- doors. LEDE’s software components are kept up-to-date, so vulnerabilities get closed shortly after they are discovered. More about security... • Performance and Stability: LEDE firmware is made of standardized modules used in all supported devices. This means each module will likely receive more testing and bug fixing than stock firmware which can be tweaked for each product line and never touched again.
  • Control and Management of Wi-Fi Networks

    Control and Management of Wi-Fi Networks

    Univerza v Ljubljani Fakulteta za elektrotehniko Bojan Pekevski Nadzor in upravljanje omreˇzijWi-Fi MAGISTRSKO DELO Mentor: prof. dr. Andrej Kos Ljubljana, 2016 University of Ljubljana Faculty of Electrical Engineering Bojan Pekevski Control and management of Wi-Fi networks MASTERS THESIS Mentor: prof. dr. Andrej Kos Ljubljana, 2016 Copyright. The results of this Masters Thesis are the intellectual property of the author and the Faculty of Electrical Engineering, University of Ljubljana. For the publication or exploitation of the Masters Thesis results, a written consent of the author, the Faculty of Electrical Engineering, and the supervisor is necessary. ⃝c 2016 Bojan Pekevski Declaration of Masters Thesis authorship I, the undersigned Bojan Pekevski am the author of the Master Thesis enti- tled: Control and management of Wi-Fi networks With my signature, I declare that: • the submitted Thesis is my own unaided work under the supervision of prof. dr. Andrej Kos • all electronic forms of the Masters Thesis, title (Slovenian, English), abstract (Slovenian, English) and keywords (Slovenian, English) are identical to the printed form of the Masters Thesis, • I agree with the university right of saving and reproduction of the copyrighted work in electronic form and the right of enabling public access and download of the copyrighted work online via the "Repository of University of Ljubljana". In Ljubljana, January 2016 Author's signature: Acknowledgments I would like to thank my mentor prof. dr. Andrej Kos and the researchers at Laboratory for Telecommunications at the Faculty of Electrical Engineering, University of Ljubljana, for their guidance and helpful suggestions throughout the process of writing this thesis.
  • A Cache Poisoning Attack Targeting DNS Forwarding Devices

    A Cache Poisoning Attack Targeting DNS Forwarding Devices

    Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices Xiaofeng Zheng∗;†, Chaoyi Lu∗, Jian Peng∗, Qiushi Yang†, Dongjie Zhou§, Baojun Liu∗, Keyu Man‡, Shuang Hao¶, Haixin Duan∗;†∗ and Zhiyun Qian‡ ∗ Tsinghua University, † Qi An Xin Technology Research Institute, § State Key Laboratory of Mathematical Engineering and Advanced Computing, ‡ University of California, Riverside, ¶ University of Texas at Dallas Abstract However, as the DNS ecosystem has evolved dramatically, In today’s DNS infrastructure, DNS forwarders are devices the system now consists of multiple layers of servers [62]. DNS forwarders standing in between DNS clients and recursive resolvers. Specifically, refer to devices standing in be- The devices often serve as ingress servers for DNS clients, tween DNS clients and recursive resolvers. Upon receiving and instead of resolving queries, they pass the DNS requests DNS queries, the devices do not resolve the domain name to other servers. Because of the advantages and several use by themselves, but pass the requests to other servers (e.g., an cases, DNS forwarders are widely deployed and queried by upstream recursive resolver). To name a few use cases, DNS Internet users. However, studies have shown that DNS for- forwarders can serve as convenient default resolvers, load warders can be more vulnerable devices in the DNS infras- balancers for upstream servers, and gateways of access con- tructure. trol. Meanwhile, for clients in a local network, using DNS forwarders can mitigate security risks, as the devices are not In this paper, we present a cache poisoning attack target- directly exposed to Internet attackers [49]. ing DNS forwarders. Through this attack, attackers can in- ject rogue records of arbitrary victim domain names using Because of the advantages, DNS forwarders are fairly a controlled domain, and circumvent widely-deployed cache prevalent devices in the DNS infrastructure.
  • Firewall Builder 4.0 User's Guide Firewall Builder 4.0 User's Guide Copyright © 2003,2010 Netcitadel, LLC

    Firewall Builder 4.0 User's Guide Firewall Builder 4.0 User's Guide Copyright © 2003,2010 Netcitadel, LLC

    Firewall Builder 4.0 User's Guide Firewall Builder 4.0 User's Guide Copyright © 2003,2010 NetCitadel, LLC The information in this manual is subject to change without notice and should not be construed as a commitment by NetCitadel LLC. NetCitadel LLC assumes no responsibility or liability for any errors or inaccuracies that may appear in this manual. Table of Contents 1. Introduction ................................................................................................................... 1 1.1. Introducing Firewall Builder ................................................................................... 1 1.2. Overview of Firewall Builder Features ..................................................................... 1 2. Installing Firewall Builder ................................................................................................ 4 2.1. RPM-based distributions (Red Hat, Fedora, OpenSUSE and others) ............................... 4 2.2. Ubuntu Installation ............................................................................................... 4 2.3. Installing FreeBSD and OpenBSD Ports ................................................................... 5 2.4. Windows Installation ............................................................................................ 5 2.5. Mac OS X Installation .......................................................................................... 5 2.6. Compiling from Source ........................................................................................