pppoe gateway routing issues
First off if this shows up as html, I apologize, I'm temporarily using a web based client. This email contains my configuration files so is kind of long but I hope this will give as much information as possible. I just got DSL after riding myself of my cable modem. The DSL I have is using pppoe. I was able to get this up and running on my laptop. I am now working on my gateway machine to get my LAN back up and running. I have used the how-to's listed in the freebsd diary ( http://www.freebsddiary.org/pppoe.php ) I also tried http://www.daemonnews.org/200101/pppoe.html These worked fine on my laptop and I was able to surf the web no problem. I then went to configure my gateway box. I added the appropriate options to the kernel and recompiled. I added the neccesary "ppp" lines to my rc.conf. I also created my ppp.conf. When I boot the machine I get the IP addresses but when I try to pass any traffic I get "no route to host" messages. I make sure my default gateway is setup correctly (which it appears to be as such). I delete the the default route and add it myself but this does not work either. I've tried using the routed daemon but I get the following error messages when I do that: (IP_ADD_MEMBERSHIP RIP) can't assign requested address setsockopt(IP_ADD_MEMBERSHIP RIP): Can't assign requested address After looking at my config files is there anything I am missing? Any other offers and suggestions? Thank you in advanced. Please CC: me as I am no longer on this list until I start my new job later this week. Rob UNAME -A: FreeBSD PITA.the-rob.com 4.5-RC FreeBSD 4.5-RC #2 Sat Jan 19 13:35:26 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/FIREWALL i386 RC.CONF: # -- sysinstall generated deltas -- # # Created: Thu Jul 26 10:02:13 2001 # Enable network daemons for user convenience. # This file now contains just the overrides from /etc/defaults/rc.conf # please make all changes to this file. gateway_enable="YES" hostname="PITA.the-rob.com" network_interfaces="xl0 dc0 lo0" ifconfig_dc0="inet 192.168.1.1 netmask 255.255.255.0" ifconfig_lo0="inet 127.0.0.1" ifconfig_xl0="inet 10.0.0.1 netmask 255.255.255.0" #ifconfig_xl0="DHCP" inetd_enable="YES" kern_securelevel_enable="NO" linux_enable="YES" sshd_enable="YES" # -- sysinstall generated deltas -- # ntpdate_flags="time.nist.gov" ntpdate_enable="YES" portmap_enable="NO" update_motd="NO" font8x8="/usr/share/syscons/fonts/iso02-8x8.fnt" allscreens_flags="132x43" syslogd_flags="-ss" sshd_flags="-4" ipfilter_enable="YES" ipmon_enable="YES" ipmon_flags="-Dsvn" ipnat_enable="YES" #router_flags="-q" #router="routed" #router_enable="YES" ppp_enable="YES" ppp_mode="ddial" ppp_profile="tds" ppp_nat="YES" PPP.CONF: # # ppp.conf: pppoe configuration # from http://www.daemonnews.org/200101/pppoe.html # default: #ppp over ethernet set device PPPoE:xl0: set speed sync set mru 1492 set mtu 1492 set ctsrts off # monitor line quality enable lqr # log just a bit set log Phase tun # insert default route upon connection add default HISADDR # download /etc/resolv.conf enable dns tds: set authname USERNAME set authkey PASSWORD IFCONFIG: dc0: flags=8843 mtu 1500 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::220:78ff:fe08:5e76%dc0 prefixlen 64 scopeid 0x1 ether 00:20:78:08:5e:76 media: Ethernet autoselect (100baseTX ) status: active xl0: flags=8843 mtu 1500 options=3 inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::204:76ff:feb8:267c%xl0 prefixlen 64 scopeid 0x2 ether 00:04:76:b8:26:7c media: Ethernet autoselect (10baseT/UTP) status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 faith0: flags=8002 mtu 1500 tun0: flags=8051 mtu 1492 inet6 fe80::220:78ff:fe08:5e76%tun0 prefixlen 64 scopeid 0x5 inet 216.170.184.59 --> 216.170.184.1 netmask 0xff00 Opened by PID 59 NETSTAT -R: Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default216.170.184.1 UGSc21 tun0 10/24 link#2 UC 00xl0 localhost localhost UH 00lo0 192.168.1 link#1 UC 00dc0 216.170.184.1 216.170.184.59 UH 30 tun0 IPX: DestinationGatewayFlags Netif Expire Internet6: Destination
Re: pppoe gateway routing issues (with updates)
> ---SNIP--- > >>gateway_enable="YES" > > good > >>hostname="PITA.the-rob.com" >>network_interfaces="xl0 dc0 lo0" >>ifconfig_dc0="inet 192.168.1.1 netmask 255.255.255.0" >>ifconfig_lo0="inet 127.0.0.1" >>ifconfig_xl0="inet 10.0.0.1 netmask 255.255.255.0" > > still looking good > >>ipfilter_enable="YES" >>ipmon_enable="YES" >>ipmon_flags="-Dsvn" >>ipnat_enable="YES" > > Yikes... note you have NAT here. > --SNIP--- Thanks for the help, I tried that earlier to no avale. New stuff. I left my laptop plugged into my internal lan and I was able to jump onto the internet fine, so here's the new deal. Configs have NOT changed at all. I can pass traffic from anything behind the gateway to the outside world just fine. But the gateway still cannot reach the internet. it cannot even ping the local IP address assigned to it (216.170.184.161) Also people are not able to ping my IP or reach any of my services. Disabling either of the ipnat or ppp_nat in the rc.conf makes no difference same results, I can get on the net, no one can ping/ftp/ssh to me. Any other suggestions? Anyone? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ip src address in outgoing ipv4 multicast packets
I was just wondering why the src address is set to the host group in outgoing multicast packets on RELENG_4? As far as I can tell, rfc1054 says that the src address should be set to that of the host, not the host group (6.2). The behavior exists in 4.5-release also. I noticed this because linux seems to reject mc packets with a multicast source address (which is also incorrect according to section 7.2). Looking at the source, it seems trivial to get the correct (?) behavior. Is there some reason why we shouldn't do this? -r To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ip src address in outgoing ipv4 multicast packets
* Rob ([EMAIL PROTECTED]) [020522 20:30]: > I was just wondering why the src address is set to the host group in > outgoing multicast packets on RELENG_4? As far as I can tell, rfc1054 > says that the src address should be set to that of the host, not the > host group (6.2). The behavior exists in 4.5-release also. > > I noticed this because linux seems to reject mc packets with a multicast > source address (which is also incorrect according to section 7.2). > > Looking at the source, it seems trivial to get the correct (?) behavior. > Is there some reason why we shouldn't do this? If anyone cares I just submitted a pr with an attached patch which will fix this problem. What is a good avenue to get this incorporated into the main tree? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38473 -r To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ip src address in outgoing ipv4 multicast packets
* Naga Narayanaswamy ([EMAIL PROTECTED]) [020523 19:21]: > When you say src address is set to host group, what application generates > them? What is the src and dest address ? I quickly checked Rich Stevens vol > II. > Looks like the code has been like this since old days. > Is the application setting the src address as mc group intentionally? yes, it does in the call to bind, though I wouldn't think that one would have to use two sockets for outgoing / incoming traffic if we just wanted to restrict incoming traffic to have a dst address of the host's group. -r To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: SOLVED! PPPoE Broken (4.6-Stable)
Thanks for the response Mike, but pppoe still seems to be broken. Disableing vjcomp didn't seem to work for me. I tried it with enable vjcomp disable vjcomp in my ppp.conf file. Didn't seem to help. I did get Brian Somer's fix to /usr/src/sys/netgraph/ng_pppoe.c This didn't seem to help either, though all the ^K^H and all the other mumbo jumbo that was in log files. Below I've inclued 1) current tcpdumps 2) logs from the tcpdump and 3) logs from the night before when I was connected. I still seem to be able to connect up for 24 hours then go down for 3-36 hours until I come back up. Hopefully these all help. 23:23:26.187588 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ee] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f34be4 23:23:28.189353 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ee] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f34be4 23:23:30.189645 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5ee] 23:23:42.967392 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:23:44.962604 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:23:44.988214 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 23:23:44.988290 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:23:45.301353 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0xa5ef] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:23:45.317586 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:47.316406 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:48.014436 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0xa5ef] [Generic-Error "session closed"] 23:23:49.317691 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:51.367007 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:53.366558 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:55.368324 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:57.368611 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:59.369153 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:24:01.369940 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:24:03.370716 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:24:05.371753 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5ef] 23:24:18.037729 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:24:20.033133 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:24:20.056497 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 23:24:20.056576 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:24:20.361739 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0xa5f0] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:24:20.390555 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:22.390848 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:23.084963 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0xa5f0] [Generic-Error "session closed"] 23:24:24.391389 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:26.392672 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:28.392963 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:30.393491 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:32.394777 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:34.395562 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(8), MRU
vnet - using a jail as a default firewall gateway to internet
Hi, I have been playing with vnet jails, and have a configuration working that I thought would not be (based on the docs out there), but it is. I have a box with 3 NICS - hme0, em0 and em1. Basically, with the assumption that the internet facing gateway is potentially a weak point, I set out to configure a jail on the above box to be the gateway, rather than the physical host itself. I recompiled the kernel, with the VIMAGE option, and setup a jail that uses em0 (192.168.x.y) as the lan side and hme0 (public IP a.b.c.d) is the ISP side. On the jail itself, its default route to the internet is public IP a.b.c.e (same network of interface hme0 above). Then I set the rest of my lan to point to 192.168.x.y (interface em0 above) as the default gateway. I have access to the internet with that configuration, routing through the jail (or at least I think so) - everything seems to work. The two errors I get upon starting the jail, are: "sysctl: net.inet.ip.sourceroute not permitted" and "sysctl: net.inet.ip.accept_sourceroute not permitted. Any body knows what may be broken with my configuration? All the docs I read about having a jail route traffic seemed to imply it is undoable. Did I create a glaring whole in my network by having this design as my firewall and router? I also noticed that the physical host is doing all the logging for dmesg and security, when I thought the jail would, but it is beginning to make sense that the kernel is only running on the physical host, and therefore does the logging of all kernel related activities. Any comments or suggestions welcome. Thanks, Robert ___ 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"
IPv6 routing
Hi, I previously had a freebsd 7.0 box set up as an IPv6 router for my home network, behind a sixxs tunnel. It was running rtadvd to hand out IPv6 addresses from my sixxs block to the network. However, after migrating this configuration over to a newly installed FreeBSD 7.2 box it appears that the machine will no longer route IPv6. All the correct settings seem to be enabled as described here: http://www.freebsd.org/doc/en/books/handbook/network-ipv6.html, and the configurations are identical to the 7.0 box. The only odd thing I can see is that the machine is not getting an IPv6 address on the lan-facing interface, which would explain why it can't route anything. There are no issues with the sixxs tunnel itself or IPv6 connectivity from the machine; it is also handing out IPv6 addresses to hosts on the network via RAs. Could there be something I'm missing? rg -- rob.gallagher (at) gmail.com || www.spoofedpacket.net || PK: 0x1DD13A78 ___ 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"
em driver packet loss in 6.2 amd64 (RELEASE and STABLE)
Hi, In 6.1-RELEASE there were a number of em driver stability and performance issues. We would regularly see packet loss at low to moderate load. A number of patches were applied that completely fixed the problem for us. We installed 6.2-RELEASE, but even though 6.2 is supposed to have a stable em driver, we are noticing the same packet loss problem again. We updated to STABLE, and we didn't see any packet drops in our first day of testing, but today we are seeing packet drops again. Has anyone else experienced this? Are there known problems with the STABLE em driver? Our hardware: tyan s5372 motherboard (bios v1.05) 2 intel x5355 processors adaptec aic7902 scsi daughter card there are 4 em interfaces (2 on-board, 2 from an add-on card), but we are currently only using em0 We have experienced the packet drop problem with a custom kernel and with the RELEASE SMP kernel. - Rob Watt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em driver packet loss in 6.2 amd64 (RELEASE and STABLE)
Nevermind. After some more research it seems that we were having problems with the risers cards on some of our servers. I will do some more testing after the riser cards are replaced to see if we still have multicast drops when using 6.2. Most likely it was purely a hardware problem. Since it was the same exact behavior that we saw with the earlier version of the em driver I figured it was the same bug resurfacing again. - Rob Watt On Mon, 2 Apr 2007, Rob Watt wrote: Hi, In 6.1-RELEASE there were a number of em driver stability and performance issues. We would regularly see packet loss at low to moderate load. A number of patches were applied that completely fixed the problem for us. We installed 6.2-RELEASE, but even though 6.2 is supposed to have a stable em driver, we are noticing the same packet loss problem again. We updated to STABLE, and we didn't see any packet drops in our first day of testing, but today we are seeing packet drops again. Has anyone else experienced this? Are there known problems with the STABLE em driver? Our hardware: tyan s5372 motherboard (bios v1.05) 2 intel x5355 processors adaptec aic7902 scsi daughter card there are 4 em interfaces (2 on-board, 2 from an add-on card), but we are currently only using em0 We have experienced the packet drop problem with a custom kernel and with the RELEASE SMP kernel. - Rob Watt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic in 6.3-RELEASE when multi-cast client exits
pcpu.h:172
#1 0x0004 in ?? ()
#2 0x8029ab57 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x8029b1f1 in panic (fmt=0xff021ef0c720
"XÓð\036\002ÿÿÿ\020Åô\036\002ÿÿÿ") at /usr/src/sys/kern/kern_shutdown.c:565
#4 0x8042bc8f in trap_fatal (frame=0xff021ef0c720,
eva=18446742983306957656) at /usr/src/sys/amd64/amd64/trap.c:669
#5 0x8042c192 in trap (frame=
{tf_rdi = -1096796658432, tf_rsi = -1090402597088, tf_rdx =
-1099077979968, tf_rcx = 8390317583334711354, tf_r8 = -1098648831624, tf_r9
= 3916890112, tf_rax = 1, tf_rbx = -1097507680240, tf_rbp = 20, tf_r10 =
-1090404108288, tf_r11 = 100, tf_r12 = -1098648832000, tf_r13 = 4, tf_r14 =
-1099498930176, tf_r15 = -1096796658432, tf_trapno = 9, tf_addr = 0,
tf_flags = -1096796658432, tf_err = 0, tf_rip = -2144050562, tf_cs = 8,
tf_rflags = 66182, tf_rsp = -1225844000, tf_ss = 16}) at
/usr/src/sys/amd64/amd64/trap.c:470
#6 0x8041333b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#7 0x8034627e in ip_input (m=0xff00a1d32500) at
/usr/src/sys/netinet/ip_input.c:624
#8 0x803302cc in netisr_processqueue (ni=0x80633f90) at
/usr/src/sys/net/netisr.c:236
#9 0x8033057d in swi_net (dummy=0xff00a1d32500) at
/usr/src/sys/net/netisr.c:349
#10 0x8027fe38 in ithread_loop (arg=0xff090520) at
/usr/src/sys/kern/kern_intr.c:682
#11 0x8027e5d7 in fork_exit (callout=0x8027fcf0
, arg=0xff090520, frame=0xb6ef1c50)
at /usr/src/sys/kern/kern_fork.c:788
#12 0x804136fe in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:411
#13 0x in ?? ()
#14-125 garbage
dump/bt #3:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x1
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x8034627e
stack pointer = 0x10:0xb6ef1ad0
frame pointer = 0x10:0x14
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 20 (swi1: net)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 1d22h10m53s
Dumping 8190 MB (3 chunks)
...
...
#0 sched_switch (td=0xff01b85114c0, newtd=0xff021ef49720, flags=1)
at /usr/src/sys/kern/sched_4bsd.c:980
980 sched_lock.mtx_lock = (uintptr_t)td;
(kgdb) bt
#0 sched_switch (td=0xff01b85114c0, newtd=0xff021ef49720, flags=1)
at /usr/src/sys/kern/sched_4bsd.c:980
#1 0x0246 in ?? ()
#2 0x8028fe25 in _mtx_lock_spin (m=0xff022c50d728, tid=0,
opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:638
#3 0x0004 in ?? ()
#4 0x in ?? ()
#5 0x803f1bbb in uma_zfree_arg (zone=0x802c5ac6,
item=0xff01b85114c0, udata=0xff01b8a746b0)
at /usr/src/sys/vm/uma_core.c:2297
#6 0xff01b4f6ca80 in ?? ()
#7 0xff01b755a460 in ?? ()
#8 0xff003bb3a000 in ?? ()
#9 0x0020 in ?? ()
#10 0xff01b4f6ca80 in ?? ()
#11 0xff01b755a460 in ?? ()
#12 0xffbce000 in ?? ()
#13 0x0013 in ?? ()
#14 0xff01b77f2000 in ?? ()
#15 0x in ?? ()
#16 0x802a5b88 in binuptime (bt=0x0) at
/usr/src/sys/kern/kern_tc.c:143
#17 0x802a8a23 in thread_exit () at
/usr/src/sys/kern/kern_thread.c:597
#18 0x8027b227 in exit1 (td=0xff01b4f6ca80, rv=-2143347781) at
/usr/src/sys/kern/kern_exit.c:528
#19 0x8027bb8e in sys_exit (td=0x0, uap=0x0) at
/usr/src/sys/kern/kern_exit.c:99
#20 0x8042cb81 in syscall (frame=
{tf_rdi = 0, tf_rsi = 0, tf_rdx = 4285347, tf_rcx = 6, tf_r8 = 0,
tf_r9 = 0, tf_rax = 1, tf_rbx = 3, tf_rbp = 140737488350784, tf_r10 = 0,
tf_r11 = 0, tf_r12 = 140737488350752, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0,
tf_trapno = 22, tf_addr = 0, tf_flags = 0, tf_err = 2, tf_rip = 34369792716,
tf_cs = 43, tf_rflags = 518, tf_rsp = 140737488350312, tf_ss = 35}) at
/usr/src/sys/amd64/amd64/trap.c:807
#21 0x80413538 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:287
#22 0x000800996acc in ?? ()
Thanks
--
Rob Watt
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic in 6.3-RELEASE when multi-cast client exits
Thanks George, we will apply this patch tonight.
On Fri, Feb 22, 2008 at 1:26 AM, <[EMAIL PROTECTED]> wrote:
> FYI this is fixed by a one line change that is about to hit 6-STABLE:
>
> @@ -991,7 +991,6 @@
> * a new record. Otherwise, we are done.
> */
>if (ifma->ifma_protospec != NULL) {
> - if_delmulti_ent(ifma); /* We don't need another reference
> */
>IN_MULTI_UNLOCK();
>IFF_UNLOCKGIANT(ifp);
>return ifma->ifma_protospec;
>
> Sent to me by Stephan Uphoff.
>
> I tested it today.
>
> Best,
> George
>
>
--
Rob Watt
Hudson River Trading
212.479.3954
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DWL-650 RevP and OLDCARD
Hi. Sorry if this has been covered before. I purchased a D-Link DWL-650, and it turned out to be the newer RevP model. I built the NDIS wrapper around drivers from the windows CD, but it doesn't seem to pick up the card. I tried using that both as a module, and built into my kernel. My laptop is old enough that it only works with OLDCARD, could this be a problem? I tried adding an appropriate entry to pccard.conf telling it to use the ndis driver, but still nothing. Does anyone have any tips to get this working? My laptop is running -current as of about a couple days ago. Any help is appreciated! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pppd pty equivilent in FBSD
Good day List, I have a question about pppd. We use ppp over ssh for a VPN solution into work. The script works on linux, but not in freebsd because the implementation of pppd that comes with freebsd does not recognize the pty command. When I attempt to connect up I get the following. testee# bash bin/vpn.init start Waiting for connection... Using interface ppp0 /usr/sbin/pppd: In file /usr/home/rob/vpn/options.vpn: unrecognized option 'pty' Connection Failed This appears to be the last piece of the puzzle for me in order to get this to work. So it leaves me to ask Is there an equivalent in Freebsd? From the pppd man page on a linux machine. pty script Specifies that the command script is to be used to communicate rather than a specific terminal device. Pppd will allocate itself a pseudo-tty master/slave pair and use the slave as its terminal device. The script will be run in a child process with the pseudo-tty master as its standard input and output. An explicit device name may not be given if this option is used. (Note: if the record option is used in conjuction with the pty option, the child process will have pipes on its standard input and output.) The fbsd pppd's man page doesn't list anything for pty, and a google doesn't turn up much. Thanks for your time. Rob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pppd pty equivilent in FBSD
On Monday 23 May 2005 08:18 am, Tim Pushor wrote: hmm, Thanks for the response, Tim. I wouldn't personally recommend vpn over ssh for anyone either, but i'm kind of stuck with it. I'm the sole bsd user at my company, and the ppp over ssh was implemented years before I came and has worked fine for them. They're not really willing to change it at the moment and it's on a system I have zero control over within our organization. If I had the option to set this up like you have below it would have been put in place a long while ago. Tim, I thank you for your scripts and time. Here's the scripts I use. Actual bash script I call: ! /usr/local/bin/bash # # This script controls starting and stopping # the VPN run over ssh. It's functions are: # # start stop on off # # start and stop control the actuall ppp interface, # while on and off turn the routes to the VPN on and off. # In this way, you can bring up the interface, but turn # the VPN on and off without affecting the ppp connection. # # # - configuration # This is the other end of the VPN VPNHOST="$WORK" # This is for editing /etc/resolv.conf DOMAIN=" $DOMAIN_NAME" #DNSSERVER="10.10.X.X" DNSSERVER="10.10.X.Y" # # Defaults should be okay # CONFFILE="/etc/resolv.conf" # tempfile, needs to be writable TMP=/tmp/file.$$ # This is to give us time for the ppp # connection to come up timeout=5 # This is the command to start pppd CMD="/usr/sbin/pppd file /usr/home/rob/vpn/options.vpn" # A place for control files svcdir="$HOME/.pppssh" # A place for pids to keep track of processes rundir="$svcdir/run" # -- end configuration --- # Some things to check before we begin USER=`id -u` PPPD=`find /usr/sbin -perm 4755 -name pppd` ROUTE=`find /sbin -perm 4755 -name route` IFCONFIG=`find /sbin -perm 4755 -name ifconfig` if [ \( $USER -ne 0 \) -a \( -z "$PPPD" -o -z "$ROUTE" -o -z "$IFCONFIG" \) ]; then echo "You must be root, or the following must be suid:" echo "/sbin/pppd, /sbin/route, /sbin/ifconfig" exit 1 fi case "$1" in start) # Make a control directory if [ ! -d $svcdir ]; then mkdir -p $svcdir fi if [ ! -d $rundir ]; then mkdir -p $rundir fi # make sure it doesn't core dump anywhere; while this could mask # problems with the daemon, it also closes some security problems ulimit -c 0 echo -n $VPNHOST > "$svcdir/host" echo Waiting for connection... # Look for unused ppp device. # But default to ppp0 dev=0 for i in `jot 9 0 `; do if [ ! -f /var/run/ppp$i.pid ] ; then echo Using interface ppp$i dev=$i break fi done # See if we're already running if [ ! -f $svcdir/lock ]; then $CMD else echo Link appears up echo Lock file in $svcdir echo Use $0 restart exit 1 fi if [ $? -eq 0 ]; then sleep $timeout ifconfig ppp$dev echo ppp$dev > $svcdir/device echo $VPNHOST > $svcdir/host touch $svcdir/lock # Routes to be added for the inside network $0 on else echo Connection Failed fi ;; stop) # Find the pid of the pppd, kill it, remove the route VPNIF=`head $svcdir/device` id=`head /var/run/$VPNIF.pid` sshpid=`head $rundir/sshpppd.pid` # Removing routes if possible echo Removing routes... $0 off echo Killing processes... kill -s SIGTERM $id kill -s SIGTERM $sshpid echo Killed ssh[$sshpid] echo Killed pppd[$id] # Bring down interface echo Bringing down interface: $VPNIF /sbin/ifconfig $VPNIF down echo Removing control files... # Remove control files rm -f "$svcdir/device" rm -f "$svcdir/host" rm -f "$rundir/sshpppd.pid" rm -f "$svcdir/lock" echo Done. ;; on) if [ ! -f "$svcdir/lock" ]; then echo VPN does not appear to be up exit 1 elif [ -f "$svcdir/on" ]; then echo VPN looks like it is already active exit 1 else # Routes are specified in /etc/ppp/routes.vpn grep -v '^#' /etc/ppp/routes.vpn |\
Re: pppd pty equivilent in FBSD
On Thursday 26 May 2005 05:10 pm, Julian Elischer wrote: > what's on the other end? My apologies, I only responded to Nikos. His suggestion of upgrading to the newer pppd23 worked. And I've now had the joyous task of rolling it out onto a couple machines. I did figure Julian would know :-) The other end is a RH box, I'm not sure of the specifics right now. But it's up and running and I can access the network. Thank you everyone for all of your help. Rob > Rob Zietlow wrote: > >On Monday 23 May 2005 08:18 am, Tim Pushor wrote: > > > >hmm, Thanks for the response, Tim. > > > >I wouldn't personally recommend vpn over ssh for anyone either, but i'm > > kind of stuck with it. I'm the sole bsd user at my company, and the ppp > > over ssh was implemented years before I came and has worked fine for > > them. They're not really willing to change it at the moment and it's on > > a system I have zero control over within our organization. > > > >If I had the option to set this up like you have below it would have been > > put in place a long while ago. Tim, I thank you for your scripts and > > time. > > > > > > > >" > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Load Balancing Outgoing, its possible ?
> On Fri, 2005-10-28 at 17:19 +0200, G Bryant wrote: >> Daniel Dias Gonçalves wrote: >> >> > >> > It is possible to make this balancing with the PF ? Exists some >> > software that I make this ? Zebra can help me? >> > This type of balancing gives to problems with the navigation of the >> > user of NAT or IP valid ? >> > If it is possible, wanted to see examples with rules. >> > > > It would be much better to do per flow load balancing then per packet. > With per packet your TCP flows will arrive out of order which is a bad > situation since it will lead to a large number of retransmissions and > zero-window acknowledgments. > > The only tunable to help correct that is to allow selective > acknowledgments. > > You are going to get much higher utilization on your load balanced lines > by using per flow with multiple TCP connections. > > Anybody know how to implement per flow load balancing in FreeBSD? Are > multiple default routes supported? > > It would be beautiful if you could put multiple routes with the same > metric into the kernel and then the kernel would enable per flow load > balancing of the routes... > > -Corey Smith > ___ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > I believe pf is per-flow. If it was not, then not only would your packets arrive out-of-order, but also with different source IPs when you were NATing to different interfaces on different ISPs (without your own block) which is something I was able to do with 3 links (with three different IP addresses) from 2 different providers. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Cisco shows LACP not enabled on 11.1U2, BCM 57810S-t, 2960X IOS 15.2
Trying to get to a LACP Trunk config working on FreeNAS, but I'm not sure if this is an upstream issue. First step is just LACP bundle in edge mode (no vlans) and bundle will not form. The FreeNAS side shows it as being active. The switch is reporting that LACP is not enabled on the individual ports. We have tried multiple versions of IOS from 15.0 to 15.2(6)E1. I have about 10 windows servers with the same NICs on the same switch that are negotiating LACP successfully as well as tagging vlans, so the hardware pieces seem to be OK. I have tried configuring from both the GUI and the CL with the same result. Cisco 2960X switch config: interface Port-channel10 switchport access vlan 1900 switchport mode access ! interface GigabitEthernet1/0/27 switchport access vlan 1900 switchport mode access channel-group 10 mode active ! interface GigabitEthernet1/0/28 switchport access vlan 1900 switchport mode access channel-group 10 mode active logs from switch: Mar 13 17:38:09.626: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/27, changed state to up Mar 13 17:38:09.665: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/28, changed state to up Mar 13 17:38:15.753: %EC-5-L3DONTBNDL2: Gi1/0/28 suspended: LACP currently not enabled on the remote port. Mar 13 17:38:16.005: %EC-5-L3DONTBNDL2: Gi1/0/27 suspended: LACP currently not enabled on the remote port. Switch#sh etherc summ Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use N - not in use, no aggregation f - failed to allocate aggregator M - not in use, minimum links not met m - not in use, port not aggregated due to minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port A - formed by Auto LAG Number of channel-groups in use: 1 Number of aggregators:1 Group Port-channel Protocol Ports --+-+---+--- 10 Po10(SD) LACP Gi1/0/27(w) Gi1/0/28(w) Switch#sh int gi1/0/27 GigabitEthernet1/0/27 is up, line protocol is down (notconnect) Switch#sh int gi1/0/28 GigabitEthernet1/0/28 is up, line protocol is down (notconnect) FreeNAS ifconfig bxe0: flags=8843 metric 0 mtu 1500 options=527bb ether 00:0e:1e:86:7c:70 hwaddr 00:0e:1e:86:7c:70 nd6 options=9 media: Ethernet autoselect (10Gbase-T ) status: active bxe1: flags=8843 metric 0 mtu 1500 options=527bb ether 00:0e:1e:86:7c:70 hwaddr 00:0e:1e:86:7c:72 nd6 options=9 media: Ethernet autoselect (10Gbase-T ) status: active lagg0: flags=8843 metric 0 mtu 1500 options=527bb ether 00:0e:1e:86:7c:70 nd6 options=9 media: Ethernet autoselect status: active groups: lagg laggproto lacp lagghash l2,l3,l4 laggport: bxe0 flags=0<> laggport: bxe1 flags=0<> Last edited: 12 minutes ago ___ 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: Cisco shows LACP not enabled on 11.1U2, BCM 57810S-t, 2960X IOS 15.2
Thanks for your help on this! On Tue, Mar 13, 2018 at 9:09 PM Eugene Grosbein wrote: > 14.03.2018 1:28, Rob Hutton wrote: > > > Trying to get to a LACP Trunk config working on FreeNAS, but I'm not sure > > if this is an upstream issue. First step is just LACP bundle in edge > mode > > (no vlans) and bundle will not form. The FreeNAS side shows it as being > > active. The switch is reporting that LACP is not enabled on the > individual > > ports. We have tried multiple versions of IOS from 15.0 to 15.2(6)E1. I > > have about 10 windows servers with the same NICs on the same switch that > > are negotiating LACP successfully as well as tagging vlans, so the > hardware > > pieces seem to be OK. I have tried configuring from both the GUI and the > > CL with the same result. > > > > Cisco 2960X > > > > switch config: > > interface Port-channel10 > > switchport access vlan 1900 > > switchport mode access > > ! > > interface GigabitEthernet1/0/27 > > switchport access vlan 1900 > > switchport mode access > > channel-group 10 mode active > > ! > > interface GigabitEthernet1/0/28 > > switchport access vlan 1900 > > switchport mode access > > channel-group 10 mode active > > > > logs from switch: > > Mar 13 17:38:09.626: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/27, > > changed state to up > > Mar 13 17:38:09.665: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/28, > > changed state to up > > Mar 13 17:38:15.753: %EC-5-L3DONTBNDL2: Gi1/0/28 suspended: LACP > currently > > not enabled on the remote port. > > Mar 13 17:38:16.005: %EC-5-L3DONTBNDL2: Gi1/0/27 suspended: LACP > currently > > not enabled on the remote port. > > > > Switch#sh etherc summ > > Flags: D - down P - bundled in port-channel > > I - stand-alone s - suspended > > H - Hot-standby (LACP only) > > R - Layer3 S - Layer2 > > U - in use N - not in use, no aggregation > > f - failed to allocate aggregator > > > > M - not in use, minimum links not met > > m - not in use, port not aggregated due to minimum links not met > > u - unsuitable for bundling > > w - waiting to be aggregated > > d - default port > > > > A - formed by Auto LAG > > > > > > Number of channel-groups in use: 1 > > Number of aggregators:1 > > > > Group Port-channel Protocol Ports > > > --+-+---+--- > > 10 Po10(SD) LACP Gi1/0/27(w) Gi1/0/28(w) > > > > Switch#sh int gi1/0/27 > > GigabitEthernet1/0/27 is up, line protocol is down (notconnect) > > > > Switch#sh int gi1/0/28 > > GigabitEthernet1/0/28 is up, line protocol is down (notconnect) > > > > > > FreeNAS > > ifconfig > > > > bxe0: flags=8843 metric 0 mtu > 1500 > > > options=527bb > M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > >ether 00:0e:1e:86:7c:70 > >hwaddr 00:0e:1e:86:7c:70 > >nd6 options=9 > >media: Ethernet autoselect (10Gbase-T ) > >status: active > > > > bxe1: flags=8843 metric 0 mtu > 1500 > > > options=527bb > M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > >ether 00:0e:1e:86:7c:70 > >hwaddr 00:0e:1e:86:7c:72 > >nd6 options=9 > >media: Ethernet autoselect (10Gbase-T ) > >status: active > > > > lagg0: flags=8843 metric 0 mtu > 1500 > > > options=527bb > M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > >ether 00:0e:1e:86:7c:70 > >nd6 options=9 > >media: Ethernet autoselect > >status: active > >groups: lagg > >laggproto lacp lagghash l2,l3,l4 > >laggport: bxe0 flags=0<> > >laggport: bxe1 flags=0<> > > > > Last edited: 12 minutes ago > > See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213606 > > In short: bxe(4) driver fails to setup hardware so it would receive > incoming > multicast LACP frames unless switched to promisc. mode. > > For now, replace the NIC with one from distinct manufacturer (Intel etc.) > > ___ 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"
Troubleshooting Idrops
I have a VPS server running FreeBSD 10.3-RELEASE-p4 and nginx. It contains three very low volume web sites that have been up for about three years. I was tinkering with TLS and SSL ciphers by eliminating TLSv1 and TLSv1.1 with different ciphers when I noticed my daily "Network interface status" report one morning saying I was getting Idrops of 48665. Network interface status: NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll Drop em01500 xx:xx:3c:cd:7e:c7 225569570 0 48665 923463 0 0 0 em0 - ::xxx:3cf fe80::216:3cff:fe0 - - 4 - - - em0 - 107.xxx.xx.xx mysite1.co94833 - -0 - - - em0 - 107.xxx.xx.0 mysite2.co 479981 - - 920067 - - - lo0 16384 783 0 0 783 0 0 0 lo0 - ::1 ::1 0 - - 0 - - - lo0 - ::1%lo0 ::1%lo0 0 - - 0 - - - lo0 - your-net localhost 783 - - 783 - - - I reverted my TLS/SSL changes but, the next day, that exact same number of Idrops happened and continued for a couple of days afterwards. I just don't know what I could have done to cause this and am looking for troubleshooting help since it's been so long since I've had to deal with this and forgotten nearly everything. All the sites seem to function normally and I should note that, besides the nginx server, there are also two nodejs servers listening via proxy. I do nothing with IPv6. Here is part of vmstat -z where I notice FAILs: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Hash: 128, 0, 5, 26, 7, 0, 0 4 Bucket:16, 0, 8, 496, 21344, 0, 0 6 Bucket:24, 0, 0, 336, 121, 0, 0 8 Bucket:32, 0, 2, 376,1600, 0, 0 12 Bucket: 48, 0, 0, 0, 97831, 0, 0 16 Bucket: 64, 0, 12, 303,9585, 8, 0 32 Bucket: 128, 0, 14, 389, 46423, 0, 0 64 Bucket: 256, 0, 20, 235, 48362, 0, 0 128 Bucket: 512, 0, 19, 101, 23133, 0, 0 mbuf_packet:256, 30975, 256, 253,455561904,97330, 0 mbuf: 256, 30975, 2, 254, 2124523, 0, 0 mbuf_cluster: 2048, 4840, 509, 3, 17874,194660, 2 mbuf_jumbo_page: 4096, 2419, 0, 2, 10659, 0, 0 mbuf_jumbo_9k: 9216,716, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384,403, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 256 Bucket:1024, 0, 27, 45, 56839,5856, 0 vmem btag: 28, 0,6648,1848, 68924, 58, 0 I ran netstat -s and can post that here if it's OK for something that big or if someone wants something specific from that. In addition, what can I do to see these drops without having to wait till the next day for the report? I know I can do netstat -i but that contains drops for the current day. ___ 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: non-random IP IDs
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Tue, 17 Apr 2001, Matt Dillon wrote: > Let me put it another way: I think this sort of thing is an excellent > example of introducing unnecessary kernel bloat into the system. Who > gives a fart whether someone can port scan you efficiently or > anonymously or not? I get port scanned every day. Most hackers don't > even bother with portscans, they just try the exploit on the target > machines directly. You could add a kernel config variable in case someone wants a less bloated kernel. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE63LNpv8Bofna59hYRA/5RAKCIRJTLpcf8kZ7q86QeLrfUzWBM9gCgqhuO GTxP1jwxVOgpsCpfGjx10js= =Y/2k -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Bridge over tun0 waters...
This message was posted Feb of '99. I was wondering if anyone has made an efforts towards this yet. (i.e. Wanna make sure I don't make a hack that's already made.) Thanks. --Rob > the bridges above will be not be doing any IP routing, just forwarding > IP packets based on MAC addresses. you can do this with cisco's and > i'd assume most other major bridge/router vendors. of course you may > run into serious traffic jams if your bridging ethernet over a much > slower line, like a 56k. in fact as many already said the most obvious solution seems to use routing, not bridging. > i'm not sure if this can be done with freebsd however. Luigi's bridge > code and ppp would be the place to look (Luigi will probably be able > to answer this :). just because i am called... bridging in freebsd only works on ethernet-type networks. Someone already asked me that i also add support for 'tun' interfaces so that solutions like the one above are possible. Shouldn't be that hard to implement, just isn't there right now. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message --Rob +--+ | Rob Harris8037 Laurel Lakes Court, Laurel MD 301.598.0500 x2236 | | Cidera, Inc. [EMAIL PROTECTED] fax: 301.598.0837 | +--+ "Don't rush me sonny. You rush a miracle man, you get rotten miracles." --Miracle Max, The Princess Bride To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
proposed changes to getnameinfo() implementation
getnameinfo() takes a struct sockaddr pointer, and a length parameter for the amount of memory pointed to by the struct sockaddr pointer. The current FreeBSD implementation of getnameinfo() does 2 problematic checks against the length parameter. First, it makes sure the length parameter is equal to the length specified in the passed in sockaddr structure. This is problematic because the length parameter refers to the amount of memory pointed to by the first parameter, and the struct sockaddr sa_len field is used to specify the size of the sockaddr structure, since there are different types of sockaddr structures with different lengths. I propose to change this exact match comparison to ensure that the length passed in is at least what the sa_len field is. This will allow a larger structure to be passed in than the size of the sockaddr structure for the desired protocol. The second comparison is similar to the first. The passed in length field is compared to the size of the sockaddr structure for the address family you're using. Again, I propose to make sure that the passed in length is at least as large as the known structure length. With these changes, it still ensure that enough memory is available to proceed, but it also allows more memory than is needed. Rob diff -u -d -b -w -u -d -r1.7 getnameinfo.c --- getnameinfo.c 2001/02/15 10:35:54 1.7 +++ getnameinfo.c 2002/02/27 20:48:14 @@ -119,7 +119,7 @@ if (sa == NULL) return ENI_NOSOCKET; - if (sa->sa_len != salen) + if (sa->sa_len > salen) return ENI_SALEN; family = sa->sa_family; @@ -131,7 +131,7 @@ return ENI_FAMILY; found: - if (salen != afd->a_socklen) + if (salen < afd->a_socklen) return ENI_SALEN; /* network byte order */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: proposed changes to getnameinfo() implementation
On Thursday, Feb 2002 at 15:7:44 Hajimu UMEMOTO wrote: > > RFC2553 defines two types of struct sockaddr, one has sa_len and the > other doesn't has it. Though we *BSD has sa_len, non-BSD doesn't have > it. Regardless of sa_len, the size of the structure is already known by the value of sa_family, which both sockaddrs have. > To keep the portability of the application, we must set the size of > the struct sockaddr according to the address family correctly. So, we > should do such sanity checking. This doesn't impair portability, it improves it. Since it is more permissive, yet still valid, it is compatible with the existing usage. > Furthermore, all of KAME delivered getnameinfo() including the version > shipped by ISC do the checking. Changing to only FreeBSD will cause > confusion. Not meaning to hold up glibc as a shining example, but this is how glibc behaves. FreeBSD would not be the first. In fact, this is needed for compatibility with systems that do honor the second parameter. Just because FreeBSD happens to have the sa_len field doesn't mean it should take precidence over the specified length. In fact for portability, the second parameter *must* be honored. Since sa_len doesn't exist on all systems, and isn't required to exist, it's value should arguably not be trusted as a portable app may have left it uninitialized. The getnameinfo() definition from RFC2553 and the FreeBSD man page does not require the sa_len field to be initialized prior to calling getnameinfo(). Since it's not required, it should not be relied upon. Rob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Issues_with_PPPoE_and_4.6 (got on now)
On Thursday 20 June 2002 03:22 pm, Brian Somers wrote: > I get this here: > > Jun 12 22:31:38 gw ppp[93193]: Phase: Received NGM_PPPOE_ACNAME (hook > "hak") Jun 12 22:31:39 gw ppp[93193]: Phase: Received NGM_PPPOE_SESSIONID > (hook "*") Jun 12 22:31:40 gw ppp[93193]: Phase: Received NGM_PPPOE_SUCCESS > (hook "tun1") > > But I'm a little confused as to why the most recent of these messages > are from June 12. I should see some nearly every day in my logs here. > > The NGM_PPPOE_<11> message is the new session id message which ppp doesn't > yet recognise (but does in my local version). > > I'll look into this some more. WellI'm online now. I just let it sit and I opened up some stuff and it tried to connect up to the internet and it worked.. So it appears touch and go. I had this same issue the first time I ran 4.6-RC...3 I think, but it was an RC vers. below is from the ppp.log from when I connected. Jun 20 20:10:11 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n^G^HM-^@ ^H^P ^K^H") Jun 20 20:10:12 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook "`^U^H^Hh ^K^H") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: carrier -> login Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: login -> lcp Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: FSM: Using "deflink" as a transport Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Initial --> Closed Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Closed --> Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: RecvConfigReq(1) state = Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x7c12a05b Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Thu Jun 20 20:09:34 2002 Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 20 20:10:09 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 20 20:10:09 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 20 20:10:09 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 20 20:10:11 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n^G^HM-^@ ^H^P ^K^H") Jun 20 20:10:12 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook "`^U^H^Hh ^K^H") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: carrier -> login Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: login -> lcp Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: FSM: Using "deflink" as a transport Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Initial --> Closed Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Closed --> Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: RecvConfigReq(1) state = Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x7c12a05b Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x62314bc6 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: QUALPROTO[8] proto c025, interval 3ms Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: SendConfigAck(1) state = Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x7c12a05b Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: LayerStart Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Stopped --> Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: RecvConfigAck(1) state = Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Ack-Sent --> Opened Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: LayerUp Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: bundle: Authenticate Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: his = PAP, mine = none Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Pap Output: rzietlow2 Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Pap Input: SUCCESS () Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: FSM: Using "deflink" as a transport Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: State change Initial --> Closed Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: LayerStart. Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: MPPE: Not usable without CHAP81 Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: SendConfigReq(1) state = Closed Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: DEFLATE[4] wi
Re: SOLVED! Native PPPoE broken (4.6-STABLE), RP-PPPoE working?!
>Just to close off this issue an feed it to the archives in case anyone = >else >runs into this issue, the telco found the article below in the vendor's >knowledge database. >Again to summarize, if you use FreeBSD, PPPoE and your ISP or your ISP's >telco uses an ERX as the PPPoE concentrator, make sure you disable and >prevent VJ header compression as it will not work. Bell Canada has been >slowly deploying these boxes so if you use Sympatico, or your ISP is in >Quebec or Ontario, you will start to run into this issue as the telco = >slow >gets rid of their Redback SMSes and replaces them with Unisphere's ERX >boxes. > >The solution I found was to make sure that its also disabled and not >offered in RADIUS either, so you might have to talk to your ISP if they >have it configured, as we did. how exactly do you turn this off? Or even find out if it's enabled? A search on google mostly gives up ISDN cases of this kernel option. one article mentions spppcontrol to turn this off, but when I attempt to use this option I get the following PITA# spppcontrol tun0 spppcontrol: SIOCGIFGENERIC(SPPPIOGDEFS): Invalid argument I also attempted 'pppstats tun0' PITA# pppstats tun0 pppstats: invalid interface 'tun0' specified pppstats: couldn't get PPP statistics: Invalid argument PITA# pppstats -h pppstats: illegal option -- h Usage: pppstats [-a|-d] [-v|-r|-z] [-c count] [-w wait] [interface] Is there anything that I need to set in the /etc/ppp/ppp.conf or a sysctrl? Rob > ---Mike -- -- Rob Zietlow Network Security Engineer SecurePipe, Inc Madison, WI (608) 294-6940 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Intel em receive hang and possible pr #72970
Hi, We have experienced a very sporadic problem on 2 amd64 machines running FreeBSD 6.0-RELEASE. The hardware: Tyan K8SR motherboard 2 AMD 275 dual-core processors Intel Pro 1000 MT dual-port copper server card Intel Pro 1000 MF dual-port fiber server card Adaptec 2230S Raid controller These machines receive multicast & tcp data on multiple interfaces and process it & record it to disk and then rebroadcast it on one interface. Twice now (once on each machine after a recent upgradee to 6.0-RELEASE) the 2 fiber em interfaces seemed to stop receiving. Transmits seemed to still be happening, and the machine itself was not hung. We could console into it and do anything not network related. The first time this happened we opted to quickly disconnect the machine from the network and move its processes to a backup machine. We did not see anything interesting with netstat, vmstat, logs, etc (I do not remember however which exact tests I ran at the time). Everything seemed normal except that it was not receiving on the 2 fiber interfaces (we did not actually test the other interfaces, but one of our apps that uses the copper interfaces was still receiving data). We rebooted the machine and ran Intel's nic diagnostics. The card passed all of the tests through like 100 iterations. We eventually put the machine back into production. The second machine had the same problem. Unfortunately I was on vacation when it happened and did get to do any diagnostics. The developers just put the backup machine into production and rebooted the one with the problem. After poking around in various group/pr postings the most similar problem that we found was PR #72970. http://www.freebsd.org/cgi/query-pr.cgi?pr=72970 Does it seem that we are encountering that bug? Is that bug fixed in 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only patch the em driver). If it does not seem that we are triggering that bug, does anyone have any thoughts about what the problem could be? We have done fairly intense stress testing in the past on these machines with tons of network/disk/cpu/memory activity all happening at the same time, and we've never encountered this bug. The fact that it is not easily repeatable makes it hard to test for. Any testing suggestions would also be appreciated. Thanks - Rob Watt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel em receive hang and possible pr #72970
On Thu, 31 Aug 2006, Joe Holden wrote: Sounds like its at least possible this is your problem, worth setting up a system to test with I would say. There's also another possibility these days -- we support errata fixes going into release branches, as we do with security fixes. These changes must be low-impact (not affect API, ABI, etc), but are useful for critical stability fixes or to correct widely experienced problems. If there is a small tweak which could make a big difference, and has been well QA'd, then that approach can be taken. However, we're currently accepting errata fixes only for the most recent release, so expanding the scope to include older releases (i.e., 6.0 in addition to 6.1) then that would require some discussion and careful thinking. So far, we've been very conservative in accepting errata fixes on the basis that we want it to be a trickle, not a waterfall, for a great many good reasons :-). Robert N M Watson Computer Laboratory University of Cambridge Thanks for all of the quick feedback. Stability and consistency are very important to us. We are not going to use STABLE on one machine and a RELEASE on another, and we are not going to roll out some random version of stable to all of our machines (there are many of them). When troubleshooting we need to be able to have a good standard reference to talk to people about and to compare from machine to machine. This is possible when using a full release, but much less so when dealing with the head of a branch. We are willing to apply small patches provided they are well tested (we are willing to do the testing). I am happy to test against 6.1-RELEASE. We are considering upgrading all of our servers to 6.1, so I have started testing 6.1 anyways. It is not clear to me from the cvs log whether rev 1.129 in branch MAIN mentioned by Mikhail will work with 6.1 (I suspect it will not). The 1.65.2.18 rev against RELENG_6 seems to include the changes in 1.129. I am going to start testing that tonight. How extensively have the changes in that version been tested? Will that version play nicely with 6.1? Thanks! - Rob Watt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel em receive hang and possible pr #72970
On Fri, 1 Sep 2006, Jack Vogel wrote: On 9/1/06, Rob Watt <[EMAIL PROTECTED]> wrote: This was my earlier point Rob, that delta of the driver WILL NOT build against 6.1 RELEASE, it has taskqueue changes in it that are not in the release, as well as a few other small gotchas. To get that fix you will need to wait for 6.2 if you want it all rolled into a determined whole. I just noticed this when I tried to compile with the recent em driver files. Since 6.2 is on the semi-near horizon, and since this bug has only been triggered twice, I might be willing to wait until October to try 6.2. What makes this a more urgent issue is it was triggered on our most critical machines, and the effect of triggering the bug causes much of our business to come to a halt until our backup server takes over. If anyone has tweaked or is willing to tweak the new driver changes to work with 6.1 or 6.0 please let me know. Thanks - Rob Watt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
