Re: kern/31130: ipfw tee functionality causes malfunction and security hole
On Tue, Oct 09, 2001 at 02:20:02AM -0700, Crist J. Clark wrote:
[snip]
> On the wire and the packets never get routed to the "real" 172.16.0.1.
> Trying to figure out if,
>
>a) This is the expected behavior, but is poorly documented, or
>b) Something is broken.
>
> I'm thinking (b), but still wading through src/sys/netinet to verify.
Well, I see why this happens, but still not sure if it is supposed to
happen. If we look at src/sys/netinet/ip_input.c, we see that all
diverted or teed packets are accepted by the host as destined for
itself,
#ifdef IPDIVERT
if (i != 0 && (i & IP_FW_PORT_DYNT_FLAG) == 0) {
/* Divert or tee packet */
divert_info = i;
goto ours;
}
#endif
The packets are clearly going to be processed by the gateway. You seem
to have already found this in the code snipped in your original PR,
but I didn't notice your change. Please post changes to code as
unified diffs. I now understand the 'fix' you were talking about. Have
you actually built a kernel with your modifications? Does it seem to
work?
But packets _leaving_ the system seem to be processed as one would
expect. That is, a copy is divert(4)ed and then the packet heads out
onto to the wire.
This apparent inconsistency is a bug since it is either unintended
behavior or at least undocumented behavior. But the inconsistency
gives you a temporary workaround. Instead of,
600 tee 8665 ip from any to any in
Does,
600 tee 8665 ip from any to any out
Work as you would expect?
--
Crist J. Clark [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Link re-negotiation on tl0 after Cisco 35xx reboot
Hi all, I just came accross and interesting problem - with autnegotiation (re-negotiation?). I have Compaq 1850R with 'tl' interface (FreeBSD 4.4R) and Sun Netra connected to Cisco switch 35xx. I use link auto-negotiation on both sides for both hosts. Ater reset of Cisco switch and also after power cycling the switch: - Sun seems to be happy. - Compaq with FreeBSD the tl0 interface accepts ARP requests from other hosts - Compaq host sends ARP reply (as seen with tcpdum on tl0) - switch sees the packed with CRC error - this setup works perfectly for both Sun and NT, (which puts me into position of envagelist of _no-go_ platform :-((( It seems that the link is not re-negotiated(?). I went through sources and there are some changes in CURRENT introducing link_changed method/callback, but it doen not not seem to be directly related (and it's not in RELEASE). Any hints or pointers ? Thanks in advance, Milon -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Getting link level addr using SIOCGIFADDR
Hello, In most case of printing (ethernet) link level address, program does a SIOCGIFCONF ioctl, gets a ifconf structure(the whole interface list), finds the very interface and prints the address. What I want to is to use SIOCGIFADDR so that program finds the address. My program does 1) get a socket (AF_INET) 2) make appropriate ifreq structure; copy interface name and set sa_family to AF_LINK 3) SIOCGIFADDR ioctl But returned ifreq structure doesn't have sockaddr_dl structure. It is impossible to get link level address using SIOCGIFADDR? Regards, Kyunghwan KIM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Some thoughts on if_ioctl()
On Mon, Oct 08, 2001 at 02:53:32PM -0400, Garrett Wollman wrote:
> < said:
>
> > Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI.
> > There is code obviously taken from if_loop.c and used in some
> > drivers, which tries to do something with the third argument "data"
> > of the if_ioctl() driver method if "data" isn't NULL.
>
> The historic implementation passed SIOCADDMULTI directly down to the
> interface to implement, which resulted in lots of duplicated code all
> over the place to manage the list of multicast addresses. Several
> years ago, I rewrote the multicast management code to simply indicate
> to the driver when the list has changed, obviating the need for the
> driver itself to manage the list.
>
> > If I understand the kernel code right, if_ioctl()'s third argument
> > is always NULL
>
> Not so. Any ioctl() in class 'i' which is not handled by the generic
> code will get passed down to the driver to handle; some of these
> requests may require the data pointer.
Sorry, I wrote an unclear phrase. I implied not all possible ioctl(2)
requests, but only the SIOC{ADD|DEL}MULTI case. In that case, "data"
seems to be always NULL since it's the way if_addmulti() and
if_delmulti() call ifp->if_ioctl(), and there is no other way to
pass SIOC{ADD|DEL}MULTI to a driver's if_ioctl(). If it's true,
all the old ugly code about AF_INET and AF_INET6 multicast groups
may be safely removed from the interface drivers. All the interface
drivers will fall into two categories:
- those which may simply do nothing on these requests (if_loop, if_sl...)
- those which will rebuild some sort of a hardware multicast filter.
--
Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Connect(2) problem
In article <[EMAIL PROTECTED]>, Nguyen-Tuong Long Le <[EMAIL PROTECTED]> wrote: > > I have a software that simulates web clients and servers to create > network congestion (for the purpose of doing research in network > congestion). In our experiment, a client opens an HTTP connection > to a server, fetches a number of objects, and then closes the > connection. A problem I seem to have right now is that a client > machine cannot simulate more than 3000 connections. When my client > machine simulates more than 3000 connections, it's able to open > a socket but then connect(2) fails with errno 35 (Resource > temporarily unavailable). Another interesting notice is that the > connect(2) system call blocks for a few miliseconds before it > fails although fcntl(2) was used to make the socket non-blocking. > The OS version I am using is FreeBSD 4.3-release. In addition to the suggestion from Alex Rousskov, adding these lines to "/boot/loader.conf" may help: kern.ipc.maxsockets="8192" kern.ipc.nmbclusters="32768" John -- John Polstra John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Trying to find out which interface an IP packet is coming from in ip_output() routine
Hi, Can anybody help me find a way to find out which interface an IP packet is coming from in ip_output()/ip_input() routine? You help is greatly appreciated. Thks a lot! Aihua Guo
Re: Trying to find out which interface an IP packet is coming from in ip_output() routine
In article <[EMAIL PROTECTED]>, Aihua Guo <[EMAIL PROTECTED]> wrote: >Can anybody help me find a way to find out which interface an IP > packet is coming from in ip_output()/ip_input() routine? The mb->m_pkthdr.rcvif field of the mbuf points to the interface on which the packet was received. John -- John Polstra John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Getting link level addr using SIOCGIFADDR
On Wed, Oct 10, 2001 at 11:40:39PM +0900, Kim Kyung-hwan wrote: > Hello, > > In most case of printing (ethernet) link level address, > program does a SIOCGIFCONF ioctl, gets a ifconf structure(the whole > interface list), finds the very interface and prints the address. > What I want to is to use SIOCGIFADDR so that program finds the > address. > > My program does > 1) get a socket (AF_INET) > 2) make appropriate ifreq structure; >copy interface name and set sa_family to AF_LINK > 3) SIOCGIFADDR ioctl > > But returned ifreq structure doesn't have sockaddr_dl structure. > It is impossible to get link level address using SIOCGIFADDR? > Nope, not possible. But this could be done with CTL_NET.PF_ROUTE.NET_RT_IFLIST sysctl(3), by setting the fourth level to AF_LINK. See lib/libc/net/getifaddrs.c for a working example. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Connect(2) problem
Hello Alex, Thanks very much for your reply! Just our of curiosity, what is the use of net.inet.ip.portrange.hifirst and net.inet.ip.portrange.hilast ? Thanks, Long On Tue, 9 Oct 2001, Alex Rousskov wrote: > > Are you running out of ephemeral ports? See net.inet.ip.portrange > sysctl or do your own port management. > > Alex. > > On Tue, 9 Oct 2001, Nguyen-Tuong Long Le wrote: > > > Hi all, > > > > I have a software that simulates web clients and servers to create > > network congestion (for the purpose of doing research in network > > congestion). In our experiment, a client opens an HTTP connection > > to a server, fetches a number of objects, and then closes the > > connection. A problem I seem to have right now is that a client > > machine cannot simulate more than 3000 connections. When my client > > machine simulates more than 3000 connections, it's able to open > > a socket but then connect(2) fails with errno 35 (Resource > > temporarily unavailable). Another interesting notice is that the > > connect(2) system call blocks for a few miliseconds before it > > fails although fcntl(2) was used to make the socket non-blocking. > > The OS version I am using is FreeBSD 4.3-release. > > > > I used sysctl to bump up kern.maxfiles and kern.maxfilesperproc to > > 16384. I also bumped up kern.ipc.somaxconn to 8192 on the server > > side. I recompiled the kernel with option NMBCLUSTERS=65536 to > > increase the number of mbufs. I guess that CPU is not the bottleneck > > since I have the same problem regardless whether I use a 300 MHz or > > a 1 GHz machine. > > > > Does anyone have any suggestion what kind of resources my client machine > > runs out and how I can fix it? > > > > Thanks, > > Long > > > > P.S. Please kindly email your reply to me since I am not on the list. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Connect(2) problem
On Wed, 10 Oct 2001, Nguyen-Tuong Long Le wrote: > Just our of curiosity, what is the use of > net.inet.ip.portrange.hifirst and net.inet.ip.portrange.hilast ? Even FreeBSD gurus/committers are unsure :-) http://people.freebsd.org/~adrian/sysctl.descriptions The answer is in "man ip". Alex. > On Tue, 9 Oct 2001, Alex Rousskov wrote: > > > > > Are you running out of ephemeral ports? See net.inet.ip.portrange > > sysctl or do your own port management. > > > > Alex. > > > > On Tue, 9 Oct 2001, Nguyen-Tuong Long Le wrote: > > > > > Hi all, > > > > > > I have a software that simulates web clients and servers to create > > > network congestion (for the purpose of doing research in network > > > congestion). In our experiment, a client opens an HTTP connection > > > to a server, fetches a number of objects, and then closes the > > > connection. A problem I seem to have right now is that a client > > > machine cannot simulate more than 3000 connections. When my client > > > machine simulates more than 3000 connections, it's able to open > > > a socket but then connect(2) fails with errno 35 (Resource > > > temporarily unavailable). Another interesting notice is that the > > > connect(2) system call blocks for a few miliseconds before it > > > fails although fcntl(2) was used to make the socket non-blocking. > > > The OS version I am using is FreeBSD 4.3-release. > > > > > > I used sysctl to bump up kern.maxfiles and kern.maxfilesperproc to > > > 16384. I also bumped up kern.ipc.somaxconn to 8192 on the server > > > side. I recompiled the kernel with option NMBCLUSTERS=65536 to > > > increase the number of mbufs. I guess that CPU is not the bottleneck > > > since I have the same problem regardless whether I use a 300 MHz or > > > a 1 GHz machine. > > > > > > Does anyone have any suggestion what kind of resources my client machine > > > runs out and how I can fix it? > > > > > > Thanks, > > > Long > > > > > > P.S. Please kindly email your reply to me since I am not on the list. > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Connect(2) problem
On Wed, 10 Oct 2001, Nguyen-Tuong Long Le wrote: > Hello Alex, > > Thanks very much for your reply! > > Just our of curiosity, what is the use of > net.inet.ip.portrange.hifirst and net.inet.ip.portrange.hilast ? > > Thanks, > Long hifirst and hilast represent the range of ports that we should be using for outbound connections. If you need more ephemeral ports, change .first and .last to equal the corresponding hi values. For more background, read one of Stevens's books. (This is mentioned in UNIX network programming volume 1, I'd assume the tcp books cover it as well.) Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: VLAN speed
Bill Fenner wrote: >>Why does vlans announce themselves as being 10 Mbits/s? I'm getting this >> >>from snmp on vlans that are attached to 100 Mbits/s cards. > > I know that real experts can communicate in very few words, but I'd appreciate a few more words. :-) Zero is a bit too little for me. :-) -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Real programmers always have a better idea. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: VLAN speed
On Tue, Oct 09, 2001 at 10:19:09PM -0700, Bill Fenner wrote: > (ifSpeed says "For a sub-layer which has no concept of bandwidth, this > object should be zero." I'd argue that this describes VLAN interfaces.) not that the vendor is always right or anything, but at least one implementation (juniper) behaves this way: interfaces.ifTable.ifEntry.ifDescr.9 = fxp1.0 interfaces.ifTable.ifEntry.ifType.9 = ethernetCsmacd(6) interfaces.ifTable.ifEntry.ifSpeed.9 = Gauge: 1 interfaces.ifTable.ifEntry.ifDescr.36 = ge-2/0/0.401 interfaces.ifTable.ifEntry.ifType.36 = ethernetCsmacd(6) interfaces.ifTable.ifEntry.ifSpeed.36 = Gauge: 10 crisco only creates entries in the ifTable for physical interfaces in their routers (or at least for the ones that I have access to that use .1q or isl). cisco msfc2 reports gigabit for vlans, but that doesn't count. just a reference point. I would argue that vlans are definitely "a sub-layer which has no concept of bandwidth" too. -- - bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: VLAN speed
< said: > On Tue, Oct 09, 2001 at 10:19:09PM -0700, Bill Fenner wrote: >> (ifSpeed says "For a sub-layer which has no concept of bandwidth, this >> object should be zero." I'd argue that this describes VLAN interfaces.) > not that the vendor is always right or anything, but at least one > implementation (juniper) behaves this way: Extreme implements the spec as Bill Fenner described it. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
[no subject]
but *not* connected to Internet (yet) I am intending to mount a ipsec or vtun vpn, but in a practical sense, I am intending to emulate the internet at home, instead to real connections to the internet, as the real conn will be far away (1,400 km apart) from the other. I am speculating in something like: lan-1/---/gw~fwall-ipsec(vtund)--/fake router/---/fake \\ router/--/gw~fw-ipsec(vtun)/--/lan-2 what do you think about such plans?? Note that gw~fw at both ends will be FreeBSD, the intermediate (up to 3) fake router can be Linux boxes or FreeBSD, with real (routable) ip-addresses, but dropping rfc-1918's private addresses. saudações, irado furioso com tudo linux user 179402 deus é construído à imagem e semelhança do homem. Principalmente em seus defeitos. por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Trying to find out which interface an IP packet is coming from inip_output() routine
John Polstra writes: > >Can anybody help me find a way to find out which interface an IP > > packet is coming from in ip_output()/ip_input() routine? > > The mb->m_pkthdr.rcvif field of the mbuf points to the interface on > which the packet was received. ...if any. In ip_input(), mb->m_pkthdr.rcvif is always non-NULL, but in ip_output() it may be NULL e.g. if the packet was locally generated. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
cisco 2509 to FreeBSD PPP
Hello, Recently I got the chance of playing with Cisco 2509 access server. The bad thing is it has only 1 Ethernet port, so if I want to play with routing..etc I need establishing connection through some other port, the AUX for example. I was told I could try connecting AUX on cisco with null modem cable(RG45 <->DB9 female) to the COM port of FreeBSD machine. So far , I've used PPP for dial-up access only, that's why it's complete darkness for me what set of ppp/at commands I need on the bsd-box, and what settings on the aux line on cisco. Can anyone help me with this? Thanks in advance! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
