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]
Bridge and NAT problems
Hello. I've got the following problem... My host is configured like this: fxp0: internal interface, requires NAT rl1: public interface, with static IP xl0: bridged to rl1, with some public IP behind ipfw diverts any traffic through rl1 to natd, i.e. I have in ipfw 50 divert 8668 ip from any to any via rl1 Internal - Internet works, as Internet - Bridged does. Internal - Bridged does not work. Let's suppose I'm pinging from the inside to a bridged machine: the ICMP packet comes in through fxp0 and is allowed, gets NATted going out by rule 50 and reaches the target hosts (I guess bridging is also happening to send it out via xl0 instead of rl1). The target answers to the public IP of this box and the packet comes in via xl0, so it's not back-NATted and gets lost. I then tought of diverting to natd every packet through xl0 (i.e. 60 divert 8668 ip from any to any via xl0), but this doesn't work either. The packet gets to natd by means of rule 60, but natd does not recognize it as an answer to a previously examined packet. From man pages I understood that natd does not take interface into account, but only source and destination IP:port. Then, what's wrong? Any suggestion? bye Thanks av. ___ 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?
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. -- Alexander Motin [EMAIL PROTECTED] Optima Telecom ___ 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]
Re: Bridge and NAT problems
If memory serves me right, Andrea Venturoli wrote: Hello. I've got the following problem... My host is configured like this: fxp0: internal interface, requires NAT rl1: public interface, with static IP xl0: bridged to rl1, with some public IP behind ipfw diverts any traffic through rl1 to natd, i.e. I have in ipfw 50 divert 8668 ip from any to any via rl1 Internal - Internet works, as Internet - Bridged does. Internal - Bridged does not work. Let's suppose I'm pinging from the inside to a bridged machine: the ICMP packet comes in through fxp0 and is allowed, gets NATted going out by rule 50 and reaches the target hosts (I guess bridging is also happening to send it out via xl0 instead of rl1). The target answers to the public IP of this box and the packet comes in via xl0, so it's not back-NATted and gets lost. I then tought of diverting to natd every packet through xl0 (i.e. 60 divert 8668 ip from any to any via xl0), but this doesn't work either. The packet gets to natd by means of rule 60, but natd does not recognize it as an answer to a previously examined packet. From man pages I understood that natd does not take interface into account, but only source and destination IP:port. Then, what's wrong? Any suggestion? You didn't say which bridging driver or version of FreeBSD you're using, but it sounds to me like you're using bridge(4), right? This is a fairly well known problem, which I wrote a little bit about here: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.html (This message describes a scenario with ipf, but it applies equally well I think to ipfw.) If you can, try switching to using if_bridge(4). You (probably) want to assign the public NAT address to the bridge0 interface, and leave the physical interfaces making up the bridges (xl0 and rl1 in your case) unnumbered. I've had good experiences with this type of configuration. Bruce. signature.asc Description: OpenPGP digital signature
Re: mpd success stories, anyone?
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. -- Alexander Motin [EMAIL PROTECTED] Optima Telecom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bridge and NAT problems
Bruce A. Mah wrote: You didn't say which bridging driver or version of FreeBSD you're using, but it sounds to me like you're using bridge(4), right? Yes. This is a fairly well known problem, which I wrote a little bit about here: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.html (This message describes a scenario with ipf, but it applies equally well I think to ipfw.) Read that. So I guess my analysis was wrong in that I thought natd was not reconverting packets; from what you say I understand the problem is that this packets are not diverted to natd, right? The details are right now beyond my understanding... If you can, try switching to using if_bridge(4). I cannot right now, since I have to wait to be physically at this box, but I could try in the future. Do you see any drawback? You (probably) want to assign the public NAT address to the bridge0 interface, and leave the physical interfaces making up the bridges (xl0 and rl1 in your case) unnumbered. I've had good experiences with this type of configuration. Ok. So I would only need to create the bridge0 interface as per man page sysctl net.link.bridge.ipfw=1 sysctl net.link.bridge.pfil_onlyip=0 change every reference to rl1 in my ipfw ruleset to bridge0 Anything else? Would everything work the same as now (apart from this feature which is causing me troubles)? bye Thanks a lot av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw limit src-addr woes
On Wed, 21 Feb 2007, Julian Elischer wrote: Ian Smith wrote: On Tue, 20 Feb 2007, Julian Elischer wrote: admin wrote: Wrong: the implied check-state done by the limit lets the connection through (i.e. performs the action) iff there's state recorded for it (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet incoming and the number of current states is trying to cross the limit, the SYN packet is implicitly dropped and the search terminates. This is not to say that I completely understand the things going on when the connections start building up (different timeouts?) but the above conclusion is based on what simulation has shown. The whole ruleset fits on one screen, there's an allow ip from any to any in the end, so I'm pretty sure I'm not crazy :-) One thing to keep in mind is that a 'check-state' rule works by effectively jumping to the rule that did the 'keep-state' and re-executing it.. (and incrementing its stats). What if the action of the rule that does the 'keep-state' (here a limit src-addr) is a skipto, rather than an allow / fwd / divert etc rule that would terminate the search? Does 're-executing' here imply anything about whether the skipto's conditional branch is or is not taken? if the keep-state rule is a skipto then the check-state will skip to.. I use that in some rules. here's a snippet that I have when acting as a filtering transparent bridge, with DNS replies (from the outside) being diverted to a snooper. The bridge is between em2 (inside) and em3 (outside). 01200 17588453 1257728932 skipto 1210 udp from any to any dst-port 53 recv em2 01201 16192860 2721432229 skipto 1220 udp from any 53 to any recv em3 01202 43658738 21537916245 skipto 1250 ip from any to any 01210 34023270 3994649771 skipto 1240 ip from any to any keep-state 01220 0 0 check-state 01229 2364 441701 deny ip from any to any 01240 16190496 2720990528 divert 5001 udp from any 53 to any recv em3 01242 17832774 1273659243 deny ip from any to any (note this requires patches to allow divert from a bridge.) It's convoluted I know but it only (well, mostly) diverts packets from the outside that are part of a conversation that was started already (probably by a dns request from inside) DNS packets from the outside that are not a response to something we already asked for are discarded (a DOS protection) note that all the packets that went to the check-state, (1220) ended up going back to 1210 where they did the skipto 1240 and were filtered again. Thanks Julian, great illustration! After much chewing I've got most of the marrow, but have buried this bone where I can dig it up again (woof) Re admin's issue, I notice that the em3 packets failing check-state still require denying at 1229, such that p(kts)1201 - p1229 = p1240. Do you have any earlier rules jumping into here too, as the 1210 packet counts don't quite add up; ie p1210 (p1200 + p1240) by ~244k packets? Re 1242, are these (mostly) diverted packets reentering the firewall? After snooping, how do the clients get their DNS replies if they're denied here, or does your divert code reinsert those elsewhere? And where do the then ~1.2M extra denied packets denied here come from? Cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
5.4-RELEASE and 5.5-RELEASE Slow routing table response
I have an Internet proxy that is running FreeBSD 5.4-RELEASE. This server has been up and running beautifully for about a year and a half with no issues. Just the other day I had a user try to connect to a host on the Internet and her connection was failing. At first I thought that it was the receiving host's issue because we were having no other Internet connection issues through the proxy. However, I ran a test connection from my home and found that everything worked fine. After investigating the issue I found that if I ran a route get xxx.xxx.xxx.xxx on my proxy server it would take 1.25 minutes for the route to come back. This same delay was also experienced if I tried to use telnet to open a connection to the remote host. After about 1.25 minutes the session would open successfully. So I ran route monitor and found that when I execute the route get command the RTM_GET returns the appropriate route almost immediately but there is still a substantial delay in the route get command displaying the response. I ran this test on three other 5.4 and one 5.5 servers and found that they all had the same issue. However, if I ran the same route get command on a 5.3 server it works just fine. After all of my testing I wanted to know exactly what IP address range was affected and found that it is limited to just 60 address within a specific range (I can provide the range). Any help you could provide would be greatly appreciated. - Don't get soaked. Take a quick peak at the forecast with theYahoo! Search weather shortcut. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RELEASE and 5.5-RELEASE Slow routing table response
On Feb 22, 2007, at 1:45 PM, Jeremy Nelson wrote: I have an Internet proxy that is running FreeBSD 5.4-RELEASE. This server has been up and running beautifully for about a year and a half with no issues. Just the other day I had a user try to connect to a host on the Internet and her connection was failing. At first I thought that it was the receiving host's issue because we were having no other Internet connection issues through the proxy. However, I ran a test connection from my home and found that everything worked fine. After investigating the issue I found that if I ran a route get xxx.xxx.xxx.xxx on my proxy server it would take 1.25 minutes for the route to come back. This same delay was also experienced if I tried to use telnet to open a connection to the remote host. After about 1.25 minutes the session would open successfully. So I ran route monitor and found that when I execute the route get command the RTM_GET returns the appropriate route almost immediately but there is still a substantial delay in the route get command displaying the response. I ran this test on three other 5.4 and one 5.5 servers and found that they all had the same issue. However, if I ran the same route get command on a 5.3 server it works just fine. After all of my testing I wanted to know exactly what IP address range was affected and found that it is limited to just 60 address within a specific range (I can provide the range). Any help you could provide would be greatly appreciated. This is almost definitely a DNS issue. Try route -n get or telnet -N and see if it still happens. -- Kevin ___ 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]
Remote Install using FreeBSD
Hello everyone, I was wondering if you could help me with this one. I am trying to do this one without any luck. How do you remote install FReeBSD using FreeBSD? There doesn't seem to be any documentation around to help me. No Step 1, Step 2 , Step 3 guide. I have searched the web and the nearest I came to was a guy using isc-DHCP program which wasn't included in the original FreeBSD installation. I download it to carry on with the rest of the steps but it doesn't do well with make install clean. If anyone has done it alternatively, please let me know. The laptop that is going to be the client has PXE boot built in the BIOS. Regards, Rajen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remote Install using FreeBSD
Rajen Jani (BT Yahoo! Broadband) wrote: Hello everyone, I was wondering if you could help me with this one. I am trying to do this one without any luck. How do you remote install FReeBSD using FreeBSD? There doesn't seem to be any documentation around to help me. No Step 1, Step 2 , Step 3 guide. I have searched the web and the nearest I came to was a guy using isc-DHCP program which wasn't included in the original FreeBSD installation. I download it to carry on with the rest of the steps but it doesn't do well with make install clean. If anyone has done it alternatively, please let me know. The laptop that is going to be the client has PXE boot built in the BIOS. Did you check FreeBSD handbook? Ganbold Regards, Rajen ___ 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]
sleeping thread
Hi Folks,
I am coming across a weird issue with FreeBSD 6.1, any help appreciated.
The problem is the following:
One thread (1) does a setsockopt, grabs a lock in udp_usrreq, calls
copyin which hits a pagefault, this leads to that thread sleeping by
calling msleep.
msleep(f01cd488,c09fe6a0,44,c0956c79,0) at
bwait(f01cd488,44,c0956c79) at
vnode_pager_input_smlfs(c10487bc,c2740ae0,0,1,fcd6d918) at
vnode_pager_generic_getpages(ccd0bcf0,fcd6da50,1000,0,fcd6d978) at
vop_stdgetpages(fcd6d98c) at
Another thread (netisr) which is processing some udp packet tries to
grab the same lock but since it's already held by thread 1, tries to
propagate the priority and panics because there is a check in the code
in propagate_priority which causes the panic
/*
* If the thread is asleep, then we are probably about
* to deadlock. To make debugging this easier, just
* panic and tell the user which thread misbehaved so
* they can hopefully get a stack trace from the truly
* misbehaving thread.
*/
if (TD_IS_SLEEPING(td)) {
printf(
Sleeping thread (tid %d, pid %d) owns a non-sleepable
lock\n,
td-td_tid, td-td_proc-p_pid);
#ifdef DDB
db_trace_thread(td, -1);
#endif
panic(sleeping thread);
}
Below is the output with witness turned on
Not sure how to go forward with this, any pointers?
Thanks,
Pramod
lock order reversal: (sleepable after non-sleepable)
1st 0xc0a20a8c udp (udp) @ src/sys/netinet/udp_usrreq.c:1523
2nd 0xccdbee54 user map (user map) @ src/sys/vm/vm_map.c:3005
KDB: stack backtrace:
kdb_backtrace(0,,c09c1b40,c09c16e0,c0978c6c) at
witness_checkorder(ccdbee54,9,c09305b4,bbd) at
_sx_xlock(ccdbee54,c09305a8,bbd) at
_vm_map_lock_read(ccdbee10,c09305a8,bbd,1d6d9b4,ccdd76a8) at
vm_map_lookup(fcd6da40,8097000,1,fcd6da44,fcd6da34) at
vm_fault(ccdbee10,8097000,1,0,ccdd5000) at
trap_pfault(fcd6db08,0,8097940) at
trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at
calltrap() at
--- trap 0xc, eip = 0xc08a5e06, esp = 0xfcd6db48, ebp = 0xfcd6db68 ---
slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at
ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at
udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at
sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at
kern_setsockopt(ccdd5000,6,0,6d,8097940) at
setsockopt(ccdd5000,fcd6dd04,5,2,292) at
syscall(3b,3b,3b,0,7a6c) at
Xint0x80_syscall() at
--- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x881d1787, esp =
0xbfbfddec, ebp = 0xbfbfde48 ---
Acquiring lockmgr lock isofs with the following non-sleepable locks
held:
exclusive sleep mutex udp r = 0 (0xc0a20a8c) locked @
src/sys/netinet/udp_usrreq.c:1523
KDB: stack backtrace:
kdb_backtrace(1,1,1,3041,ccd0bd6c) at
witness_warn(5,c09b211c,c09416bb,c09406a1) at
lockmgr(ccd0bd48,3041,ccd0bd6c,ccdd5000,fcd6d918) at
vop_stdlock(fcd6d938,3041,ccd0bcf0,fcd6d954,c058e20c) at
VOP_LOCK_APV(c09704e0,fcd6d938) at
vn_lock(ccd0bcf0,3041,ccdd5000,ccd0bcf0,3041) at
vget(ccd0bcf0,3041,ccdd5000) at
vnode_pager_lock(ccdf1840,ccdf1840,ccdf1840,0,c0930058) at
vm_fault(ccdbee10,8097000,1,0,ccdd5000) at
trap_pfault(fcd6db08,0,8097940) at
trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at
calltrap() at
--- trap 0xc, eip = 0xc08a5e06, esp = 0xfcd6db48, ebp = 0xfcd6db68 ---
slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at
ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at
udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at
sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at
kern_setsockopt(ccdd5000,6,0,6d,8097940) at
setsockopt(ccdd5000,fcd6dd04,5,2,292) at
syscall(3b,3b,3b,0,7a6c) at
Xint0x80_syscall() at
--- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x881d1787, esp =
0xbfbfddec, ebp = 0xbfbfde48 ---
Sleeping on vnsrd with the following non-sleepable locks held:
exclusive sleep mutex udp r = 0 (0xc0a20a8c) locked @
src/sys/netinet/udp_usrreq.c:1523
KDB: stack backtrace:
kdb_backtrace(1,1,1,ccdd763c,ccdd5000) at
witness_warn(5,c09fe6a0,c0942b95,c0956c79) at
msleep(f01cd488,c09fe6a0,44,c0956c79,0) at
bwait(f01cd488,44,c0956c79) at
vnode_pager_input_smlfs(c10487bc,c2740ae0,0,1,fcd6d918) at
vnode_pager_generic_getpages(ccd0bcf0,fcd6da50,1000,0,fcd6d978) at
vop_stdgetpages(fcd6d98c) at
VOP_GETPAGES_APV(c09704e0,fcd6d98c) at
vnode_pager_getpages(c10487bc,fcd6da50,1,0) at
vm_fault(ccdbee10,8097000,1,0,ccdd5000) at
trap_pfault(fcd6db08,0,8097940) at
trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at
calltrap() at
--- trap 0xc, eip = 0xc08a5e06, esp = 0xfcd6db48, ebp = 0xfcd6db68 ---
slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at
ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at
udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at
sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at
kern_setsockopt(ccdd5000,6,0,6d,8097940) at
setsockopt(ccdd5000,fcd6dd04,5,2,292) at
syscall(3b,3b,3b,0,7a6c) at
Xint0x80_syscall() at
---
Re: Bridge and NAT problems
If memory serves me right, Andrea Venturoli wrote: Bruce A. Mah wrote: You didn't say which bridging driver or version of FreeBSD you're using, but it sounds to me like you're using bridge(4), right? Yes. This is a fairly well known problem, which I wrote a little bit about here: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.html (This message describes a scenario with ipf, but it applies equally well I think to ipfw.) Read that. So I guess my analysis was wrong in that I thought natd was not reconverting packets; from what you say I understand the problem is that this packets are not diverted to natd, right? The details are right now beyond my understanding... Without more details it's difficult to say. Not to be overly critical, but does not work from your original post isn't real helpful, unfortunately. If you had packet traces of, say, attempted pings, that would give a lot more data to help say exactly what the problem is. It just sounds *very* similar to a problem I spent a lot of time working on. If you can, try switching to using if_bridge(4). I cannot right now, since I have to wait to be physically at this box, but I could try in the future. Do you see any drawback? None I can think of. Note that bridge(4) is deprecated in RELENG_6 and is gone entirely from HEAD (in favor of if_bridge(4)). if_bridge(4) is also more featureful and is being actively worked on. You (probably) want to assign the public NAT address to the bridge0 interface, and leave the physical interfaces making up the bridges (xl0 and rl1 in your case) unnumbered. I've had good experiences with this type of configuration. Ok. So I would only need to create the bridge0 interface as per man page sysctl net.link.bridge.ipfw=1 sysctl net.link.bridge.pfil_onlyip=0 change every reference to rl1 in my ipfw ruleset to bridge0 Anything else? Would everything work the same as now (apart from this feature which is causing me troubles)? I think that'll work, yes. (Caveat: If you are doing other filtering in ipfw you might need to make some additional adjustments, but if all you're doing is NAT/divert, change every reference to rl1 ... to bridge0 should work just fine.) Bruce. signature.asc Description: OpenPGP digital signature
Re: Fighting mpd
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. -- Alexander Motin [EMAIL PROTECTED] Optima Telecom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
