Current problem reports assigned to you
Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description --- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description --- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mem leak in mii ? (fwd)
Hi, haven't had any feedback on this Can someone please review? Also answers to the questions would be welcome. Thanks. -- Forwarded message -- Date: Tue, 23 Nov 2004 19:31:10 + (UTC) From: Bjoern A. Zeeb <[EMAIL PROTECTED]> To: John Baldwin <[EMAIL PROTECTED]> Cc: Bjoern A. Zeeb <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: mem leak in mii ? On Mon, 22 Nov 2004, John Baldwin wrote: Hi, hope you won't get it twice; the first one didn't seem to go out... > On Friday 19 November 2004 06:49 pm, Bjoern A. Zeeb wrote: > > Hi, > > > > in sys/dev/mii/mii.c there are two calls to malloc for ivars; > > see for example mii_phy_probe: .. > > Where is the free for this malloc ? I cannot find it. > > > > analogous: miibus_probe ? > > It's a leak. It should be free'd when the miibus device is destroyed. Here's > a possible fix: could you please review this one ? Should plug both of the memleaks; also for more error cases. notes: * mii doesn't ssem to be very error corrective and reporting; as others currently also seem to be debugging problems with undetectable PHYs I added some error handling in those places that I touched anyway. * in miibus_probe in the loop there is the possibility - and the comment above the functions also talks about this - that we find more than one PHY ? I currrently doubt that but I don't know for sure. As device_add_child may return NULL we cannot check for that; I had seen some inconsistency while debugging the BMSR_MEDIAMASK check so I added the count variable for this to have a reliable state. * all PHY drivers currently seem to use mii_phy_detach for device_detach. If any implements his own function it will be responsible for freeing the ivars allocated in miibus_probe. This should perhaps be documented somewhere ? patch can also be found at http://sources.zabbadoz.net/freebsd/patchset/mii-memleaks.diff Index: mii.c === RCS file: /local/mirror/FreeBSD/r/ncvs/src/sys/dev/mii/mii.c,v retrieving revision 1.20 diff -u -p -r1.20 mii.c --- mii.c 15 Aug 2004 06:24:40 - 1.20 +++ mii.c 23 Nov 2004 17:08:58 - @@ -111,7 +111,7 @@ miibus_probe(dev) struct mii_attach_args ma, *args; struct mii_data *mii; device_tchild = NULL, parent; - int bmsr, capmask = 0x; + int count = 0, bmsr, capmask = 0x; mii = device_get_softc(dev); parent = device_get_parent(dev); @@ -145,12 +145,26 @@ miibus_probe(dev) args = malloc(sizeof(struct mii_attach_args), M_DEVBUF, M_NOWAIT); + if (args == NULL) { + device_printf(dev, "%s: memory allocation failure, " + "phyno %d", __func__, ma.mii_phyno); + continue; + } bcopy((char *)&ma, (char *)args, sizeof(ma)); child = device_add_child(dev, NULL, -1); + if (child == NULL) { + free(args, M_DEVBUF); + device_printf(dev, "%s: device_add_child failed", + __func__); + continue; + } device_set_ivars(child, args); + count++; + /* XXX should we break here or is it really possible +* to find more then one PHY ? */ } - if (child == NULL) + if (count == 0) return(ENXIO); device_set_desc(dev, "MII bus"); @@ -173,12 +187,15 @@ miibus_attach(dev) */ mii->mii_ifp = device_get_softc(device_get_parent(dev)); v = device_get_ivars(dev); + if (v == NULL) + return (ENXIO); ifmedia_upd = v[0]; ifmedia_sts = v[1]; + device_set_ivars(dev, NULL); + free(v, M_DEVBUF); ifmedia_init(&mii->mii_media, IFM_IMASK, ifmedia_upd, ifmedia_sts); - bus_generic_attach(dev); - return(0); + return (bus_generic_attach(dev)); } int @@ -186,8 +203,14 @@ miibus_detach(dev) device_tdev; { struct mii_data *mii; + void*v; bus_generic_detach(dev); + v = device_get_ivars(dev); + if (v != NULL) { + device_set_ivars(dev, NULL); + free(v, M_DEVBUF); + } mii = device_get_softc(dev); ifmedia_removeall(&mii->mii_media); mii->mii_ifp = NULL; @@ -305,12 +328,15 @@ mii_phy_probe(dev, child, ifmedia_upd, i int bmsr, i; v = malloc(sizeof(vm_offset_t) * 2, M_DEVBUF, M_NOWAIT); - if (v == 0) { + if (v == NULL) return (ENOMEM); - } v[0] = ifmedia_upd; v[1] = ifmedia_sts; *child = device_add_child(dev, "miibus", -1); +
Re: Marvell 88E8001 on sk0 and RELENG_5_3 - big problems
On Sun, Dec 19, 2004 at 10:55:18PM +0100, Heinz Knocke wrote: > > By the way - do you know if sk(4) driver supports device polling > (man 4 polling)? I know there were some plans > to make it work, but I couldn't found any up2date information. > polling(4) isn't supported yet. I'm not aware of anyone working on it either. I'll take a look at it, as time permits (don't have hardware though). - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0qTjZZh0Sx.pgp Description: PGP signature
Re: double vlans - once again.
On Sat, Dec 18, 2004 at 08:57:58PM +0200, Mihail Balikov wrote: > I have done this 2 years ago for FreeBSD 4-STABLE > > in sys/net/if_vlan.c in vlan_config(), replace > >if (p->if_data.ifi_type != IFT_ETHER) > return EPROTONOSUPPORT; > > with > >if (p->if_data.ifi_type != IFT_ETHER && >p->if_data.ifi_type != IFT_L2VLAN) > return EPROTONOSUPPORT; Hmm, for -current this appears incomplete. I think the following is what is needed. Any one in a position to test this? -- Brooks Index: if_vlan.c === RCS file: /home/ncvs/src/sys/net/if_vlan.c,v retrieving revision 1.73 diff -u -p -r1.73 if_vlan.c --- if_vlan.c 15 Aug 2004 06:24:42 - 1.73 +++ if_vlan.c 20 Dec 2004 18:25:48 - @@ -273,7 +273,8 @@ vlan_clone_match_ethertag(struct if_clon /* Check for . style interface names. */ IFNET_RLOCK(); TAILQ_FOREACH(ifp, &ifnet, if_link) { - if (ifp->if_type != IFT_ETHER) + if (ifp->if_type != IFT_ETHER && + ifp->if_type != IFT_L2VLAN) continue; if (strncmp(ifp->if_xname, name, strlen(ifp->if_xname)) != 0) continue; @@ -566,6 +567,7 @@ vlan_input(struct ifnet *ifp, struct mbu } else { switch (ifp->if_type) { case IFT_ETHER: + case IFT_L2VLAN: if (m->m_len < sizeof(*evl) && (m = m_pullup(m, sizeof(*evl))) == NULL) { if_printf(ifp, "cannot pullup VLAN header\n"); @@ -641,7 +643,8 @@ vlan_config(struct ifvlan *ifv, struct i VLAN_LOCK_ASSERT(); - if (p->if_data.ifi_type != IFT_ETHER) + if (p->if_data.ifi_type != IFT_ETHER && + p->if_data.ifi_type != IFT_L2VLAN) return (EPROTONOSUPPORT); if (ifv->ifv_p) return (EBUSY); -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp33r5fY8Dq5.pgp Description: PGP signature
RE: FW: Curiosity in IPFW/Freebsd bridge. [more] 802.1q VLAN at fault?
Hello asegu, This one should work OK. But do not forget to put parent interfaces in up and promisc mode in your rc.conf, otherwise you will not see any vlan-bridging. Sunday, December 19, 2004, 11:33:57 PM, [EMAIL PROTECTED] wrote: abc> Ok, the whole discussion to date led to how VLAN traffic wasn't being abc> registered by IPFW in my system. I think that it'll probably be too late abc> for a code change to fix my problem, so I'm going to go the route of abc> changing the network configuration. abc> I've rebuilt to 4.10 and.. And I had no luck there (IPFW _really_ doesn't abc> see the traffic now!). On the other hand, I've read about vlan pseudo-dev abc> and goten myself access to the switch's configuration. abc> So tomorrow evening I plan on changing the vlan id used to 3, and then in abc> freebsd, use the following configuration(and I post this to the list to abc> see if anybody knows that this is going to fail) fxp1 -->> router (uses ID 2) fxp0 -->> switch (uses ID 2, will switch to ID 3) abc> ifconfig vlan1 vlan 3 vlandev fxp0 abc> ifconfig vlan0 vlan 2 vlandev fxp1 abc> sysctl net.link.ether.bridge_cfg=vlan1,vlan0 abc> sysctl net.link.ether.bridge_ipfw=1 abc> Does anybody think this will allow IPFW to see the packets? or that this abc> will outright fail? abc> Thank you everybody, abc> Andrew -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Router : ARP who-has requests
Hi there, We are using a FreeBSD machine as a router in one of our PoPs (using Quagga for BGP support). Today I've noticed a sudden increase in the amount of ether broadcast traffic on the network. This seems to boil down to the rate the router is issuing ARP who-has requests. The machine has about 10 local subnets connected to it via one interface (ranging in size up to /26's, totalling about a /23). I'm using device polling on the network adapters, and have the following option in the kernel: 'options HZ=1000'. The requests are only for IPs not in use (presumably because the ones in use are cached). I'm seeing the same who-has request for the same IP about 3-4 times a second. We've had the machine configured the same way for about a month, normal broadcast traffic is around 2kbps, but suddenly today it's increased 10 fold to about 20kbps. Does any one have any ideas on this? Could the kernel option (options HZ) which we use for dummynet/polling effect the rate in which ARP requests are issued? I had planned to place each subnet in a VLAN, and looks like this will have to be done fairly quickly. But I just don't understand the sudden increase. My only other though is that some could be port scanning, or someone has just been exploited. Appreciate any feedback. Thanks, Regards, Lee. Lee Johnston, Wildcard Internet t: +44 (0)845 165 1510 f: +44 (0)845 165 1511 m: +44 (0)7795 423 617 e: [EMAIL PROTECTED] www: http://www.wildcard.net.uk/ Web Development - Domains - Hosting - Co-location - Dedicated Servers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
build failure in usr.sbin
-- Qing cc -O2 -fno-strict-aliasing -pipe -DUSE_INET6 -DIPL_NAME=\"/dev/ipl\" -DIPFILTER_LOG -I/usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet -I/usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter -I/usr/src/usr.sbin/ipftest/../../contrib/ipfilter -c /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c: In function `nat_log': /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: `rulen' undeclared (first use in this function) /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: (Each undeclared identifier is reported only once /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: for each function it appears in.) /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: `np' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/usr.sbin/ipftest. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Route-Server
Hi, Does anyone knows how to create a route-server for BGPv4 peering using freebsd and vlans (802.1q) ? There is some good tutorial about it ? I read something about quagga software !!! This is enough secure ? Its possible to use it for BGP MD-5 authentication ? How can I do that ? thanks a lot Giuliano ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dingo and PerForce
On Sun, Dec 19, 2004 at 01:23:43PM +0900, [EMAIL PROTECTED] wrote: > Howdy, > > For those who use PerForce and want to work on Dingo there is > now a dingo branch, named "dingo". The dingo branch contains > all of src, not just sys, as I suspect there are userland bits > we'll want to do. I know I'll be doing userland things. What's the planned model for committing changes to the main dingo branch? The IPv6 ipfw patches I'm working with are probably ready for wider exposure. Also, for subsystems such as ip6fw that have no future, how agressive should we be about nuking them in dingo. My guess is not very because we don't want to hamper work that might need to modify the old stuff to be committed when we aren't entierly sure how much longer we'll be supporting the subsystem in cvs, but I think there's some arugment for a more agressive approach to reduce the amount of junk we have to look at. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpOwmySQYYms.pgp Description: PGP signature
IPF to PF rule migration tools
Greetings All and a merry X-Mas, I am looking for a migration script/program to migrate my IPF rule bases to a PF rule base... does anyone know of any such tool or do I need to go through them all by hand?. Thanks in advance. Cheers!, -- David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
firewalling with tunnels, and/or ipv6
Ok, I've got a v6 tunnel, and to make it work I had to "allow ipv6 from " in ipfw. From what I understand, I have to make a completely different set of rules for ipv6, and load them using the -6 flag. Correct so far? Ok, so I want to set up an ipip v4 tunnel to another box (that runs ipf), and then squirt ipv6 through the tunnel. Sounds easy, but I can't even seem to get the ipip tunnel working. The question: How do you configure ipf/ipfw (in a general sense) to allow ipip tunnels? More importantly, if I "allow ipip from " does that mean I just poked a big ass hole in the firewall... i.e. anything coming through the ipip tunnel will pass? Or, does that make an IP layer be shed, then the packet is run through all the rules again? Inefficient, but I'd think this would be the desired behaivor. At any rate, simply allowing ipip from doesn't allow the v4 tunnel to work. What else is needed? (of course static routes, etc.) I think I'll stop here for now; once that's clear I should be able to set it up. Thanks, _Charlie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Router : ARP who-has requests
At Mon, 20 Dec 2004 19:28:21 +, Lee Johnston wrote: > Does any one have any ideas on this? Could the kernel option (options HZ) > which we use for dummynet/polling effect the rate in which ARP requests are > issued? > > I had planned to place each subnet in a VLAN, and looks like this will have > to be done fairly quickly. But I just don't understand the sudden increase. > My only other though is that some could be port scanning, or someone has > just been exploited. > > Appreciate any feedback. > This may be obvious to you, but I would sniff the net for the IPs that are being arped for. Also, if you're being scanned there might be a pattern. Good luck, George ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dingo and PerForce
At Mon, 20 Dec 2004 15:57:36 -0800, Brooks Davis wrote: > > [1 ] > On Sun, Dec 19, 2004 at 01:23:43PM +0900, [EMAIL PROTECTED] wrote: > > Howdy, > > > > For those who use PerForce and want to work on Dingo there is > > now a dingo branch, named "dingo". The dingo branch contains > > all of src, not just sys, as I suspect there are userland bits > > we'll want to do. I know I'll be doing userland things. > > What's the planned model for committing changes to the main dingo > branch? The IPv6 ipfw patches I'm working with are probably ready > for wider exposure. I would think that work being done on Dingo, once people think it's ready, should be shared. The usual comments of "don't break the build" apply. I also figure that folks doing dingo work are watching the dingo branch for changes, but it might be good, before a big change, to say something here on [EMAIL PROTECTED] > Also, for subsystems such as ip6fw that have no future, how > agressive should we be about nuking them in dingo. My guess is not > very because we don't want to hamper work that might need to modify > the old stuff to be committed when we aren't entierly sure how much > longer we'll be supporting the subsystem in cvs, but I think there's > some arugment for a more agressive approach to reduce the amount of > junk we have to look at. I like cleaning things up, but I'm really the greenhorn at committing so I hope others wil chime in. If it were my decision I would say that the Dingo branch should be the "cleanest" and then we could decide, when pushing to HEAD, how to handle that. Other thoughts? Later, George ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: firewalling with tunnels, and/or ipv6
On Mon, Dec 20, 2004 at 06:05:16PM -0800, Charlie Schluting wrote: > Ok, I've got a v6 tunnel, and to make it work I had to "allow ipv6 from > " in ipfw. From what I understand, I have to make a completely > different set of rules for ipv6, and load them using the -6 flag. > > Correct so far? ip6fw is an entierly different beast from ipfw. There is no -6 option to ipfw. Use ip6fw instead. If 6.x we should have ipv6 support in ipfw and ip6fw should be gone. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpao22qRDX1j.pgp Description: PGP signature