Re: 4.8-RC report
this is what i get when using a USB kb: 1- bios works ok (at least from the kb point of view :-) 2- (pxe)boot works ok - i can hit the space-bar, then type boot -v 3- the boot process hangs somewhere after recognizing the em0. all is ok with a ps/2 kb. danny > > Possibly false alarm: > > Preloading the usb keyboard module seems to cause the > normal kbd to hang forever during probing.. > I do not yet know if this is documented anywhere > if it isn't then it's still a problem I guess. > > > On Thu, 6 Mar 2003, Julian Elischer wrote: > > > > > After instralling afew machines it seems to mostly work with the > > exception of a couple of machiens which just Hang forever while trying > > to probe their keyboard.. Has anyone been fiddling in the keyboard > > code? > > > > CVS only shows cosmetic changes over the last few months > > but something has changed .. I'm going to try another keyboard.. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
High CPU usage when forwarding packets
I've just setup a P75 system as a router, containing fa311 and pcnet network cards. The fa311 is doing nat to my private network, which is served by the pcnet card. However, I've found that it often uses 40% cpu just to send packets from the fa311 (sis) to the pcnet (lnc) cards. natd uses 20%, 10% are interrupts, and 25% is 'system' as shown in top. Also, I'm getting several thousand 'lnc0: Missed packet -- no receive buffer' messages. Could this be the problem, or is the system just not powerful enough do nat? The sis0 card is 100MBit PCI, while the lcn0 is 10MBit ISA. Bruce Cran To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
Wes Peters writes: | On Thursday 06 March 2003 15:02, Paulo Roberto wrote: | > --- Bram Van Dam <[EMAIL PROTECTED]> wrote: | > > cheap they are they do their job fairly well. If performance isn't | > > an issue then go for it. | > | > I couldn't agree more. If you are just staying in 55 mph, you don't | > need a Ferrari. | | It's not a ford vs. ferrari problem, it's that the ford only has first | gear, so you're doing 45 mph at redline and in grave danger of blowing | the heads off continuously. | | The problem with the RealTek chipset is that the packets have to be | aligned on some completely stupid boundary in memory (32 bytes if memory | serves). The driver code ends up copying the packet data to a tempory | buffer before sending it for almost every outgoing packet, which is just | totally stupid. [snip] | JUST SAY NO. Actually, test and the pick the fastest tends to be better. Since D-Link dropped their good 4-port card for a broken one which they discontinued we had to scramble for a solution. Our test bed was a basically a "server" machine tied to a "router/bridge" like thing with 4 clients. We'd run tests all to the server, all to the clients and everything at once. This illustrated the HW issue with the new D-Link 4 port card since none of their "supported" drivers and OSes could get over 20Mbs. We had 100FDX links to each client and a Gig link to the server. FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD must be broken even though it was faster then their supported OSes (Windows < 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD driver. Using this framework we had a bridge riser card that we could plug 4 various PCI ethernet cards. We tested the dc(4), fxp(4), rl(4), sis(4) cards of various types and with our motherboard and CPU the rl(4) 8139C chips where the fastest via netperf with a significant margin. I went into the test biased against Realtek but couldn't justify not using them after testing. Now we are using the 8100L chip so we have a pretty simple design. So I'd say given a sufficiently fast CPU and memory the Realteks work pretty darn good. The speed win could be do to a slightly better bus interface. That was the problem with the newer D-Link 4 port card in that during RX the chip would take over the PCI bus for a lng time. A sufficiently fast CPU in our case is 700Mhz Celeron which is a lot different then pushing 100Mbs with a P5 133Mhz. Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port cards. To date we haven't had any trouble with them and we've shipped a bunch. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
Wes Peters wrote: > The problem with the RealTek chipset is that the packets have to be > aligned on some completely stupid boundary in memory (32 bytes if memory > serves). The driver code ends up copying the packet data to a tempory > buffer before sending it for almost every outgoing packet, which is just > totally stupid. And TCP/IP headers are not an even multiple of the alignment boundary (4 bytes, actually). So every packet the card DMA's in has to be copied so that access to the TCP packet contents are aligned. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: High CPU usage when forwarding packets
Bruce Cran wrote: > Also, I'm getting > several thousand 'lnc0: Missed packet -- no receive buffer' messages. > Could this be the problem, or is the system just not powerful enough do > nat? The sis0 card is 100MBit PCI, while the lcn0 is 10MBit ISA. The "no receive buffers available" message happens when the system runs out of mbufs. There are a lot of reasons this could happen, but the proximal cause is you didn't tune the number NMBCLUSTERS, et. al. high enough. You should try rebuilding your kernel with a larger number. If the problem still happens, you need to do a "netstat -a > x", and then look for large numbers in the "Recv-Q" and "Send-Q" columns, and then figure out what's causing them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
Le Friday 07 March 2003 18:16, Doug Ambrisko a écrit : [SNIP] > everything at once. This illustrated the HW issue with the new D-Link 4 > port card since none of their "supported" drivers and OSes could get over > 20Mbs. We had 100FDX links to each client and a Gig link to the server. > FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD > must be broken even though it was faster then their supported OSes > (Windows < 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD > driver. > [re-SNIP] > > Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port > cards. and the avid reader asks : so, now, what NIC are you really using ? (I too have used with great pleasure quite a bunch of DLink-DFE-570), and I was leaning towards using the newer DFE-580 4-port on another project ...) any suggestions (with benchmark results ?) heartily welcome ! TfH > > To date we haven't had any trouble with them and we've shipped a bunch. then, what are these "them" ? > > Doug A. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
Thierry Herbelot writes: | Le Friday 07 March 2003 18:16, Doug Ambrisko a ?crit : | > everything at once. This illustrated the HW issue with the new D-Link 4 | > port card since none of their "supported" drivers and OSes could get over | > 20Mbs. We had 100FDX links to each client and a Gig link to the server. | > FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD | > must be broken even though it was faster then their supported OSes | > (Windows < 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD | > driver. | > | [re-SNIP] | > | > Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port | > cards. | | and the avid reader asks : so, now, what NIC are you really using ? (I too | have used with great pleasure quite a bunch of DLink-DFE-570), and I was | leaning towards using the newer DFE-580 4-port on another project ...) The DFE-580 is EOL. That is their solution to their less then optimal card with no replacement coming according to our rep. We are using our own custom board with the Realtek 8100L parts. | any suggestions (with benchmark results ?) heartily welcome ! I need to find them however, you need to benchmark in your environment since CPU load etc can effect things. PHK found a 4 port fxp card that was priced pretty good. I don't know how successful he has with them. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
seeking advice WRT maintaining private FreeBSD ports branch
I apologize for the odd subject line, and will fill in some details: I'm exploring tweaks to various ports, for my private use. Some of these tweaks can't be addressed via pkgtools.conf or abuse of environment variables, and instead required actual modifications to files. I maintain a local CVS repository of FreeBSD via CVSup. I regularly update my packages via the classic 'cvs co ports; portupgrade --package --all'. What I want is to somehow preserve my local tweaks, such that they get reapplied to my working copy upon a checkout. Tracking these tweaks via CVS _seems_ to be the way to go, but apparently I'm not as sophisticated a CVS admin as I thought, and can't seem to stumble on the right combinations of tools/practices to do what I want. So, does anyone have any concrete examples of how I can accomplish this, or at least provide some magic terminology, such that I can better pursue web research? (Or, suggest a better forum to pitch this question?) Thanks for any input... -- Brian 'you Bastard' Reichert<[EMAIL PROTECTED]> 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: seeking advice WRT maintaining private FreeBSD ports branch
> From: Brian Reichert [mailto:[EMAIL PROTECTED] ... > I maintain a local CVS repository of FreeBSD via CVSup. ... http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html has the details you need. It entails an env var like: CVS_LOCAL_BRANCH_NUM=1000 and changing the style of your cvsup. --don To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
On Fri, Mar 07, 2003 at 10:43:37AM -0800, Terry Lambert wrote: >And TCP/IP headers are not an even multiple of the alignment boundary >(4 bytes, actually). So every packet the card DMA's in has to be >copied so that access to the TCP packet contents are aligned. Last time I looked at TCP/IP, the header lengths were all defined in 4-byte units so they must be a multiple of 4 bytes by definition. Maybe you are referring to the Ethernet header - which is 14 bytes long (18 bytes in a VLAN trunk). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seeking advice WRT maintaining private FreeBSD ports branch
Brian Reichert wrote: > I'm exploring tweaks to various ports, for my private use. Some > of these tweaks can't be addressed via pkgtools.conf or abuse of > environment variables, and instead required actual modifications > to files. [ ... ] > What I want is to somehow preserve my local tweaks, such that they > get reapplied to my working copy upon a checkout. [ ... ] > So, does anyone have any concrete examples of how I can accomplish > this, or at least provide some magic terminology, such that I can > better pursue web research? This doesn't directly answer your question, but it does directly address your problem... Submit your tweaks back to the port maintainer. If they are tweaks to the software the port represents, rather than tweaks to the port, then submit them back to the original author of the software in question, and they will come in through the FreeBSD port that way. I've actually spent a substantial amount of time, on various occasions, going through the patches in the ports tree, and, as long as they don't do something like break the ability of the code to run on non-FreeBSD platforms, cleaned the patches up and submitted them back to the original vendors. Mostly things that don't require a big pipe to download before I can do the work. For example, I've submitted a number of patches to "bind", "MySQL", and so on, this way. I like to do this, because I like to see code compile and run on FreeBSD "out of the box", without having to be filtered through the ports system. If you are building an embedded product, and want to use software for which a port, with patches, exists, then it really sucks to use the port, because you need to include a copy of the software in your local repository, and that's pretty immiscible with the way the ports system works. Sending patches back so that ports are as "vanilla" as possible lets me keep my options open that way. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
Peter Jeremy wrote: > On Fri, Mar 07, 2003 at 10:43:37AM -0800, Terry Lambert wrote: > >And TCP/IP headers are not an even multiple of the alignment boundary > >(4 bytes, actually). So every packet the card DMA's in has to be > >copied so that access to the TCP packet contents are aligned. > > Last time I looked at TCP/IP, the header lengths were all defined > in 4-byte units so they must be a multiple of 4 bytes by definition. > Maybe you are referring to the Ethernet header - which is 14 bytes > long (18 bytes in a VLAN trunk). Yes. Unless the transfer is padded by the card in the DMA, or it can DMA to a two-byte shifted boundary from it's own start address, you end up having to copy to gt the TCP/IP headers onto a 4 byte alignment boundary. There are a couple other cards that suck this way; if Bill Paul wrote the driver for the card, then the information is in the comments in the driver. Generally, reading the comments in all the drivers, and picking the one with the least disparaging remarks is a good way to pick hardware. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seeking advice WRT maintaining private FreeBSD ports branch
On Fri, Mar 07, 2003 at 02:18:20PM -0800, Terry Lambert wrote: > This doesn't directly answer your question, but it does directly > address your problem... Er, nope. Nice try: > Submit your tweaks back to the port maintainer. Um, some of these tweaks are _not_ going to be accepted, such as commenting out 'NO_PACKAGE' out of a makefile. The rest of your suggestions are quite sound, and would be employed by me once I feel my changes are ready for prime-time... > > -- Terry > -- Brian 'you Bastard' Reichert<[EMAIL PROTECTED]> 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seeking advice WRT maintaining private FreeBSD ports branch
On Fri, Mar 07, 2003 at 04:58:03PM -0500, Don Bowman wrote: > > From: Brian Reichert [mailto:[EMAIL PROTECTED] > ... > > I maintain a local CVS repository of FreeBSD via CVSup. > ... > > http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html > > has the details you need. It entails an env var like: > CVS_LOCAL_BRANCH_NUM=1000 > > and changing the style of your cvsup. Excellent! Seems quite to-the-point. Lemme see if I can make it sing... > > --don > -- Brian 'you Bastard' Reichert<[EMAIL PROTECTED]> 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: High CPU usage when forwarding packets
On 2003-03-07 10:58, Terry Lambert <[EMAIL PROTECTED]> wrote: >Bruce Cran wrote: >> Also, I'm getting several thousand 'lnc0: Missed packet -- no >> receive buffer' messages. Could this be the problem, or is the >> system just not powerful enough do nat? The sis0 card is 100MBit >> PCI, while the lcn0 is 10MBit ISA. > > The "no receive buffers available" message happens when the > system runs out of mbufs. > > There are a lot of reasons this could happen, but the proximal > cause is you didn't tune the number NMBCLUSTERS, et. al. high > enough. You should try rebuilding your kernel with a larger > number. Aren't the following two tunable from the loader too? [EMAIL PROTECTED]:53]/home/giorgos$ sysctl -a | grep nmb[cu][fl] kern.ipc.nmbclusters: 17216 kern.ipc.nmbufs: 34432 Just wondering, since I haven't had today a reasonn to reboot yet. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Are there any on-going projects on v4l porting?
Hello all, As subj. said - does anybody work on porting v4l & (especially!) drivers for non- bt8x based cards? Specifically saa7134 based (got one and would rather not have to reboot to Linux to watch TV :-) Yes, I know, the simplest answer would be "you're interested - you do" but that'd be quite beyond my skills. Still I'd happily help with testing/debugging/whatever else. Regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
On Friday 07 March 2003 09:16, Doug Ambrisko wrote: > Wes Peters writes: > | On Thursday 06 March 2003 15:02, Paulo Roberto wrote: > | > --- Bram Van Dam <[EMAIL PROTECTED]> wrote: > | > > cheap they are they do their job fairly well. If performance > | > > isn't an issue then go for it. > | > > | > I couldn't agree more. If you are just staying in 55 mph, you don't > | > need a Ferrari. > | > | It's not a ford vs. ferrari problem, it's that the ford only has > | first gear, so you're doing 45 mph at redline and in grave danger of > | blowing the heads off continuously. > | > | The problem with the RealTek chipset is that the packets have to be > | aligned on some completely stupid boundary in memory (32 bytes if > | memory serves). The driver code ends up copying the packet data to a > | tempory buffer before sending it for almost every outgoing packet, > | which is just totally stupid. > > [snip] > > | JUST SAY NO. > > Actually, test and the pick the fastest tends to be better. > > Since D-Link dropped their good 4-port card for a broken one which they > discontinued we had to scramble for a solution. Our test bed was a > basically a "server" machine tied to a "router/bridge" like thing with > 4 clients. We'd run tests all to the server, all to the clients and > everything at once. This illustrated the HW issue with the new D-Link > 4 port card since none of their "supported" drivers and OSes could get > over 20Mbs. We had 100FDX links to each client and a Gig link to the > server. FreeBSD could peak to 40Mbs if I recall right and we were told > FreeBSD must be broken even though it was faster then their supported > OSes (Windows < 1Mbs)! To be honest I did fix a bunch of bugs in the > FreeBSD driver. > > Using this framework we had a bridge riser card that we could plug > 4 various PCI ethernet cards. We tested the dc(4), fxp(4), rl(4), > sis(4) cards of various types and with our motherboard and CPU the > rl(4) 8139C chips where the fastest via netperf with a significant > margin. I went into the test biased against Realtek but couldn't > justify not using them after testing. Now we are using the 8100L chip > so we have a pretty simple design. You did something truly bizarre. I've tested similar cards on many machines ranging from K6-2 400MHz to P4 2.4GHz and the RealTek performance has always been at or near the bottom of the heap. On the slower processors, the overhead of aligning packets shows heavily, but it can be noticed on any system. A number of the chips folded into the dc(4) driver are horrible and perform right down there with the RealTek, but a few are fairly good. The 3com 3c905s are generally quite good using the xl(4) driver, as are the Intel EEPro's using fxp. I've read of others struggling with both but never encountered this myself. I tend to be quite conservative about throwing random versions of FreeBSD at systems, though, and many of those complaints come from people at various points on -stable, rather than a known release point. > So I'd say given a sufficiently fast CPU and memory the Realteks work > pretty darn good. For a sufficient engine RPM, that escort will do 85 MPH in first gear, too. ;^) > The speed win could be do to a slightly better > bus interface. That was the problem with the newer D-Link 4 port card > in that during RX the chip would take over the PCI bus for a lng > time. Yup, they're complicated beasts. For someone who is not going to work on the drivers themselves but wants performance, I suspect buying whatever you can get in bulk for eight dollars is not an optimal strategy. > A sufficiently fast CPU in our case is 700Mhz Celeron which is a lot > different then pushing 100Mbs with a P5 133Mhz. > > Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port > cards. > > To date we haven't had any trouble with them and we've shipped a bunch. Give me 1 second and I can easily bring any of your systems to their knees, regardless of which cards you have installed. Everything is relative. Were you watching the system load while performing your testing? Was the cpu doing anything but routing? Is it required to for your application? These and many others are all important questions, and tend to have different answers for every application. For a desktop workstation with undemanding network application requirements (email, web browsing, occasional software updates) RealTek or any other card that successfully attach to the network and correctly autonegotiate with your hub (shudder) or switch is fine. Even a RealTek. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek
On Friday 07 March 2003 13:17, Doug Ambrisko wrote: > Thierry Herbelot writes: > | > | and the avid reader asks : so, now, what NIC are you really using ? > | (I too have used with great pleasure quite a bunch of DLink-DFE-570), > | and I was leaning towards using the newer DFE-580 4-port on another > | project ...) > > PHK found a 4 port fxp card that was priced pretty good. I don't know > how successful he has with them. We're using a 2-port EEPro with 82551 chips with the two ports connected with relays and a watchdog; we get excellent throughput in our testing so far. I don't recall the vendor, it is "Ad-something." I can look them up Monday if you email me about it then. I think they make a 4-port 551 card without the relays as well, but I don't know about pricing. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why natd don't divert packets?
On Fri, Mar 07, 2003 at 11:51:45AM +0300, denb wrote: > This working in FreeBSD4.7(ipfw1), but broken in FreeBSD 5.0(ipfw2). > Why? This is an issue triggered by compiling libalias with -O2. Recompile libalias without -O2 and recompile natd so it binds to the rebuild libalias.a The problem wasn't there a month ago. See -current list for firther details. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why natd don't divert packets?
Bernd Walter <[EMAIL PROTECTED]>: > On Fri, Mar 07, 2003 at 11:51:45AM +0300, denb wrote: > > This working in FreeBSD4.7(ipfw1), but broken in FreeBSD 5.0 (ipfw2). > > Why? > > This is an issue triggered by compiling libalias with -O2. > Recompile libalias without -O2 and recompile natd so it binds to the > rebuild libalias.a > The problem wasn't there a month ago. > See -current list for firther details. > > -- > B.Walter COSMO-Project http://www.cosmo- project.de > [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] > > I ran this on FreeBSD 5.0-RELEASE, not CURRENT. Any suggestions? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Why natd don't divert packets?
Why natd don't divert packets? *screenshot*** #ipfw add divert tcp from any to any 7 #ipfw add divert tcp from any 7 to any #natd -v -p -a 172.16.0.102 -redirect_port tcp 172.16.0.253:7 7 In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to [TCP] 172.16.0.104:49169 -> 172.16.0.253:7 In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to [TCP] 172.16.0.104:49169 -> 172.16.0.253:7 ^C *screenshot*** Where is Out[TCP]? Rules after natd running (why second rule has 0 in packets number?): *screenshot*** #ipfw show 0001 6 180 divert tcp from any to any dst-port 7 0002 00 divert tcp from any 7 to any *screenshot*** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why natd don't divert packets?
On Fri, 7 Mar 2003 11:02:06 +0300 (MSK) denb <[EMAIL PROTECTED]> wrote: > Why natd don't divert packets? > > *screenshot*** > > #ipfw add divert tcp from any to any 7 > #ipfw add divert tcp from any 7 to any > #natd -v -p -a 172.16.0.102 -redirect_port tcp 172.16.0.253:7 7 > > In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to >[TCP] 172.16.0.104:49169 -> 172.16.0.253:7 > > In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to >[TCP] 172.16.0.104:49169 -> 172.16.0.253:7 > > ^C > *screenshot*** > > Where is Out[TCP]? > Your boxes seems to be on the same subnet, "out" packets are directly sent to 172.16.0.104, not 172.16.0.102 nat'ing implies routing, so natd is inefficient in your case clem To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why natd don't divert packets?
Clement Laforet <[EMAIL PROTECTED]>: > On Fri, 7 Mar 2003 11:02:06 +0300 (MSK) > denb <[EMAIL PROTECTED]> wrote: > > > Why natd don't divert packets? > > > > *screenshot*** > > > > #ipfw add divert tcp from any to any 7 > > #ipfw add divert tcp from any 7 to any > > #natd -v -p -a 172.16.0.102 -redirect_port tcp 172.16.0.253:7 7 > > > > In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to > >[TCP] 172.16.0.104:49169 -> 172.16.0.253:7 > > > > In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to > >[TCP] 172.16.0.104:49169 -> 172.16.0.253:7 > > > > ^C > > *screenshot*** > > > > Where is Out[TCP]? > > > Your boxes seems to be on the same subnet, "out" packets are directly > sent to 172.16.0.104, not 172.16.0.102 > nat'ing implies routing, so natd is inefficient in your case > > clem > > This working in FreeBSD4.7(ipfw1), but broken in FreeBSD 5.0(ipfw2). Why? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
