RE: pptp via mpd
>Is it possible to authenticate users on /etc/master.passwd or >by some other >method possibly RADIUS or an SQL table? storing the usernames >and passwords >in the mpd.secret file is redundant and insecure IMHO. > >Ryan > PPTP is itself insecure against SSH or IPSEC... MPD is a great application. Using MPD is as secure as PPTP is! :) oc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: pptp via mpd
On Wed 2001-10-24 (09:28), Olivier Cherrier wrote: > > PPTP is itself insecure against SSH or IPSEC... > MPD is a great application. Using MPD is as secure as > PPTP is! :) > slightly off topic form the original question, but PPTP works rather well over IPSEc, infact iirc win2k will attempt to setup an IPSEC connection when you establish a VPN session. FreeBSD IPSEC +racoon work really nicely ( well other than the wierd issue I am having in 4.4 :<) Barry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: Silly problem has me stumped
think that *if* your ISP is cooperative enough, he can create routing rules saying that your ip-public can be found behind their's own. Also he can make an aliases (YOUR public in THEIR's machine), and a ipfilter/ipw rule saying that 'any request shoud be redirected to YOUR private address' Anyway, it must assure that your ISP is cooperative, otherwise.. And also for the private ip-addr: must not be thru DHCP, otherwise.. >my new public address block is 1.2.3.0/24, and that the routing block >between their network and mine is 10.0.0.0/30, and my default router is saudações, irado furioso com tudo GNU/Linux user CASSADO 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
RTM_NEWADDR
After a long time looking into this, I have finally understood what's the problem. RTM_NEWADDR is generated sometimes yes, sometimes no. I have absolutely no idea what makes the difference, particularly because I have absolutely no idea where the relevant code portions is located. As for my environment, my test base is all vlan, and I run a routing daemon (zebra). Attached are two logs. The first is a list of commands running in background manipulating the interfaces. The second is the output of route -n monitor at the same time. If anyone can point me in the right direction to debug this problem, I would appreciate immensily. This problem is being a hell on us. -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Writing about music is like dancing about architecture. -- Frank Zappa vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.22 (172.31.199.22): 56 data bytes --- 172.31.199.22 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.22 (172.31.199.22): 56 data bytes --- 172.31.199.22 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev
Re: PXE boot vs. DHCP
In article <[EMAIL PROTECTED]>, Cyrille Lefevre <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > > > What is the reason you think it would be better to put the solution > > into dhclient-enter-hooks? > > IMHO, for instance, because this hack is only needed at PXE level > not after, I am right ? Not quite. It's not the "PXE level," it's the normal operating state of the system. The only difference is that it was booted with PXE instead of by some other means. PXE booting is being used more and more at large installations. My change addresses a common situation which is becoming more common all the time. Shouldn't the standard dhclient installation function properly, regardless of how the system was booted? I think it should. Also, I don't feel that my patch is a hack. The entire purpose of dhclient's PREINIT phase is to put the network interface into an enabled state so that IP packets can be sent. If the interface is already up, then it is already in that state. By failing to check the interface first, the current dhclient-script needlessly destroys its configuration and hangs the system. That is a bug, and my patch fixes it. 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
ADSL with two interfaces in one machine using "dhclient"
I can obtain two seperate IP addresses and everything routes OK for both interfaces. Its just these ARP messages that are annoying me (filling up my logs with repeated messages). I'm having a problem with ARP's from my gateway. Both interfaces use the same gateway, but I get an error message in the log stating that: (GW = Gateway, IP1 = IP of first interface etc...) /kernel: arp: is on xl0 but got reply from on ed0 last message repeated 35 times last message repeated 136 times last message repeated 149 times last message repeated 112 times /kernel: arp: is on ed0 but got reply from on xl0 last message repeated 94 times last message repeated 111 times etc. etc... Failing this how can I stop the kernel from even logging this? (what to turn off?) I also get errors saying that my interface MAC addresses have changed (this is due to one interface thinking that the other interfaces MAC address is the MAC of my DSL router, and then it finds the REAL MAC address for the other interface and so forth). I have set a metric (scopeid) to one on my primary interface and to two on my secondary interface. External connections. A switch rather than a hub could fix this problem and I'll probably buy one anyway, but I'd like to know how to stop this. Can I have two interfaces with the same gateway without getting MAC address notices? --- Landon Stewart [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PXE boot vs. DHCP
On Wed, Oct 24, 2001 at 08:13:52AM -0700, John Polstra wrote: > Not quite. It's not the "PXE level," it's the normal operating state > of the system. The only difference is that it was booted with PXE > instead of by some other means. PXE booting is being used more and > more at large installations. My change addresses a common situation > which is becoming more common all the time. > > Shouldn't the standard dhclient installation function properly, > regardless of how the system was booted? I think it should. > > Also, I don't feel that my patch is a hack. The entire purpose of > dhclient's PREINIT phase is to put the network interface into an > enabled state so that IP packets can be sent. If the interface is > already up, then it is already in that state. By failing to check the > interface first, the current dhclient-script needlessly destroys its > configuration and hangs the system. That is a bug, and my patch fixes > it. Hear hear. Joe PGP signature
Mpd with a large number, 200+ , of bundles
Hi, some info about the machine: vpn-gw2# uname -a FreeBSD vpn-gw2 4.4-STABLE FreeBSD 4.4-STABLE #2: Tue Oct 16 16:42:27 CEST 2001 root@vpn-gw2:/usr/obj/usr/src/sys/VPN-GW2 i386 vpn-gw2# The machine is a dual 700MHz PIII with 512MB ram and 3 3c905B nics. /etc/sysctl.conf looks like this: vpn-gw2# cat /etc/sysctl.conf kern.ipc.shm_use_phys=1 vfs.vmiodirenable=1 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.tcp.always_keepalive=1 kern.ipc.somaxconn=1024 net.inet.ip.rtexpire=10 I'm trying to set up mpd as a replacement for poptop + ppp. But I run into a problem when I try to configure more than 100 bundles. When I configure 30 bundles, everything works nicely. When I configure 100 bundles, things seems to work nicely, but when I run ngctl, I get the following error when typing 'list' at the ngctl prompt: [lines for ng100 - ng24 removed] Name: ng23Type: iface ID: 0849 Num hooks: 1 Name:Type: socket ID: 0848 Num hooks: 2 Name:Type: vjc ID: 0847 Num hooks: 4 Name:Type: bpf ID: 0846 Num hooks: 3 Name: mpd37379-pptp12 Type: ppp ID: 0845 Num hooks: 6 Name: ng22Type: iface ID: 0844 Num hooks: 1 Name:Type: socket ID: 0843 Num hooks: 2 Name:Type: vjc ID: 0842 Num hooks: 4 Name:Type: bpf ID: 0841 Num hooks: 3 Name: xl0 Type: ether ID: 0001 Num hooks: 0 ngctl: send msg: No such file or directory + quit it seems to be missing ng0 - ng21, but ifconfig shows all the interfaces. Earlier ngctl would not list any interfaces but print something like the following: + list ngctl: send msg: No buffer space available + quit which buffer is this, and how do I make it larger? On a PIII 1.3GHz with 1GB ram, trying to run with 110 bundles: vpn-gw3# uname -a FreeBSD vpn-gw3 4.4-STABLE FreeBSD 4.4-STABLE #0: Thu Oct 18 18:37:21 CEST 2001 root@vpn-gw3:/usr/obj/usr/src/sys/VPN-GW3 i386 vpn-gw3# [cut out 97 bundle configs] [pptp98] ppp node is "mpd18285-pptp98" [pptp98] using interface ng108 Radius: radius_Init [pptp99] ppp node is "mpd18285-pptp99" [pptp99] using interface ng109 Radius: radius_Init [pptp100] can't name ppp node: Address already in use [pptp100] netgraph initialization failed [pptp101] can't name ppp node: Address already in use [pptp101] netgraph initialization failed [pptp102] can't name ppp node: Address already in use [pptp102] netgraph initialization failed [pptp103] can't name ppp node: Address already in use [pptp103] netgraph initialization failed [pptp104] can't name ppp node: Address already in use [pptp104] netgraph initialization failed [pptp105] can't name ppp node: Address already in use [pptp105] netgraph initialization failed [pptp106] can't name ppp node: Address already in use [pptp106] netgraph initialization failed [pptp107] can't name ppp node: Address already in use [pptp107] netgraph initialization failed [pptp108] can't name ppp node: Address already in use [pptp108] netgraph initialization failed [pptp109] can't name ppp node: Address already in use [pptp109] netgraph initialization failed [pptp110] can't name ppp node: Address already in use [pptp110] netgraph initialization failed [pptp99:pptp99] vpn-gw3# ngctl + list ngctl: send msg: No buffer space available + This is with standard sendspace/recvspace. Trond To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RTM_NEWADDR
On Wed, Oct 24, 2001 at 11:14:54AM -0200, Daniel C. Sobral wrote: > After a long time looking into this, I have finally understood what's > the problem. RTM_NEWADDR is generated sometimes yes, sometimes no. I > have absolutely no idea what makes the difference, particularly because > I have absolutely no idea where the relevant code portions is located. > > As for my environment, my test base is all vlan, and I run a routing > daemon (zebra). Attached are two logs. The first is a list of commands > running in background manipulating the interfaces. The second is the > output of route -n monitor at the same time. > > If anyone can point me in the right direction to debug this problem, I > would appreciate immensily. This problem is being a hell on us. > I don't see RTM_NEWADDR's in the logs, only RTM_NEWMADDR's. 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: Fw: documentacao do sistema de gerencia
Alan wrote: > On Wed, Oct 24, 2001 at 11:14:54AM -0200, Daniel C. Sobral wrote: > >>After a long time looking into this, I have finally understood what's >>the problem. RTM_NEWADDR is generated sometimes yes, sometimes no. I >>have absolutely no idea what makes the difference, particularly because >>I have absolutely no idea where the relevant code portions is located. >> >>As for my environment, my test base is all vlan, and I run a routing >>daemon (zebra). Attached are two logs. The first is a list of commands >>running in background manipulating the interfaces. The second is the >>output of route -n monitor at the same time. >> >>If anyone can point me in the right direction to debug this problem, I >>would appreciate immensily. This problem is being a hell on us. >> >> > I don't see RTM_NEWADDR's in the logs, only RTM_NEWMADDR's. Well, that's the whole point. It should. -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] There is nothing more silly than a silly laugh. -- Gaius Valerius Catullus To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PXE boot vs. DHCP
"John Polstra" <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Cyrille Lefevre <[EMAIL PROTECTED]> wrote: > > John Polstra wrote: > > > > > > What is the reason you think it would be better to put the solution > > > into dhclient-enter-hooks? > > > > IMHO, for instance, because this hack is only needed at PXE level > > not after, I am right ? > > Not quite. It's not the "PXE level," it's the normal operating state > of the system. The only difference is that it was booted with PXE > instead of by some other means. PXE booting is being used more and > more at large installations. My change addresses a common situation > which is becoming more common all the time. > > Shouldn't the standard dhclient installation function properly, > regardless of how the system was booted? I think it should. > > Also, I don't feel that my patch is a hack. The entire purpose of > dhclient's PREINIT phase is to put the network interface into an > enabled state so that IP packets can be sent. If the interface is > already up, then it is already in that state. By failing to check the > interface first, the current dhclient-script needlessly destroys its > configuration and hangs the system. That is a bug, and my patch fixes > it. ok, did you ask the dhcp mailing list about that ? since, as a general rule, dhclient should be fixed for all platforms and not only for FreeBSD... Cyrille. -- mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
fxp patch - bundling receive interrupts
An updated fxp driver patch for bundling receive interrupts, thus saving a noticeable amount of CPU overhead for interrupt processing, can be found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: - control of microcode parameters through sysctl variables - activation/deactivation of microcode without bringing the interface down - independent control of microcode parameters/activity for each fxp interface instance - new parameter hw.fxp.size_mask - hw.fxp.int_delay is now defined in microseconds, instead of microcode time-counter units The microcode should work on many revisions - if not all - of Intel 8255* chipset, but the BSD driver is currently tested only on 82558-B0, so I would really appreciate any feedback on driver functionality/stability on other chipset revisions. Have fun! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: fxp patch - bundling receive interrupts
I am not an official FreeBSD commiter, so I can't tell really... Therefore jlemon was in cc: (he is the fxp driver maintainer), so it is his call. Nevertheless, I think this patch needs a little bit more testing - there are many 8255* chipset revisions out there, and as the code is *very* chipset dependent, we should wait for gathering some feedback first from the people testing the driver. Dennis Wong wrote: > Marko, > > Is this going to be rolled into -stable anytime soon? > > Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: fxp patch - bundling receive interrupts
On Wed, 24 Oct 2001, Marko Zec wrote: > An updated fxp driver patch for bundling receive interrupts, thus saving > a noticeable amount of CPU overhead for interrupt processing, can be > found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: I haven't reviewed the code and don't have a fxp near, but your patch sounds impressive. I'm sure we'd all be proud of its inclusion in -stable once enough testing has been performed. That being said, I thought I should check on one thing: In your original post, you mentioned that these techniques came from the linux drive for these cards. In the process of writing this patch, did you copy any section of code from the Linux driver? If possible, it would be best to avoid any GPL entanglements. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: fxp patch - bundling receive interrupts
Mike Silbersack wrote: > That being said, I thought I should check on one thing: In your original > post, you mentioned that these techniques came from the linux drive for > these cards. In the process of writing this patch, did you copy any > section of code from the Linux driver? If possible, it would be best to > avoid any GPL entanglements. I used the microcode from Intel's proprietary Linux driver, which is definetely not GPL'ed. I'm not nearly a copyright expert, but it seems to me that Intel put a BSD-like copyrihght on mentioned sources. Intel's copyright is included in rcvbundle.h, so I hope some of BSD "legals" can check on that, and if in any doubt the simplest thing to do would be asking Intel for their position before including the code in a official distributon. Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: fxp patch - bundling receive interrupts
On Wed, 24 Oct 2001, Marko Zec wrote: > The microcode should work on many revisions - if not all - of > Intel 8255* chipset, but the BSD driver is currently tested only > on 82558-B0, so I would really appreciate any feedback on driver > functionality/stability on other chipset revisions. Chalk up another 82558B that it works on. I started using it shortly after you mentioned this patch a couple of days ago and haven't experienced any problems. While doing a large file transfer between two FreeBSD boxes, performance definately did not suffer. I got 11MB/sec over FTP. When communicating with a Windows NT server over SMB, though, performance was bad (max 1.2MB/sec). I haven't yet checked to see if this is because of the interrupt coalescing or if it is just because Windows sucks. I did notice a 33% decrease in interrupts (if about 900 packets came in, about 600 interrupts were generated), so it definately worked. If I get real brave I might try it on my router which has mostly 82558B's but also an 82559 or two. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: struct ifnet changes
In article <[EMAIL PROTECTED]> you write: >Hi, >in order to add polling support to network interfaces >i need to add one more flag to network interface descriptors, >but the relevant field in struct ifnet (if_flags) is only 16 bit >wide and already fully used. > >I would like to extend it to 32 bit, which is not a problem in >CURRENT, but doing this in STABLE will break binary compatibility >with older drivers (presumably up to FreeBSD 4.2, as between 4.1 >and 4.2 there were other changes that probably prevent the use of >old binary drivers). > >Are there strong objections to this change ? > >I can avoid breaking binary compatibility by using some other unused >field (e.g. if_ipending, which is currently unused), but i'd rather >not have to, because we risk to carry this dirty hack forever. > >If I am allowed to make changes to the structure, I would do the following: > > + change if_flags to an u_int32_t to accommodate more flags, > and move it to the beginning of the structure -- this is > accessed very very frequently, and this change makes the > kernel 200 bytes smaller, and possibly a bit faster; > > + remove if_ipending -- noone is using it; > > + change if_index to u_int32_t (mostly to preserve alignment > of the remaining fields); > > + maybe change if_unit and if_timer to 32 bit, for better alignment > and code efficiency > > + redefine some of the (currently unused) fields for polling > support. This does not compromise binary compatibility > because the field size and position will remain the same, > only the type will change. > >Comments ? Hmm, I think you would be better off sending this to -net, not -stable. :-) A few things: - I've been kicking around the idea of splitting if_flags into two fields, to better handle locking issues. Some of the fields are accessed by the driver frequently (OACTIVE), while others are more static. However, I haven't figured out whether this is needed or not. - I also have a few changes for polling support of my own, I use the poll_xmit/poll_recv slots in the dispatch table - You mention moving if_flags to the first element, is there any code that assumes that if_softc is the first element in the ifnet? Putting at the start of the second cache line might be another option. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: struct ifnet changes
< said: > - You mention moving if_flags to the first element, is there any code > that assumes that if_softc is the first element in the ifnet? Putting > at the start of the second cache line might be another option. There shouldn't be; if_softc is a recent invention, and should by rights be unnecessary. Put more precisely: assert(ifp->if_softc == ifp); The people who wanted if_softc are the same ones who were arguing against this softc layout restriction, so it's quite unlikely that there would be anyone depending on &ifp->if_softc == (void **)ifp. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPv6 /PPP using FreeBSD 4.4
> Hi Brian, > > thanks alot for your info.. I can assigned IPv6 address using ppp.conf like you >showed me. > > However, when ppp was started using ppp -auto, tun0 appears and > you can see the assigned IPv6 address on tun0. But when the connection > is established with the peer, tun1 appears and tun1 is where the > actual connection established with the link local addresses. > > What i want to achieve is to have the connection established at > tun0 where the global IPv6 was already assigned... This is what should be happening. I would guess that something else on your machine is starting another ppp invocation (on tun1) - although this sounds bizarre. > Below is the ifconfig from my machine: > > > tun0: flags=8051 mtu 1500 > inet6 fe80::250:4ff:fec1:ba68%tun0 prefixlen 64 scopeid 0x8 > inet 10.0.0.2 --> 10.0.0.1 netmask 0xff00 > inet6 2001:200:703:1::1 --> 2001:200:703:1::2 prefixlen 128 > Opened by PID 2025 > tun1: flags=8051 mtu 1500 > inet6 fe80::250:4ff:fec1:ba68%tun1 prefixlen 64 scopeid 0x9 > inet 0.0.0.0 --> 192.168.100.2 netmask 0xff00 > inet6 fe80::86e4:81d4%tun1 --> fe80::3a48:d102%tun1 prefixlen 128 scopei > d 0x9 > Opened by PID 2007 > tun2: flags=8010 mtu 1500 > inet6 fe80::250:4ff:fec1:ba68%tun2 prefixlen 64 scopeid 0xa > > > any ideas how to prevent the above from occuring??? I guess that depends on what's starting the second ppp invocation. > thanks in advance, > > kim chua > -- [.] -- Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]> http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
[Fwd: colisions!]
i have the follow problem: i use etinc in one FreeBSD box (4.2). it works fine. this freebsd make bridge (one interface in switch), and another cross over to router. in the conection to router, there are one colision led, that are almost always up! i did put one rule for bridge only ip in rl0 (switch interface). why there are colisions betwen etinc and router??? the etinc interface are 10Mbps (half-duplex) and router too. the cross over is: etinc 12 orange/white 3 6 blue/white router 1 2 blue/white 3 6 orange/white thanks ___ The ISP-WIRELESS Discussion List ___ To Join: mailto:[EMAIL PROTECTED] To Remove: mailto:[EMAIL PROTECTED] Archives: http://isp-lists.isp-planet.com/isp-wireless/archives/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
