issue with atheros and channel selection
Hi guys. When you ifconfig athX channel XX it works fine But when you then want to change that to ifconfig athX channel any (or '-' or '0') the old channel number does not change. The number then can be changed only to a different numeric value. Cheers, Marcin Jessa ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interface cleanup
> Currently I am going through netstat and > rewriting some of the functions to rely on sysctl rather than kvm. > The hope is to completely remove kvm from netstat, and parts that > solely depend on it, like the core dump analysis would be factored > out and moved to a more suitable place (kgdb?) I also worked on it a bit. I didn't find a way to get the "IP interface" statistics with a sysctl. I wrote a small patch to kernel to include it which you may find usefull. Attached are the patches and a program that uses the new function. It's used pretty similarly to if_mib. I can't find the modifications to netstat to use it :-(. I'also played a bit with route printing through sysctl but it's nothing fancy. I can give you the result of this if you'd like to. Att Index: conf/files === RCS file: /home/fcvs/cvs/src/sys/conf/files,v retrieving revision 1.975 diff -u -r1.975 files --- conf/files 9 Dec 2004 13:54:28 - 1.975 +++ conf/files 16 Dec 2004 23:37:03 - @@ -1477,6 +1477,7 @@ netinet/igmp.c optional inet netinet/in.c optional inet netinet/in_gif.c optional gif inet +netinet/in_mib.c optional inet netinet/ip_gre.c optional gre inet netinet/ip_id.c optional inet netinet/in_pcb.c optional inet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problem with sending SYN/ACK
Hello, Suppose I have three daemons, who grab all the packets which are forwarded to their addresses via different vlans fwd 10.104.50.2,9998 tcp from any to any dst-port 80 in recv vlan0 fwd 10.104.50.6,9998 tcp from any to any dst-port 80 in recv vlan1 fwd 10.104.50.10,9998 tcp from any to any dst-port 80 in recv vlan2 Those daemons then proceed to answer with a static responce (well, I mean they actually accept connection, give the responce and close socket which they've created accepting connection) Those daemons run with uids of 2 20001 and 20002. So, I forward the answers to the proper gateway by using ipfw rules: fwd 10.104.50.1 tcp from any to any out uid 2 fwd 10.104.50.5 tcp from any to any out uid 20001 fwd 10.104.50.9 tcp from any to any out uid 20002 The problem is that the SYN/ACK packet seems to be sent from another uid, and thus cannot be forwarded to the proper gateway. Is there a way I can force sending SYN/ACK from uids I need? I don't want to use additional natd's on those gateways, neither I want to run those daemons on gateways. Thank You for reading this. -- Roman Petrov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what to replace splnet in FreeBSD 5.x?
On Tue, 12 Jul 2005, Ed Maste wrote:
On Tue, Jul 12, 2005 at 04:30:18PM +0100, Robert Watson wrote:
I'm concerned about the multicast address list problems you've been
experiencing, but haven't yet had a chance to investigate. If you could
provide a code fragment that exercises this problem, that would probably
get me started a lot more quickly.
Thanks Robert. So far we've reproduced it only within our test lab
environment and with our product executables -- a large amount of code
and infrastructure. I've attempted to reduce it to a small amount of
code that demonstrates the problem but have had no success yet.
Ed,
The attached patch introduces locking around the link layer and IPv4
multicast address lists, as well as updates drivers to use the locking.
It's a fairly large diff, but other than the changes to if.c, in.c, and
igmp.c, is fairly mechanical. It may well correct the problem you've been
seeing. If possible, and given sufficient review, I'd like to get this
change into 6.0, especially given that it affects the layout of struct
ifnet which is part of the ABI for network interface device drivers.
I've tested it with a basic IPv4 multicast regression test locally, but
not with a lot of multicast parallelism, since I don't have easily
accessible real-world workloads. Any testing you could provide would be
most welcome. Likewise, code review :-).
Similar changes will also be needed in the IPv6 multicast code. I've CC'd
George to victimize him further ... er ... to see if he's interested in
this area.
Robert N M Watson
--- //depot/vendor/freebsd/src/sys/dev/ath/if_ath.c 2005/07/22 18:00:59
+++ //depot/projects/netsmp/src/sys/dev/ath/if_ath.c2005/07/23 00:06:01
@@ -1661,6 +1661,7 @@
/* calculate and install multicast filter */
if ((ifp->if_flags & IFF_ALLMULTI) == 0) {
mfilt[0] = mfilt[1] = 0;
+ IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
caddr_t dl;
@@ -1673,6 +1674,7 @@
pos &= 0x3f;
mfilt[pos / 32] |= (1 << (pos % 32));
}
+ IF_ADDR_UNLOCK(ifp);
} else {
mfilt[0] = mfilt[1] = ~0;
}
--- //depot/vendor/freebsd/src/sys/dev/awi/awi.c2005/07/22 16:50:36
+++ //depot/projects/netsmp/src/sys/dev/awi/awi.c 2005/07/23 00:06:01
@@ -1146,15 +1146,19 @@
#ifdef __FreeBSD__
if (ifp->if_flags & IFF_ALLMULTI)
goto set_mib;
+ IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
if (ifma->ifma_addr->sa_family != AF_LINK)
continue;
- if (n == AWI_GROUP_ADDR_SIZE)
+ if (n == AWI_GROUP_ADDR_SIZE) {
+ IF_ADDR_UNLOCK(ifp);
goto set_mib;
+ }
IEEE80211_ADDR_COPY(sc->sc_mib_addr.aGroup_Addresses[n],
LLADDR((struct sockaddr_dl *)ifma->ifma_addr));
n++;
}
+ IF_ADDR_UNLOCK(ifp);
#else
ETHER_FIRST_MULTI(step, &sc->sc_ic.ic_ec, enm);
while (enm != NULL) {
--- //depot/vendor/freebsd/src/sys/dev/bfe/if_bfe.c 2005/06/10 16:51:34
+++ //depot/projects/netsmp/src/sys/dev/bfe/if_bfe.c2005/07/19 21:29:46
@@ -883,12 +883,14 @@
val |= BFE_RXCONF_ALLMULTI;
else {
val &= ~BFE_RXCONF_ALLMULTI;
+ IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
if (ifma->ifma_addr->sa_family != AF_LINK)
continue;
bfe_cam_write(sc,
LLADDR((struct sockaddr_dl *)ifma->ifma_addr), i++);
}
+ IF_ADDR_UNLOCK(ifp);
}
CSR_WRITE_4(sc, BFE_RXCONF, val);
--- //depot/vendor/freebsd/src/sys/dev/bge/if_bge.c 2005/06/24 21:45:25
+++ //depot/projects/netsmp/src/sys/dev/bge/if_bge.c2005/07/19 21:29:46
@@ -1171,6 +1171,7 @@
CSR_WRITE_4(sc, BGE_MAR0 + (i * 4), 0);
/* Now program new ones. */
+ IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
if (ifma->ifma_addr->sa_family != AF_LINK)
continue;
@@ -1178,6 +1179,7 @@
ifma->ifma_addr), ETHER_ADDR_LEN) & 0x7F;
hashes[(h & 0x60) >> 5] |= 1 << (h & 0x1F);
}
+ IF_ADDR_UNLOCK(ifp);
for (i = 0; i < 4; i++)
CSR_WRITE_4(sc, BGE_MAR0 + (i * 4), hashes[i]);
--- //depot/vendor/freebsd/src/sys/dev/ed/if_ed.c 2005/06/15 20:25:30
+++ //depot/projects/netsmp/src/sys/dev/ed/if_ed.c 2005/07/19 21:29:46
@@ -1778,6 +1778,7 @@
mcaf[0] = 0;
mcaf[1] = 0;
+ IF_ADDR_LOCK(sc->ifp);
TAILQ_FOREACH(ifma, &sc->ifp->if_multiaddrs, ifma_link) {
Re: what to replace splnet in FreeBSD 5.x?
On Sat, 23 Jul 2005, Robert Watson wrote: The attached patch introduces locking around the link layer and IPv4 multicast address lists, as well as updates drivers to use the locking. It's a fairly large diff, but other than the changes to if.c, in.c, and igmp.c, is fairly mechanical. It may well correct the problem you've been seeing. If possible, and given sufficient review, I'd like to get this change into 6.0, especially given that it affects the layout of struct ifnet which is part of the ABI for network interface device drivers. Updated version of the patch at: http://www.watson.org/~robert/freebsd/netperf/20050523-multicast.diff Spl-related cleanups (no longer useful documentation of old synchronization in many places), lock order hard-coded into WITNESS order rather than dynamically detected. Robert N M Watson ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: altq for vlans?
I believe the solution is not patching ALTQ to the VLAN driver, but rather make ALTQ recognize rules that classify according to fields in Layer 2 header (fields such as VLANid and Priority, other than just src/dst addr/port and protocol in IP header). For example, build filter rules that specify priority tracking according to the 3-bit field in the VLAN tag as per 802.1p. For example in /etc/altq.conf: interface vx0 bandwidth 100M cbq class cbq vx0 root_class NULL pbandwidth 100 class cbq vx0 vlan1_class root_class pbandwidth 80 filter vx0 cs1_class vlan1_class vlanprio 6 # priority 6 takes more bandwidth class cbq vx0 vlan2_class root_class pbandwidth 15 filter vx0 cs2_class vlan2_class vlanprio 4 # priority 4 takes less bandwidth The discussion (patch) back then is good for a FreeBSD configured as end-host, but not as a MAC bridge: [1]http://lists.freebsd.org/pipermail/freebsd-net/2005-January/006240. html Regards, Gilbert Tsang. Max Laier wrote: On Sunday 13 February 2005 22:36, David Gilbert wrote: Has anyone considered patching the vlan driver to support altq? I gather that since tun works, so should vlan. This should be a FAQ. Anyway, here is the story: While you can do ALTQ queueing on vlan interfaces the usefulness of this is very little. If the physical interface supports ALTQ it is *always* better to do the queueing there. If the physical interface does not support ALTQ it must be patched. [snipped] References 1. http://lists.freebsd.org/pipermail/freebsd-net/2005-January/006240.html ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interface cleanup
Anders Persson wrote: Hi all, I have not had time to go through netgraph enough yet, but does anyone have some ideas how to avoid using kvm to obtain netgraph info? what info do you want to get that isn't already avaliable? Thanks a lot, Anders ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
