Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On Monday 22 October 2012 01:03:19 Adrian Chadd wrote: ... > > Obviously, handling device attach events is an exception from this > > rule, and up to this date this was never properly addressed... > > *laugh*. > > The problem now is figuring out how to do it without modifying all the > drivers. > > The attach is easy - I can likely set it up during the device_attach() > pass. I can do that, but it's enforcing "networking-ness" with the > device attach, which will be called for networking and non-networking > devices alike. > > However detach isn't easy - because I'm required to call > CURVNET_SET(ifp->if_vnet) and CURVNET_RESTORE() around if_free(), and > if_free() is called in the device specific detach() routine, I can't > easily set the current VNET context from outside the driver. > > I _guess_ I could device_attach() to use CURVNET_SET(vnet0) but > device_detach() can't do the same - it doesn't "know" about the > networking-ness of the device. > > I'm open to other suggestions. The only option I can think of now is to update all of the hotunpluggable device_detach() handlers to do CURVNET_SET(ifp->if_vnet) before calling further down into the networking stack, because as you already observed, whatever triggers a device_detach() handler is not aware of the nature of the driver. > (how the hell does this work for devices attached at probe time? What > vnet context do they have, and why doesn't the kernel panic there?) Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). Similarly, curvnet is set to vnet0 during kldload events. Marko ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/172895 net[ixgb] [ixgbe] do not properly determine link-state o kern/172683 net[ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net[netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172364 net[cxbge] cxbge_vlan_config() Fatal trap 12: page fault o kern/172113 net[panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net[ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net[oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net[bce] [panic] bce related kernel panic o kern/171728 net[arp] arp issue o kern/171711 net[dummynet] [panic] Kernel panic in dummynet o kern/171697 net[ip6] [ndp] panic when changing routes o kern/171532 net[ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net[ndis] undocumented dependency for ndis(4) o kern/171524 net[ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net[epair] [request] Add the ability to name epair device o kern/171228 net[re] [patch] if_re - eeprom write issues o kern/170701 net[ppp] killl ppp or reboot with active ppp connection c o kern/170267 net[ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net[fxp] pf/nat/jails not working if checksum offloading o kern/169898 netifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net[bge] [hang] system hangs, fully or partially after re o kern/169664 net[bgp] Wrongful replacement of interface connected net o kern/169620 net[ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net[ppp] umodem/ppp/3g stopped working after update from o kern/169438 net[ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net[ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net[em] Multiple em(4) not working with qemu o kern/168245 net[arp] [regression] Permanent ARP entry not deleted on o kern/168244 net[arp] [regression] Unable to manually remove permanent o kern/168183 net[bce] bce driver hang system o kern/167947 net[setfib] [patch] arpresolve checks only the default FI o kern/167603 net[ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net[em] [panic] Kernel panics in em driver o kern/167325 net[netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net[igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net[tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net[ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net[gre] gre(4) when using a tunnel source address from c o kern/166372 net[patch] ipfilter drops UDP packets with zero checksum o kern/166285 net[arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net[net] [patch] It should be possible to disable "promis o kern/165963 net[panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 netmbuf leak o kern/165643 net[net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net[ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net[request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net[bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net[ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net[ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net[vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net[igb] igb freezes after about 2 weeks of uptime o kern/165174 net[patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net[ip6] Does not work through the issue of ipv6 addresse o kern/164495 net[igb] connect double head igb to switch cause system t o kern/164490 net[pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net[gre] gre misses RUNNING flag after a reboot o kern/164265 net[netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net[igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 netfreebsd do not add itself to ping route packet o kern/162927 net[tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On 22 October 2012 03:08, Marko Zec wrote: > The only option I can think of now is to update all of the hotunpluggable > device_detach() handlers to do CURVNET_SET(ifp->if_vnet) before calling > further down into the networking stack, because as you already observed, > whatever triggers a device_detach() handler is not aware of the nature of > the driver. Right. Well, since most things are in theory hotpluggable these days (or soon will be, with pcie hotplug), I think we need a slightly more generic solution. >> (how the hell does this work for devices attached at probe time? What >> vnet context do they have, and why doesn't the kernel panic there?) > > Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 > between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). > > Similarly, curvnet is set to vnet0 during kldload events. .. like this. The trouble is going to be handling unplug and kldunload events too. Does curvnet -> vnet0 during kldunload events? Thanks, Adrian ___ 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"
[patch] Review: Fix Tahi "Redirected On-link" Test Case
Bjoern and net@: I would appreciate your review and comments on the following patches. http://vangyzen.net/FreeBSD/patches/redir_onlink_8_rev1.diff http://vangyzen.net/FreeBSD/patches/redir_onlink_9_rev1.diff http://vangyzen.net/FreeBSD/patches/redir_onlink_10_rev1.diff Thanks in advance, Eric Fix the Redirected On-Link test cases in the Tahi IPv6 Ready Logo Phase 2 test suite. On receipt of a redirect message, install an interface route for the redirected destination. On removal of the corresponding Neighbor Cache entry, remove the interface route. This requires changes in rtredirect_fib() to cope with an AF_LINK address for the gateway and with the absence of RTF_GATEWAY. Unrelated to the above, fix a recursion on the radix node head lock triggered by the Redirected to Alternate Router test cases. All Section 2 (Neighbor Discovery) test cases pass on 10-CURRENT and 9-STABLE. (8-STABLE pending) Other test cases: * the RTF_MODIFIED case, with IPv4 and IPv6 (using a RTF_HOST|RTF_GATEWAY route for the destination) * the redirected-to-self case, with IPv4 and IPv6 * a valid IPv4 redirect All testing was done with WITNESS and INVARIANTS. Submitted by:Eric van Gyzen , Mark Kelley , Terence Telkamp Sponsored by:Dell, Inc. PR:kern/152791 ___ 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: VIMAGE crashes on 9.x with hotplug net80211 devices
On 10/22/12 7:12 AM, Adrian Chadd wrote: On 22 October 2012 03:08, Marko Zec wrote: The only option I can think of now is to update all of the hotunpluggable device_detach() handlers to do CURVNET_SET(ifp->if_vnet) before calling further down into the networking stack, because as you already observed, whatever triggers a device_detach() handler is not aware of the nature of the driver. Right. Well, since most things are in theory hotpluggable these days (or soon will be, with pcie hotplug), I think we need a slightly more generic solution. (how the hell does this work for devices attached at probe time? What vnet context do they have, and why doesn't the kernel panic there?) Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). Similarly, curvnet is set to vnet0 during kldload events. .. like this. The trouble is going to be handling unplug and kldunload events too. Does curvnet -> vnet0 during kldunload events? I think in unload events we probably need to cycle through all vnets and do individual shutdowns of anything that is set up on that vnet.. (but I'm not reading the code to say that, it's possible to ignore me safely) Thanks, Adrian ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-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: VIMAGE crashes on 9.x with hotplug net80211 devices
On 22 October 2012 10:29, Julian Elischer wrote: >> The trouble is going to be handling unplug and kldunload events too. >> Does curvnet -> vnet0 during kldunload events? > > I think in unload events we probably need to cycle through all vnets and > do individual shutdowns of anything that is set up on that vnet.. > (but I'm not reading the code to say that, it's possible to ignore me > safely) Well, in an unload event you know the device you're unloading. However, there may be clones and such involved. It's not like a kldunload will kill a specific VAP on an ath(4) interface, it'll kill the whole interface with all vaps. So in net80211 I need to teach the VAP setup/destroy path to use CURVNET_*() correctly. That's a given. I still however need to ensure that CURVNET_SET(vnet0)/CURVNET_RESTORE() is used around the device attach/detach, as right now the hotplug code doesn't do this. So Marko: * Given that you've "fixed" the kldload path and bootup path to set CURVNET_SET(vnet0) as a special case, how about we teach the device_attach() path to just do this in general? * How does kldunload work right now if any devices are in a vnet? If I kldunload if_bridge with vnets everywhere, what happens? if_bridge doesn't at all know anything about VIMAGE. How do the cloned interfaces get correctly destroyed? I don't want to have to teach _every network device_ that they need to be vnet aware on attach or detach. * the device probe/attach path should just use vnet0; and * the device detach/destroy path, to things like if_free(), should have those functions just use ifp->if_vnet, rather than assuming CURVNET_SET() was called. I know you wanted to be warned if parts of the stack weren't correctly using CURVNET_SET()/CURVNET_RESTORE(), but I think this battle is already lost. :/ Adrian ___ 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: TCP_DROP_SYNFIN kernel option side effects?!
Thanks Andre for your answer:) On Thu, Oct 18, 2012 at 4:56 PM, Andre Oppermann wrote: > On 16.10.2012 17:27, h bagade wrote: > >> Hi all, >> >> I need to add this option to kernel in order to defeating Nmap >> OS-Fingerprinting. My system is running as Web Server and also it is the >> gateway on the network. >> I want to know if setting this option has any side effects on other parts >> of the system? Is there any situation that SYN and FIN bits are set both >> in >> TCP packets? Is it a normal situation? >> > > SYN and FIN is not normal. Doing TCP_DROP_SYNFIN is not RFC compliant > but doesn't cause any problems. > > -- > Andre > > ___ 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: VIMAGE crashes on 9.x with hotplug net80211 devices
On Monday 22 October 2012 19:41:19 Adrian Chadd wrote: > On 22 October 2012 10:29, Julian Elischer wrote: > >> The trouble is going to be handling unplug and kldunload events too. > >> Does curvnet -> vnet0 during kldunload events? > > > > I think in unload events we probably need to cycle through all vnets > > and do individual shutdowns of anything that is set up on that vnet.. > > (but I'm not reading the code to say that, it's possible to ignore me > > safely) > > Well, in an unload event you know the device you're unloading. > However, there may be clones and such involved. It's not like a > kldunload will kill a specific VAP on an ath(4) interface, it'll kill > the whole interface with all vaps. > > So in net80211 I need to teach the VAP setup/destroy path to use > CURVNET_*() correctly. That's a given. > > I still however need to ensure that > CURVNET_SET(vnet0)/CURVNET_RESTORE() is used around the device > attach/detach, as right now the hotplug code doesn't do this. > > So Marko: > > * Given that you've "fixed" the kldload path and bootup path to set > CURVNET_SET(vnet0) as a special case, how about we teach the > device_attach() path to just do this in general? While it's true that the kldunload path (most probably) does CURVNET_SET(vnet0), this is obviously just a kludge which works on pure luck, i.e. only when ifnets to be detached live inside vnet0. > * How does kldunload work right now if any devices are in a vnet? It (most probably) doesn't. > If I > kldunload if_bridge with vnets everywhere, what happens? if_bridge > doesn't at all know anything about VIMAGE. How do the cloned > interfaces get correctly destroyed? Haven't tried this out recently, really, though bz@ maintained a patch for a while which specifically targetted VNET issues with cloner ifnets, but I don't know the current status of that work... > I don't want to have to teach _every network device_ that they need to > be vnet aware on attach or detach. > > * the device probe/attach path should just use vnet0; and Right. > * the device detach/destroy path, to things like if_free(), should > have those functions just use ifp->if_vnet, rather than assuming > CURVNET_SET() was called. How many functions like if_free() are we talking about here? If only a few would need to be extended to do a CURVNET_SET(ifp->if_vnet), that doesn't sound like too big an issue, though I'm not completely convinced that such an approach could guarantee that every driver would survive hotunplugging with vnets. Still, that would be an improvement over what we have right now. > I know you wanted to be warned if parts of the stack weren't correctly > using CURVNET_SET()/CURVNET_RESTORE(), but I think this battle is > already lost. :/ It is absolutely critical that, at minimum, we always completely unwind the VNET stack when exiting the networking code, otherwise we risk to continue running with a fully random implicit curvnet context. As many of the networking subsystems or code paths are still not VNET-friendly, entering any of those on a VIMAGE kernel should lead to panics, not to obscure and silent inter-vnet leakages which may become a nightmare to nail down. OTOH, avoiding excessive recursions on curvnet remains an effort similar to our style(9) - if you don't stick to it to the letter, things will still work, but some code paths may become more difficult to debug when things go wrong... Plus, keep in mind that every CURVNET_SET() consumes a few CPU cycles here and there, and requires a few extra bytes on the stack... Marko ___ 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: VIMAGE crashes on 9.x with hotplug net80211 devices
Hi, I don't mind tackling the net80211 clone detach path. I do mind how the default for hotplug is "argh, it doesn't work." :-) So I'd like to come up with something to fix the basic device detach, rather than having to actually add CURVNET_*() calls around each if_free() in each device detach method. Adrian ___ 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/156226: Lagg failover does not announce the failover to switch
The following reply was made to PR kern/156226; it has been noted by GNATS. From: Ryan Steinmetz To: Per von Zweigbergk Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: kern/156226: Lagg failover does not announce the failover to switch Date: Mon, 22 Oct 2012 21:12:40 -0400 This isn't a solution, but is a workaround that I've been using for a bit: http://people.freebsd.org/~zi/ping You can drop the file in /usr/local/etc/rc.d and then add ping_enable="YES" to /etc/rc.conf Basically, it sends an icmp echo request to your default gateway every 5 seconds by default, which forces the switch to update its FIB. This means that after a maximum of 5 seconds after lagg completes an interface failover, you should regain network connectivity. -r ___ 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"
