Problems in using SCTP CMT
Hi, We have some problems when we tried to send data using CMT-SCTP. Actually, we are not sure if we do enable CMT functionalities. We set up two PCs with FreeBSD-7.0. Each PC has two NICs and two IPs. One is public and the other is private. We wrote simple FTP server and client programs. On both sides, local addresses are bound as INADDR_ANY. According to http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-14#section-4.1.5 , if we bind INADDR_ANY and then call connect(), the multi-homing capability of SCTP is automatically enabled. Further, we also turn on sysctl states by setting sysctl net.inet.sctp.cmt_pf=1 sysctl net.inet.sctp.cmt_use_dac=1 sysctl net.inet.sctp.cmt_on_off=1 Then we start transmission and capture the traffics. Unfortunately, the captured packet shows data were transmitted on primary path and there were only heartbeat/HB ACKs on the other path. To our knowledge, to use CMT, the only things we have to do is to establish a multihomed association, and turn on the sysctl options. Can anyone point out something we did wrong or steps we missed? Thanks in advance. ___ 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 f bin/132911 netip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net[ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net[wlan] 802.1x broken after SVN rev 189592 o conf/132851 net[fib] [patch] allow to setup fib for service running f o bin/132798 net[patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net[ifmib] [panic] panic in net/if_mib.c o kern/132722 net[ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net[lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net[libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net[ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net[xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net[iwn] iwn drivers don't support setting country o kern/132554 net[ipl] There is no ippool start script/ipfilter magic t o kern/132354 net[nat] Getting some packages to ipnat(8) causes crash o kern/132342 net[ndis] [patch] incorrect number used in for loop; fix o kern/132285 net[carp] alias gives incorrect hash in dmesg o kern/132277 net[crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net[patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net[carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net[ndis] ndis keeps dropping the link o kern/131776 net[wi] driver fails to init o kern/131753 net[altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net[socket] [patch] Update for regression/sockets/unix_cm o kern/131549 netifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net[netinet] [patch] kernel does allow manipulation of su o bin/131365 netroute(8): route add changes interpretation of network o kern/131310 net[netgraph] [panic] 7.1 panics with mpd netgraph interf o kern/131162 net[ath] Atheros driver bugginess and kernel crashes o kern/131153 net[iwi] iwi doesn't see a wireless network f kern/131087 net[ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net[ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net[nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net[rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net[ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net[wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net[patch] ppp(8) fails to correctly set routes o kern/130109 net[ipfw] Can not set fib for packets originated from loc f kern/130059 net[panic] Leaking 50k mbufs/hour o kern/129750 net[ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net[nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net[ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net[ipsec] [panic] double fault / stack overflow o kern/129508 net[carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net[xl] [patch] xl0 watchdog timeout o kern/129219 net[ppp] Kernel panic when using kernel mode ppp o kern/129135 net[vge] vge driver on a VIA mini-ITX not working o bin/128954 netifconfig(8) deletes valid routes o kern/128917 net[wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net[msk] if_msk page fault while in kernel mode o kern/128840 net[igb] page fault under load with igb/LRO o bin/128602 net[an] wpa_supplicant(8) crashes with an(4) o kern/128598 net[bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net[nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net[request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net[patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 netwpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net[tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net[ixgbe] [patch] wrong error counting o kern/127826 net[iwi] iwi0 driver has reduced performance and connecti o kern/127815 net[gif] [patch] if_gif does not set vlan attributes from o kern/127724 net[rtalloc] rtfree: 0xc5a8f870
Re: Problems in using SCTP CMT
H Andrew, what you describe is correct. Are there actually multiple addresses changed within the INIT/INIT-ACK chunk? If yes, you have done everything correctly. The interesting thing: I also noticed that there are CMT problems on FreeBSD 8.0 Current. Randall Stewart and myself have started debugging the problem yesterday... We'll send you a notice, once we have found the problem and fixed it. Best regards Michael On Mar 23, 2009, at 3:20 AM, Andrew Chen wrote: Hi, We have some problems when we tried to send data using CMT-SCTP. Actually, we are not sure if we do enable CMT functionalities. We set up two PCs with FreeBSD-7.0. Each PC has two NICs and two IPs. One is public and the other is private. We wrote simple FTP server and client programs. On both sides, local addresses are bound as INADDR_ANY. According to http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-14#section-4.1.5 , if we bind INADDR_ANY and then call connect(), the multi-homing capability of SCTP is automatically enabled. Further, we also turn on sysctl states by setting sysctl net.inet.sctp.cmt_pf=1 sysctl net.inet.sctp.cmt_use_dac=1 sysctl net.inet.sctp.cmt_on_off=1 Then we start transmission and capture the traffics. Unfortunately, the captured packet shows data were transmitted on primary path and there were only heartbeat/HB ACKs on the other path. To our knowledge, to use CMT, the only things we have to do is to establish a multihomed association, and turn on the sysctl options. Can anyone point out something we did wrong or steps we missed? Thanks in advance. ___ 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: Problems with inward PPTP tunnel
Just a quick followup: I've finally figured out a workaround. A hack, to be sure, but a workaround nonetheless. I've created a shell script called /etc/ppp/pppfix, which looks like this: #!/bin/sh # Fix up PPP routes sleep 1; logger -i -t ppp Fixing route: route change -host $1 $2 -ifp $3 route change -host $1 $2 -ifp $3 I invoke this from the relevant section of /etc/ppp.linkup with the line !bg /etc/ppp/pppfix HISADDR MYADDR INTERFACE Note that the "sleep" may not be absolutely necessary, but it seems like a good idea just in case there's a race condition. I also added the following lines in the relevant section of ppp.linkdown: iface clear delete! HISADDR delete! ALL shell arp -d HISADDR quit all I found that if I did not do this, the modified route persisted after the connection terminated. The "arp -d HISADDR" should only be used if proxy arp is being done, and may not be strictly necessary; I wanted to make sure I tore down any residual proxy arp entry. Of course, all of this is an awful hack and the relevant code in userland PPP still needs to be looked at. --Brett Glass Brett, I've fixed these two issues with ppp(8), please check the PRs: bin/130159 and bin/131250. If it works for you please let a note and maybe someone commit this. Best regards, Luiz ___ 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/132342: commit references a PR
On 3/9/09, dfilter service wrote:
> The following reply was made to PR kern/132342; it has been noted by GNATS.
>
> From: dfil...@freebsd.org (dfilter service)
> To: bug-follo...@freebsd.org
> Cc:
> Subject: Re: kern/132342: commit references a PR
> Date: Mon, 9 Mar 2009 02:38:02 + (UTC)
>
> Author: sam
> Date: Mon Mar 9 02:37:52 2009
> New Revision: 189550
> URL: http://svn.freebsd.org/changeset/base/189550
>
> Log:
>Fix TXPMGT handling:
>o correct dBm<->mW conversion logic
>o set net80211 TXPMGT capability only if driver reports it is capable
>
>PR:kern/132342
>Submitted by: "Paul B. Mahol"
>
> Modified:
>head/sys/dev/if_ndis/if_ndis.c
>
> Modified: head/sys/dev/if_ndis/if_ndis.c
> ==
> --- head/sys/dev/if_ndis/if_ndis.c Mon Mar 9 02:34:02 2009
> (r189549)
> +++ head/sys/dev/if_ndis/if_ndis.c Mon Mar 9 02:37:52 2009
> (r189550)
> @@ -102,7 +102,7 @@ SYSCTL_INT(_hw_ndisusb, OID_AUTO, halt,
> "Halt NDIS USB driver when it's attached");
>
> /* 0 - 30 dBm to mW conversion table */
> -const uint16_t dBm2mW[] = {
> +static const uint16_t dBm2mW[] = {
> 1, 1, 1, 1, 2, 2, 2, 2, 3, 3,
> 3, 4, 4, 4, 5, 6, 6, 7, 8, 9,
> 10, 11, 13, 14, 16, 18, 20, 22, 25, 28,
> @@ -749,7 +749,7 @@ ndis_attach(dev)
> ic->ic_ifp = ifp;
> ic->ic_opmode = IEEE80211_M_STA;
> ic->ic_phytype = IEEE80211_T_DS;
> -ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS |
> IEEE80211_C_TXPMGT;
> +ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS;
> setbit(ic->ic_modecaps, IEEE80211_MODE_AUTO);
> len = 0;
> r = ndis_get_info(sc, OID_802_11_NETWORK_TYPES_SUPPORTED,
> @@ -928,6 +928,11 @@ got_crypto:
> r = ndis_get_info(sc, OID_802_11_POWER_MODE, &arg, &i);
> if (r == 0)
> ic->ic_caps |= IEEE80211_C_PMGT;
> +
> +r = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &i);
> +if (r == 0)
> +ic->ic_caps |= IEEE80211_C_TXPMGT;
> +
> bcopy(eaddr, &ic->ic_myaddr, sizeof(eaddr));
> ieee80211_ifattach(ic);
> ic->ic_raw_xmit = ndis_raw_xmit;
> @@ -2325,9 +2330,10 @@ ndis_setstate_80211(sc)
> ndis_set_info(sc, OID_802_11_POWER_MODE, &arg, &len);
>
> /* Set TX power */
> -if (ic->ic_txpowlimit < sizeof(dBm2mW)) {
> -len = sizeof(arg);
> +if ((ic->ic_caps & IEEE80211_C_TXPMGT) &&
> +ic->ic_txpowlimit < (sizeof(dBm2mW) / sizeof(dBm2mW[0]))) {
> arg = dBm2mW[ic->ic_txpowlimit];
> +len = sizeof(arg);
> ndis_set_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len);
> }
>
> @@ -2798,11 +2804,10 @@ ndis_getstate_80211(sc)
> }
>
> /* Get TX power */
> -len = sizeof(arg);
> -rval = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len);
> -
> -if (!rval) {
> -for (i = 0; i < sizeof(dBm2mW); i++)
> +if (ic->ic_caps & IEEE80211_C_TXPMGT) {
> +len = sizeof(arg);
> +ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len);
> +for (i = 0; i < (sizeof(dBm2mW) / sizeof(dBm2mW[0])); i++)
> if (dBm2mW[i] >= arg)
> break;
> ic->ic_txpowlimit = i;
> ___
> svn-src-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-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"
>
Looks to be still open, should get closed. I dont expect anybody is
going to MFC this and similar changes.
--
Paul
___
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: Problems with inward PPTP tunnel
Luis: It looks as if bin/130159 ought to fix the problem I am having. I see that it sets the "IFP" flag in the route update request and specifies the interface, which ought to be what is needed. I am not seeing problems with proxy ARP, but that may be because I am running 7.1-RELEASE and not -STABLE. The patch in bin/131250 should probably also be committed to keep things working. --Brett Glass At 05:06 AM 3/23/2009, Luiz Otavio O Souza wrote: Brett, I've fixed these two issues with ppp(8), please check the PRs: bin/130159 and bin/131250. If it works for you please let a note and maybe someone commit this. Best regards, Luiz ___ 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/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver
On 3/21/09, lini...@freebsd.org wrote: > Old Synopsis: NDIS kernel crash on load BCM4321 AGN driver > New Synopsis: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Sat Mar 21 15:25:09 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=132889 > ___ > 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" > Cause of this panic may already been fixed in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118439 But it still unknown why attach failed, so OP could provide more info with changing sysctl debug.ndis to 1. -- Paul ___ 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"
netgraph modules won't unload after use
Thanks for looking at it Julian, I still can't figure out which resource it needs to release before exiting. I've replaced the raw ether_input routine on the interface to continue my module until I can figure out what's wrong with my netgraph glue. Again this minimal module demonstrates the trouble, I'd appreciate it if some sage could say "there's your trouble" http://pastebin.com/m31b6ece6 netgraph modules won't unload after use Julian Elischer julian at elischer.org Wed Mar 18 09:16:15 PDT 2009 * Previous message: netgraph modules won't unload after use * Next message: kern/126469: [fxp] [panic] fxp(4) related kernel panic * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Ash Gokhale wrote: > I'm developing a kernel module that will be doing inspection and needed > access to raw network frames, > so I turned to netgraph as the solution.However it seems that netgraph > will not permit a module > to unload once it's participated in a mkpeer/connect operation. > Rebooting to remove a module is > angrymaking (not like mtx/sleep crashes). > > This going into the kernel because my bpf based userland stuff is > probably not going to hold up to the packet rate. > > Should I file a PR? Or is there magic in the documentation I havn't found? > > > I've observed the trouble in 7.0 release, and tonight's 7_RELENG, with > GENERIC + WITNESS/INVARIANTS > > The module code ( cobbled together from netgraph/ng_sample.c / ng_echo.c) > http://pastebin.com/m31b6ece6 > > The module loads and unloads fine until connected to a netgraph hook: hmm they are supposed to, and they did in the past.. let me check... root at trafmon1:kldload ng_ether root at trafmon1:ifconfig bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:43:30:fb:8a inet 10.7.2.3 netmask 0xff00 broadcast 10.7.2.255 media: Ethernet autoselect (100baseTX ) status: active bge1: flags=8802 metric 0 mtu 1500 options=9b ether 00:11:43:30:fb:8b media: Ethernet autoselect (none) status: no carrier fxp0: flags=8843 metric 0 mtu 1500 options=b ether 00:0e:0c:62:aa:14 inet 10.7.0.101 netmask 0xff00 broadcast 10.7.0.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff00 root at trafmon1:ngctl + list There are 4 total nodes: Name: bge0Type: ether ID: 0002 Num hooks: 0 Name: bge1Type: ether ID: 0003 Num hooks: 0 Name: ngctl4252 Type: socket ID: 0005 Num hooks: 0 Name: fxp0Type: ether ID: 0004 Num hooks: 0 + mkpeer bge0: hole lower hook + list There are 5 total nodes: Name:Type: holeID: 0006 Num hooks: 1 Name: bge0Type: ether ID: 0002 Num hooks: 1 Name: bge1Type: ether ID: 0003 Num hooks: 0 Name: ngctl4252 Type: socket ID: 0005 Num hooks: 0 Name: fxp0Type: ether ID: 0004 Num hooks: 0 + shutdown [6]: + list There are 4 total nodes: Name: bge0Type: ether ID: 0002 Num hooks: 0 Name: bge1Type: ether ID: 0003 Num hooks: 0 Name: ngctl4252 Type: socket ID: 0005 Num hooks: 0 Name: fxp0Type: ether ID: 0004 Num hooks: 0 + quit root at trafmon1:kldstat -v Id Refs AddressSize Name 1 36 0xc040 6a9c28 kernel (/boot/kernel/kernel) [...] 71 0xccb16000 4000 ng_ether.ko (/boot/kernel/ng_ether.ko) Contains modules: Id Name 246 ng_ether 81 0xccb1b000 2000 ng_hole.ko (/boot/kernel/ng_hole.ko) Contains modules: Id Name 247 ng_hole root at trafmon1:klunload ng_hole klunload: Command not found. root at trafmon1:kldunload ng_hole root at trafmon1:kldunload ng_ether kldunload: can't unload file: Device busy root at trafmon1:kldstat -v Id Refs AddressSize Name 1 36 0xc040 6a9c28 kernel (/boot/kernel/kernel) [...] 71 0xccb16000 4000 ng_ether.ko (/boot/kernel/ng_ether.ko) Contains modules: Id Name 246 ng_ether root at trafmon1: this is expected. ng-ether is not unloadable as the connections are too complicated to unwind easily.. one day root at trafmon1: >> Stop in /root/tmp/food.ko. >> Exit 1 >> #Mar 18 03:14:31 kernel: quiesced >> :ro:~/tmp/food.ko:3:14:31:32 >> Mar 18 03:14:31 kernel: foodmod unloaded > > > Seems that I can't unload some of the other netgraph types either ( it's > not just me): > >> #kldunload ng_ether >> :ro:~/tmp/food.ko:3:24:07:41 >> kldunload: can't unload file
Re: Problems with inward PPTP tunnel
P.S. -- Just tried the patches in bin/130159 and bin/131250 and they do seem to function properly. Please commit. --Brett Glass ___ 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: bin/130159: [patch] ppp(8) fails to correctly set routes
The following reply was made to PR bin/130159; it has been noted by GNATS. From: Brett Glass To: bug-follo...@freebsd.org, loos...@gmail.com Cc: Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes Date: Mon, 23 Mar 2009 11:48:50 -0600 Patch appears to work properly. Please commit. ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) below are some information concerning the AP, ifconfig ... the output of the tcpdump is on my server as http://www.unixarea.de/ath-current.txt let me know if you need more information; HIH matthias info about AP: Siemens Gigaset SE 505 dsl/cable S30853-S1006-R107-3 (handwritten label says: "this is no DSL router; IP 192.168.2.1") as DSL-modem some Fritz!Box is connected to this box http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ifconfig -a ath0: flags=8843 metric 0 mtu 2290 ether 00:15:af:b2:ae:e6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:15:af:b2:ae:e6 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g status: associated ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL # tcpdump -n -i ath0 -y IEEE802_11_RADIO 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.750225 43659844us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] ... full log see: http://www.unixarea.de/ath-current.txt ___ 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: Problems in using SCTP CMT
Michael and I have developed a fix here at the IETF. at least with pf=0 dac=1 and off=1 We will next test with pf.. I will commit the code to Head... I can also send you a 7.x version tarball.. not sure if it will compile (it will work for 7.1 I know for sure) Let me know if you want such a tar.. R On Mar 23, 2009, at 6:20 AM, Andrew Chen wrote: Hi, We have some problems when we tried to send data using CMT-SCTP. Actually, we are not sure if we do enable CMT functionalities. We set up two PCs with FreeBSD-7.0. Each PC has two NICs and two IPs. One is public and the other is private. We wrote simple FTP server and client programs. On both sides, local addresses are bound as INADDR_ANY. According to http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-14#section-4.1.5 , if we bind INADDR_ANY and then call connect(), the multi-homing capability of SCTP is automatically enabled. Further, we also turn on sysctl states by setting sysctl net.inet.sctp.cmt_pf=1 sysctl net.inet.sctp.cmt_use_dac=1 sysctl net.inet.sctp.cmt_on_off=1 Then we start transmission and capture the traffics. Unfortunately, the captured packet shows data were transmitted on primary path and there were only heartbeat/HB ACKs on the other path. To our knowledge, to use CMT, the only things we have to do is to establish a multihomed association, and turn on the sysctl options. Can anyone point out something we did wrong or steps we missed? Thanks in advance. ___ 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" -- Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Matthias Apitz wrote: I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. We have yet to produce a tcpdump to catch it 'in the act' and observe the DLT_IEEE80211 traffic when it actually happens, I have only seen the symptoms. The AP does not show the EeePC units as being associated any more at this point, but ath0 still shows 'status: associated'. The AP involved is a Netgear WG602 V2, and is running the vendor's firmware. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). cheers BMS ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce M Simpson To: Matthias Apitz Cc: bug-follo...@freebsd.org, Sam Leffler , freebsd-net@freebsd.org, "Sean C. Farley" Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 18:44:42 + Matthias Apitz wrote: > I went today evening with my EeePC and CURRENT on USB key > to that Greek restaurant; DHCP does not get IP in CURRENT either; > this is somehow good news, isn't it :-) > This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. We have yet to produce a tcpdump to catch it 'in the act' and observe the DLT_IEEE80211 traffic when it actually happens, I have only seen the symptoms. The AP does not show the EeePC units as being associated any more at this point, but ath0 still shows 'status: associated'. The AP involved is a Netgear WG602 V2, and is running the vendor's firmware. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). cheers BMS ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
El día Monday, March 23, 2009 a las 06:44:42PM +, Bruce M Simpson escribió: > Matthias Apitz wrote: > >I went today evening with my EeePC and CURRENT on USB key > >to that Greek restaurant; DHCP does not get IP in CURRENT either; > >this is somehow good news, isn't it :-) > > > > This may be orthogonal, but: >A lab colleague and I have been seeing a sporadic problem where the > ath0 exhibits the symptoms of being disassociated from its AP. We are > running RELENG_7 on the EeePC 701 since the open source HAL merge. >In the behaviour we're seeing, we don't see any problem with the > initial dhclient run, the ath0 just seems to get disassociated within > 5-10 minutes of associating. > > If we leave 'ping ' running in the background, we don't > see this problem. ... This must be a complete different problem, because in my case the AP stays (at least what ifconfig shows) always associated, but don't get offered IP addr; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Matthias Apitz wrote: I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) below are some information concerning the AP, ifconfig ... the output of the tcpdump is on my server as http://www.unixarea.de/ath-current.txt let me know if you need more information; HIH matthias info about AP: Siemens Gigaset SE 505 dsl/cable S30853-S1006-R107-3 (handwritten label says: "this is no DSL router; IP 192.168.2.1") as DSL-modem some Fritz!Box is connected to this box http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ifconfig -a ath0: flags=8843 metric 0 mtu 2290 ether 00:15:af:b2:ae:e6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:15:af:b2:ae:e6 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g status: associated ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL # tcpdump -n -i ath0 -y IEEE802_11_RADIO 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.750225 43659844us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] ... full log see: http://www.unixarea.de/ath-current.txt If you have the raw pcap capture please provide a url to it. From the log it appears you're sending+receiving wep-encrypted frames. They keyid is the same and since you're receiving frames I have to assume the key matter is correct as otherwise the h/w would drop the frame. You can verify this by feeding the key into wireshark to check if the frame contents make sense. I'm out of ideas. About the only thing I can suggest is you setup a different ap w/ the same wep key and see if things work. If so then you know it's something this ap is doing. I can't recall when I last tested wep on HEAD but I'm pretty sure it works. I will re-test that when I get a chance. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Bruce M Simpson wrote: Matthias Apitz wrote: I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. We have yet to produce a tcpdump to catch it 'in the act' and observe the DLT_IEEE80211 traffic when it actually happens, I have only seen the symptoms. The AP does not show the EeePC units as being associated any more at this point, but ath0 still shows 'status: associated'. The AP involved is a Netgear WG602 V2, and is running the vendor's firmware. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). There are many issues with the wireless code in RELENG_7. Now that the hal is merged we can try to address them. Unfortunately the 7.2 release has just begun so it's unclear what we can get in. I'm also limited in what I'm willing to commit given that I do not run RELENG_7. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Sam Leffler To: Matthias Apitz Cc: bug-follo...@freebsd.org, freebsd-net@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 12:12:04 -0700 Matthias Apitz wrote: > I went today evening with my EeePC and CURRENT on USB key > to that Greek restaurant; DHCP does not get IP in CURRENT either; > this is somehow good news, isn't it :-) > > below are some information concerning the AP, ifconfig ... > the output of the tcpdump is on my server as > http://www.unixarea.de/ath-current.txt > let me know if you need more information; > > HIH > > matthias > > > info about AP: > Siemens Gigaset SE 505 dsl/cable > S30853-S1006-R107-3 > (handwritten label says: "this is no DSL router; IP 192.168.2.1") > as DSL-modem some Fritz!Box is connected to this box > > http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html > > > # uname -a > FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 > CET 2009 > r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC > i386 > > # ifconfig -a > ath0: flags=8843 metric 0 mtu 2290 > ether 00:15:af:b2:ae:e6 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:15:af:b2:ae:e6 > inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 > media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g > status: associated > ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 > regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 > wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS > wme burst roaming MANUAL > > > > # tcpdump -n -i ath0 -y IEEE802_11_RADIO > 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.750225 43659844us tsft 1.0 Mb/s -81dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > ... > > full log see: http://www.unixarea.de/ath-current.txt > > > If you have the raw pcap capture please provide a url to it. From the log it appears you're sending+receiving wep-encrypted frames. They keyid is the same and since you're receiving frames I have to assume the key matter is correct as otherwise the h/w would drop the frame. You can verify this by feeding the key into wireshark to check if the frame contents make sense. I'm out of ideas. About the only thing I can suggest is you setup a different ap w/ the same wep key and see if things work. If so then you know it's something this ap is doing. I can't recall when I last tested wep on HEAD but I'm pretty sure it works. I will re-test that when I get a chance. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz To: bug-follo...@freebsd.org Cc: Sam Leffler , freebsd-net@freebsd.org, Bruce Simpson , "Sean C. Farley" Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 19:23:11 +0100 I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) below are some information concerning the AP, ifconfig ... the output of the tcpdump is on my server as http://www.unixarea.de/ath-current.txt let me know if you need more information; HIH matthias info about AP: Siemens Gigaset SE 505 dsl/cable S30853-S1006-R107-3 (handwritten label says: "this is no DSL router; IP 192.168.2.1") as DSL-modem some Fritz!Box is connected to this box http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ifconfig -a ath0: flags=8843 metric 0 mtu 2290 ether 00:15:af:b2:ae:e6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:15:af:b2:ae:e6 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g status: associated ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL # tcpdump -n -i ath0 -y IEEE802_11_RADIO 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.750225 43659844us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] ... full log see: http://www.unixarea.de/ath-current.txt ___ 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"
ath0 apparent silent disassociation
[Repost without attachment] OK. We've managed to reproduce this set of symptoms now in our work area. [If anyone needs to see a pcap, please Cc: me offlist.] Timebase: beginning of the pcap is in sync with a bringup from single-user mode; the tcpdump runs in the background from init whilst the system is brought up. OK, so I timed the apparent loss of connectivity as 6m 30s from that point I hit the stopwatch, to when I hit it again when the AP's Web GUI no longer shows the STA affected as being associated. Obviously such a timing is subject to human/visual jitter, and how often Netgear's firmware pulls the STA association list from the AP into the web GUI. What stands out in the pcap is that 302.291s in (almost 5m exactly), the STA (ath0) sends an IEEE 802.11 NULL frame to the AP with the PWR MGT bit set (I'm going to sleep!). This more or less coincides with a normal beacon from the Netgear AP. It does not advertise Auto Power Save Delivery (apsd), that bit is 0. This is puzzling as we don't enable power management by default. As I understand it, this may be an AP feature in some environments... I can try reproducing this with an explicit 'ifconfig ath0 -powersave' and see if it reoccurs. You'll see that after this NULL frame is sent, there is another Probe Request, and the Netgear AP does Probe Respond, but this makes no difference (I ended the capture around 150s after the NULL frame was sent). At this point we can't send traffic from the ath0, or rather, the AP is acting as though it never even heard the STA. The STA learns the AP's IP address/MAC mapping through passive ARP -- we still see broadcasts on the SSID -- but the AP has started to totally ignore the STA, and seemed to have ignored its ARP requests also. We are using MAC address ACL control with this AP, and the ath0 affected is definitely listed in its ACL table, configured up, rebooted etc. It is as though the STA is entering power saving mode when not explicitly told to, and the AP is not waking up the STA as it should. If any more information needed, or where to look, please let me know what's involved (I MFCed the change after all, so I'll help where I can until I'm on holiday this week...) My lab colleague is just working around this with 'ping ' for now, that keeps things up, as does OpenVPN... cheers BMS ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
On Mon, Mar 23, 2009 at 06:44:42PM +, Bruce M Simpson wrote: > Matthias Apitz wrote: > >I went today evening with my EeePC and CURRENT on USB key > >to that Greek restaurant; DHCP does not get IP in CURRENT either; > >this is somehow good news, isn't it :-) > > > > This may be orthogonal, but: >A lab colleague and I have been seeing a sporadic problem where the > ath0 exhibits the symptoms of being disassociated from its AP. We are > running RELENG_7 on the EeePC 701 since the open source HAL merge. >In the behaviour we're seeing, we don't see any problem with the > initial dhclient run, the ath0 just seems to get disassociated within > 5-10 minutes of associating. > > If we leave 'ping ' running in the background, we don't > see this problem. > I found doing a -bgscan before it happens, make it not happen. I now have -bgscan in my rc.conf. John -- John Hay -- john@meraka.csir.co.za / j...@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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: John Hay To: Bruce M Simpson Cc: Matthias Apitz , freebsd-net@freebsd.org, Sam Leffler , "Sean C. Farley" , bug-follo...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 22:40:50 +0200 On Mon, Mar 23, 2009 at 06:44:42PM +, Bruce M Simpson wrote: > Matthias Apitz wrote: > >I went today evening with my EeePC and CURRENT on USB key > >to that Greek restaurant; DHCP does not get IP in CURRENT either; > >this is somehow good news, isn't it :-) > > > > This may be orthogonal, but: >A lab colleague and I have been seeing a sporadic problem where the > ath0 exhibits the symptoms of being disassociated from its AP. We are > running RELENG_7 on the EeePC 701 since the open source HAL merge. >In the behaviour we're seeing, we don't see any problem with the > initial dhclient run, the ath0 just seems to get disassociated within > 5-10 minutes of associating. > > If we leave 'ping ' running in the background, we don't > see this problem. > I found doing a -bgscan before it happens, make it not happen. I now have -bgscan in my rc.conf. John -- John Hay -- john@meraka.csir.co.za / j...@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/119361: commit references a PR
The following reply was made to PR kern/119361; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/119361: commit references a PR
Date: Mon, 23 Mar 2009 20:54:04 + (UTC)
Author: marius
Date: Mon Mar 23 20:53:38 2009
New Revision: 190335
URL: http://svn.freebsd.org/changeset/base/190335
Log:
MFC: r190194
- In bge_ifmedia_upd_locked() take advantrage of LIST_FOREACH().
- If boot verbose, print asicrev, chiprev and bus type on attach.
- For PCI Express devices:
1) Adjust max read request size to 4Kbytes
2) Turn on FIFO_LONG_BURST in RDMA during bge_blockinit()
Though 1) does not seem to have much to do with the poor TX performance
observed on PCI Express bge(4), 2) does fix the problem. [1]
- Nuke the RX CPU self-diag, which prevents working cards from working
(Linux tg3 does not have this diag neither does OpenBSD's bge(4)).
The increasing of the firmware handshaking timeout to 2 retries
done as part of the original commit isn't merged as way already have a
way higher BGE_TIMEOUT of 10.
PR: 119361 [1]
Obtained from: tg3 via DragonflyBSD [1], DragonflyBSD
Modified:
stable/7/sys/ (props changed)
stable/7/sys/contrib/pf/ (props changed)
stable/7/sys/dev/ath/ath_hal/ (props changed)
stable/7/sys/dev/bge/if_bge.c
stable/7/sys/dev/bge/if_bgereg.h
stable/7/sys/dev/cxgb/ (props changed)
Modified: stable/7/sys/dev/bge/if_bge.c
==
--- stable/7/sys/dev/bge/if_bge.c Mon Mar 23 20:37:37 2009
(r190334)
+++ stable/7/sys/dev/bge/if_bge.c Mon Mar 23 20:53:38 2009
(r190335)
@@ -384,6 +384,7 @@ static uint32_t bge_readreg_ind(struct b
#endif
static void bge_writemem_direct(struct bge_softc *, int, int);
static void bge_writereg_ind(struct bge_softc *, int, int);
+static void bge_set_max_readrq(struct bge_softc *, int);
static int bge_miibus_readreg(device_t, int, int);
static int bge_miibus_writereg(device_t, int, int, int);
@@ -523,6 +524,34 @@ bge_writemem_ind(struct bge_softc *sc, i
pci_write_config(dev, BGE_PCI_MEMWIN_BASEADDR, 0, 4);
}
+/*
+ * PCI Express only
+ */
+static void
+bge_set_max_readrq(struct bge_softc *sc, int expr_ptr)
+{
+ device_t dev;
+ uint16_t val;
+
+ KASSERT((sc->bge_flags & BGE_FLAG_PCIE) && expr_ptr != 0,
+ ("%s: not applicable", __func__));
+
+ dev = sc->bge_dev;
+
+ val = pci_read_config(dev, expr_ptr + BGE_PCIE_DEVCTL, 2);
+ if ((val & BGE_PCIE_DEVCTL_MAX_READRQ_MASK) !=
+ BGE_PCIE_DEVCTL_MAX_READRQ_4096) {
+ if (bootverbose)
+ device_printf(dev, "adjust device control 0x%04x ",
+ val);
+ val &= ~BGE_PCIE_DEVCTL_MAX_READRQ_MASK;
+ val |= BGE_PCIE_DEVCTL_MAX_READRQ_4096;
+ pci_write_config(dev, expr_ptr + BGE_PCIE_DEVCTL, val, 2);
+ if (bootverbose)
+ printf("-> 0x%04x\n", val);
+ }
+}
+
#ifdef notdef
static uint32_t
bge_readreg_ind(struct bge_softc *sc, int off)
@@ -1278,18 +1307,6 @@ bge_chipinit(struct bge_softc *sc)
/* Set endianness before we access any non-PCI registers. */
pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4);
- /*
- * Check the 'ROM failed' bit on the RX CPU to see if
- * self-tests passed. Skip this check when there's no
- * chip containing the Ethernet address fitted, since
- * in that case it will always fail.
- */
- if ((sc->bge_flags & BGE_FLAG_EADDR) &&
- CSR_READ_4(sc, BGE_RXCPU_MODE) & BGE_RXCPUMODE_ROMFAIL) {
- device_printf(sc->bge_dev, "RX CPU self-diagnostics failed!\n");
- return (ENODEV);
- }
-
/* Clear the MAC control register */
CSR_WRITE_4(sc, BGE_MAC_MODE, 0);
@@ -1742,14 +1759,18 @@ bge_blockinit(struct bge_softc *sc)
/* Enable host coalescing bug fix. */
if (sc->bge_asicrev == BGE_ASICREV_BCM5755 ||
sc->bge_asicrev == BGE_ASICREV_BCM5787)
- val |= 1 << 29;
+ val |= 1 << 29;
/* Turn on write DMA state machine */
CSR_WRITE_4(sc, BGE_WDMA_MODE, val);
+ DELAY(40);
/* Turn on read DMA state machine */
- CSR_WRITE_4(sc, BGE_RDMA_MODE,
- BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS);
+ val = BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS;
+ if (sc->bge_flags & BGE_FLAG_PCIE)
+ val |= BGE_RDMAMODE_FIFO_LONG_BURST;
+ CSR_WRITE_4(sc, BGE_RDMA_MODE, val);
+ DELAY(40);
/* Turn on RX data completion state machine */
CSR_WRITE_4(sc, BGE_RDC_MODE, BGE_RDCMODE_ENABLE);
@@ -2387,7 +2408,7 @@ bge_attach(device_t
Re: kern/119361: commit references a PR
The following reply was made to PR kern/119361; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/119361: commit references a PR
Date: Mon, 23 Mar 2009 20:54:30 + (UTC)
Author: marius
Date: Mon Mar 23 20:53:50 2009
New Revision: 190336
URL: http://svn.freebsd.org/changeset/base/190336
Log:
MFC: r190194
- In bge_ifmedia_upd_locked() take advantrage of LIST_FOREACH().
- If boot verbose, print asicrev, chiprev and bus type on attach.
- For PCI Express devices:
1) Adjust max read request size to 4Kbytes
2) Turn on FIFO_LONG_BURST in RDMA during bge_blockinit()
Though 1) does not seem to have much to do with the poor TX performance
observed on PCI Express bge(4), 2) does fix the problem. [1]
- Nuke the RX CPU self-diag, which prevents working cards from working
(Linux tg3 does not have this diag neither does OpenBSD's bge(4)).
The increasing of the firmware handshaking timeout to 2 retries
done as part of the original commit isn't merged as way already have a
way higher BGE_TIMEOUT of 10.
PR: 119361 [1]
Obtained from: tg3 via DragonflyBSD [1], DragonflyBSD
Modified:
stable/6/sys/ (props changed)
stable/6/sys/contrib/pf/ (props changed)
stable/6/sys/dev/bge/if_bge.c
stable/6/sys/dev/bge/if_bgereg.h
stable/6/sys/dev/cxgb/ (props changed)
Modified: stable/6/sys/dev/bge/if_bge.c
==
--- stable/6/sys/dev/bge/if_bge.c Mon Mar 23 20:53:38 2009
(r190335)
+++ stable/6/sys/dev/bge/if_bge.c Mon Mar 23 20:53:50 2009
(r190336)
@@ -383,6 +383,7 @@ static uint32_t bge_readreg_ind(struct b
#endif
static void bge_writemem_direct(struct bge_softc *, int, int);
static void bge_writereg_ind(struct bge_softc *, int, int);
+static void bge_set_max_readrq(struct bge_softc *, int);
static int bge_miibus_readreg(device_t, int, int);
static int bge_miibus_writereg(device_t, int, int, int);
@@ -521,6 +522,34 @@ bge_writemem_ind(struct bge_softc *sc, i
pci_write_config(dev, BGE_PCI_MEMWIN_BASEADDR, 0, 4);
}
+/*
+ * PCI Express only
+ */
+static void
+bge_set_max_readrq(struct bge_softc *sc, int expr_ptr)
+{
+ device_t dev;
+ uint16_t val;
+
+ KASSERT((sc->bge_flags & BGE_FLAG_PCIE) && expr_ptr != 0,
+ ("%s: not applicable", __func__));
+
+ dev = sc->bge_dev;
+
+ val = pci_read_config(dev, expr_ptr + BGE_PCIE_DEVCTL, 2);
+ if ((val & BGE_PCIE_DEVCTL_MAX_READRQ_MASK) !=
+ BGE_PCIE_DEVCTL_MAX_READRQ_4096) {
+ if (bootverbose)
+ device_printf(dev, "adjust device control 0x%04x ",
+ val);
+ val &= ~BGE_PCIE_DEVCTL_MAX_READRQ_MASK;
+ val |= BGE_PCIE_DEVCTL_MAX_READRQ_4096;
+ pci_write_config(dev, expr_ptr + BGE_PCIE_DEVCTL, val, 2);
+ if (bootverbose)
+ printf("-> 0x%04x\n", val);
+ }
+}
+
#ifdef notdef
static uint32_t
bge_readreg_ind(struct bge_softc *sc, int off)
@@ -1261,18 +1290,6 @@ bge_chipinit(struct bge_softc *sc)
/* Set endianness before we access any non-PCI registers. */
pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4);
- /*
- * Check the 'ROM failed' bit on the RX CPU to see if
- * self-tests passed. Skip this check when there's no
- * chip containing the Ethernet address fitted, since
- * in that case it will always fail.
- */
- if ((sc->bge_flags & BGE_FLAG_EADDR) &&
- CSR_READ_4(sc, BGE_RXCPU_MODE) & BGE_RXCPUMODE_ROMFAIL) {
- device_printf(sc->bge_dev, "RX CPU self-diagnostics failed!\n");
- return (ENODEV);
- }
-
/* Clear the MAC control register */
CSR_WRITE_4(sc, BGE_MAC_MODE, 0);
@@ -1736,14 +1753,18 @@ bge_blockinit(struct bge_softc *sc)
/* Enable host coalescing bug fix. */
if (sc->bge_asicrev == BGE_ASICREV_BCM5755 ||
sc->bge_asicrev == BGE_ASICREV_BCM5787)
- val |= 1 << 29;
+ val |= 1 << 29;
/* Turn on write DMA state machine */
CSR_WRITE_4(sc, BGE_WDMA_MODE, val);
+ DELAY(40);
/* Turn on read DMA state machine */
- CSR_WRITE_4(sc, BGE_RDMA_MODE,
- BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS);
+ val = BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS;
+ if (sc->bge_flags & BGE_FLAG_PCIE)
+ val |= BGE_RDMAMODE_FIFO_LONG_BURST;
+ CSR_WRITE_4(sc, BGE_RDMA_MODE, val);
+ DELAY(40);
/* Turn on RX data completion state machine */
CSR_WRITE_4(sc, BGE_RDC_MODE, BGE_RDCMODE_ENABLE);
@@ -2383,8 +2404,7 @@ bge_attach(device_t dev)
sc->bge_btag = rman_get_bustag(sc->bge
Re: kern/119361: [bge] bge(4) transmit performance problem
Synopsis: [bge] bge(4) transmit performance problem State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Mon Mar 23 21:04:40 UTC 2009 State-Changed-Why: close http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 ___ 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: ath0 apparent silent disassociation
Bruce M Simpson wrote: Sam Leffler wrote: Bruce M Simpson wrote: ... This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). There are many issues with the wireless code in RELENG_7. Now that the hal is merged we can try to address them. Unfortunately the 7.2 release has just begun so it's unclear what we can get in. I'm also limited in what I'm willing to commit given that I do not run RELENG_7. OK. We've managed to reproduce this set of symptoms now in our work area. I've attached some script(1) output of netstat -in being run, and a pcap dump. Timebase: beginning of the pcap is in sync with a bringup from single-user mode; the tcpdump runs in the background from init whilst the system is brought up. OK, so I timed the apparent loss of connectivity as 6m 30s from that point I hit the stopwatch, to when I hit it again when the AP's Web GUI no longer shows the STA affected as being associated. Obviously such a timing is subject to human/visual jitter, and how often Netgear's firmware pulls the STA association list from the AP into the web GUI. What stands out in the pcap is that 302.291s in (almost 5m exactly), the STA (ath0) sends an IEEE 802.11 NULL frame to the AP with the PWR MGT bit set (I'm going to sleep!). This more or less coincides with a normal beacon from the Netgear AP. It does not advertise Auto Power Save Delivery (apsd), that bit is 0. This is puzzling as we don't enable power management by default. As I understand it, this may be an AP feature in some environments... I can try reproducing this with an explicit 'ifconfig ath0 -powersave' and see if it reoccurs. You'll see that after this NULL frame is sent, there is another Probe Request, and the Netgear AP does Probe Respond, but this makes no difference (I ended the capture around 150s after the NULL frame was sent). At this point we can't send traffic from the ath0, or rather, the AP is acting as though it never even heard the STA. The STA learns the AP's IP address/MAC mapping through passive ARP -- we still see broadcasts on the SSID -- but the AP has started to totally ignore the STA, and seemed to have ignored its ARP requests also. We are using MAC address ACL control with this AP, and the ath0 affected is definitely listed in its ACL table, configured up, rebooted etc. It is as though the STA is entering power saving mode when not explicitly told to, and the AP is not waking up the STA as it should. If any more information needed, or where to look, please let me know what's involved (I MFCed the change after all, so I'll help where I can until I'm on holiday this week...) My lab colleague is just working around this with 'ping ' for now, that keeps things up, as does OpenVPN... Your sta did a background scan. There are bugs in this area fixed in HEAD. One was that periodic calibration in the driver might kick in while off channel and setup state that was wrong for the channel where the ap was. As I said, now that the hal code is finally in RELENG_7 I'm willing to look at stuff. You or someone else can do likewise but given things have sat basically untouched since 7.0RC1 I suspect that's expecting too much. Of course if people don't test HEAD then once 8.0 goes out we'll likely have a similar situation on that branch. I do feel more confident about HEAD as that code has gone through multiple product cycles outside the tree. Sam ___ 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: bin/128167: [patch] [libc] add support for SCTP to getaddrinfo(3)
Synopsis: [patch] [libc] add support for SCTP to getaddrinfo(3) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:18:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128167 ___ 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: ath0 apparent silent disassociation
Sam Leffler wrote: > You or someone else can do likewise but given things > have sat basically untouched since 7.0RC1 I suspect that's expecting too > much. Sorry, this wasn't directed at you; it was meant at the community as a whole. I don't run RELENG_7 and when I do I use a backport of the wireless code in HEAD. Folks running RELENG_7 need to pitch in and help maintain the wireless code. I'm always available to help/advise. Sam ___ 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/30186: [libc] getaddrinfo(3) does not handle incorrect servname
Synopsis: [libc] getaddrinfo(3) does not handle incorrect servname Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:33:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=30186 ___ 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/100709: [libc] getaddrinfo(3) should return TTL info
Synopsis: [libc] getaddrinfo(3) should return TTL info Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:33:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=100709 ___ 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: bin/51827: [libc] [patch] getaddrinfo(3) is broken with numeric service
Synopsis: [libc] [patch] getaddrinfo(3) is broken with numeric service Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:34:21 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=51827 ___ 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/92880: [libc] [patch] almost rewritten inet_network(3) function
Synopsis: [libc] [patch] almost rewritten inet_network(3) function Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:35:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=92880 ___ 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/31647: [libc] socket calls can return undocumented EINVAL
Synopsis: [libc] socket calls can return undocumented EINVAL Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:41:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=31647 ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
El día Monday, March 23, 2009 a las 12:12:04PM -0700, Sam Leffler escribió:
> If you have the raw pcap capture please provide a url to it.
I have to capture it and will provide it;
>
> From the log it appears you're sending+receiving wep-encrypted frames.
> They keyid is the same and since you're receiving frames I have to
> assume the key matter is correct as otherwise the h/w would drop the
> frame. You can verify this by feeding the key into wireshark to check
> if the frame contents make sense.
>
> I'm out of ideas. About the only thing I can suggest is you setup a
> different ap w/ the same wep key and see if things work. If so then you
> know it's something this ap is doing. I can't recall when I last tested
> wep on HEAD but I'm pretty sure it works. I will re-test that when I
> get a chance.
>
>Sam
WEP in general works; my AP at home is configured as WEP and the entries
in wpa_supplicant.conf are nearly the same, only the key differs:
# my home
#
network={
ssid="tarara"
scan_ssid=0
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=xx
}
# Restaurante Odyssee (2007-11-18)
#
network={
ssid="ConnectionPoint"
scan_ssid=0
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=
}
but I will configure another AP to also use the same wep_key0, if you
think that the problem could depend on the key itself;
and I will check if I could get somewhere this model of AP for a test;
matthias
___
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/124282: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value
Synopsis: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:45:54 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124282 ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS.
From: Matthias Apitz
To: Sam Leffler
Cc: bug-follo...@freebsd.org, freebsd-net@freebsd.org
Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or
IP does not work
Date: Mon, 23 Mar 2009 22:42:07 +0100
El día Monday, March 23, 2009 a las 12:12:04PM -0700, Sam Leffler escribió:
> If you have the raw pcap capture please provide a url to it.
I have to capture it and will provide it;
>
> From the log it appears you're sending+receiving wep-encrypted frames.
> They keyid is the same and since you're receiving frames I have to
> assume the key matter is correct as otherwise the h/w would drop the
> frame. You can verify this by feeding the key into wireshark to check
> if the frame contents make sense.
>
> I'm out of ideas. About the only thing I can suggest is you setup a
> different ap w/ the same wep key and see if things work. If so then you
> know it's something this ap is doing. I can't recall when I last tested
> wep on HEAD but I'm pretty sure it works. I will re-test that when I
> get a chance.
>
>Sam
WEP in general works; my AP at home is configured as WEP and the entries
in wpa_supplicant.conf are nearly the same, only the key differs:
# my home
#
network={
ssid="tarara"
scan_ssid=0
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=xx
}
# Restaurante Odyssee (2007-11-18)
#
network={
ssid="ConnectionPoint"
scan_ssid=0
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=
}
but I will configure another AP to also use the same wep_key0, if you
think that the problem could depend on the key itself;
and I will check if I could get somewhere this model of AP for a test;
matthias
___
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/124282: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value
bru...@freebsd.org wrote: Synopsis: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:45:54 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). rwatson@ saw this crop up in -CURRENT and I believe he has a fix. Not sure about MFC but it clearly needs to get fixed... cheers, BMS ___ 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/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver
The following reply was made to PR kern/132889; it has been noted by GNATS. From: Miroslav Drbal To: bug-follo...@freebsd.org, mdr...@nymfe.net Cc: Subject: Re: kern/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver Date: Tue, 24 Mar 2009 00:38:31 +0100 Additional debug info: Unread portion of the kernel message buffer: ndis0: mem 0xf1efc000-0xf1ef,0xf000-0xf00f irq 17 at device 0.0 on pci11 ndis0: [ITHREAD] ndis0: NDIS API version: 5.1 ndis0: NDIS ERROR: c000138d (unknown error) ndis0: init handler failed ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
John Hay wrote: I found doing a -bgscan before it happens, make it not happen. I now have -bgscan in my rc.conf. That's exactly the workaround I needed. Thanks John. As Sam points out, the root fix is probably already in HEAD; it would be nice to find time to backport, but this works for us for now as a workaround (we are just using ath0 as a STA for testing in the lab at the moment, it is likely we will use hostap later). cheers, BMS ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce M Simpson To: John Hay Cc: Matthias Apitz , freebsd-net@freebsd.org, Sam Leffler , "Sean C. Farley" , bug-follo...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 24 Mar 2009 01:08:33 + John Hay wrote: > I found doing a -bgscan before it happens, make it not happen. I now > have -bgscan in my rc.conf. > That's exactly the workaround I needed. Thanks John. As Sam points out, the root fix is probably already in HEAD; it would be nice to find time to backport, but this works for us for now as a workaround (we are just using ath0 as a STA for testing in the lab at the moment, it is likely we will use hostap later). cheers, BMS ___ 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/132984: [netgraph] swi1: net 100% cpu usage
Synopsis: [netgraph] swi1: net 100% cpu usage Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 24 01:16:17 UTC 2009 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=132984 ___ 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"
#netstat -rn output
Hi all, I don't know if this belongs here or not, but here it is anyway. I'm in the middle of troubleshooting why two sub-interfaces on two FreeBSD boxes (directly connected via XO cable) within a /30 can't communicate, and I found that output when doing ``netstat'' is carved at a char length for interface name. Can the Netif column be expanded via the command line? If not, could someone let me know where the format is declared, so I might have a crack at forging it a bit? (I need to see 7 chars, not 6. ie: em3.30N): pe-test-4# netstat -rn | grep 208.70.111 DestinationGatewayFlagsRefs Use Netif 142.46.193.0/24208.70.111.66 UG1 095133em6 172.16.104.2 208.70.111.66 UGH1016184em6 172.16.104.3 208.70.111.54 UGH1011745 em3.30 172.16.104.99 208.70.111.62 UGH10 1171 em1.99 208.70.107.0/25208.70.111.54 UG1 0 28066384 em3.30 Steve ___ 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"
