jail source address selection doesn't work?
Hello! On a multihomed FreeBSD 8.1-RELEASE, in a multihomed jail, source IP selection suddenly refused to work. ifconfig on a box: bce0: flags=8943 metric 0 mtu 1500 options=c01bb ether 00:1a:64:c5:d0:c8 inet 192.168.80.40 netmask 0xff00 broadcast 192.168.80.255 media: Ethernet autoselect (100baseTX ) status: active bce1: flags=8943 metric 0 mtu 1500 options=c01bb ether 00:1a:64:c5:d0:ca media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 inet 127.0.0.2 netmask 0xff00 nd6 options=3 vlan75: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca inet 192.168.75.4 netmask 0xff00 broadcast 192.168.75.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 75 parent interface: bce1 vlan82: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca inet 192.168.82.2 netmask 0xff00 broadcast 192.168.82.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 82 parent interface: bce1 vlan83: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca inet 83.69.203.3 netmask 0xfff0 broadcast 83.69.203.15 media: Ethernet autoselect (100baseTX ) status: active vlan: 83 parent interface: bce1 vlan63: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca inet 10.19.63.100 netmask 0xff00 broadcast 10.19.63.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 63 parent interface: bce1 carp0: flags=49 metric 0 mtu 1500 inet 192.168.80.42 netmask 0xff00 carp: MASTER vhid 145 advbase 1 advskew 0 carp1: flags=49 metric 0 mtu 1500 inet 192.168.75.3 netmask 0xff00 carp: MASTER vhid 146 advbase 1 advskew 0 carp2: flags=49 metric 0 mtu 1500 inet 192.168.82.4 netmask 0xff00 carp: MASTER vhid 147 advbase 1 advskew 0 carp3: flags=49 metric 0 mtu 1500 inet 83.69.203.1 netmask 0xfff0 carp: MASTER vhid 148 advbase 1 advskew 0 carp4: flags=49 metric 0 mtu 1500 inet 10.19.63.67 netmask 0xff00 carp: MASTER vhid 149 advbase 1 advskew 0 ifconfig in a jail bce0: flags=8943 metric 0 mtu 1500 options=c01bb ether 00:1a:64:c5:d0:c8 media: Ethernet autoselect (100baseTX ) status: active bce1: flags=8943 metric 0 mtu 1500 options=c01bb ether 00:1a:64:c5:d0:ca media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 vlan75: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca inet 192.168.75.4 netmask 0xff00 broadcast 192.168.75.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 75 parent interface: bce1 vlan82: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca media: Ethernet autoselect (100baseTX ) status: active vlan: 82 parent interface: bce1 vlan83: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca media: Ethernet autoselect (100baseTX ) status: active vlan: 83 parent interface: bce1 vlan63: flags=8943 metric 0 mtu 1500 options=103 ether 00:1a:64:c5:d0:ca media: Ethernet autoselect (100baseTX ) status: active vlan: 63 parent interface: bce1 carp0: flags=49 metric 0 mtu 1500 inet 192.168.80.42 netmask 0xff00 carp: MASTER vhid 145 advbase 1 advskew 0 carp1: flags=49 metric 0 mtu 1500 carp: MASTER vhid 146 advbase 1 advskew 0 carp2: flags=49 metric 0 mtu 1500 carp: MASTER vhid 147 advbase 1 advskew 0 carp3: flags=49 metric 0 mtu 1500 inet 83.69.203.1 netmask 0xfff0 carp: MASTER vhid 148 advbase 1 advskew 0 carp4: flags=49 metric 0 mtu 1500 inet 10.19.63.67 netmask 0xff00 carp: MASTER vhid 149 advbase 1 advskew 0 routing table: Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default83.69.203.14 UGS 232 1221991 vlan83 10.0.0.0/8 10.19.63.126 UGS 0 8768 vlan63 10.19.63.0/24 link#7 U 185 613762 vlan63 10.19.63.67link#12UH 00 carp4 10.19.63.100 link#7 UHS 0 244lo0 83.69.203.0/28 link#6 U 438198 vlan83 83.69.203.1link#11UH 0 1876305 carp3 83.69.203.3link#6 UHS 0 154lo0 127.0.0.1 link#3 UH 0 1078596lo0 127.0.0.2 link#3 UH 0 18lo0 172.16.0.0/12 10.19.63.126 UGS 00 vlan63 192.168.0.0/16 10.19.63.126 UGS 8 205694 vlan63 192.168.75.0/24link#4 U 49 1222391 vlan75 192.168.7
VRRP on VLANs: does it work?
Hello! I've run into strange problem: in non-promisc mode, two freevrrpds does not seems to see each others multicasts. Is it a bug or a feature? Alex. ___ 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: jail source address selection doesn't work?
03.03.2011 0:48, Bjoern A. Zeeb пишет: On Mon, 7 Feb 2011, Alex Povolotsky wrote: Hello! On a multihomed FreeBSD 8.1-RELEASE, in a multihomed jail, source IP selection suddenly refused to work. ifconfig on a box: Seems reasonable, yes? Pinging from the box # ping 192.168.75.59 PING 192.168.75.59 (192.168.75.59): 56 data bytes 64 bytes from 192.168.75.59: icmp_seq=0 ttl=64 time=0.993 ms 64 bytes from 192.168.75.59: icmp_seq=1 ttl=64 time=0.986 ms 64 bytes from 192.168.75.59: icmp_seq=2 ttl=64 time=0.988 ms ^C --- 192.168.75.59 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.986/0.989/0.993/0.003 ms 10:45:31.425232 IP 192.168.75.4 > 192.168.75.59: ICMP echo request, id 12430, seq 0, length 64 10:45:31.426283 IP 192.168.75.59 > 192.168.75.4: ICMP echo reply, id 12430, seq 0, length 64 10:45:32.425415 IP 192.168.75.4 > 192.168.75.59: ICMP echo request, id 12430, seq 1, length 64 10:45:32.426404 IP 192.168.75.59 > 192.168.75.4: ICMP echo reply, id 12430, seq 1, length 64 Okay, yes? From jail: # ping 192.168.75.59 PING 192.168.75.59 (192.168.75.59): 56 data bytes ^C --- 192.168.75.59 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss 10:45:52.146600 IP 83.69.203.1 > 192.168.75.59: ICMP echo request, id 14222, seq 0, length 64 10:45:53.146702 IP 83.69.203.1 > 192.168.75.59: ICMP echo request, id 14222, seq 1, length 64 Setting ip.saddrsel to 1 or 0 did not change anything. Kernel is GENERIC+ALTQ What could I miss?... Don't use ping to test this. a) for ping inside the jail to work you need to enable raw sockets b) a) could give you a hint that ping does it's own thing. Telnet did all the same thing. Try a telnet to a random port to the destination and verify with tcpdump whether things are still not working correctly, of if you establish the connection with netstat. I used telnet to connect to specific ports. Ok, let's try again 104:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls JID IP Address Hostname Path 1 192.168.82.2 test /usr/jails/test 107:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls -j 1 ip4.saddrsel true 108:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls -j 1 ip4.addr 192.168.82.2,192.168.75.2 114:tarkhil@box2.u.energodata.local:...local/etc/ezjail # tcpdump -l -n -i bce0 host 192.168.82.2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bce0, link-type EN10MB (Ethernet), capture size 96 bytes 09:27:54.492105 IP 192.168.82.2.50823 > 192.168.72.3.22: Flags [S], seq 3819433473, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 1306232522 ecr 0], length 0 115:tarkhil@box2.u.energodata.local:...local/etc/ezjail # ifconfig bce0 bce0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:14:5e:1a:a6:27 inet 192.168.80.41 netmask 0xff00 broadcast 192.168.80.255 media: Ethernet autoselect (100baseTX ) status: active test# sysctl security.jail.jailed security.jail.jailed: 1 test# ifconfig bce0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:14:5e:1a:a6:27 media: Ethernet autoselect (100baseTX ) status: active bce1: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:14:5e:1a:a6:29 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 vlan75: flags=8843 metric 0 mtu 1500 options=103 ether 00:14:5e:1a:a6:29 inet 192.168.75.2 netmask 0xff00 broadcast 192.168.75.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 75 parent interface: bce1 vlan82: flags=8843 metric 0 mtu 1500 options=103 ether 00:14:5e:1a:a6:29 inet 192.168.82.2 netmask 0xff00 broadcast 192.168.82.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 82 parent interface: bce1 In other words, source address is selected as primary IP, and packet runs out on 100% improper interface. No specific routing, no firewall. Alex. ___ 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: jail source address selection doesn't work?
On 03/03/11 15:03, Bjoern A. Zeeb wrote: Not sure what you expect. Your jail has an address out of 192.168.82.2/24 and 192.168.75.2/24 You are trying to connect to neither of those networks but 192.168.72.3. Now it was a typo. Either I've lost my mind or I can't reproduce a problem. Will check everything again. Alex. ___ 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"
mpd, nat, netflow: does not work for me
Hello! I'm trying to use mpd 5.1, on FreeBSD 6.2, and got some really strange problems. 1. NAT. [10:37] services-new:/<2>etc/mpd5 # grep nat /usr/local/etc/mpd5/mpd.conf set nat address 81.195.122.86 set iface enable nat in web interface, option for interface includes "nat enable" NO address translation at all. 2. Netflow set iface enable netflow-out set netflow peer PEER-IP-ADDR 8787 netflow-out, of course, is labeled as "enable" MPD even sends some netflow data (1464 bytes packet every 15-20 minutes, it is definitely insufficient to send required data), collector receives it and stores nothing. Maybe someone could help? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pipe dropping lots of packets
Hello! I'm trying to set up FreeBSD-based router, and got troubles with bandwidth limiting. My queues drops lots of packets. [23:38] gw:~ # ipfw pipe 200 config bw 30mbit/s queue 100 [23:42] gw:~ # ipfw add 600 pipe 200 ip from any to any out via vlan333 00600 pipe 200 ip from any to any out via vlan333 seems to be easy. now [23:43] gw:~ # ipfw zero Accounting cleared. make sure we'll catch packets out of pipe [23:43] gw:~ # sysctl net.inet.ip.fw.one_pass net.inet.ip.fw.one_pass: 0 and, waiting a bit [23:43] gw:~ # ipfw show | grep vlan333 00600 2010140730 pipe 200 ip from any to any out via vlan333 00700 0 0 allow ip from any to table(1) via vlan333 00710840142335 allow ip from table(1) to any via vlan333 whoops! No packets left pipe part of ipfw pipe list 00200: 30.000 bit/s 0 ms 100 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 172.23.114.136/6220217.70.17.154/3931 7292 683466 100 12092 7048 As far as I understand, pipe dropped most of tcp packets, didn't it? Of course, people complaints of network "not working". Eventually, some packets gets out of queue, but with 30 mbit/s pipe on 100 mbit link I'd expect to drop 2/3 packets at most, not 99 of 100 00600 1012 64217 pipe 200 ip from any to any out via vlan333 00700 14 560 allow ip from any to any out via vlan333 What could I do wrong? System is fairly unloaded. External card is Intel PRO 100/1000; last pid: 11209; load averages: 0.52, 0.36, 0.34up 5+19:37:14 23:52:17 70 processes: 2 running, 68 sleeping CPU states: 1.3% user, 0.0% nice, 6.4% system, 14.1% interrupt, 78.2% idle Mem: 87M Active, 673M Inact, 195M Wired, 33M Cache, 111M Buf, 8324K Free Swap: 4096M Total, 4096M Free top shows quite little load on system. Alex. (FreeBSD 6.1-RELEASE) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pipe dropping lots of packets
Tobias P. Santos wrote: Hello! Alex Povolotsky wrote: Hello! I'm trying to set up FreeBSD-based router, and got troubles with bandwidth limiting. My queues drops lots of packets. [23:38] gw:~ # ipfw pipe 200 config bw 30mbit/s queue 100 You should use 30Mbit/s (with capital M). [23:42] gw:~ # ipfw add 600 pipe 200 ip from any to any out via vlan333 00600 pipe 200 ip from any to any out via vlan333 seems to be easy. now [23:43] gw:~ # ipfw zero Accounting cleared. make sure we'll catch packets out of pipe [23:43] gw:~ # sysctl net.inet.ip.fw.one_pass net.inet.ip.fw.one_pass: 0 and, waiting a bit [23:43] gw:~ # ipfw show | grep vlan333 00600 2010140730 pipe 200 ip from any to any out via vlan333 00700 0 0 allow ip from any to table(1) via vlan333 00710840142335 allow ip from table(1) to any via vlan333 whoops! No packets left pipe part of ipfw pipe list 00200: 30.000 bit/s 0 ms 100 sl. 1 queues (1 buckets) droptail See, 30 bit/s will drop a lot of packets! ;) Whooops!!! Thanks. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mpd locking system?
Hello! for about 4-5 days, I'm expeirencing heavy troubles with my VPN (mpd) 6.1-RELEASE based server. After some time (minimum 2 seconds, maximum 12 hours) of running MPD with moderate load (about 100-200 clients, CPU not overused), system locks (even keyboard hangs) to reset. Nothing at all in logs. Patching kernel to 6.1p12 did not help. Attempt to add kern.ipc.nmbclusters="0" to /boot/loader.conf did not change anything. The box seems to be healthy (at least, CPU fan works ok, no symptoms of overheating at all). It has run under more load without a flaw. I hope someone can help. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mpd sometimes hangs the whole system?
Hello! mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. I'm updating to 6.2 now, but have little hope. What can I turn on in kernel to fix it or at least to make computer reboot? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Richard Tector wrote: Alex Povolotsky wrote: Hello! mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. I'm updating to 6.2 now, but have little hope. What can I turn on in kernel to fix it or at least to make computer reboot? Which version of mpd are you using? Have you tried the latest version from ports, 4.1? I've read it fixes a *lot* of problems found with the older versions. 3.18_5; Is mpd 4 100% backwards compartible? And, what's worse, I've heard of exactly the same problem on 4.0. Kernel _freeze_ should be something kernel-related, I fear. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Richard Tector wrote: Alex Povolotsky wrote: Richard Tector wrote: Alex Povolotsky wrote: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. Which version of mpd are you using? Have you tried the latest version from ports, 4.1? I've read it fixes a *lot* of problems found with the older versions. 3.18_5; Is mpd 4 100% backwards compartible? Yes, 4.x should work just fine with your 3.x configuration files. And, what's worse, I've heard of exactly the same problem on 4.0. Kernel _freeze_ should be something kernel-related, I fear. Quite possible. It involves putting the interfaces in promiscuous mode so could be due to a bug in your network card driver. What interfaces are you using? Proimisc?... hmm... fxp. Rock solid thing, as far as I can remember. Can try em instead Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Max Laier wrote: [ Removing -stable from CC ] On Monday 19 February 2007 15:57, Alex Povolotsky wrote: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. I'm updating to 6.2 now, but have little hope. What can I turn on in kernel to fix it or at least to make computer reboot? How do you figure it's mpd related? Did you collect *any* debugging information at all? How about enabling DDB and WITNESS? A "hanging" system usually suggests a deadlock. WITNESS should turn up possible causes. Also, could you check if setting debug.mpsafenet=0 in loader.conf helps? Well, I'll try new kernel tomorrow; I've rebuild non-SMP kernel, so mpsafenet should not be of any use? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Andrey V. Elsukov wrote: Alex Povolotsky пишет: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. It's easy to reproduce? Can you try make debug-friendly kernel? RELATIVELY easy. It happens about once a day or more often; but it requires someone to press Reset. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html Thanks a lot, I've added invariants and witness; if it won't yield any information, I'll try more. So far, this cursed thing is working with some load for 2 hours, that's much. It does NOT, surely NOT try to tunnel tunnelled traffic; any serialconsole setup is useless since it is also a main gateway. If it dies, nothing but physical access can help. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Mike Tancsa wrote: At 11:35 AM 2/20/2007, Alex Povolotsky wrote: Thanks a lot, I've added invariants and witness; if it won't yield any information, I'll try more. So far, this cursed thing is working with some load for 2 hours, that's much. It does NOT, surely NOT try to tunnel tunnelled traffic; any serialconsole setup is useless since it is also a main gateway. If it dies, nothing but physical access can help. Although not a hard fast rule, I have found that if the box locks up to the point where a BREAK on the serial console does not send it to the debugger prompt, is usually a sign of a hardware lockup as opposed to a software bug. Well... I'll try to get to the box and try serial console.. What is the chipset of the MB ? Does ichwd work with it to reset it ? Whoops! Thanks, I'll give a try device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub Interface to PCI Bridge' you mean this thing, yes? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mpd success stories, anyone?
Hello! Is there anybody here who can say "I'm running mpd with 400 pptp connections, and it works without a flaw"? I mean 400 ACTIVE connections. If yes, I'll ask lots of questions. If no, I'll have to look for other pptp server. Cannot afford CISCO right now. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd success stories, anyone?
Alexander Motin wrote: Alex Povolotsky wrote: Is there anybody here who can say "I'm running mpd with 400 pptp connections, and it works without a flaw"? I am running >100 mpd servers, and they work without a flaw. I mean 400 ACTIVE connections. And I have >10k PPPoE users and some amount of PPTP. I have >700 ACTIVE PPPoE on some servers. Hmm... May I ask you to show your dmesg, kernel config and mpd configs? I have heard several rumors about system lockup with mpd. If yes, I'll ask lots of questions. If no, I'll have to look for other pptp server. Cannot afford CISCO right now. Have you tried latest mpd4.1? Do you know anything better? Not _yet_. I do not know anything better, but I cannot make mpd on 100+ active connections to work. And I'm not the only dumb one, as far as I've found Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd success stories, anyone?
Alexander Motin wrote: Alex Povolotsky wrote: Hmm... May I ask you to show your dmesg, kernel config and mpd configs? I have heard several rumors about system lockup with mpd. I have heard only one and that person answered me that problem was solved by avoiding of routing loop, when tunnel traffic was routed inside the same tunnel. I have written this in my answer to 'mpd sometimes hangs the whole system' thread. Have you red it? yes; and it's 100% not my case. > Hmm... May I ask you to show your dmesg, kernel config and mpd configs? Nothing special. Latest 6-STABLE, latest mpd4.1, latest libpdel port. Two em Ethernets, single P4/i386 CPU at Intel mobo. Hmm. Will check mpd4.1, and try to use em to listen on... And, again, please show me your mpd.conf Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd success stories, anyone?
Alexander Motin wrote: Alex Povolotsky wrote: And, again, please show me your mpd.conf Attached. Thanks a lot; watchdog is armed, WITNESS and INVARIANTS on, running... Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd success stories, anyone?
Alexander Motin wrote: Alex Povolotsky wrote: And, again, please show me your mpd.conf Attached. Thanks, it seems to be more or less stable; however, throughput is quite little, lots of packets lost and "No buffer space available" on attempt to ping VPN addresses (only VPN is affected). I guess I should tune some kernel tunable, but what specific one? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd success stories, anyone?
Alexander Motin wrote: Alex Povolotsky wrote: Thanks, it seems to be more or less stable; however, throughput is quite little, lots of packets lost and "No buffer space available" on attempt to ping VPN addresses (only VPN is affected). Have you tried to disable PPTP windowing in mpd config? ENOBUFS is the errno used by ng_pptp node's windowing code when outgoing window is full. It is not related to any system tunables. Maximum window size in current ng_pptp is 16 packets. It can be small for LFNs and can reduce speed. I guess I should tune some kernel tunable, but what specific one? I can recomend you to set net.graph.maxdgram=524288 net.graph.recvspace=524288 to make 'ngctl list' command work, but it is not critical. Whoops! After disabling windowing and setting net.graph's, mpd4 refuses to work Feb 22 19:41:43 gw mpd: can't create socket node: No buffer space available Feb 22 19:41:43 gw mpd: pptp0: killing connection with 172.23.115.234 1735 Feb 22 19:41:44 gw mpd: PPTP connection from 172.23.114.214 2955 Feb 22 19:41:44 gw mpd: pptp0: attached to connection with 172.23.114.214 2955 Feb 22 19:41:44 gw mpd: [pptp7] Accepting PPTP connection Feb 22 19:41:44 gw mpd: [pptp7] opening link "pptp7"... Feb 22 19:41:44 gw mpd: [pptp7] link: OPEN event Feb 22 19:41:44 gw mpd: [pptp7] LCP: Open event Feb 22 19:41:44 gw mpd: [pptp7] LCP: state change Initial --> Starting Feb 22 19:41:44 gw mpd: [pptp7] LCP: LayerStart Feb 22 19:41:44 gw mpd: [pptp7] attaching to peer's outgoing call Feb 22 19:41:44 gw mpd: [pptp7] can't attach pptpgre node: Bad file descriptor Feb 22 19:41:44 gw mpd: pptp0-0: killing channel Feb 22 19:41:44 gw mpd: [pptp7] PPTP call cancelled in state CONNECTING Feb 22 19:41:44 gw mpd: pptp0: closing connection with 172.23.114.214 2955 Feb 22 19:41:44 gw mpd: [pptp7] can't shutdown "bypass.link0": Bad file descript or Feb 22 19:41:44 gw mpd: [pptp7] link: DOWN event Feb 22 19:41:44 gw mpd: [pptp7] LCP: Close event Feb 22 19:41:44 gw mpd: [pptp7] LCP: state change Starting --> Initial Feb 22 19:41:44 gw mpd: [pptp7] LCP: LayerFinish and no ng interfaces ever created lowering both tunables to 128000 solved the problem, will look more. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fighting mpd
Hello! Thanks to all who helped, I'm progressing. The box seems to be unstable, however, it reboots with watchdog, not freeze. After boot, I'm getting a message Feb 22 20:58:12 gw kernel: Memory modified after free 0xc4524000(2048) val=a028c0de @ 0xc4524000 Feb 22 20:58:12 gw kernel: Memory modified after free 0xc4525800(2048) val=a028c0de @ 0xc4525800 Feb 22 20:58:12 gw kernel: Memory modified after free 0xc452d800(2048) val=a028c0de @ 0xc452d800 I guess something is wrong with some part of kernel. I'll happily accept any help in tracing the problem source. I'll look at average uptime. FreeBSD 6.2-RELEASE-p1, mpd 4.1 Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fighting mpd
Alexander Motin wrote: To somehow limit searching area, I think you should try to disable all possible additional functions like netflow, tee, DialOnDemand, tcpmssfix, nat, vjcomp, compression, encryption and everything else you have and can disable for some time without harm. No netflow, no nat, no dialonemand; disabling tcpmssfix will most likely render system useless, I'll disable all compression and encryption today and look. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd success stories, anyone?
Alexander Motin wrote: Alex Povolotsky wrote: After disabling windowing and setting net.graph's, mpd4 refuses to work and no ng interfaces ever created lowering both tunables to 128000 solved the problem, will look more. Oops! I have missed kern.ipc.maxsockbuf=1048576 , which is required before those two tunes. But as I have said that options is not required for mpd itself. It's just usefull for 'ngctl list' command. Nothing helped after all. Freezes. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Any success with Intel Wi-Fi on IBM Lenovo R60 and FreeBSD 6.x?
Hello! Does anyone have any positive experience with Intel WiFi adapter on Lenovo R60 with FreeBSD 6.X? Native driver or ndis, does not matter. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any success with Intel Wi-Fi on IBM Lenovo R60 and FreeBSD 6.x?
Max Laier wrote: On Saturday 17 March 2007 07:38, Alex Povolotsky wrote: Does anyone have any positive experience with Intel WiFi adapter on Lenovo R60 with FreeBSD 6.X? That would be the 3945abg part, right? In that case you want the driver from here: http://www.clearchain.com/wiki/Wpi Already wrote to author - it recognize card, but attempt to ifconfig it up results in computer lockup Native driver or ndis, does not matter. I have heard that ndis doesn't work for this one, but I wouldn't know. Yes, for me it did not work. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
redirecting pf example
Hello! I'm trying to set up a box as round-robin TCP proxy. Of course, I'm trying to do everything on kernel-level. This simple setup rdr on sk0 proto tcp from any to any port = smtp -> port 25 round-robin should work. At least, I thought so. However, attempt to connect to port 25 yielded unexpected result. pfctl -s state shows self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- 89.108.94.211:56975 CLOSED:SYN_SENT connection never established, and no IP packet ever sends out to 89.108.94.212:25 I don't understand this thing. Maybe someone can point me to my error? (firewall rules a quite permissive, in fact, they are pass in quick and pass out quick for all interfaces. attempt to telnet to port 25 outside works ok) Alex. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Please help with PF-based redirector
Hello! I'm trying to set up a box as round-robin TCP proxy. Of course, I'm trying to do everything on kernel-level. This simple setup rdr on sk0 proto tcp from any to any port = smtp -> port 25 round-robin should work. At least, I thought so. However, attempt to connect to port 25 yielded unexpected result. pfctl -s state shows self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- 89.108.94.211:56975 CLOSED:SYN_SENT connection never established, and no IP packet ever sends out to 89.108.94.212:25 I don't understand this thing. Maybe someone can point me to my error? (firewall rules a quite permissive, in fact, they are pass in quick and pass out quick for all interfaces. attempt to telnet to port 25 outside works ok) Alex. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Please help with PF-based redirector
Max Laier wrote: On Sunday 15 April 2007 20:11, Alex Povolotsky wrote: Hello! I'm trying to set up a box as round-robin TCP proxy. Of course, I'm trying to do everything on kernel-level. This simple setup rdr on sk0 proto tcp from any to any port = smtp -> port 25 round-robin should work. At least, I thought so. However, attempt to connect to port 25 yielded unexpected result. pfctl -s state shows self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- 89.108.94.211:56975 CLOSED:SYN_SENT Your test hosts seem to be on the same subnet. This does not work as you seems to think. In the same broadcast domain it is not possible for the pf box to forward the packet on behalf of the sending host (otherwise it would confuse the recipient or the switch). Instead it emits icmp redirects which are ignored in a normal setup. You have to separate the two networks in order for redirect to work the way you want it to. Okay, thanks a lot, I'll give a try Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Please help with PF-based redirector
Max Laier wrote: On Sunday 15 April 2007 20:11, Alex Povolotsky wrote: Hello! I'm trying to set up a box as round-robin TCP proxy. Of course, I'm trying to do everything on kernel-level. This simple setup rdr on sk0 proto tcp from any to any port = smtp -> port 25 round-robin should work. At least, I thought so. However, attempt to connect to port 25 yielded unexpected result. pfctl -s state shows self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- 89.108.94.211:56975 CLOSED:SYN_SENT Your test hosts seem to be on the same subnet. This does not work as you seems to think. In the same broadcast domain it is not possible for the pf box to forward the packet on behalf of the sending host (otherwise it would confuse the recipient or the switch). Instead it emits icmp redirects which are ignored in a normal setup. You have to separate the two networks in order for redirect to work the way you want it to. I have separated them. #pfctl -s nat rdr on rl0 proto tcp from any to any port = smtp -> port 25 round-robin # pfctl -s state No ALTQ support in kernel ALTQ related functions disabled self tcp 89.108.94.212:25 <- 10.180.210.2:25 <- 10.180.210.1:61298 CLOSED:SYN_SENT tcpdump does not show any ICMP redirect unknown-1717# tcpdump -l -n -i rl0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 20:53:14.907833 arp who-has 10.180.210.2 tell 10.180.210.1 20:53:14.907857 arp reply 10.180.210.2 is-at 00:0e:2e:98:7e:55 20:53:14.907924 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 1,nop,nop,timestamp 285791868 0,sackOK,eol> 20:53:17.907599 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 1,nop,nop,timestamp 285794868 0,sackOK,eol> 20:53:21.107441 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 1,nop,nop,timestamp 285798068 0,sackOK,eol> 20:53:24.307283 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 20:53:27.507126 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 20:53:30.706974 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 ^C 8 packets captured 8 packets received by filter 0 packets dropped by kernel What am I doing wrong? Or I can only redirect routable traffic? Nope, I've added alias to "external" interface, no changes Alex ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Please help with PF-based redirector
Max Laier wrote: On Sunday 15 April 2007 20:11, Alex Povolotsky wrote: Hello! I'm trying to set up a box as round-robin TCP proxy. Of course, I'm trying to do everything on kernel-level. This simple setup rdr on sk0 proto tcp from any to any port = smtp -> port 25 round-robin should work. At least, I thought so. However, attempt to connect to port 25 yielded unexpected result. pfctl -s state shows self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- 89.108.94.211:56975 CLOSED:SYN_SENT Your test hosts seem to be on the same subnet. This does not work as you seems to think. In the same broadcast domain it is not possible for the pf box to forward the packet on behalf of the sending host (otherwise it would confuse the recipient or the switch). Instead it emits icmp redirects which are ignored in a normal setup. You have to separate the two networks in order for redirect to work the way you want it to. Sorry, things are not THAT simple. I've tried the setup: unknown-1717# ifconfig rl0: flags=8843 mtu 1500 options=8 inet 10.180.210.2 netmask 0xff00 broadcast 10.180.210.255 ether 00:0e:2e:98:7e:55 media: Ethernet autoselect (100baseTX ) status: active sk0: flags=8943 mtu 1500 options=b inet 89.108.94.91 netmask 0xf000 broadcast 89.108.95.255 inet 10.180.220.1 netmask 0xff00 broadcast 10.180.220.255 ether 00:18:f3:5c:de:6d media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 pfsync0: flags=0<> mtu 1348 syncpeer: 224.0.0.240 maxupd: 128 carp0: flags=49 mtu 1500 inet 89.108.94.92 netmask 0xf000 carp: MASTER vhid 21 advbase 1 advskew 0 unknown-1717# pfctl -s nat No ALTQ support in kernel ALTQ related functions disabled nat on sk0 inet from 10.180.210.0/24 to any -> (sk0) round-robin rdr on rl0 proto tcp from any to any port = smtp -> port 25 round-robin seems reasonable. yes? FIRST connect works ok Than - no success at all for some time. Than - works again unknown-1717# pfctl -s state No ALTQ support in kernel ALTQ related functions disabled self tcp 89.108.65.126:25 <- 10.180.210.2:25 <- 10.180.210.1:62736 CLOSED:SYN_SENT self tcp 89.108.65.126:25 <- 10.180.210.2:25 <- 10.180.210.1:58177 FIN_WAIT_2:FIN_WAIT_2 self tcp 89.108.94.212:25 <- 10.180.210.2:25 <- 10.180.210.1:57950 FIN_WAIT_2:FIN_WAIT_2 self tcp 89.108.94.212:25 <- 10.180.210.2:25 <- 10.180.210.1:58727 CLOSED:SYN_SENT self tcp 89.108.65.124:25 <- 10.180.210.2:25 <- 10.180.210.1:63480 CLOSED:SYN_SENT self tcp 10.180.210.1:63480 -> 89.108.94.91:54490 -> 89.108.65.124:25 SYN_SENT:CLOSED self tcp 10.180.210.1:62736 -> 10.180.220.1:52675 -> 89.108.65.126:25 SYN_SENT:CLOSED self tcp 10.180.210.1:58177 -> 89.108.94.91:51550 -> 89.108.65.126:25 FIN_WAIT_2:FIN_WAIT_2 self tcp 10.180.210.1:58727 -> 10.180.220.1:50704 -> 89.108.94.212:25 SYN_SENT:CLOSED self tcp 10.180.210.1:57950 -> 89.108.94.91:65245 -> 89.108.94.212:25 FIN_WAIT_2:FIN_WAIT_2 You can see that some connections works, and some fails. 110% problem is NOT on real SMTP servers' side. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Asus WL-167g not working
Hello! I'm trying to use ASUS WL-167g, with ural driver compiled into kernel, but system does not recognize it. from /var/log/messages May 12 23:47:15 tarkhil kernel: ugen1: Ralink 802.11 bg WLAN, rev 2.00/0.01, addr 2 from usbdevs -v port 5 addr 2: high speed, power 300 mA, config 1, 802.11 bg WLAN(0x1723), Ralink(0x0b05), rev 0.01 System is FreeBSD 6.2-RELEASEp3. Any help is appreciated. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Asus WL-167g not working
Volker wrote: On 05/12/07 21:55, Alex Povolotsky wrote: Hello! I'm trying to use ASUS WL-167g, with ural driver compiled into kernel, but system does not recognize it. from /var/log/messages May 12 23:47:15 tarkhil kernel: ugen1: Ralink 802.11 bg WLAN, rev 2.00/0.01, addr 2 from usbdevs -v port 5 addr 2: high speed, power 300 mA, config 1, 802.11 bg WLAN(0x1723), Ralink(0x0b05), rev 0.01 if_ural.c does not know about a usb ID 1723 (only Asus IDs 1706 and 1705 are known). You need to patch it. Partially helped. Now it can be detected, but cannot scan. May 13 01:37:03 tarkhil kernel: ural0: Ralink 802.11 bg WLAN, rev 2.00/0.01, addr 2 May 13 01:37:04 tarkhil kernel: ural0: MAC/BBP RT2570 (rev 0x00), RF unknown May 13 01:37:04 tarkhil kernel: ural0: Ethernet address: 00:18:f3:e5:b8:dd May 13 01:37:04 tarkhil kernel: ural0: if_start running deferred for Giant Here I do ifconfig ural0 up scan May 13 01:37:08 tarkhil kernel: ural0: timeout waiting for BBP/RF to wakeup And no scan result. Alex. HTH Volker ___ 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]"
altq in current: where?
Hello! I'm trying to find out how to set up altq in 5.2.1-release and simply cannot understand where to start from. There is an rc.d script, and node for altq; but nothing more, no docs, no daemons. On altq page, the latest release is about stoneage time. Is it dead? Or I'm just cannot find the starting point for searching? -- Alex. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
help needed with dummynet
Hello! I've read man ipfw several times but still did not catch the following thing: I want to make ssh traffic 'top priority', giving it all bandwidth it wants, without explicitly limiting other kinds of traffic. man ipfw is quite unclear on queue usage, can anyone give me a working example? -- Alex. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GRE and PF problem
Hello! I'm using FreeBSD (5.3-RELEASE-p5) as internet access server, and I have to NAT GRE packets. I'm using pf. The problem is that SOMETIMES PF fails to create proper rule using nat, while binat works fine. Not only I do not want to expose Windows boxes (even if those addresses are firewalled), but it's also a terrible waste of real IPs. Can anyone point me if I have incorrect PF config, or PF just work poorly with gre? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GRE and PF problem
compunction wrote: GRE needs to pass bidirectional. You will need a binat to make it work. I have not found a firewall that will allow GRE to work with a many to one nat. The most painful thing is that pf's nat works for GRE - SOMETIMES :-( The only thing firewall needs to implement for natting GRE is creation of two rules (forward and back) for GRE packet, just like it does for ICMP. I'm not a firewall writer, but as far as I understand general procedural programming, it cannot be THAT complicated. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GRE and PF problem
compunction wrote: GRE needs to pass bidirectional. You will need a binat to make it work. I have not found a firewall that will allow GRE to work with a many to one nat. The most painful thing is that pf's nat works for GRE - SOMETIMES :-( The only thing firewall needs to implement for natting GRE is creation of two rules (forward and back) for GRE packet, just like it does for ICMP. I'm not a firewall writer, but as far as I understand general procedural programming, it cannot be THAT complicated. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GRE and PF problem
Giovanni P. Tirloni wrote: Alex Povolotsky wrote: compunction wrote: GRE needs to pass bidirectional. You will need a binat to make it work. I have not found a firewall that will allow GRE to work with a many to one nat. The most painful thing is that pf's nat works for GRE - SOMETIMES :-( The only thing firewall needs to implement for natting GRE is creation of two rules (forward and back) for GRE packet, just like it does for ICMP. I'm not a firewall writer, but as far as I understand general procedural programming, it cannot be THAT complicated. When a packet comes from 1.2.3.4 to your external interface you can't determine if it's destined to 192.168.0.1 or 192.168.0.2 if both initiated a GRE tunnel to 1.2.3.4. That's because GRE doesn't have ports like UDP or TCP to make (de)multiplexing possible, AFAIK. http://www.networksorcery.com/enp/protocol/gre.htm Cool. I did not know that ICMP doesn't work through nat. It always worked for me. Moreover, as far as I remember, GRE worked with IPFW/NATD, and SOMETIMES it works with pf. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SO_BINDANY in FreeBSD 10.3
Hello Is SO_BINDANY supported in FreeBSD 10.3? If not, do any patches exists? Alex ___ 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: SO_BINDANY in FreeBSD 10.3
Yes, got it already. For now, my problem has moved to deep squid/pf/tproxy issues... On 12.08.2016 18:37, Adrian Chadd wrote: Yeah, I integrated them from you like 10 years ago. It's in there somewhere. :-) (IP_BINDANY?) https://groups.google.com/forum/#!topic/mailing.freebsd.ipfw/L8lzLmG05WE ... poke me to write up some documentation. :) -adrian On 12 August 2016 at 08:29, Julian Elischer wrote: On 12/08/2016 8:00 PM, Alex Povolotsky wrote: Hello Is SO_BINDANY supported in FreeBSD 10.3? If not, do any patches exists? I'm certain that it is, somehow, but I'll be damned if I can remember how to do it.. There were patches for it in the 90s and early 2000s but I seem to remember they were integrated into the system. I think it had a different name though. Alex ___ 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" ___ 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" ___ 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"
