Re: IPv6 accept_rtadv + bfe0
On Tuesday, October 18, 2011 11:16:57 pm Bjoern A. Zeeb wrote: On 18. Oct 2011, at 20:00 , Johann Hugo wrote: Hi The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in rc.conf it does nothing. grep bfe /etc/rc.conf ifconfig_bfe0=DHCP accept_rtadv ifconfig_bfe0=DHCP ifconfig_bfe0_ipv6=inet6 accept_rtadv That works, but what is the function of ipv6_activate_all_interfaces=YES in rc.conf Johann ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
IPv6 accept_rtadv + bfe0
Hi The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in rc.conf it does nothing. grep bfe /etc/rc.conf ifconfig_bfe0=DHCP accept_rtadv ifconfig bfe0 bfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=80008VLAN_MTU,LINKSTATE ether 00:1d:09:a7:41:a8 inet6 fe80::21d:9ff:fea7:41a8%bfe0 prefixlen 64 scopeid 0x9 inet 146.64.80.134 netmask 0xff00 broadcast 146.64.80.255 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active ifconfig bfe0 inet6 accept_rtadv ifconfig bfe0 bfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=80008VLAN_MTU,LINKSTATE ether 00:1d:09:a7:41:a8 inet6 fe80::21d:9ff:fea7:41a8%bfe0 prefixlen 64 scopeid 0x9 inet 146.64.80.134 netmask 0xff00 broadcast 146.64.80.255 inet6 2001:4200:7000:100:21d:9ff:fea7:41a8 prefixlen 64 autoconf nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active uname -a FreeBSD pcbsd-615 9.0-BETA3 FreeBSD 9.0-BETA3 grep v6 /etc/rc.conf ipv6_activate_all_interfaces=YES grep rtadv /etc/sysctl.conf net.inet6.ip6.accept_rtadv=1 Is there anything else that I need to do ? Johann ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
atheros (ath) - duplicate packets with long distance link
Hi I am getting a lot of duplicate packets on my long distance wireless link, but on my identical link in the Lab everything works fine. (DWL-AG520 adapter). The one adapter is configured in hostap mode, and the other one as a client, both in 11b mode. ( current 5.2-BETA - 24 Nov ) I know there are a lot of CRC errors on the long distance wireless link, but if I swap the hostap device with a 802.11b Lucent AP (over the same distance) then I don't get any duplicate packets. atheros# ./athstats 1 beacon miss interrupts 52 tx management frames 106 tx frames discarded prior to association 4 tx failed 'cuz too many retries 88 long on-chip tx retries 45 tx frames with no ack marked 62 tx frames with short preamble 58979 rx failed 'cuz of bad CRC 11 rx failed 'cuz decryption 1511778 rx failed 'cuz of PHY err 1495162 OFDM timing 16614 CCK timing 2 CCK restart 8 periodic calibrations 40 rate control checks 1 rate control dropped xmit rate AP = DWL-AG520 - HostAP atheros# ping -s 1450 192.168.10.10 PING 192.168.10.10 (192.168.10.10): 1450 data bytes 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=27.432 ms 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=101.903 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=178.306 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=15.965 ms 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=96.968 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=216.500 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=27.865 ms 1458 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=107.189 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=19.401 ms 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=138.412 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=213.613 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=4 ttl=64 time=57.855 ms 1458 bytes from 192.168.10.10: icmp_seq=4 ttl=64 time=134.540 ms (DUP!) AP = Lucent AP-1000 PING 146.64.86.3 (146.64.86.3): 56 data bytes 64 bytes from 146.64.86.3: icmp_seq=0 ttl=64 time=81.586 ms 64 bytes from 146.64.86.3: icmp_seq=1 ttl=64 time=4.358 ms 64 bytes from 146.64.86.3: icmp_seq=2 ttl=64 time=2.837 ms 64 bytes from 146.64.86.3: icmp_seq=3 ttl=64 time=3.878 ms 64 bytes from 146.64.86.3: icmp_seq=4 ttl=64 time=3.889 ms 64 bytes from 146.64.86.3: icmp_seq=5 ttl=64 time=5.677 ms 64 bytes from 146.64.86.3: icmp_seq=6 ttl=64 time=3.915 ms 64 bytes from 146.64.86.3: icmp_seq=7 ttl=64 time=3.945 ms 64 bytes from 146.64.86.3: icmp_seq=8 ttl=64 time=5.720 ms Regards Johann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) - duplicate packets with long distance link
On Monday 24 November 2003 21:22, Sam Leffler wrote: tcpdump -e -i ath0 -y IEEE802_11 and verify the 802.11 frames are actual duplicates. They should not be unless there's a bug in the duplicate suppression logic in the 802.11 code. The packets are definately from the same host. Will it help if I recompile with AR_DEBUG turned on ? PING 192.168.10.10 (192.168.10.10): 56 data bytes 64 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=4.373 ms 64 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=74.278 ms (DUP!) 64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=2.646 ms 64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=83.930 ms (DUP!) 64 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=2.631 ms 64 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=4.127 ms atheros# tcpdump -e -i ath0 -y IEEE802_11 proto ICMP tcpdump: data link type DLT_IEEE802_11 tcpdump: listening on ath0 00:04:57.452451 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 192.168.10.10: icmp: echo request 00:04:57.455152 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.457598 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.461559 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.467485 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.478495 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.483984 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.490683 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.509604 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.531031 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.546951 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.557694 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.469354 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 192.168.10.10: icmp: echo request 00:04:58.473004 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.476335 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.488546 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.508876 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.521360 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.528470 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.537460 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.547434 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.551423 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:59.479303 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 192.168.10.10: icmp: echo request Johann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atheros (ath) driver - media option
Hi I've just started playing with some D-link DWL-AG520 PCI adapters with the Atheros 5212 chipset. The one adapter is configured in hostap mode, and the other one as a client. When I set the media option to a lower speed that the maximum, then it only works for the adapter in client mode, but it does not seem to work for the adapter that is in hostap mode. I've tried it on 11a, 11b and 11g at all the supported rates, but the tx speed always defaults to the maximum for the selected mode. I'm using -current from September 07th. e.g. ifconfig ath0 media DS/1Mbps mode 11b mediaopt hostap ssid ath101 channel 11 wicontrol ath0 NIC serial number: [ ] Station name: [ atheros.icomtek.csir.co.za ] SSID for IBSS creation: [ ath101 ] Current netname (SSID): [ ath101 ] Desired netname (SSID): [ ath101 ] Current BSSID: [ 00:05:5d:95:f0:04 ] Channel list: [ ffe ] IBSS channel: [ 11 ] Current channel:[ 11 ] Comms quality/signal/noise: [ 0 8 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc):[ 6 ] MAC address:[ 00:05:5d:95:f0:04 ] TX rate (selection):[ 1 ] TX rate (actual speed): [ 11 ] -- RTS/CTS handshake threshold:[ 2312 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys:[ ][ ][ ][ ] Is this correct, or should the tx rate (actual speed) be the same as the media setting ? Regards Johann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver - media option
On Wednesday 12 November 2003 00:54, Sam Leffler wrote: Not sure what you're trying to accomplish by setting the media when operating in hostap mode. It should be ignored, but I'm not sure exactly what will happen. Locking the tx rate on the client side makes more sense and should be honored correctly. Maybe I should give you some more info here. We currently have a 30km wireless link to a remote site: Lucent/orinoco AP -30km - FreeBSD client with Lucent adapter. The problem is that over that distance the SIFS counter expires on most of the packets before we receive a ACK on the other side. So the throughput is way down. I've decided to installed a parallel/experimental link on another frq. so that I can play around with the atheros driver/cards and also 11g. The second link looks something like this: FreeBSD/HostAP/Atheros - 30km -- FreeBSD/Soekris/Client/Atheros The problem is: (mode 11b media DS/1Mbps) HostAP TX = 11Mbps - 30km -Client RX at 11Mbps not OK HostAP RX at 1Mbps = OK - 30km - Client TX at 1Mbps (mode 11g media OFDM/6Mbps) HostAP TX = 54Mbps - 30km -Client RX at 54 Mbps not OK HostAP RX at 1Mbps = OK - 30km - Client RX at 54 Mbps not OK So I am trying to force the max TX rate on both ends to a lower speed. Another question: Do you have control over the SIFS counter. Is there a way to adjust the counter so that it will be more tolerant to longer links, or is it possible to disable the ACK's for unicast packets ? http://lists.nocat.net/pipermail/nocat/2002-April/001223.html Johann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mouse madness under X
On Tue, 08 Aug 2000, you wrote: This is a problem I've had starting with the last couple of builds. If I switch from X to a virtual console, then back again, *sometimes* the mouse cursor will be stuck on the right hand side of the screen. I can move it up and down, but not side to side. The way to cure the problem is to go back to the console, wait a few seconds, then come back into X. The problem goes away. At first I thought this was a problem with my wm, but I tried a different one and got the same result. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message I've experienced the same mouse problem yesterday. I eventually had to restarted moused to cure the problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
