Re: [rfc] removing the NDISulator
On Monday, October 21, 2013 6:29:24 pm Adrian Chadd wrote: The NDISulator is a crutch from a time when there wasn't _any_ real alternative. There are plenty of alternatives now. What's lacking is desire and person-power. But the datasheets are there, or the vendor code has been released, or there's linux/otherbsd drivers. Leaving it in there is just delaying the inevitable - drivers need to be fixed, ported, or reverse engineered. This is going to upset users in the same way that eliminating any other transition/sideways compatibility layer upsets users. But as I said, the path forward is fixing up the lack of stable drivers, not simply supporting some crutch. If there are drivers that people absolutely need fixed then they should stand up and say hey, I really would like X to work better! and then follow it up with some encouraging incentives. Right now the NDISulator lets people work _around_ this by having something that kind of works for them but it doesn't improve our general driver / stack ecosystems. Eh, having taken a stab at porting the bwl blob already, I would strongly oppose removing NDIS. If you do that I will just stop using my netbook with a Broadcom part altogether as I wouldn't be able to use it to try to test bwl changes. The NDIS thing is a bit hackish, but it is quite useful for a lot of folks. -- John Baldwin ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd adr...@freebsd.org wrote: If there are drivers that people absolutely need fixed then they should stand up and say hey, I really would like X to work better! and then follow it up with some encouraging incentives. Right now the NDISulator lets people work _around_ this by having something that kind of works for them but it doesn't improve our general driver / stack ecosystems. I doubt most people prefer to use the ndisulator over a native driver. However, many people don't have the skills, time, or money to provide the incentives you are talking about. At this point ndisulator provides a means to an end: working wireless and it isn't causing significant strain on the project in terms of development effort. Our end users are not always developers and I think removing this feature will hurt more than it will help. -- Eitan Adler ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org wrote: Eh, having taken a stab at porting the bwl blob already, I would strongly oppose removing NDIS. If you do that I will just stop using my netbook with a Broadcom part altogether as I wouldn't be able to use it to try to test bwl changes. The NDIS thing is a bit hackish, but it is quite useful for a lot of folks. I have to agree. Deprecation != motivation. I can pull out examples of this not holding true: * all the giant locking in drivers * all the giant locking in VFS People did pop up and claim ownership of things they cared about. Some stuff died, some stuff didn't. There was enough of a motivation by us to kill giant off in these pathways so things could continue to evolve. We didn't leave the GIANT crutch in forever. -adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On 10/23/13 11:11 AM, Adrian Chadd wrote: On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org wrote: Eh, having taken a stab at porting the bwl blob already, I would strongly oppose removing NDIS. If you do that I will just stop using my netbook with a Broadcom part altogether as I wouldn't be able to use it to try to test bwl changes. The NDIS thing is a bit hackish, but it is quite useful for a lot of folks. I have to agree. Deprecation != motivation. I can pull out examples of this not holding true: * all the giant locking in drivers * all the giant locking in VFS People did pop up and claim ownership of things they cared about. Some stuff died, some stuff didn't. There was enough of a motivation by us to kill giant off in these pathways so things could continue to evolve. We didn't leave the GIANT crutch in forever. Sure, however those drivers and vfs systems were not sustainable and holding the kernel back. What part of the NDISulator actually holds the system back? I'm saying that it seems as if it was conjecture rather than a need. Is the NDISulator giant locked? Also why the interest in writing drivers so much? Being able to leverage other platform drivers is pretty neat and saves us a ton of work. -- Alfred Perlstein ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On 10/23/13 7:23 AM, John Baldwin wrote: On Monday, October 21, 2013 6:29:24 pm Adrian Chadd wrote: The NDISulator is a crutch from a time when there wasn't _any_ real alternative. There are plenty of alternatives now. What's lacking is desire and person-power. But the datasheets are there, or the vendor code has been released, or there's linux/otherbsd drivers. Leaving it in there is just delaying the inevitable - drivers need to be fixed, ported, or reverse engineered. This is going to upset users in the same way that eliminating any other transition/sideways compatibility layer upsets users. But as I said, the path forward is fixing up the lack of stable drivers, not simply supporting some crutch. If there are drivers that people absolutely need fixed then they should stand up and say hey, I really would like X to work better! and then follow it up with some encouraging incentives. Right now the NDISulator lets people work _around_ this by having something that kind of works for them but it doesn't improve our general driver / stack ecosystems. Eh, having taken a stab at porting the bwl blob already, I would strongly oppose removing NDIS. If you do that I will just stop using my netbook with a Broadcom part altogether as I wouldn't be able to use it to try to test bwl changes. The NDIS thing is a bit hackish, but it is quite useful for a lot of folks. I have to agree. Deprecation != motivation. -- Alfred Perlstein ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On Wednesday, October 23, 2013 2:11:29 pm Adrian Chadd wrote: On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org wrote: Eh, having taken a stab at porting the bwl blob already, I would strongly oppose removing NDIS. If you do that I will just stop using my netbook with a Broadcom part altogether as I wouldn't be able to use it to try to test bwl changes. The NDIS thing is a bit hackish, but it is quite useful for a lot of folks. I have to agree. Deprecation != motivation. I can pull out examples of this not holding true: * all the giant locking in drivers * all the giant locking in VFS People did pop up and claim ownership of things they cared about. Some stuff died, some stuff didn't. There was enough of a motivation by us to kill giant off in these pathways so things could continue to evolve. We didn't leave the GIANT crutch in forever. Giant isn't dead yet. :) (And I've done a lot of the de-Gianting FWIW.) I don't consider ndis in the same camp. Often times there are vendors where datasheets, etc. are not obtainable, but a foo.sys + foo.inf is. -- John Baldwin ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
And the link momentum is strong now. There's driver source. Adrian On Oct 23, 2013 2:41 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, October 23, 2013 2:11:29 pm Adrian Chadd wrote: On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org wrote: Eh, having taken a stab at porting the bwl blob already, I would strongly oppose removing NDIS. If you do that I will just stop using my netbook with a Broadcom part altogether as I wouldn't be able to use it to try to test bwl changes. The NDIS thing is a bit hackish, but it is quite useful for a lot of folks. I have to agree. Deprecation != motivation. I can pull out examples of this not holding true: * all the giant locking in drivers * all the giant locking in VFS People did pop up and claim ownership of things they cared about. Some stuff died, some stuff didn't. There was enough of a motivation by us to kill giant off in these pathways so things could continue to evolve. We didn't leave the GIANT crutch in forever. Giant isn't dead yet. :) (And I've done a lot of the de-Gianting FWIW.) I don't consider ndis in the same camp. Often times there are vendors where datasheets, etc. are not obtainable, but a foo.sys + foo.inf is. -- John Baldwin ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: 9.2-STABLE r255918 with GENERIC and iwn - core dump
Hi, Please try this: http://people.freebsd.org/~adrian/ath/20131023-net80211-txmgt-locking-2.diff It implements what I think is the mostly-right fix: * remove the node reference in the callout, it's actually not freaking needed! * grab the ic lock when doing the timeout callout, ensuring consistency * expose ieee80211_new_state_locked(), as a few places will already hold the ic lock when wanting to update state Please try it out and let me know if it fixes your panics. Thanks! -adrian On 22 October 2013 07:28, claudiu vasadi claudiu.vas...@gmail.com wrote: Hi everyone, I have a Lenovo Thinkpad T420s with Intel core i7 @ 2.70GHz, 8GB RAM, Intel SSD 160GB and iwn0: Intel Centrino Ultimate-N 6300 mem 0xf420-0xf4201fff irq 17 at device 0.0 on pci3 Today, while connecting to different AP's, I noticed at one point that I was not getting an IP although the wifi card was associated. Within wifimgr, I did a Save and Reconnect and then got a core dump. Bellow, the bt: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xff801e5f7000 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a10431 stack pointer= 0x28:0xff8000276980 frame pointer= 0x28:0xff8000276a20 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x80948a06 at kdb_backtrace+0x66 #1 0x8090e50e at panic+0x1ce #2 0x80cf3440 at trap_fatal+0x290 #3 0x80cf37a1 at trap_pfault+0x211 #4 0x80cf3d54 at trap+0x344 #5 0x80cdd093 at calltrap+0x8 #6 0x808dfddd at intr_event_execute_handlers+0xfd #7 0x808e15cd at ithread_loop+0x9d #8 0x808dc82f at fork_exit+0x11f #9 0x80cdd5be at fork_trampoline+0xe Uptime: 8h20m28s Dumping 952 out of 8106 MB:..2% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..11% (CTRL-C to abort) (CTRL-C to abort) ..21%..31% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..41% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..51% (CTRL-C to abort) (CTRL-C to abort) ..61% (CTRL-C to abort) ..71% (CTRL-C to abort) ..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot-mount/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot-mount/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boot-mount/boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot-mount/boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot-mount/boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot-mount/boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/mmc.ko...Reading symbols from /boot-mount/boot/kernel/mmc.ko.symbols...done. done. Loaded symbols for /boot/kernel/mmc.ko Reading symbols from /boot/kernel/mmcsd.ko...Reading symbols from /boot-mount/boot/kernel/mmcsd.ko.symbols...done. done. Loaded symbols for /boot/kernel/mmcsd.ko Reading symbols from /boot/kernel/acpi_call.ko...done. Loaded symbols for /boot/kernel/acpi_call.ko Reading symbols from /boot/kernel/umodem.ko...Reading symbols from /boot-mount/boot/kernel/umodem.ko.symbols...done. done. Loaded symbols for /boot/kernel/umodem.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot-mount
Re: 9.2-STABLE r255918 with GENERIC and iwn - core dump
Hi, Still getting the Cannot reset interface wlan0 - exit status 1 in wifimgr but no crash yet. Will keep trying :D On Wed, Oct 23, 2013 at 9:51 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, Please try this: http://people.freebsd.org/~adrian/ath/20131023-net80211-txmgt-locking-2.diff It implements what I think is the mostly-right fix: * remove the node reference in the callout, it's actually not freaking needed! * grab the ic lock when doing the timeout callout, ensuring consistency * expose ieee80211_new_state_locked(), as a few places will already hold the ic lock when wanting to update state Please try it out and let me know if it fixes your panics. Thanks! -adrian On 22 October 2013 07:28, claudiu vasadi claudiu.vas...@gmail.com wrote: Hi everyone, I have a Lenovo Thinkpad T420s with Intel core i7 @ 2.70GHz, 8GB RAM, Intel SSD 160GB and iwn0: Intel Centrino Ultimate-N 6300 mem 0xf420-0xf4201fff irq 17 at device 0.0 on pci3 Today, while connecting to different AP's, I noticed at one point that I was not getting an IP although the wifi card was associated. Within wifimgr, I did a Save and Reconnect and then got a core dump. Bellow, the bt: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xff801e5f7000 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a10431 stack pointer= 0x28:0xff8000276980 frame pointer= 0x28:0xff8000276a20 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x80948a06 at kdb_backtrace+0x66 #1 0x8090e50e at panic+0x1ce #2 0x80cf3440 at trap_fatal+0x290 #3 0x80cf37a1 at trap_pfault+0x211 #4 0x80cf3d54 at trap+0x344 #5 0x80cdd093 at calltrap+0x8 #6 0x808dfddd at intr_event_execute_handlers+0xfd #7 0x808e15cd at ithread_loop+0x9d #8 0x808dc82f at fork_exit+0x11f #9 0x80cdd5be at fork_trampoline+0xe Uptime: 8h20m28s Dumping 952 out of 8106 MB:..2% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..11% (CTRL-C to abort) (CTRL-C to abort) ..21%..31% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..41% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..51% (CTRL-C to abort) (CTRL-C to abort) ..61% (CTRL-C to abort) ..71% (CTRL-C to abort) ..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot-mount/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot-mount/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boot-mount/boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot-mount/boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot-mount/boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot-mount/boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/mmc.ko...Reading symbols from /boot-mount/boot/kernel/mmc.ko.symbols...done. done. Loaded symbols for /boot/kernel/mmc.ko Reading symbols from /boot/kernel/mmcsd.ko...Reading symbols from /boot-mount/boot/kernel/mmcsd.ko.symbols...done. done. Loaded symbols for /boot/kernel/mmcsd.ko Reading symbols from /boot/kernel/acpi_call.ko...done. Loaded symbols for /boot/kernel/acpi_call.ko Reading symbols from /boot/kernel/umodem.ko...Reading symbols from /boot-mount/boot/kernel/umodem.ko.symbols...done. done. Loaded symbols for /boot/kernel/umodem.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols
Re: 9.2-STABLE r255918 with GENERIC and iwn - core dump
On 23 October 2013 13:10, claudiu vasadi claudiu.vas...@gmail.com wrote: Hi, Still getting the Cannot reset interface wlan0 - exit status 1 in wifimgr but no crash yet. Will keep trying :D I have no idea about that. It's likely there's some net80211/iwn bug(s) but I don't use wifimgr so I don't know what it's doing. For that I'd bug the wifimgr people in PCBSD. they can always file bug reports with me :) Thanks, -adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: 9.2-STABLE r255918 with GENERIC and iwn - core dump
Understood. Will do so. On Wed, Oct 23, 2013 at 10:12 PM, Adrian Chadd adr...@freebsd.org wrote: On 23 October 2013 13:10, claudiu vasadi claudiu.vas...@gmail.com wrote: Hi, Still getting the Cannot reset interface wlan0 - exit status 1 in wifimgr but no crash yet. Will keep trying :D I have no idea about that. It's likely there's some net80211/iwn bug(s) but I don't use wifimgr so I don't know what it's doing. For that I'd bug the wifimgr people in PCBSD. they can always file bug reports with me :) Thanks, -adrian -- Best regards, Claudiu Vasadi ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On 23 October 2013 13:10, claudiu vasadi claudiu.vas...@gmail.com wrote: Hi, Still getting the Cannot reset interface wlan0 - exit status 1 in wifimgr but no crash yet. Will keep trying :D I have no idea about that. It's likely there's some net80211/iwn bug(s) but I don't use wifimgr so I don't know what it's doing. For that I'd bug the wifimgr people in PCBSD. they can always file bug reports with me :) Thanks, -adrian I don't have wifimgr either, can't even install it until I get wifi set up. Does wifimgr have more functionality than wpa_cli? Why would some drivers not be ndisulatable/ndiswrappable? Would that be because the resulting driver would fail, or because of the lack of .inf and .sys files in Windows driver? Tom ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On 23/10/2013 18:35, Eitan Adler wrote: On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd adr...@freebsd.org wrote: If there are drivers that people absolutely need fixed then they should stand up and say hey, I really would like X to work better! and then follow it up with some encouraging incentives. Right now the NDISulator lets people work _around_ this by having something that kind of works for them but it doesn't improve our general driver / stack ecosystems. I doubt most people prefer to use the ndisulator over a native driver. However, many people don't have the skills, time, or money to provide the incentives you are talking about. At this point ndisulator provides a means to an end: working wireless and it isn't causing significant strain on the project in terms of development effort. Our end users are not always developers and I think removing this feature will hurt more than it will help. As an end user, the main issue I have is that according to the manpage it supports ndis 5.1 According to http://en.wikipedia.org/wiki/Network_Driver_Interface_Specification this is the version supported by Windows XP http://en.wikipedia.org/wiki/Windows_XP, Server 2003 http://en.wikipedia.org/wiki/Windows_Server_2003, Windows CE http://en.wikipedia.org/wiki/Windows_CE 4.x, 5.0, 6.0 As you might guess most new devices wont be coming with drivers for XP, so does this mean I wont be able to use drivers for a recent windows version (my understanding is that it will but happy to learn differently) If this is the case and there is no active development on it, a gradual depreciation over the 10.x series is probably a good idea. If however its likely to support current drivers/devices it does have a place (I've used it once or twice in a pinch.) Vince ^ ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
service netif restart [iface] runs a wpa_supplicant twice
What is the best way to restart a wireless stack?
A command ifconfig wlan0 create wlandev ath0 starts the wpa_supplicant
by itself. It means that the netif script runs the wpa_supplicant twice,
always. Is it ok?
There is my debug during booting:
[netif.network_common()] START:
[netif.network_common()] ITERATION:
[wpa_supplicant] SUPPID=30067
[wpa_supplicant] SUPPID=30067
[netif.network_common()] STOP:
It means that during running a network_common() from the /etc/rc.d/netif
the /etc/rc.d/wpa_supplicant was called twice.
/etc/rc.conf
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
ifconfig_em0=DHCP
ipsec_enable=YES
/etc/wpa_supplicant.conf
network={
ssid=ssid
psk=psk
}
11.0-CURRENT
signature.asc
Description: This is a digitally signed message part
Re: service netif restart [iface] runs a wpa_supplicant twice
.. that needs to be fixed. It definitely shouldn't be started twice!
-adrian
On 23 October 2013 16:56, clutton clut...@zoho.com wrote:
What is the best way to restart a wireless stack?
A command ifconfig wlan0 create wlandev ath0 starts the wpa_supplicant
by itself. It means that the netif script runs the wpa_supplicant twice,
always. Is it ok?
There is my debug during booting:
[netif.network_common()] START:
[netif.network_common()] ITERATION:
[wpa_supplicant] SUPPID=30067
[wpa_supplicant] SUPPID=30067
[netif.network_common()] STOP:
It means that during running a network_common() from the /etc/rc.d/netif
the /etc/rc.d/wpa_supplicant was called twice.
/etc/rc.conf
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
ifconfig_em0=DHCP
ipsec_enable=YES
/etc/wpa_supplicant.conf
network={
ssid=ssid
psk=psk
}
11.0-CURRENT
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [IWN] Review
Hi,
Ok. I've reviewed this stuff in more depth.
Split-6 is still way too big to commit as one commit.
I was also hoping that we could get the updated hardware support into this
without necessarily adding the PAN support. But, you're the one driving
this, so it's up to you. :)
* There's DPRINTF() and the debug flags that you've moved into if_iwnreg.h,
which is the wrong place for it!
* .. same as iwn_intr_str()
* You still have style(9) issues:
+ the if constructs should be if (), not if();
+ you need spaces between things - eg, if (a == b) rather than if(a==b)
or if (a==b);
+ the } else { should be on one line, not separate on multiple lines.
* What's the story behind sc-ctx? When is it being set/changed?
* And then there's also ivp-ctx; that's the current VAP context, right? If
that's the case ,why are we bothering checking unit number? Why don't we
consistently check the vap context?
So, let's break up split_6 into this:
* create if_iwn_debug.h; put the debug macros, enum and such into that;
* submit a patch _just_ for the debug work, that's easy to do.
* Then, fix up the style(9) issues.
* Then, help me figure out what the story is with sc-ctx so I understand
what's going on there. I'd like to try and remove that if possible.
Thanks,
-adrian
On 28 September 2013 10:23, Cedric GROSS c...@cgross.info wrote:
Hello,
I'm get some free time. So I setted up my github for split work.
So on https://github.com/KreizIT/FreeBSD-IWN/
You will find 2 new branch : split_6 and split_7.
Split_6 is iwn -HEAD with split 6 applied. Patch for that is also available
in this branch.
Split_7 is iwn -HEAD with split 6 and new split 7 applied.
Split_7 start parameters task. So no massive change except that it's
manage NIC without BT.
Regards
Cedric
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [IWN] Review
.. and I've just done the if_iwn_debug.h stuff, so you should update your
patchset to include that.
Thanks,
-adrian
On 23 October 2013 17:43, Adrian Chadd adr...@freebsd.org wrote:
Hi,
Ok. I've reviewed this stuff in more depth.
Split-6 is still way too big to commit as one commit.
I was also hoping that we could get the updated hardware support into this
without necessarily adding the PAN support. But, you're the one driving
this, so it's up to you. :)
* There's DPRINTF() and the debug flags that you've moved into
if_iwnreg.h, which is the wrong place for it!
* .. same as iwn_intr_str()
* You still have style(9) issues:
+ the if constructs should be if (), not if();
+ you need spaces between things - eg, if (a == b) rather than if(a==b)
or if (a==b);
+ the } else { should be on one line, not separate on multiple lines.
* What's the story behind sc-ctx? When is it being set/changed?
* And then there's also ivp-ctx; that's the current VAP context, right?
If that's the case ,why are we bothering checking unit number? Why don't we
consistently check the vap context?
So, let's break up split_6 into this:
* create if_iwn_debug.h; put the debug macros, enum and such into that;
* submit a patch _just_ for the debug work, that's easy to do.
* Then, fix up the style(9) issues.
* Then, help me figure out what the story is with sc-ctx so I understand
what's going on there. I'd like to try and remove that if possible.
Thanks,
-adrian
On 28 September 2013 10:23, Cedric GROSS c...@cgross.info wrote:
Hello,
I'm get some free time. So I setted up my github for split work.
So on https://github.com/KreizIT/FreeBSD-IWN/
You will find 2 new branch : split_6 and split_7.
Split_6 is iwn -HEAD with split 6 applied. Patch for that is also
available
in this branch.
Split_7 is iwn -HEAD with split 6 and new split 7 applied.
Split_7 start parameters task. So no massive change except that it's
manage NIC without BT.
Regards
Cedric
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
freebsd-wireless-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: service netif restart [iface] runs a wpa_supplicant twice
IT's not. It's devd doing something dumb.
-a
On 23 October 2013 21:30, clutton clut...@zoho.com wrote:
Indeed.
I have looked at a sys/net80211 and at a sys/dev/ath.
But I still have no idea which one triggers rc script and how on the
earth it can be done.
On Wed, 2013-10-23 at 16:57 -0700, Adrian Chadd wrote:
. that needs to be fixed. It definitely shouldn't be started twice!
-adrian
On 23 October 2013 16:56, clutton clut...@zoho.com wrote:
What is the best way to restart a wireless stack?
A command ifconfig wlan0 create wlandev ath0 starts the
wpa_supplicant
by itself. It means that the netif script runs the wpa_supplicant
twice,
always. Is it ok?
There is my debug during booting:
[netif.network_common()] START:
[netif.network_common()] ITERATION:
[wpa_supplicant] SUPPID=30067
[wpa_supplicant] SUPPID=30067
[netif.network_common()] STOP:
It means that during running a network_common() from the
/etc/rc.d/netif
the /etc/rc.d/wpa_supplicant was called twice.
/etc/rc.conf
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
ifconfig_em0=DHCP
ipsec_enable=YES
/etc/wpa_supplicant.conf
network={
ssid=ssid
psk=psk
}
11.0-CURRENT
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
freebsd-wireless-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
