Re: CFT: 11n support for iwn(4)
On Sunday, May 01, 2011 23:36:56 Brandon Gooch wrote: > On Sun, May 1, 2011 at 8:24 AM, Bernhard Schmidt wrote: > > On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote: > >> Hi, > >> > >> I finally managed to get the 11n bits for iwn(4) sorted out. Well, > >> there is still an issue somewhere with HT40 frame protection or > >> TX chain setup on 5000 adapters, resulting in throughput not being > >> that stable. But overall it seems to work pretty decently > >> > >> This is for HEAD only right now, net80211 in stable/8 does not yet > >> contain the latest 11n related fixes. So, if you run HEAD and have > >> some iwn(4) hardware, I'd appreciate feedback. > >> .. > > > > Updated version, I've missed a locking issue. > > > > -- > > Bernhard > > Thanks for working on this Bernhard! > > Unfortunately, I'm having trouble achieving HT rates. > > After 'wlandebug 0x', lots of: > ... > May 1 14:38:15 x300 kernel: wlan0: received beacon from > 00:1d:0f:d3:fb:cc rssi 47 > May 1 14:38:15 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard beacon > frame, ie too short, got 26, expected 30 > ... > > I've attached relevant debugging information, but let me know if there > may be anything else that could help. I need to work on DTracing > net80211, any tips on relevant function traces? Attachment seems to be missing? I'd start of with enabling bootverbose to figure out if your adapter supports 11n at all. There are some where the 11n bits have been disabled. Next thing would be to check with % ifconfig -v wlan0 list chan if the HT channel setup works, if so it should list several HT20/HT40 channels. With % wlanconfig +11n you should at least see something like "Switching channel to HT20" right before moving into RUN state. Also, does % ifconfig wlan0 list scan show HTCAP for the AP you're associating too? -- Bernhard ___ 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: CFT: 11n support for iwn(4)
2011/5/2 Bernhard Schmidt : > On Sunday, May 01, 2011 23:36:56 Brandon Gooch wrote: >> On Sun, May 1, 2011 at 8:24 AM, Bernhard Schmidt >> wrote: >> > On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote: >> >> Hi, >> >> >> >> I finally managed to get the 11n bits for iwn(4) sorted out. Well, >> >> there is still an issue somewhere with HT40 frame protection or >> >> TX chain setup on 5000 adapters, resulting in throughput not being >> >> that stable. But overall it seems to work pretty decently >> >> >> >> This is for HEAD only right now, net80211 in stable/8 does not yet >> >> contain the latest 11n related fixes. So, if you run HEAD and have >> >> some iwn(4) hardware, I'd appreciate feedback. >> >> .. >> > >> > Updated version, I've missed a locking issue. >> > >> > -- >> > Bernhard >> >> Thanks for working on this Bernhard! >> >> Unfortunately, I'm having trouble achieving HT rates. >> >> After 'wlandebug 0x', lots of: >> ... >> May 1 14:38:15 x300 kernel: wlan0: received beacon from >> 00:1d:0f:d3:fb:cc rssi 47 >> May 1 14:38:15 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard beacon >> frame, ie too short, got 26, expected 30 >> ... >> >> I've attached relevant debugging information, but let me know if there >> may be anything else that could help. I need to work on DTracing >> net80211, any tips on relevant function traces? > > Attachment seems to be missing? I'll send the attachment again, directly to you, bypassing the list... > I'd start of with enabling bootverbose to figure out if your adapter > supports 11n at all. iwn0: mem 0xf9f0-0xf9f01fff irq 17 at device 0.0 on pci3 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 55 iwn0: using IRQ 259 for MSI iwn0: MIMO 2T3R, MoW1, address 00:1f:3b:28:30:c5 iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 2T3R iwn0: 11na MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: MCS 8-15: 13Mbps - 130Mbps iwn0: 11na MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: MCS 8-15: 14.5Mbps - 144.5Mbps iwn0: 11na MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: MCS 8-15: 27Mbps - 270Mbps iwn0: 11na MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps iwn0: MCS 8-15: 30Mbps - 300Mbps iwn0: 11ng MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: MCS 8-15: 13Mbps - 130Mbps iwn0: 11ng MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: MCS 8-15: 14.5Mbps - 144.5Mbps iwn0: 11ng MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: MCS 8-15: 27Mbps - 270Mbps iwn0: 11ng MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps iwn0: MCS 8-15: 30Mbps - 300Mbps >There are some where the 11n bits have been > disabled. Next thing would be to check with > % ifconfig -v wlan0 list chan I think you may be right about this, despite the dmesg output, as I see no 11n listed in the output: # ifconfig -v wlan0 list chan Channel 1 : 2412 MHz 11b Channel 40 : 5200* MHz 11a Channel 1 : 2412 MHz 11g Channel 40 : 5200* MHz 11a ht/20 Channel 1 : 2412 MHz 11g ht/20Channel 40 : 5200* MHz 11a ht/40- Channel 2 : 2417 MHz 11b Channel 44 : 5220* MHz 11a Channel 2 : 2417 MHz 11g Channel 44 : 5220* MHz 11a ht/20 Channel 2 : 2417 MHz 11g ht/20Channel 44 : 5220* MHz 11a ht/40+ Channel 3 : 2422 MHz 11b Channel 48 : 5240* MHz 11a Channel 3 : 2422 MHz 11g Channel 48 : 5240* MHz 11a ht/20 Channel 3 : 2422 MHz 11g ht/20Channel 48 : 5240* MHz 11a ht/40- Channel 4 : 2427 MHz 11b Channel 52 : 5260* MHz 11a Channel 4 : 2427 MHz 11g Channel 52 : 5260* MHz 11a ht/20 Channel 4 : 2427 MHz 11g ht/20Channel 52 : 5260* MHz 11a ht/40+ Channel 5 : 2432 MHz 11b Channel 56 : 5280* MHz 11a Channel 5 : 2432 MHz 11g Channel 56 : 5280* MHz 11a ht/20 Channel 5 : 2432 MHz 11g ht/20Channel 56 : 5280* MHz 11a ht/40- Channel 6 : 2437 MHz 11b Channel 60 : 5300* MHz 11a Channel 6 : 2437 MHz 11g Channel 60 : 5300* MHz 11a ht/20 Channel 6 : 2437 MHz 11g ht/20Channel 60 : 5300* MHz 11a ht/40+ Channel 7 : 2442 MHz 11b Channel 64 : 5320* MHz 11a Channel 7 : 2442 MHz 11g Channel 64 : 5320* MHz 11a ht/20 Channel 7 : 2442 MHz 11g ht/20Channel 64 : 5320* MHz 11a ht/40- Channel 8 : 2447 MHz 11b Channel 149 : 5745* MHz 11a Channel 8 : 2447 MHz 11g Channel 149 : 5745* MHz 11a ht/20 Channel 8 : 2447 MHz 11g ht/20Channel 149 : 5745* MHz 11a ht/40+ Channel 9 : 2452 MHz 11b Channel 153 : 5765* MHz 11a Channel 9 : 2452 MHz 11g Channel 153 : 5765* MHz 11a ht/20 Channel 9 : 2452 MHz 11g ht/20Channel 153 : 5765* MHz 11a ht/40- Channel 10 : 2457 MHz 11b Channel 157 : 5785* MHz 11a Channel 10 : 2457 MHz 11g Channel 15
Re: interface ip arp
Hi,
On Sun, May 1, 2011 at 10:50 PM, Li, Qing wrote:
> jeez, this bug has been around for quite a while ...
>
> Please try patch at http://people.freebsd.org/~qingli/arp.patch
>
d'oh!... Concerning Ingo's bug, your patch do the job, my report was
bad, 4.9-RELEASE and 7.x show the same behavior:
# uname -a
FreeBSD server 7.1-RELEASE-p13 FreeBSD 7.1-RELEASE-p13
# ifconfig em0 up 192.168.45.200/24
# arp -n 192.168.45.200
? (192.168.45.200) at 00:03:2d:16:6e:fc on em0 permanent [ethernet]
# ifconfig em0 down
# arp -n 192.168.45.200
192.168.45.200 (192.168.45.200) -- no entry
# ifconfig em0 up
# arp -n 192.168.45.200
192.168.45.200 (192.168.45.200) -- no entry
The behavioral change I noticed is that permanent address (manually
added) in the ARP table are flushed along with all other addresses on
>8.x (cf. the script output of my previous mail) while they are kept
in the cache on <7.x during a down/up transition. The following patch:
diff --git a/sys/netinet/in.c b/sys/netinet/in.c
index 1012012..27e44a2 100644
--- a/sys/netinet/in.c
+++ b/sys/netinet/in.c
@@ -1372,6 +1372,8 @@ in_lltable_prefix_free(struct lltable *llt,
for (i=0; i < LLTBL_HASHTBL_SIZE; i++) {
LIST_FOREACH_SAFE(lle, &llt->lle_head[i], lle_next, next) {
+ if (lle->la_flags & LLE_STATIC)
+ continue;
if (IN_ARE_MASKED_ADDR_EQUAL((struct
sockaddr_in *)L3_ADDR(lle),
pfx, msk)) {
partially restores the old behavior. Only partially as before 8.x,
interface addresses were not marked as 'permanent'. You could manually
add a 'permanent' entry for this address in such a way it would
survive the down/up transition. In 8.x, the interface address is
marked as 'permanent', but is removed explicitly by arp_ifscrub(). So
even the above change would not work for the interface address.
Shouldn't this address be removed later when "removing all L2 entries
on the given prefix", in which case it would not have to be re-added
again, if marking it 'permanent' is deliberate ?
Thanks,
- Arnaud
___
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: interface ip arp
Your patch doesn't work because the in_lltable_prefix_free() is a generic
function.
The static entries are kept only when issuing if-down command, however, if the
interface
address is being removed, permanent static entries are gone and have to be
reinstalled.
I already have a working patch for IPv4, just going over the IPv6 code.
I will post the patch in a few minutes.
-- Qing
From: Arnaud Lacombe [lacom...@gmail.com]
Sent: Monday, May 02, 2011 12:41 AM
To: Li, Qing
Cc: Ingo Flaschberger; freebsd-net@freebsd.org
Subject: Re: interface ip arp
Hi,
On Sun, May 1, 2011 at 10:50 PM, Li, Qing wrote:
> jeez, this bug has been around for quite a while ...
>
> Please try patch at http://people.freebsd.org/~qingli/arp.patch
>
d'oh!... Concerning Ingo's bug, your patch do the job, my report was
bad, 4.9-RELEASE and 7.x show the same behavior:
# uname -a
FreeBSD server 7.1-RELEASE-p13 FreeBSD 7.1-RELEASE-p13
# ifconfig em0 up 192.168.45.200/24
# arp -n 192.168.45.200
? (192.168.45.200) at 00:03:2d:16:6e:fc on em0 permanent [ethernet]
# ifconfig em0 down
# arp -n 192.168.45.200
192.168.45.200 (192.168.45.200) -- no entry
# ifconfig em0 up
# arp -n 192.168.45.200
192.168.45.200 (192.168.45.200) -- no entry
The behavioral change I noticed is that permanent address (manually
added) in the ARP table are flushed along with all other addresses on
>8.x (cf. the script output of my previous mail) while they are kept
in the cache on <7.x during a down/up transition. The following patch:
diff --git a/sys/netinet/in.c b/sys/netinet/in.c
index 1012012..27e44a2 100644
--- a/sys/netinet/in.c
+++ b/sys/netinet/in.c
@@ -1372,6 +1372,8 @@ in_lltable_prefix_free(struct lltable *llt,
for (i=0; i < LLTBL_HASHTBL_SIZE; i++) {
LIST_FOREACH_SAFE(lle, &llt->lle_head[i], lle_next, next) {
+ if (lle->la_flags & LLE_STATIC)
+ continue;
if (IN_ARE_MASKED_ADDR_EQUAL((struct
sockaddr_in *)L3_ADDR(lle),
pfx, msk)) {
partially restores the old behavior. Only partially as before 8.x,
interface addresses were not marked as 'permanent'. You could manually
add a 'permanent' entry for this address in such a way it would
survive the down/up transition. In 8.x, the interface address is
marked as 'permanent', but is removed explicitly by arp_ifscrub(). So
even the above change would not work for the interface address.
Shouldn't this address be removed later when "removing all L2 entries
on the given prefix", in which case it would not have to be re-added
again, if marking it 'permanent' is deliberate ?
Thanks,
- Arnaud
___
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: CFT: 11n support for iwn(4)
On Monday, May 02, 2011 09:34:31 Brandon Gooch wrote: > 2011/5/2 Bernhard Schmidt : > > On Sunday, May 01, 2011 23:36:56 Brandon Gooch wrote: > >> On Sun, May 1, 2011 at 8:24 AM, Bernhard Schmidt > >> wrote: > >> > On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote: > >> >> Hi, > >> >> > >> >> I finally managed to get the 11n bits for iwn(4) sorted out. Well, > >> >> there is still an issue somewhere with HT40 frame protection or > >> >> TX chain setup on 5000 adapters, resulting in throughput not being > >> >> that stable. But overall it seems to work pretty decently > >> >> > >> >> This is for HEAD only right now, net80211 in stable/8 does not yet > >> >> contain the latest 11n related fixes. So, if you run HEAD and have > >> >> some iwn(4) hardware, I'd appreciate feedback. > >> >> .. > >> > > >> > Updated version, I've missed a locking issue. > >> > > >> > -- > >> > Bernhard > >> > >> Thanks for working on this Bernhard! > >> > >> Unfortunately, I'm having trouble achieving HT rates. > >> > >> After 'wlandebug 0x', lots of: > >> ... > >> May 1 14:38:15 x300 kernel: wlan0: received beacon from > >> 00:1d:0f:d3:fb:cc rssi 47 > >> May 1 14:38:15 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard beacon > >> frame, ie too short, got 26, expected 30 > >> ... > >> > >> I've attached relevant debugging information, but let me know if there > >> may be anything else that could help. I need to work on DTracing > >> net80211, any tips on relevant function traces? > > > > Attachment seems to be missing? > > I'll send the attachment again, directly to you, bypassing the list... > > > I'd start of with enabling bootverbose to figure out if your adapter > > supports 11n at all. > > .. > iwn0: 11na MCS 20MHz > iwn0: MCS 0-7: 6.5Mbps - 65Mbps > iwn0: MCS 8-15: 13Mbps - 130Mbps > .. That indicates 11n support. > >There are some where the 11n bits have been > > disabled. Next thing would be to check with > > % ifconfig -v wlan0 list chan > > I think you may be right about this, despite the dmesg output, as I > see no 11n listed in the output: > > # ifconfig -v wlan0 list chan > > Channel 1 : 2412 MHz 11g ht/20Channel 40 : 5200* MHz 11a ht/40- HT channels are available. > > if the HT channel setup works, if so it should list several HT20/HT40 > > channels. With > > % wlanconfig +11n > > # wlandebug +11n > > May 2 02:22:24 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <268:331> (0 frames) rxseq 267 tid 0 (retransmit) > May 2 02:22:28 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <336:399> (0 frames) rxseq 335 tid 0 (retransmit) > May 2 02:22:28 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <393:456> (0 frames) rxseq 392 tid 0 (retransmit) > May 2 02:22:28 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <406:469> (0 frames) rxseq 405 tid 0 (retransmit) That is probably the reason why you're seeing low performance. I remember seeing this with ath9k but didn't dig any deeper. Well, time to do so now. > > you should at least see something like "Switching channel to HT20" > > right before moving into RUN state. Also, does > > % ifconfig wlan0 list scan > > show HTCAP for the AP you're associating too? > > # ifconfig -v wlan0 list scan > > bingo00:1d:0f:d3:fb:cc 11 54M -71:-95 > .. > txop 47]> VEN HTCAPhttp://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: interface ip arp
Please give this patch a try for IPv4 ARP
http://people.freebsd.org/~qingli/arp2.patch
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Monday, May 02, 2011 12:45 AM
To: Arnaud Lacombe
Cc: freebsd-net@freebsd.org; Ingo Flaschberger
Subject: RE: interface ip arp
Your patch doesn't work because the in_lltable_prefix_free() is a generic
function.
The static entries are kept only when issuing if-down command, however, if the
interface
address is being removed, permanent static entries are gone and have to be
reinstalled.
I already have a working patch for IPv4, just going over the IPv6 code.
I will post the patch in a few minutes.
-- Qing
From: Arnaud Lacombe [lacom...@gmail.com]
Sent: Monday, May 02, 2011 12:41 AM
To: Li, Qing
Cc: Ingo Flaschberger; freebsd-net@freebsd.org
Subject: Re: interface ip arp
Hi,
On Sun, May 1, 2011 at 10:50 PM, Li, Qing wrote:
> jeez, this bug has been around for quite a while ...
>
> Please try patch at http://people.freebsd.org/~qingli/arp.patch
>
d'oh!... Concerning Ingo's bug, your patch do the job, my report was
bad, 4.9-RELEASE and 7.x show the same behavior:
# uname -a
FreeBSD server 7.1-RELEASE-p13 FreeBSD 7.1-RELEASE-p13
# ifconfig em0 up 192.168.45.200/24
# arp -n 192.168.45.200
? (192.168.45.200) at 00:03:2d:16:6e:fc on em0 permanent [ethernet]
# ifconfig em0 down
# arp -n 192.168.45.200
192.168.45.200 (192.168.45.200) -- no entry
# ifconfig em0 up
# arp -n 192.168.45.200
192.168.45.200 (192.168.45.200) -- no entry
The behavioral change I noticed is that permanent address (manually
added) in the ARP table are flushed along with all other addresses on
>8.x (cf. the script output of my previous mail) while they are kept
in the cache on <7.x during a down/up transition. The following patch:
diff --git a/sys/netinet/in.c b/sys/netinet/in.c
index 1012012..27e44a2 100644
--- a/sys/netinet/in.c
+++ b/sys/netinet/in.c
@@ -1372,6 +1372,8 @@ in_lltable_prefix_free(struct lltable *llt,
for (i=0; i < LLTBL_HASHTBL_SIZE; i++) {
LIST_FOREACH_SAFE(lle, &llt->lle_head[i], lle_next, next) {
+ if (lle->la_flags & LLE_STATIC)
+ continue;
if (IN_ARE_MASKED_ADDR_EQUAL((struct
sockaddr_in *)L3_ADDR(lle),
pfx, msk)) {
partially restores the old behavior. Only partially as before 8.x,
interface addresses were not marked as 'permanent'. You could manually
add a 'permanent' entry for this address in such a way it would
survive the down/up transition. In 8.x, the interface address is
marked as 'permanent', but is removed explicitly by arp_ifscrub(). So
even the above change would not work for the interface address.
Shouldn't this address be removed later when "removing all L2 entries
on the given prefix", in which case it would not have to be re-added
again, if marking it 'permanent' is deliberate ?
Thanks,
- Arnaud
___
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"
Radix sorting bug affecting IPSec performance.
This line from the OpenBSD 4.9 release notes attracted my attention : "A radix tree sorting bug was fixed, which results in significant improvements to IPsec performance under certain conditions.| And this seems to be the relevant commit : http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix.c?rev=1.28;sortby=date Looking at the FreeBSD code it seems that is also affected, maybe it's a good idea to add their fix in FreeBSD :) Regards, Nikolay___ 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"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/156493 net[msk] Marvell Yukon 2 device works only few seconds o kern/156408 net[vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net[icmp]: host can ping other subnet but no have IP from o kern/156317 net[ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net[ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net[if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net[lagg]: failover does not announce the failover to swi o kern/156030 net[ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 netifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net[multicast] problems with multicast s kern/155642 net[request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155636 net[msk] msk driver locks marvel yukon 88E8057 NIC o kern/155604 net[flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net[panic] Kernel panics with "sbdrop" message o kern/155585 net[tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155498 net[ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net[vlan] adding vlan break existent vlan o bin/155365 net[patch] routed(8): if.c in routed fails to compile if o kern/155177 net[route] [panic] Panic when inject routes in kernel o kern/155030 net[igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net[msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net[bce] [panic] kernel panic in bce0 driver o kern/154943 net[gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net[request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net[netgraph] [patch] ng_ether fails to name nodes when t o kern/154831 net[arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net[em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net[tcp] [panic] Random kernel panics on tcp_output o kern/154557 net[tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net[if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net[netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net[nfs] NFS not responding o kern/154214 net[stf] [panic] Panic when creating stf interface o kern/154185 netrace condition in mb_dupcl o kern/154169 net[multicast] [ip6] Node Information Query multicast add o kern/154134 net[ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net[netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net[vlan] [patch] change to way of auto-generatation of v o kern/153937 net[ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net[ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net[ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net[ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net[netgraph] netgraph panic due to race conditions o kern/153454 net[patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net[em] em interface use 100% cpu o kern/153244 net[em] em(4) fails to send UDP to port 0x o kern/152893 net[netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net[em] tftpd (and likely other udp traffic) fails over e o kern/152828 net[em] poor performance on 8.1, 8.2-PRE o kern/152569 net[net]: Multiple ppp connections and routing table prob o kern/152360 net[dummynet] [panic] Crash related to dummynet. o kern/152235 net[arp] Permanent local ARP entries are not properly upd o kern/152141 net[vlan] [patch] encapsulate vlan in ng_ether before out o kern/151690 net[ep] network connectivity won't work until dhclient is o kern/151681 net[nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net[igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net[ixgbe][igb] Panic when packets are dropped with heade o bin/150642 netnetstat(1) doesn't print anything for SCTP sockets o kern/150557 net[igb] igb0: Watchdog timeout -- resetting o kern/150251 net[patch] [ixgbe] Late cable insertion broken
Re: SNMP Network Auto Discovery software ... ?
On Wed, Apr 27, 2011 at 03:55:11PM -0300, Marc G. Fournier wrote: > > Would like to find something that runs on FreeBSD that I can use to map > our network, preferrably dumping to a database, and grabbing > information like: interface / ip / cpus / hostname, etc ... > > Server needs to run on FreeBSD ... needs to be able to commuicate, via > SNMP, with Windows, Cisco, Linux, FreeBSD, NetApp Filers, etc ... > > Would like it to be able to generate an overall map of our network, but, > also, be able to use it as a basis for keeping stuff liek nagios / cacti > up to date ... > > Web based interface into the database would be nice ... > > Is there anything like this available that runs on FreeBSD that ppl are > happily using? net-mgmt/scotty3 in ports used to have a network discovery mode. Haven't used it in years but it may be worth a look. Gary ___ 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: SNMP Network Auto Discovery software ... ?
On Wed, Apr 27, 2011 at 1:55 PM, Marc G. Fournier wrote: > > Would like to find something that runs on FreeBSD that I can use to map our > network, preferrably dumping to a database, and grabbing information like: > interface / ip / cpus / hostname, etc ... > > Server needs to run on FreeBSD ... needs to be able to commuicate, via > SNMP, with Windows, Cisco, Linux, FreeBSD, NetApp Filers, etc ... > > Would like it to be able to generate an overall map of our network, but, > also, be able to use it as a basis for keeping stuff liek nagios / cacti up > to date ... > > Web based interface into the database would be nice ... > > Is there anything like this available that runs on FreeBSD that ppl are > happily using? > I've used OpenNMS and zabbix on FreeBSD servers. I liked the OpenNMS interface(restful) better than zabbix for several reasons, but ultimately the fact it's java based and resource intensive required me to go with zabbix. Zabbix is good too, except for some annoying, non-critical interface bugs. -- Adam Vande More ___ 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: SNMP Network Auto Discovery software ... ?
Nailed it, thank you ... I've used this one in the past, and it was fantastic then .. .couldn't recall the name, and when I did a 'grep -i snmp' in the descr files under net-mgmt, wasn't finding that one :( Thx ... On Mon, 2 May 2011, Gary Palmer wrote: On Wed, Apr 27, 2011 at 03:55:11PM -0300, Marc G. Fournier wrote: Would like to find something that runs on FreeBSD that I can use to map our network, preferrably dumping to a database, and grabbing information like: interface / ip / cpus / hostname, etc ... Server needs to run on FreeBSD ... needs to be able to commuicate, via SNMP, with Windows, Cisco, Linux, FreeBSD, NetApp Filers, etc ... Would like it to be able to generate an overall map of our network, but, also, be able to use it as a basis for keeping stuff liek nagios / cacti up to date ... Web based interface into the database would be nice ... Is there anything like this available that runs on FreeBSD that ppl are happily using? net-mgmt/scotty3 in ports used to have a network discovery mode. Haven't used it in years but it may be worth a look. Gary Marc G. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.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: interface ip arp
Hi,
On Mon, May 2, 2011 at 4:03 AM, Li, Qing wrote:
> Please give this patch a try for IPv4 ARP
>
> http://people.freebsd.org/~qingli/arp2.patch
>
Your patch works; the manually added address is kept upon a up/down/up
transition. However, the interface address is still flush, which I
find inconsistent with it being marked 'permanent'.
- Arnaud
> --Qing
>
>
> From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
> of Li, Qing
> Sent: Monday, May 02, 2011 12:45 AM
> To: Arnaud Lacombe
> Cc: freebsd-net@freebsd.org; Ingo Flaschberger
> Subject: RE: interface ip arp
>
> Your patch doesn't work because the in_lltable_prefix_free() is a generic
> function.
>
> The static entries are kept only when issuing if-down command, however, if
> the interface
> address is being removed, permanent static entries are gone and have to be
> reinstalled.
>
> I already have a working patch for IPv4, just going over the IPv6 code.
>
> I will post the patch in a few minutes.
>
> -- Qing
>
>
> From: Arnaud Lacombe [lacom...@gmail.com]
> Sent: Monday, May 02, 2011 12:41 AM
> To: Li, Qing
> Cc: Ingo Flaschberger; freebsd-net@freebsd.org
> Subject: Re: interface ip arp
>
> Hi,
>
> On Sun, May 1, 2011 at 10:50 PM, Li, Qing wrote:
>> jeez, this bug has been around for quite a while ...
>>
>> Please try patch at http://people.freebsd.org/~qingli/arp.patch
>>
> d'oh!... Concerning Ingo's bug, your patch do the job, my report was
> bad, 4.9-RELEASE and 7.x show the same behavior:
>
> # uname -a
> FreeBSD server 7.1-RELEASE-p13 FreeBSD 7.1-RELEASE-p13
> # ifconfig em0 up 192.168.45.200/24
> # arp -n 192.168.45.200
> ? (192.168.45.200) at 00:03:2d:16:6e:fc on em0 permanent [ethernet]
> # ifconfig em0 down
> # arp -n 192.168.45.200
> 192.168.45.200 (192.168.45.200) -- no entry
> # ifconfig em0 up
> # arp -n 192.168.45.200
> 192.168.45.200 (192.168.45.200) -- no entry
>
> The behavioral change I noticed is that permanent address (manually
> added) in the ARP table are flushed along with all other addresses on
>>8.x (cf. the script output of my previous mail) while they are kept
> in the cache on <7.x during a down/up transition. The following patch:
>
> diff --git a/sys/netinet/in.c b/sys/netinet/in.c
> index 1012012..27e44a2 100644
> --- a/sys/netinet/in.c
> +++ b/sys/netinet/in.c
> @@ -1372,6 +1372,8 @@ in_lltable_prefix_free(struct lltable *llt,
>
> for (i=0; i < LLTBL_HASHTBL_SIZE; i++) {
> LIST_FOREACH_SAFE(lle, &llt->lle_head[i], lle_next, next) {
> + if (lle->la_flags & LLE_STATIC)
> + continue;
> if (IN_ARE_MASKED_ADDR_EQUAL((struct
> sockaddr_in *)L3_ADDR(lle),
> pfx, msk)) {
>
> partially restores the old behavior. Only partially as before 8.x,
> interface addresses were not marked as 'permanent'. You could manually
> add a 'permanent' entry for this address in such a way it would
> survive the down/up transition. In 8.x, the interface address is
> marked as 'permanent', but is removed explicitly by arp_ifscrub(). So
> even the above change would not work for the interface address.
>
> Shouldn't this address be removed later when "removing all L2 entries
> on the given prefix", in which case it would not have to be re-added
> again, if marking it 'permanent' is deliberate ?
>
> Thanks,
> - Arnaud
> ___
> 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: collisions on tun interfaces ...
On Sun, May 01, 2011 at 06:49:47PM +0300, Zeus V Panchenko wrote: > Adrian Chadd (adr...@freebsd.org) [11.05.01 09:09] wrote: > > On 1 May 2011 04:43, YongHyeon PYUN wrote: > > > > > It's tunable. Set net.link.ifqmaxlen. > > > > I know it's tunable at boot time; I mean why is it that low by default? > > > > and what will be acceptable value for ASDL connections 8 and more MBit/s? > Maybe that depends on traffic pattern. I agree default value is too low but I don't know what would be best default value since I don't have experimentation data. Note, most non-pseudo drivers do not rely on the tunable. ___ 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: collisions on tun interfaces ...
On Fri, Apr 29, 2011 at 11:28:07AM -0700, YongHyeon PYUN wrote: > On Fri, Apr 29, 2011 at 12:52:31PM +0300, Zeus V Panchenko wrote: > > Hi, > > > > may somebody epxplain it for me, what can cause collisions on tun > > interfaces created by ppp(8) and openvpn? > > > > > uname -a > > FreeBSD 8.2-STABLE #0 i386 > > > > > netstat -i > > NameMtu Network Address Ipkts Ierrs IdropOpkts > > Oerrs Coll > > tun0 1492 18940349 0 0 15737760 > > 0 45668 > > tun0 1492 A.B.C.D A-B-C-D.domain 15623965 - - 12429351 > > - - > > tun1 1500 12721670 0 0 9957662 > > 0 11161 > > tun1 1500 E.F.G.H E-F-G-H.vpn 6454 - - > > 445751 - - > > > > > > rl0: flags=8843 metric 0 mtu 1500 > > options=3808 > > ether 00:30:4f:67:cf:81 > > media: Ethernet autoselect (100baseTX ) > > status: active > > tun0: flags=8051 metric 0 mtu 1492 > > options=8 > > inet A.B.C.D --> A1.B1.C1.D1 netmask 0x > > Opened by PID 3943 > > tun1: flags=8051 metric 0 mtu 1500 > > options=8 > > inet E.F.G.H --> E1.F1.G1.H1 netmask 0x > > Opened by PID 1387 > > > > tun0 is created by ppp(8) > > > > in /etc/ppp.conf is: > > default: > > set log Phase Chat LCP IPCP CCP tun command > > set server /var/run/ppp/internet "" 0177 > > set device PPPoE:rl0 > > set speed sync > > enable lqr echo > > set lqrperiod 30 > > set login > > set ctsrts off > > add default HISADDR > > set timeout 0 > > set redial 0 0 > > set cd 5 > > > > tun1 is created by OpenVPN with configuration: > > client > > dev tun1 > > proto udp > > ... > > > > so, what can cause the collisions and can i fix them? > > > > It seems tun(4) just increments collision counter whenever it > can't enqueue packet. Because it's not collision at all I think > it's a bug that had been there from day 1. Just nuking updating the > counter will address the issue. You still can get the previous > collision counter of tun(4) with d option of netstat which shows > number of packets dropped due to send queue full. If there is no objection, I'll commit it in this week. ___ 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: collisions on tun interfaces ...
It's tunable. Set net.link.ifqmaxlen. I know it's tunable at boot time; I mean why is it that low by default? and what will be acceptable value for ASDL connections 8 and more MBit/s? Maybe that depends on traffic pattern. I agree default value is too low but I don't know what would be best default value since I don't have experimentation data. Note, most non-pseudo drivers do not rely on the tunable. perhaps to mention the net.link.ifqmaxlen tuneable and symptoms at tun manpage? Kind regards, Ingo Flaschberger ___ 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/156667: [em] em0 fails to init on CURRENT after March 17
Old Synopsis: em0 fails to init on CURRENT after March 17 New Synopsis: [em] em0 fails to init on CURRENT after March 17 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 3 06:12:14 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=156667 ___ 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/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions
Old Synopsis: ipfw/dummynet: performance improvement and several extensions New Synopsis: [ipfw] [dummynet] [patch]: performance improvement and several extensions Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 3 06:50:31 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=156770 ___ 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"
