Re: if_ral regression
On Jan 5, 2008 10:19 PM, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > "Sepherosa Ziehau" <[EMAIL PROTECTED]> writes: > > This actually brings up two things: > > 1) I think we should ignore seq in multicast frames; this is permitted in > > 802.11 standard. In dfly I did that, since one of our users > > encountered a broken commercial AP which is not 802.11e but uses > > different seq for data and beacon. > > 2) TX sequence. I think standards only mention QSTA/nQSTA, but not > > AP. Currently our AP uses per node TX seq, which means beacon's seq > > is difficult to choose, at least for 2560 based ral(4), whose beacons' > > seq need to be set by software. I saw Linksys AP uses one seq for all > > of the frames it sends. Sam, what's you opinion on this? > > > > I think if STA counts ral(4)'s beacon seq, as what we do currently, > > beacon missing will quickly happen since beacons will be discarded > > after first several data frames. > > OK, I *think* I understood most of that. Does this suggest a solution > to you? I will try to get the wlandebug output tonight. I don't know whether you are still interested to track down the wired problem you had experienced. If you have time please try following patches: revert the old patch at your AP side and try this one http://people.freebsd.org/~sephe/rt2560_test.diff1 apply following patch at you STA side http://people.freebsd.org/~sephe/ieee80211_input.c.diff Best Regards, sephe -- Live Free or Die ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/119361: [bge] bge(4) transmit performance problem
On Jan 8, 2008 1:28 AM, <[EMAIL PROTECTED]> wrote: > Synopsis: [bge] bge(4) transmit performance problem > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Mon Jan 7 17:28:37 UTC 2008 > Responsible-Changed-Why: > reassign to -net team > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 Have you tested polling(4)? If polling could give you better TX performance, you should consider raise: in bge_attach() sc->bge_tx_max_coal_bds = 10; to 64 or more > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Live Free or Die ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
the socket can't bind?
Hi all, I attempt to run a program like this: 1. make a socket 2. set socket option with SO_REUSEADDR. 3. bind it 4. listen... accept...etc.. Alright, it works well. And I kill it, it can bind immediately. After this, I do: 5. close all fd. 6. reload it with execvp. So it would run 1-4. but it reports EADDRINUSE after bind. Why? How to resolve it? Should I dup() the fd? Thanks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_ral regression
"Sepherosa Ziehau" <[EMAIL PROTECTED]> writes: > revert the old patch at your AP side and try this one > http://people.freebsd.org/~sephe/rt2560_test.diff1 I will, thanks. > apply following patch at you STA side > http://people.freebsd.org/~sephe/ieee80211_input.c.diff My STA side doesn't run FreeBSD... the only laptop I have that does has a flat battery and I can't find the mains adapter :( DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/119548: [pf] [ath] PF Altq with ath hostap problem
On Jan 11, 2008 10:22 AM, <[EMAIL PROTECTED]> wrote: > Old Synopsis: PF Altq with ath hostap problem > New Synopsis: [pf] [ath] PF Altq with ath hostap problem > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Fri Jan 11 02:22:26 UTC 2008 > Responsible-Changed-Why: > Assign to -net mailing list. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119548 Please test following patch: http://people.freebsd.org/~sephe/ieee80211_input.c.6_3.diff Best Regards, sephe -- Live Free or Die ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem
Old Synopsis: [pf] [ath] PF Altq with ath hostap problem New Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Fri Jan 11 17:43:47 UTC 2008 State-Changed-Why: To submitter: a patch has been created, can you give it a try please? http://www.freebsd.org/cgi/query-pr.cgi?pr=119548 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: the socket can't bind?
SnaiX wrote: So it would run 1-4. but it reports EADDRINUSE after bind. Why? The stack assumes that SO_REUSEADDR is never cleared on a socket after it gets set. How to resolve it? Should I dup() the fd? Did you close the affected socket in (5) ? Presumably you are still trying to use the same port; is it a non-ephemeral port? You might want to consider SO_REUSEPORT although I believe FreeBSD doesn't fully support it for non-multicast. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_ral regression [was seq#'s on ap frames]
Sepherosa Ziehau wrote: On Jan 5, 2008 10:19 PM, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: "Sepherosa Ziehau" <[EMAIL PROTECTED]> writes: This actually brings up two things: 1) I think we should ignore seq in multicast frames; this is permitted in 802.11 standard. In dfly I did that, since one of our users encountered a broken commercial AP which is not 802.11e but uses different seq for data and beacon. 2) TX sequence. I think standards only mention QSTA/nQSTA, but not AP. Currently our AP uses per node TX seq, which means beacon's seq is difficult to choose, at least for 2560 based ral(4), whose beacons' seq need to be set by software. I saw Linksys AP uses one seq for all of the frames it sends. Sam, what's you opinion on this? I think if STA counts ral(4)'s beacon seq, as what we do currently, beacon missing will quickly happen since beacons will be discarded after first several data frames. OK, I *think* I understood most of that. Does this suggest a solution to you? I will try to get the wlandebug output tonight. I don't know whether you are still interested to track down the wired problem you had experienced. If you have time please try following patches: revert the old patch at your AP side and try this one http://people.freebsd.org/~sephe/rt2560_test.diff1 apply following patch at you STA side http://people.freebsd.org/~sephe/ieee80211_input.c.diff Best Regards, sephe [just back from holiday and only now caught your question about seq#'s] The issue of seq# generation has mostly been ignored because many/most devices generate them directly. I'm aware of issues w/ management frames not getting correct seq#'s for ap mode (e.g. probe response) and have some uncommitted changes. Beacon frames should track the seq# in the bss node though there might be some trickiness w/ the bss node being rebuilt too much (we may need to propagate the current seq# as we do some other state). On the rx side I'm not sure about ignoring seq# of mcast frames; it would definitely be a WAR for broken ap implementations. FWIW I took ownership of a ral bug where AP mode tx just stopped for no apparent reason (I think it was probe response frames but can't recall). This sounds like the same thing; can you check kern/117655? Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/119225: 7.0-RC1 no carrier with Prism 2.5 wifi card
The following reply was made to PR kern/119225; it has been noted by GNATS. From: Harrison Grundy <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/119225: 7.0-RC1 no carrier with Prism 2.5 wifi card Date: Sat, 12 Jan 2008 07:48:32 +0900 I have seen the same behavior on a Prism 2.5 system I've got. The NDISulator driver works fine, though. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/116837: ifconfig tunX destroy: panic
The following reply was made to PR kern/116837; it has been noted by GNATS.
From: KUROSAWA Takahiro <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/116837: ifconfig tunX destroy: panic
Date: Sat, 12 Jan 2008 15:48:39 +0900
The KASSERT() check in tun_destroy() seems incorrect
since the function can actually be called while
a user thread is opening /dev/tunX. If we needed to
ensure that no threads have fd for /dev/tunX in
tun_destroy(), we should implement it in if_tun.
Instead, we can rely on destroy_dev() to ensure that
no threads access /dev/tunX anymore (the function
blocks when there are threads accessing the device).
But just deleting KASSERT() is insufficient because
there is a race condition: tun_destroy() calls
if_free() before destroy_dev(), so user threads might
access the destroyed ifnet structure by read()/write()/...
on /dev/tunX.
I guess the following change is needed for if_tun.c:
--- sys/net/if_tun.c 2008/01/11 04:14:11 1.1
+++ sys/net/if_tun.c 2008/01/12 04:04:39
@@ -249,15 +249,12 @@ tun_destroy(struct tun_softc *tp)
{
struct cdev *dev;
- /* Unlocked read. */
- KASSERT((tp->tun_flags & TUN_OPEN) == 0,
- ("tununits is out of sync - unit %d", TUN2IFP(tp)->if_dunit));
-
dev = tp->tun_dev;
+ /* destroy_dev() ensures no threads access /dev/tunX anymore. */
+ destroy_dev(dev);
bpfdetach(TUN2IFP(tp));
if_detach(TUN2IFP(tp));
if_free(TUN2IFP(tp));
- destroy_dev(dev);
knlist_destroy(&tp->tun_rsel.si_note);
mtx_destroy(&tp->tun_mtx);
free(tp, M_TUN);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
