Re: kern/140742: rum(4) Two asus-WL167G adapters cannot talk to each other
Old Synopsis: assus-WL167G rum driver New Synopsis: rum(4) Two asus-WL167G adapters cannot talk to each other Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Nov 22 12:08:40 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=140742 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Intel NIC 0x10f08086
Hi List, Hi Jack! I have an Intel NIC with the pci chip=0x10f08086 rev=0x05 as onboard Card on an "Intel DP55WB" Mainboard. According to Google it is an "82578DC". Now i wonder how to make it work. I tried to add the PCI ID to both em(4) and igb(4) but the attach failed, so it looks like something more is required. Any ideas? regards arved___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ARP regression in releng-8
Hi all, I try to figure out something simple like the ARP retransmission timeout to populate the ipv4InterfaceRetransmitTime in the RFC4293 MIB. In line 357 of netinet/if_ether.c it says: /* * Return EWOULDBLOCK if we have tried less than arp_maxtries. It * will be masked by ether_output(). Return EHOSTDOWN/EHOSTUNREACH * if we have already sent arp_maxtries ARP requests. Retransmit the * ARP request, but not faster than one request per second. */ Unfortunately the comment about the 1s minimum retransmit interval is there, but the code not. A simple ping -f shows the code transmitting ARP requests every 30 milliseconds, which is not good in my opinion. releng-7 (with the old L2 code) works correctly. BTW, what means the comment on line 282 in the same file? /* X */ harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[CFR] unified rc.firewall
Hi,
The ipfw and ip6fw were unified into ipfw2, now. But, we still have
rc.firewall and rc.firewall6. However, there are conflicts with each
other, and it confuses the users, IMHO.
So, I made a patch to unify rc.firewall and rc.firewall6, and obsolete
rc.firewall6 and rc.d/ip6fw.
Please review the attached patch. If there is no objection, I'll
commit it in next weekend.
Sincerely,
ipfw-unify.diff
Description: Binary data
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: ARP regression in releng-8
I will look into it and get back to you. -- Qing > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Harti Brandt > Sent: Sunday, November 22, 2009 5:09 AM > To: freebsd-net@freebsd.org > Subject: ARP regression in releng-8 > > Hi all, > > I try to figure out something simple like the ARP retransmission > timeout > to populate the ipv4InterfaceRetransmitTime in the RFC4293 MIB. In line > 357 of netinet/if_ether.c it says: > > /* > * Return EWOULDBLOCK if we have tried less than arp_maxtries. > It > * will be masked by ether_output(). Return > EHOSTDOWN/EHOSTUNREACH > * if we have already sent arp_maxtries ARP requests. > Retransmit > the > * ARP request, but not faster than one request per second. > */ > > Unfortunately the comment about the 1s minimum retransmit interval is > there, but the code not. A simple ping -f shows the code transmitting > ARP > requests every 30 milliseconds, which is not good in my opinion. > releng-7 > (with the old L2 code) works correctly. > > BTW, what means the comment on line 282 in the same file? > > /* X > */ > > harti > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: openbgpd + 8.0
I am not sure if what you are observing is a side effect of
svn-r196714. In particular, the code I added for:
- Routing messages are not generated when adding and removing
interface address aliases.
If my memory serves me right, I put in the above patch for SCTP.
I'd be happy to work with you offline and confirm either way...
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Adam Jacob Muller
> Sent: Saturday, November 21, 2009 6:33 PM
> To: freebsd-net@freebsd.org
> Subject: openbgpd + 8.0
>
> Hi,
> I have an openbgpd running on an 8.0 box where openbgpd crashes (exits
> silently) whenever an interface on the system (vlan/tun/tap s are
> dynamically created here) is removed.
>
>
> I've traced the error back to kroute.c:dispatch_rtmsg_addr
>
> if ((sa = rti_info[RTAX_DST]) == NULL) {
>
>
> This check is failing, which returns -1, which is passed up
> (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets
> exit=1).
> Unfortunately, this is quickly approaching
>
> Any idea what exactly is going on here?
>
> I'm not 100% sure but I think this is a regression from 7.x, I don't
> have any 7.x systems I can test this on at the moment unfortunately.
>
> I've subverted this check by, simply, not setting quit=1 in main.c
when
> kr_dispatch_msg() fails, and everything SEEMS to operate normally, i'm
> kinda curious to hear thoughts on this though...
>
>
> -Adam
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: openbgpd + 8.0
Just to be a bit more specific, in r196714 /sys/netinet/in.c:
/* QL: XXX
1090* Report a blank rtentry when a route has not been
1091* installed for the given interface address.
1092*/
1093
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> Sent: Sunday, November 22, 2009 10:40 AM
> To: Adam Jacob Muller; freebsd-net@freebsd.org
> Subject: RE: openbgpd + 8.0
>
> I am not sure if what you are observing is a side effect of
> svn-r196714. In particular, the code I added for:
>
>
> - Routing messages are not generated when adding and removing
> interface address aliases.
>
>
> If my memory serves me right, I put in the above patch for SCTP.
> I'd be happy to work with you offline and confirm either way...
>
> -- Qing
>
>
> > -Original Message-
> > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> > n...@freebsd.org] On Behalf Of Adam Jacob Muller
> > Sent: Saturday, November 21, 2009 6:33 PM
> > To: freebsd-net@freebsd.org
> > Subject: openbgpd + 8.0
> >
> > Hi,
> > I have an openbgpd running on an 8.0 box where openbgpd crashes
> (exits
> > silently) whenever an interface on the system (vlan/tun/tap s are
> > dynamically created here) is removed.
> >
> >
> > I've traced the error back to kroute.c:dispatch_rtmsg_addr
> >
> > if ((sa = rti_info[RTAX_DST]) == NULL) {
> >
> >
> > This check is failing, which returns -1, which is passed up
> > (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets
> > exit=1).
> > Unfortunately, this is quickly approaching
> >
> > Any idea what exactly is going on here?
> >
> > I'm not 100% sure but I think this is a regression from 7.x, I don't
> > have any 7.x systems I can test this on at the moment unfortunately.
> >
> > I've subverted this check by, simply, not setting quit=1 in main.c
> when
> > kr_dispatch_msg() fails, and everything SEEMS to operate normally,
> i'm
> > kinda curious to hear thoughts on this though...
> >
> >
> > -Adam
> > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-
> unsubscr...@freebsd.org"
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: openbgpd + 8.0
On Sun, Nov 22, 2009 at 8:44 PM, Li, Qing wrote: > Just to be a bit more specific, in r196714 /sys/netinet/in.c: [...] Just wanting to let you know the following behavior changes: 1. Some customers of mine used to run 7.x with quagga. Another app was adding static routes with a nexthop of 127.0.0.1, which were redistributed by quagga to BGP as part of the "redistribute kernel" directive. After upgrading to 8.x, routes are being properly exported upon adding, however quagga doesn't stop announcing them in BGP after they disappear from the kernel route table. "route monitor" sees the RTM_DELETE message, but quagga either doesn't, or just ignores it. The same quagga port version was used on both 7.x and 8.x. 2. Switching to OpenBGPD fixed the above issue, with the notable mention that it doesn't redistribute routes with a nexthop of 127.0.0.1, so we had to rewrite the app for that (127.0.0.1 was hardcoded - INADDR_LOOPBACK). This might be an OpenBGPD check, though. Hope this is useful info. Cheers, Vlad ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [CFR] unified rc.firewall
Hajimu UMEMOTO wrote: > Hi, > > The ipfw and ip6fw were unified into ipfw2, now. But, we still have > rc.firewall and rc.firewall6. However, there are conflicts with each > other, and it confuses the users, IMHO. > So, I made a patch to unify rc.firewall and rc.firewall6, and obsolete > rc.firewall6 and rc.d/ip6fw. > Please review the attached patch. If there is no objection, I'll > commit it in next weekend. Overall I think this is good, and I'm definitely in favor of more integration of IPv6 into the mainstream rather than something that is glued on. A few comments: In rc.firewall you seem to have copied afexists() from network.subr. Is there a reason that you did not simply source that file? That would be the preferred method. Also in that file you call "if afexists inet6" quite a few times. My preference from a performance standpoint would be to call it once, perhaps in a start_precmd then cache the value. And of course, you have regression tested this thoroughly, yes? :) Please include scenarios where there is no INET6 in the kernel as well. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140778: [em] randomly panic in vlan/em
Old Synopsis: randomly panic in vlan/em New Synopsis: [em] randomly panic in vlan/em Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 22 23:18:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140778 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140796: [ath] [panic] privileged instruction fault
Old Synopsis: panic: privileged instruction fault (ath related) New Synopsis: [ath] [panic] privileged instruction fault Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 22 23:31:33 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140796 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bridging vs wifi, proxy arp broken on 8.0 rc? (was: Re: Bridged networking for virtualbox on -current?)
In article <4b09992f.1080...@shapeshifter.se> you write: >Doug Barton wrote: >> Fredrik Lindberg wrote: >>> Doug Barton wrote: Is bridged networking for vbox supposed to work on -current? It says on the wiki that it does, but I tried it tonight and couldn't get it to work. I did see one page that suggested trying one of the Intel virtual nicks, which I did, no luck. If this is not supposed to work it would be nice to update the wiki, I spent quite a bit of time trying to get it to work that I hope was not wasted. >>> The short answer is that it should work. The long answer is that >>> it depends, for example it doesn't play nice when trying to >>> bridge a virtual nic with an if_bridge interface. >>> >>> A slightly more verbose description of your environment and what >>> error messages you're seeing would probably help. >> >> Thanks. I'm using an up to date -current, and my outgoing nic is >> wlan0. I followed the instructions on the wiki. I first tried the >> default nic in OSE then I tried the first Intel nic on the list (which >> required downloading drivers of course). >> > >Which type of virtual interface you're using in virtualbox doesn't >matter. However, it hits me that I've actually never really tested >the bridging code with a wireless interface and it looks like you've >hit a bug. I tried to use a wireless interface just now and it >doesn't work, need to look into why though. The problem with bridging and wifi is that on wifi you usually can use only a single mac address... There are ways around this (using nat or routing), and I actually played with the latter using qemu tap networking recently, but couldn't get the most ideal solution working the way I wanted on 8.0 rc - it only worked on 7-stable. (using a sub-subnet of the lan interface for the tap interface + guest, and routing + proxy arp for the guest ip.) I just wanted to try it again on the 8.0 rc box and now even setting up the prox arp entry fails with: arp: writing to routing socket: Invalid argument Commands I tried: arp -s pub only and arp -s auto pub only (both before even configuring the tap interface this time...) Mind you my 8.0 rc checkout is a little old (Sep 29) so maybe I should try updating first (I want to test 8-stable anyway one of these days) - but looking for `arp' in the relevant commitlogs also came up empty. :( (I'm Cc'ing -net just in case, please keep me on the Cc cause I'm not subscribed there...) Cheers, Juergen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bridging vs wifi, proxy arp broken on 8.0 rc?
Juergen Lock wrote: > The problem with bridging and wifi is that on wifi you usually can > use only a single mac address... Ok, I'm not heartbroken if it won't work, but it would be nice if the wiki were updated so that no one else wastes time on it like I did last night. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_bridge as if_vlan parent
Tom Judge wrote: Josh Paetzel wrote: On Nov 21, 2009, at 11:39 AM, Tom Judge wrote: Hi, I was why I get the following error when trying to create a vlan on top of if_bridge: # ifconfig bridge0 create # ifconfig vlan2 vlan 2 vlandev bridge0 ifconfig: SIOCSETVLAN: Protocol not supported And if there was/is any reason for this to not be supported. Thanks You can create a bridge from a pair of vlan devices # ifconfig vlan1 create # ifcconfig vlan2 create # ifconfig bridge0 create # ifconfig vlan1 vlan 1 vlandev em0 # ifconfig vlan2 vlan 2 vlandev em0 # ifconfig bridge0 addm vlan1 addm vlan2 Is that more in line with what you want to do? I'm a little curious what problem set using a bridge as the parent of a vlan solves though. You have the problem upside down. I am trying to bridge 2 trunk ports on 2 separate switches with a FreeBSD box, and I would like to access a number of tagged vlans on the trunk with the FreeBSD box. [sw1-1/g1]->[FBSD-em0]-[FBSD-bridge0]-[FBSD-em1]->[sw2-1/g1] / \ [FBSD-vlan2][FBSD-vlan200] So: ifconfig em0 up ifconfig em1 up ifconfig bridge0 create ifconfig bridge0 addm em0 stp em0 addm em1 stp em1 up ifconfig vlan2 create ifconfig vlan2 10.0.0.1/24 vlan 2 vlandev bridge0 ifconfig vlan200 create ifconfig vlan200 10.9.9.1/24 vlan 200 vlandev bridge0 This will fail when I try to attach the if_vlan's to the if_bridge. I haven't tried it, but you MAY be able to plumb up some solution to this using the netgraph vlan and bridge nodes. Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock
The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-follo...@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Mon, 23 Nov 2009 02:25:35 -0500 (EST) On Sun, 22 Nov 2009, Bernhard Schmidt wrote: > On Sunday 01 November 2009 00:24:59 you wrote: >> Indeed, I think I saw a lockup a couple days ago, possibly when >> my card had dissociated and was trying to reassociate. >> >> Thanks for looking into this, > > Seems like your initial fix for that was actually correct, that lock up you > saw there is related to something else. There was an issue with sending null > data frames. > > Can you verify that the LOR is gone with the latest checkout of my > repository? > Compile instructions: > http://forums.freebsd.org/showpost.php?p=47627&postcount=16 I upgraded to today's current (which picked up a number of probably-unrelated changes), and then installed the driver from your tree on top of it. No LOR on boot, and I'll let you know if I see any lockups. Thanks, Ben ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140684: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot
Old Synopsis: Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot New Synopsis: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 23 07:46:48 UTC 2009 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=140684 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
