Getting netgraph stats
I am having a problem monitoring network stats on jails on a host. Scenario: One host, FreeBSD 12.1, with a small number of vnet jails. I'm using netgraph to bridge two or more VLANs from physical NICs into each jail - so each jail has at least 2 ngether interfaces which are the only NICs in the jail. All of this works well. And then I wanted to see what each of my ngethX interface statistics were doing - from my host. snmpd only sees the physical NICs (of course, because the ngeth ones don't appear any more since the jails are started - they all moved to the jails). As another approach, is there any way for me to get the network stats (in/out packets and in/out bytes) from my ngeth netgraph nodes directly? Or have I missed some other way? I really need to monitor the jails from the outside as I cannot guarantee I can reach snmpd running inside the jail (think of the jail as being a private environment where I cannot route my SNMP requests to). Thanks Paul. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph VLANs on Hyper-V
Hi, I have recently been testing with jails, vnet and netgraph on ESXi - so not Hyper-V - but to make this work I needed to: ngctl msg vmx0: setpromisc 1 ngctl msg vmx0: setautosrc 0 outside of the jail when setting up netgraph (where vmx0 is the "real" NIC that the ng_vlans are part of). and then I had to set the mac address for the ngeth interface that was set to be put into the jail ifconfig ngeth0 ether 02:00:01:02:03:04 Once done, and the jail started, ngeth0 worked as expected. In ESXi, the portgroup that vmx0 is connected to allowed spoofing and promiscuous mode. Paul. On 10/04/2020 08:07, Reshad Patuck wrote: Hi, I am trying to use ng_vlan on Hyper-V to deploy vnet jails. The "Enable MAC address Spoofing" setting on the Hyper-V host is enabled. However when I try to use ng_vlan I am not able to reach the jail. If I change this to if_vlan instead everything works fine. Is there something that creating a VLAN using ifconfig does that ng_vlan does not. The same setup works well on VMware ESXi, Xen and KVM. I am not sure if this is relevant to my issue but the hn1 devices sysrc's changes when I use different vlan methods: no vlan: dev.hn.1.rxfilter: 9 dev.hn.1.hwassist: 17 if_vlan: dev.hn.1.rxfilter: 20 dev.hn.1.hwassist: 17 ng_vlan: dev.hn.1.rxfilter: 9 dev.hn.1.hwassist: 0 All the other sysrc's either stay the same or seem to be counters. I can provide you with scripts to setup vlans and jails with both if_vlan and ng_vlan if that helps. Any help understanding what these sysrc's do, or on how I could get ng_vlan to work would be very appreciated. Best, Reshad ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- Paul Thornton ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: How can I send packets to 255.255.255.255 from the command line?
On 18/08/2016 21:55, Ryan Stone wrote: On Thu, Aug 18, 2016 at 4:48 PM, Paul A. Procacci wrote: You should be able to ping the local subnet. Alternatively you can use net/arping. ~Paul I'm specifically looking to test the handling of 255.255.255.255, so a local broadcast address is out. Unfortunately, arping doesn't seem to do the right thing on FreeBSD. It manages to get the kernel to try arp'ing for 255.255.255.255. This very likely comes under the heading of "horrible bodges" but when I needed to do this, after much experimenting I added a static route to 255.255.255.0/24 pointing to the local LAN broadcast address. For example, on a machine with address 192.168.10.10/24 the "fix" would be: route add 255.255.255.0/24 192.168.10.255 My code could then happily send UDP to 255.255.255.255 without issue, and the packets make it out onto the wire with a broadcast destination MAC address. This was under 10.1-RELEASE; things may have changed that make it no longer work. I did warn you that it came under the heading of "horrible bodges" :) Paul. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Frequent hickups on the networking layer
Hi, On 28/04/2015 22:06, Rick Macklem wrote: ... If your net device driver is one that allocates 9K jumbo mbufs for receive instead of using a list of smaller mbuf clusters, I'd guess this is what is biting you. Apologies for the thread drift, but is there a list anywhere of what drivers might have this issue? I've certainly seen performance decrease in the past between two machines with igb interfaces when the MTU was raised to use 9k frames. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net.inet.ip.forwarding is mysteriously set to 0
Hi On 27/04/2015 06:41, Julian Elischer wrote: Basically all the setup scripts in /etc/rc.d (andaother setup scripts in /etc and /usr/local/etc) all source /etc/rc.conf and it's friends (defaults etc.) if any of thse scripts gets called (for example by devd when it notices a new interface), then the entire chain of dependencies related to that chain will be run **according to how the config files tell it to run* * and not how the current sysctls are set. if you think about it, this must be the case as htey need to change the sysctls as part of their operation. maybe we should have a script to do what you want and also uses sysrc(8) to make it permanent. I don't think this is a major problem to be honest. The issue I had back in January is that the behaviour changed with an upgrade to 10.1 from 8.something as the interaction with devd wasn't well known. I don't know how this can be dealt with unless we have a load of special-cases that log warnings when, for example, forwarding is enabled in sysctl.conf but there isn't a gateway_enable in rc.conf. That sounds like a messy solution to be honest. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net.inet.ip.forwarding is mysteriously set to 0
Hi This happens when any interface is created if you've enabled forwarding with the sysctl and not using gateway_enable in rc.conf. It is easily fixed though. See this thread from January: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=403720+0+archive/2015/freebsd-net/20150104.freebsd-net Paul. On 24/04/2015 17:47, Paul S. wrote: Can confirm that anything to do with netif restart on a forwarding interface also creates the same problem. On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote: Hi, Just saw this. Can somebody re-produce this? root@m4fh2:~ # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 root@m4fh2:~ # ifconfig bridge0 create root@m4fh2:~ # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 That's on GENERIC 10-STABLE from the day before yesterday. Thanks, Nikos ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig greX create disables IPv6 forwarding
On 09/02/2015 16:34, Daniel Corbe wrote: For some reason, every time I create a GRE interface on a FreeBSD IPv6 gateway, net.inet6.ip6.forwarding is disabled. As long as I manually re-enable it with sysctl, both the GRE tunnel and the IPv6 network behind this machine will continue to work; however, it's certainly far from ideal. I stumbled acro I discovered this in January. See this thread: http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or are you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf? devd gets involved running /etc/rc.d/netif start and that seems to check (and set) the forwarding sysctls based on the rc.conf entries - so if you've set them "manually" they get reset when a new interface is brought up. Adding ipv6_gateway_enable="YES" in /etc/rc.conf should fix this. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Issue with forwarding when creates new interface [was USB Tethering and forwarding]
Hi, On 03/01/2015 18:06, Mike Tancsa wrote: do you set forwarding via just /etc/sysctl.conf or in /etc/rc.conf via ipv6_gateway_enable and gateway_enable. I seem to recall some discussion about there being a difference. Perhaps devd is calling something that then fiddles with the setting ignoring whats in sysctl.conf ? That seems to be what is happening. In the earlier post, I was just setting the three sysctls in /etc/sysctl.conf - and observed that forwarding went away if an interface was added. Doing it by setting fastforwarding only in sysctl.conf, and setting both gateway_enables to yes in rc.conf fixes the problem: [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 1 [root@test1 ~]# ifconfig vlan1 create [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 1 That's quite ... odd, to sat the least. I can't see anything in devd.conf which would relate to a new interface being created, but that doesn't mean that there isn't some magic functionality in there. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Issue with forwarding when creates new interface [was USB Tethering and forwarding]
Hi, I can also replicate this behaviour on 10.1-RELEASE by simply creating an additional vlan interface. It affects IPv4 and IPv6 forwarding. This is taken from a test setup of FreeBSD boxes running Quagga as BGP routers - but with a default GENERIC kernel. This machine has 2x ixgbe, 4x igb and 2x bce physical interfaces, with a cloned lo1 and vlan0. [root@test1 ~]# uname -a FreeBSD test1.prtsystems.ltd.uk 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 1 [root@test1 ~]# ifconfig vlan1 create [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 0 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 0 I haven't tried using 10.0 as a router, so don't know if this crept in between 10.0 and 10.1 or 9 and 10. Paul. On 03/01/2015 13:12, wishmaster wrote: Hi, I have been seeing strange behavior of my system lately. After creating new interface the system variable net.inet.ip.forwarding becomes "0". E.g. manually load if_ral kernel module, then rel0 interface appears and net.inet.ip.forwarding becomes "0". Previously this happened when I attached smartphone with USB tethering is on. May be this is VIMAGE-related... Any ideas? Below my original first post. Hi, list. Server works as router for small network and some services in the jails. When I connect Android-based smartphone and attempt to use USB Tethering, the net.inet.ip.forwarding becomes 0 and I must change it to 1 every time. Is this normal behavior? FreeBSD server.local 10.1-STABLE FreeBSD 10.1-STABLE #1 r275636: Mon Dec 22 11:05:33 EET 2014 wishmaster@server.local:/usr/obj/usr/src/sys/SMS i386 Kernel has been compiled with VIMAGE Cheers, Vitaliy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Broadcom BCM57765 support?
On 04/05/2011 18:05, YongHyeon PYUN wrote: > > FYI: Committed to HEAD(r221445). I've been away from the machines with this chipset for the past week so have not finished the testing, but can report that the initial tests I did involving normal use, jumbo frames, v4 and v6 etc. all worked fine and throughput was good. Once I have done a thorough test of the NIC I will post a report here. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Broadcom BCM57765 support?
Hi, Good news - I have success! On 20/04/2011 18:18, YongHyeon PYUN wrote: > Ok, that would indicate there is an interrupt delivery issue if all > others changes(including Marius' patch) are correct. Because there > is no publicly available data sheet for BCM57765 yet I'm not sure > what is real difference between BCM5717 and BCM57765. However I > guess they require similar hardware configuration. Both BCM5717 and > BCM57765 will use tagged status feature of controller if MSI is > available. And NVIDIA bridge controller is known to have MSI issues > for a long time in FreeBSD. Please check whether you received any > interrupts for bge(4) with vmstat(8). If you see no interrupt from > the output, either try disabling MSI or apply r219737 and r219740 > and see whether that makes any difference. The problem is definitely with the interrupts. I saw nothing for bge in vmstat with MSI enabled. Rebooting with MSI disabled and all works well so far - I haven't done a lot of testing yet, but it has been operating with pings / file transfers for over 1 hour now without problems. Apologies for asking such a basic question, but I've typically downloaded latest sources etc. from HEAD via cvsweb in the past when I needed them. How do I locate the r219737 and r219740 changes on their own to try them out with MSI enabled? I'm guessing I'll need to cvsup the relevant sources but I can't see how to find out what I need. Thanks, Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Broadcom BCM57765 support?
Hi, On 20/04/2011 14:44, Marius Strobl wrote: > Hrm, looks like neither NetBSD nor OpenBSD support this variant so > far, however Linux also doesn't seem to have special handling for it. > Could you please give the attached patch in addition to the existing > one a try? I've added your patch to brgphy as well - but at a user level I'm still seeing the same thing: - Ethernet frames are transmitted by the box, switch sees them with no errors. - Frames received don't seem to make it to/beyond the driver. - After I hit CTRL-C on the non-working ping, I get a "bge0: watchdog timeout -- resetting" message. If I tcpdump the interface, I see nothing, but the dev.bge.0.stats counters are incrementing when I attempt to ping. The switch is showing counts on both its tx and rx packets counters with no errors. Is there somewhere I need to add more debug in the driver to understand what it is doing? The current dmesg looks like: bge0: mem 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x00d897, model 0x0024, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Broadcom BCM57765 support?
Hi, On 20/04/2011 14:16, Marius Strobl wrote: > Looks like brgphy(4) also needs to be taught about this hardware. Could > you please provide the corresponding part of a verbose dmesg? Hopefully this covers everything that you might need: pcib4: slot 0 INTA is routed to irq 18 found-> vendor=0x14e4, dev=0x16bc, revid=0x00 domain=0, bus=4, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0x9312, size 16, enabled pcib4: requested memory range 0x9312-0x9312: good pcib0: matched entry for 0.22.INTB (src \\_SB_.PCI0.Z00O:0) pci_link13: Picked IRQ 19 with weight 1 pcib0: slot 22 INTB routed to irq 19 via \\_SB_.PCI0.Z00O pcib4: slot 0 INTB is routed to irq 19 bge0: mem 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x00d897, model 0x0024, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Many thanks, Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Broadcom BCM57765 support?
On 19/04/2011 23:09, YongHyeon PYUN wrote: > Here is experimental patch for BCM57765 family controllers. I > don't have these controllers so the patch was not tested at all > except compile. Recent Broadcom controllers like BCM57765 support > EEE(Energy Efficient Ethernet) feature but it is not yet supported > by the patch. Many thanks for this patch. The patch wouldn't apply cleanly to either the 8.2-release source or to the latest if_bge / if_bgereg so I had to do it manually; but that wasn't too much of a problem. What revision should I have tried to apply the patch to? Things are not fully working yet after the patch is applied though. The current state is that the device is recognised, MAC address detected OK, link state detected OK; you can ifconfig up the interface without a problem. However, I'm seeing "bge0: watchdog timeout -- resetting" messages shortly after attempting to ping something on the LAN. The machine being pinged doesn't show up in the ARP cache. Looking at the switch that its connected to, I see the mac address learned on the port, and the received packet and byte counts incrementing with no errors so I believe that the machine is successfully transmitting frames but not able to receive them properly. The switch stats show that the switch is transmitting frames to the machine. > Also it would good to see the output of "pciconf -lcbv" and dmesg > after applying the patch. The machine in question is a 2010 Mac Mini (model rev A1347) - this has a number of "features" that make FreeBSD an interesting challenge. The kernel I'm using is a normal 8.2-GENERIC with another very minor tweak to stop the Nvidia MCP89 ata controller from being used in SATA mode (this doesn't work - Linux has a workaround based on using UDMA). Attached is a dmesg, pciconf, and the output of sysctl -a dev.bge.0 after the patch was applied. If there is any other debugging information I need to get to help please let me know. Once we have this working I'll willingly give it some thorough proper testing. Thanks again, Paul. Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #1: Wed Apr 20 08:58:24 UTC 2011 r...@badger.prt.org:/usr/src/sys/amd64/compile/GENERIC-TEST2 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (2389.26-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1780576256 (1698 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported acpi_hpet0: iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 2500 Hz quality 900 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) isab0: port 0x2100-0x21ff at device 3.0 on pci0 isa0: on isab0 pci0: at device 3.1 (no driver attached) pci0: at device 3.2 (no driver attached) pci0: at device 3.3 (no driver attached) pci0: at device 3.4 (no driver attached) ohci0: mem 0x9358a000-0x9358afff irq 18 at device 4.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0x9358b100-0x9358b1ff irq 19 at device 4.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.10 usbus1: on ehci0 ohci1: mem 0x93589000-0x93589fff irq 20 at device 6.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0x9358b000-0x9358b0ff irq 21 at device 6.1 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.10 usbus3: on ehci1 pci0: at device 8.0 (no driver attached) atapci0: port 0x2298-0x229f,0x22a4-0x22a7,0x2290-0x2297,0x22a0-0x22a3,0x2280-0x228f mem 0x93584000-0x93585fff irq 23 at device 10.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 11.0 (no driver attached) pcib1: at device 14.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 fwohci0: <1394 Open Host Controller Interface> me
Broadcom BCM57765 support?
Hi, The bge driver doesn't support this chipset yet and I was wondering if anyone has looked at implementing it. NetBSD looks like it has support for it. Now I may be wrong here, but it appears that the BCM57765 is similar to other devices based on the NetBSD if_bge.c source version 1.194. I've tried applying the NetBSD changes to the FreeBSD bge source but I don't know enough about the hardware and the code is different enough that I haven't made it very far. I can get a patched 8.2 kernel to detect the device, complain that the ASIC is unknown, read the MAC address correctly and determine there is link but as soon as you attempt to ifconfig up the interface the machine locks up. I'm happy to try and port this over but need a nudge in the right direction from someone who knows the code. Thanks, Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
On 09/11/2010 20:16, Paul Thornton wrote: > Sorry for that unedited copy of the last mail to the list. Finger trouble in mail client. Must try harder! Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: > I'm also going to give mpd a go and see if that works - but if it tries > the same config options as pppoed then I may be straight back to where I > am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
On 26/10/2010 18:55, Paul Thornton wrote: > I've been taking another look at this after being dragged off onto other > things for a few days, and hopefully have some more information that > might help point in the right direction for a fix / where to debug next. > > On 20/10/2010 17:16, Julian Elischer wrote: >> have you tried to connect this cisco router to anything else pppoe? >> (take it home and make it connect to your ISP for example?) > The Cisco client does work to a Cisco router acting as a PPPoE server - > I used a 891 (client) to a 3945 (server) and using an established setup > that is known to work, I collected a happy tcpdump. Of course that > doesn't tell us why there was such an issue with the FreeBSD ppp server > and it looks very similar to me. > > I'm also going to give mpd a go and see if that works - but if it tries > the same config options as pppoed then I may be straight back to where I > am now. > > Thanks to everyone for their help with this. > > So here is the dump from a known good setup, IOS at both ends - starting > from the CHAP success point again. This time, both ends play the game > and agree amongst themselves what they will and won't do as expected > (many thanks to Ian here for the commentary as to what was going on in > the exchanges I have): > >> 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value >> 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, >> Name vt123456...@vdsl01.v >> 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg >> 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0101 000a >>IP-Addr Option (0x03), length 6: 109.71.168.123 >> 0x: 6d47 a87b >> 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0101 000a >>IP-Addr Option (0x03), length 6: 0.0.0.0 >> 0x: >> 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) >> 0x: 0101 0004 >> 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0201 000a >>IP-Addr Option (0x03), length 6: 109.71.168.123 >> 0x: 6d47 a87b >> 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0301 000a >>IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x: 6d47 ae32 >> 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: c021 0802 000a >>Rejected unknown Protocol (0x8207) >>Rejected Packet >> 0x: 0101 0006 >> 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0102 000a >>IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x: 6d47 ae32 >> 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0202 000a >>IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x: 6d47 ae32 >> 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, >> flags [none], proto ICMP (1), length 100) >> 109.71.174.50 > 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 >> 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, >> flags [none], proto ICMP (1), length 100) >> 217.65.161.4 > 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 > The ping here is the start of real data flowing - I used this setup for > about 30 minutes of web browsing with no problems. > > Paul. > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Polling slows down bandwidth
Hi, On 29/10/2010 18:23, Chuck Swiger wrote: > On Oct 28, 2010, at 11:39 PM, Коньков Евгений wrote: >> so using polling on gigabit NICs is a bottle neck? and is cause of low >> performance, is not? > > Simple answer is yes. It should be possible that you could tune polling to > get similar performance, or at least better performance than you see now, but > the additional hardware capabilities of gigabit NICs are likely to outperform > polling mode, just as polling mode can generally outperform old 100MBs > ethernet NICs. I have been using polling for a long time with em and fxp interfaces on 6.2 and 4.9 boxes that are working as routers. I've been doing testing with FreeBSD 8 and em interfaces recently, and my experience agrees with Chuck's statement - that polling makes things worse when you use new (anything in the last 2 or 3 years) hardware with good quality gigabit ethernet interfaces. I've only really worked with bge and em but they have good high performance without polling in 8.0 and 8.1 Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
I've been taking another look at this after being dragged off onto other things for a few days, and hopefully have some more information that might help point in the right direction for a fix / where to debug next. On 20/10/2010 17:16, Julian Elischer wrote: > have you tried to connect this cisco router to anything else pppoe? > (take it home and make it connect to your ISP for example?) The Cisco client does work to a Cisco router acting as a PPPoE server - I used a 891 (client) to a 3945 (server) and using an established setup that is known to work, I collected a happy tcpdump. Of course that doesn't tell us why there was such an issue with the FreeBSD ppp server and it looks very similar to me. I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. Thanks to everyone for their help with this. So here is the dump from a known good setup, IOS at both ends - starting from the CHAP success point again. This time, both ends play the game and agree amongst themselves what they will and won't do as expected (many thanks to Ian here for the commentary as to what was going on in the exchanges I have): > 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value > 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, > Name vt123456...@vdsl01.v > 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg > 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0101 000a > IP-Addr Option (0x03), length 6: 109.71.168.123 > 0x: 6d47 a87b > 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0101 000a > IP-Addr Option (0x03), length 6: 0.0.0.0 > 0x: > 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) > 0x: 0101 0004 > 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0201 000a > IP-Addr Option (0x03), length 6: 109.71.168.123 > 0x: 6d47 a87b > 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0301 000a > IP-Addr Option (0x03), length 6: 109.71.174.50 > 0x: 6d47 ae32 > 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 > encoded length 10 (=Option(s) length 6) > 0x: c021 0802 000a > Rejected unknown Protocol (0x8207) > Rejected Packet > 0x: 0101 0006 > 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0102 000a > IP-Addr Option (0x03), length 6: 109.71.174.50 > 0x: 6d47 ae32 > 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0202 000a > IP-Addr Option (0x03), length 6: 109.71.174.50 > 0x: 6d47 ae32 > 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, > flags [none], proto ICMP (1), length 100) > 109.71.174.50 > 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 > 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, > flags [none], proto ICMP (1), length 100) > 217.65.161.4 > 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 The ping here is the start of real data flowing - I used this setup for about 30 minutes of web browsing with no problems. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
Hi, On 19/10/2010 22:06, Julian Elischer wrote: > Wireshark understands all the protocols in question so get packet > captures of good and > bad sessions (as similar as you can) and see what is different. > (wireshark reads > tcpdump files so it's easy to capture). As is often the case, the packets on the wire start telling the story of what is happening... still not sure about the why, but progress is being made. Thanks for that nudge. With a Windows XP client (I know, it was nearby though) the following things happen: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP config request Server -> Client IPCP Config request (setting IP address of server end) Client -> Server PPP CCP config request - and they carry on here working fine - With the Cisco client, things break at this point: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP Config request Server -> Client IPCP Config Request (setting IP address of server end) Client -> Server Termination request Server -> Client Termination ack So either that CCP request or the IPCP request is upsetting the Cisco. However, even with its debugging fully on for PPP, it isn't clear why. Initially, my server was requesting deflate compression and VJ compression - so I disabled all compression options in ppp.conf but it made no difference. The tcpdumps were taken after compression was disabled. The cisco config being used on the WAN interface and Dialer interface for testing is as follows. This is an 891 and so is an Ethernet WAN port (no VDSL or other cable interface to add problems): interface GigabitEthernet0 no ip address ip accounting output-packets duplex auto speed auto pppoe enable group global pppoe-client dial-pool-number 1 ! interface Dialer0 description PPPoE dialer mtu 1492 ip address negotiated no ip redirects no ip proxy-arp ip accounting output-packets encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 ppp mtu adaptive ppp authentication chap callin optional ppp chap hostname vt123456...@vdsl01 ppp chap password 0 LetMeIn123 ! ! ip route 0.0.0.0 0.0.0.0 Dialer0 ! dialer-list 1 protocol ip permit ! In terms of the routing, the route being added as a result of the Framed-Route radius attribute does have the correct syntax. For some reason, it had failed to add the /29 route to the routing table in my logs taken yesterday - although that now works fine. That may still be a potential issue but I don't think it is relevant now. To describe what addresses are what (and two of these have changed since yesterday as I was using some that were already occasionally used elsewhere on the network): WAN IP address of router: 217.65.167.128 /32 - set by RADIUS Framed-IP-Address value. LAN subnet of router: 217.65.167.160 /29 - set by RADIUS Framed-Route value. Router's LAN interface has 217.65.167.161/29. IP address of PPPoE server's end of PPP link: 217.65.168.254 VLAN 1005 is just the access side; it has the clients attached to it and has no IP address. Everything happening on there is PPPoE only. The server has another interface which is network side that carries traffic to and from the rest of the world. > also for fun you might look at the documentation for running mpd.. I > dont' remember if it > can do a pppoe SERVER but I vaguely remember that it can. I did once try mpd in the past - I remember it being hard to find any decent documentation for it; especially around PPPoE as a server. It looks very flexible as an option so I may have another crack at it if I can't make the standard ppp work. Does anyone know of any good howto for mpd and pppoe servers? My google skills have lacked severely so far. Here is part of the tcpdump with the XP client, starting at the CHAP success message. I've included quite a lot as there seems to be something going on with IPCP and setting DNS addresses - is this normal? (address ending 5e:ed is the server): > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, > Success (0x03), id 1, Msg Welcome!! > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Request (0x01), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0101 000a > IP-Addr Option (0x03), length 6: 217.65.168.254 > 0x: d941 a8fe > 14:40:27.741765 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S > (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 12: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 6, length 12 > encoded length 10 (=Opt
Problems with 8.1, PPPoE server, and Cisco client
Hi all, I'm hoping that someone can point me in the right direction to get enough debug to troubleshoot a very annoying connection problem with PPPoE to a Cisco. I have a freshly installed 8.1-RELEASE amd64 box with a very simple PPPoE daemon setup on it. This works fine for a test WinXP and Mac OS X client so I know that fundamentally that side of things should be OK. I have also used a similar setup (under 7.0) with all sorts of consumer routers doing PPPoE and it "just works". The server I'm testing with has VLANs on top of igb interfaces, and I haven't seen any other network issues. Using a Cisco 800 series as the client, however, things start off working fine - connects up OK, authenticates, etc. but then it immediately disconnects. There is no clear error as to why the disconnect happens at either end - hence my confusion. I've tried several routers (some direct Ethernet link, some via VDSL) and have upgraded to the latest IOS in an attempt to make this work, nothing changes. Have also tried with 7.2-RELEASE in case it was an 8.X issue - again, same problem seen. Any hints to help debug this (from either end) would be much appreciated. Thanks, Paul. Info follows: FreeBSD vdsl02a 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Oct 19 14:48:21 UTC 2010 r...@vdsl01a:/usr/src/sys/amd64/compile/PPPOE-ROUTER-2 amd64 ppp.conf: default: set log Chat Command Phase#turn on some logging. See man ppp.conf enable pap#turn on chap and pap accounting enable chap allow mode direct #turn on ppp bridging disable proxy #turn on ppp proxyarping disable ipv6cp#don't currently support v6 set mru 1492 #set mru below 1500 (PPPoE MTU issue) set mtu 1492 #set mtu below 1500 (PPPoE MTU issue) set timeout 0 enable lqr echo set echoperiod 5 accept dns set dns 217.65.160.42 set radius /etc/ppp/radius.conf set ifaddr 217.65.168.254/32 # access VLAN PPPoE definitions cv1004e: set device PPPoE:vlan1004:test cv1005e: set device PPPoE:vlan1005:test The daemon is running with the following command: > /usr/libexec/pppoed -P /var/run/pppoed-1005.pid -a test -l cv1005e vlan1005 The RADIUS plumbing works as expected, and the router gets past authentication and gets the correct IP address. ppp.log shows: > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Using interface: tun0 > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Created in closed state > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable pap > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable chap > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable proxy > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable ipv6cp > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mru 1492 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mtu 1492 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set timeout 0 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable lqr echo > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set echoperiod 5 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: accept dns > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set dns 217.65.160.42 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set radius > /etc/ppp/radius.conf > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set ifaddr > 217.65.168.254/32 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: cv1005e: set device > PPPoE:vlan1005:test > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: PPP Started (direct mode). > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Establish > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: closed -> opening > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Link is a netgraph node > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Connected! > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: opening -> carrier > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: carrier -> lcp > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Authenticate > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: his = none, mine = CHAP > 0x05 > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE dropped (got > id 1, not 2) > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE (16 bytes from > vt123456...@vdsl01) > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius: Request sent > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius(auth): ACCEPT received > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: IP 217.65.167.1 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Route: 217.65.167.64/29 > 217.65.167.1 1 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: MTU 1492 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Netmask 255.255.255.255 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: SUCCESS > Oct 19 20:05:36 vdsl02a ppp[2234]:
Current best version for router use
Hi list, A bit of advice please, folks. We currently use 6.2-release + Quagga as a router on a number of boxes. These are stable but we have seen some CPU issues recently and clearly the code is all getting old now, and so I'm starting to look at updating them. Specifically, the hardware consists of a single dual-core Xeon at 2GHz with 2G RAM, containing 10x em interfaces (2x quad PCI-X cards, plus 2 onboard) . IRQ sharing is a bit of an issue and only 8 of those 1G ports can be used without re-using an interrupt. They run with polling enabled, with kern.polling.user_frac = 22 These routers run Quagga 0.99.7 doing v4 and v6 OSPF/BGP. We do use a number of vlans and a couple of gif tunnels. Total throughput varies quite a lot - from 50M to about 200M - but usually isn't high. There seem to be a lot of issues that have appeared around 8.0 and the em code, and although patches have quickly appeared, I know that a lot of the forwarding and routing code in 8 is new - so whilst I would normally have just tested this with 8 and not considered anything else, I am thinking that maybe sticking with 7 is a better plan. I'd appreciate any input from anyone who is using 8.0 in a similar environment, any advice and suggestions would be gratefully received. Thanks, Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw problems using divert and fwd at the same time with 6.3-release
I have found the error of my ways... For the purposes of the archives, I'm posting what actually made this work. It is a very simple fix and I don't quite know how I missed trying this out during my frustrations. Before the "ipfw fwd..." line you need one or more "ipfw skipto..." lines to ensure that you don't accidentally match the more specific addresses on the fwd. What's interesting is that I'd had "ipfw allow..." lines before the "ipfe fwd..." line doing a similar thing to skipto, and it didn't work. So I amended the ruleset to the following (other rules stay the same): 06000 515 153945 divert 8668 ip from any to me via em0 07000485472 skipto 32000 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 07100 0 0 skipto 32000 ip from 10.81.129.0/24 to any 0800094 10434 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80 32000 499 230890 allow ip from any to any Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ipfw problems using divert and fwd at the same time with 6.3-release
Hi folks, I'm having trouble using NAT and forward in the same ipfw ruleset. It appears that the forward "wins" over the NAT regardless of ordering in the ipwf ruleset. I'm hoping that I'm missing something obvious; but is there a way to use these two together? Some background - I'm testing in the lab a potential setup to provide limited network access to a few subnets in 10.X address space, but if you aren't going to an "approved" address then you get forwarded to a web page running on port 8000 on the same box. This box is running 6.3-RELEASE-p9 and has two em interfaces. In this setup, 10.81.0.0/16 are my subnets. They are presented to the machine as a bunch of VLANs physically on em1, one /24 subnet per VLAN. The machine also does DHCP and DNS for each of these VLANs, and is the default gateway. em0 is the external IP address for the machine, currently 192.91.199.5 The machine has no problem accessing the 'net. If I remove the "clever" divert rules and the fwd rule, and make it a vanilla NAT setup, the client has no problem accessing the 'net. In this setup, I expect to be able to browse to www.prt.org (on 217.65.161.4) and that a machine in the 10.81.129.0/24 subnet has unrestricted NATted access to the 'net. Any other attempt at browsing should hit the forward and display the "no access" page from the server on the gateway machine. Using the following ruleset: [r...@xrg1 /var/tmp]# ipfw show 00010 0 0 allow ip from any to any via lo0 00020 0 0 deny ip from any to 127.0.0.1 00022 0 0 deny ip from 127.0.0.1 to any 00050 0 0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68 00052 0 0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68 00054 0 0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68 00056 0 0 allow udp from 10.81.0.0/16 to me dst-port 53 00058 0 0 allow udp from me 53 to 10.81.0.0/16 00060 0 0 allow icmp from 10.81.0.0/16 to me 00062 0 0 allow icmp from me to 10.81.0.0/16 00100 0 0 allow ip from 192.91.199.5 to any 02000 0 0 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 via em0 05000 0 0 divert 8668 ip from 10.81.129.0/24 to any via em0 06000 0 0 divert 8668 ip from any to me via em0 08000 0 0 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80 32000 0 0 allow ip from any to any If I browse "www.prt.org" on the client machine (10.81.2.246) I hit the fwd rule and I get my "Sorry you can't view this" webpage from the local server, and neither of the NAT rules are hit. (DNS on the client correctly resolves to 217.65.161.4) : [r...@xrg1 /var/tmp]# ipfw show 00010 0 0 allow ip from any to any via lo0 00020 0 0 deny ip from any to 127.0.0.1 00022 0 0 deny ip from 127.0.0.1 to any 00050 0 0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68 00052 0 0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68 00054 0 0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68 00056 2 119 allow udp from 10.81.0.0/16 to me dst-port 53 00058 2 356 allow udp from me 53 to 10.81.0.0/16 00060 0 0 allow icmp from 10.81.0.0/16 to me 00062 0 0 allow icmp from me to 10.81.0.0/16 00100 3 214 allow ip from 192.91.199.5 to any 02000 0 0 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 via em0 05000 0 0 divert 8668 ip from 10.81.129.0/24 to any via em0 06000 3 601 divert 8668 ip from any to me via em0 08000434796 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80 3200058 55935 allow ip from any to any If I remove rule 8000, then I can browse to www.prt.org as expected, and I hit the divert rules: 00010 0 0 allow ip from any to any via lo0 00020 0 0 deny ip from any to 127.0.0.1 00022 0 0 deny ip from 127.0.0.1 to any 00050 0 0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68 00052 0 0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68 00054 0 0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68 00056 7 460 allow udp from 10.81.0.0/16 to me dst-port 53 00058 71247 allow udp from me 53 to 10.81.0.0/16 00060 0 0 allow icmp from 10.81.0.0/16 to me 00062 0 0 allow icmp from me to 10.81.0.0/16 00100453375 allow ip from 192.91.199.5 to any 02000385096 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 via em0 05000 0 0 divert 8668 ip from 10.81.129.0/24 to any via em0 0600075 37498 divert 8668 ip from any to me via em0 32000 273 142906 allow ip from any to any The natd config is trivial - I'm just launching it with: natd -port 8668 -same_ports -verbose interface em0 Does anyone have any ideas? I've spent the whole weekend trying various things (l
Re: pppoed problem with reconnections
Hi, Eugene Perevyazko wrote: You have to look at keep-alive settings to terminate dead connections. And why don't you try an mpd (/usr/ports/net/mpd) that is perfectly suited to manage hundreds and thousands of simultaneous ppp (and PPPoE in particular) connections? It's fast, flexible and easy to setup both as server and client. As Luiz suggested, I've changed the config to: enable lqr echo set echoperiod 5 which sorts my problem out just fine. I did look into using mpd - mainly to compare which works best for our situation. However, I was having trouble making any PPPoE connections come up when using mpd; I suspect that this is me not fully understanding what I'm doing - and although I've done quite a bit of looking, I can't find any good example configurations for a PPPoE server using mpd (I'm sure they exist!). Do you have any pointers for this? Regards, Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: pppoed problem with reconnections
Hi Luiz, Luiz Otavio O Souza wrote: Change the enable lqr to: enable lqr echo set echoperiod 5 The ppp will check the remote peer at echoperiod and after five consecutive fails the ppp link will be closed. That does exactly what I want, thank you. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
pppoed problem with reconnections
Hi folks, I am currently doing some lab testing with 6.3-release and a pppoe setup where each user has their own VLAN. On the termination box have an em interface with about 200 VLANs configured on it, and have a ppp.conf looking like this: default: set log Chat Command Phase enable pap enable chap allow mode direct set mru 1462 set mtu 1462 set timeout 0 enable lqr accept dns set dns 192.168.1.1 192.168.1.2 set radius /etc/ppp/radius.conf set ifaddr 192.168.254.254/32 cv1001e: set device PPPoE:vlan1001:cv1001 cv1002e: set device PPPoE:vlan1002:cv1002 cv1003e: set device PPPoE:vlan1003:cv1003 cv1004e: set device PPPoE:vlan1004:cv1004 (and so on for several pages) There are multiple pppoed processes running, one for each VLAN (this might seem wasteful but there are other reasons for doing it this way). All user authentication and IP address assignment is handled by the radius server, and each user ID has a static IP address. The problem I'm seeing is as follows: - PPPoE connection comes in, is authenticated, and a ppp process is exec()ed by pppoed. - This connection has the user's IP address, say 192.168.254.1. - Everything works as expected. This is a Good Thing. - The PPPoE connection is then not disconnected cleanly (say network cable pulled out, or machine reboots, etc) - Back on the termination box, there is still a ppp process running using that address. - When you try and reconnect as the original user, it fails because the address cannot be assigned (already in use). Things then stay like this for ever until I kill the ppp process that was connected with the pppoed running on that VLAN. I don't want to set a timeout as I want these sessions to be always on. Is there any way to configure pppoed to kill the old ppp process before trying to launch the new one, so the IP address is released? I guess I'm asking the reverse of the age old "how do I deny multiple logins" question - how do I allow it, but have the new one boot the old one off? Thanks, Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"