tech-net by thread

• Date Index
• Date Index (newest page)
• Old Index

• why not remove AF_LOCAL sockets on last close?, Thor Simon
  • Re: why not remove AF_LOCAL sockets on last close?, Matthias Scheler
  • Re: why not remove AF_LOCAL sockets on last close?, Robert Elz
    • Re: why not remove AF_LOCAL sockets on last close?, Thor Lancelot Simon
  • Re: why not remove AF_LOCAL sockets on last close?, Greg Troxel
    • Re: why not remove AF_LOCAL sockets on last close?, Thor Simon
      • Re: why not remove AF_LOCAL sockets on last close?, Matthew Mondor
      • Re: why not remove AF_LOCAL sockets on last close?, der Mouse
      • Re: why not remove AF_LOCAL sockets on last close?, Greg Troxel
      • Re: why not remove AF_LOCAL sockets on last close?, Thor Simon
      • Re: why not remove AF_LOCAL sockets on last close?, der Mouse
  • Re: why not remove AF_LOCAL sockets on last close?, Joerg Sonnenberger
    • Re: why not remove AF_LOCAL sockets on last close?, Matthew Mondor
      • Re: why not remove AF_LOCAL sockets on last close?, Joerg Sonnenberger
    • Re: why not remove AF_LOCAL sockets on last close?, Thor Lancelot Simon
      • Re: why not remove AF_LOCAL sockets on last close?, Joerg Sonnenberger
      • Re: why not remove AF_LOCAL sockets on last close?, der Mouse
  • Re: why not remove AF_LOCAL sockets on last close?, Matthew Mondor
    • Re: why not remove AF_LOCAL sockets on last close?, Thor Lancelot Simon
    • Re: why not remove AF_LOCAL sockets on last close?, Matthew Mondor
• MPLS patches (again), Mihai Chelaru
• Limit on number of sockets, Edgar Fuß
  • Re: Limit on number of sockets, Matthew Mondor
    • Re: Limit on number of sockets, Matthew Mondor
• porting OpenBSD's eephy(4) driver to replace makph, Greg A. Woods
  • Re: porting OpenBSD's eephy(4) driver to replace m, Thor Lancelot Simon
    • Re: porting OpenBSD's eephy(4) driver to replace m, Greg A. Woods
      • Re: porting OpenBSD's eephy(4) driver to replace m, Thor Lancelot Simon
      • Re: porting OpenBSD's eephy(4) driver to replace m, Manuel Bouyer
• getnameinfo extra len checking, Sean Boudreau
  • Re: getnameinfo extra len checking, Christos Zoulas
    • Re: getnameinfo extra len checking, Thor Lancelot Simon
      • Re: getnameinfo extra len checking, Christos Zoulas
      • Re: getnameinfo extra len checking, der Mouse
      • Re: getnameinfo extra len checking, Sean Boudreau
      • Re: getnameinfo extra len checking, Sean Boudreau
      • Re: getnameinfo extra len checking, Christos Zoulas
      • Re: getnameinfo extra len checking, Thor Lancelot Simon
      • Re: getnameinfo extra len checking, Antti Kantee
      • Re: getnameinfo extra len checking, der Mouse
      • Re: getnameinfo extra len checking, Thor Lancelot Simon
      • Re: getnameinfo extra len checking, Antti Kantee
      • Re: getnameinfo extra len checking, der Mouse
      • Re: getnameinfo extra len checking, Matthew Mondor
      • Re: getnameinfo extra len checking, Sean Boudreau
      • Re: getnameinfo extra len checking, Sean Boudreau
• netbsd 5.1_rc3 ipf and bad header checksums, Mark Davies
  • Re: netbsd 5.1_rc3 ipf and bad header checksums, Mark Davies
    • Re: netbsd 5.1_rc3 ipf and bad header checksums, Mark Davies
• Odd behavior, Paul Goyette
  • Re: Odd behavior, Hubert Feyrer
    • Re: Odd behavior, Paul Goyette
• Another update for axe(4), Paul Goyette
  • Re: Another update for axe(4), Izumi Tsutsui
    • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), Izumi Tsutsui
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), Izumi Tsutsui
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), Izumi Tsutsui
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), FUKAUMI Naoki
  • <Possible follow-ups>
  • Re: Another update for axe(4), Paul Goyette
    • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), der Mouse
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), Izumi Tsutsui
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), Izumi Tsutsui
      • Re: Another update for axe(4), Paul Goyette
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), FUKAUMI Naoki
      • Re: Another update for axe(4), Paul Goyette
• netbsd & packet-forwarding ASIC/FPGA?, David Young
• Wrong assumptions about return values of hifn_cryp, Daniel Zebralla (A.P.E. IT-Security - Hard- & Software Development)
  • Re: Wrong assumptions about return values of hifn_, Thor Lancelot Simon
    • Re: Wrong assumptions about return values of hifn_, Matthew Mondor
      • Re: Wrong assumptions about return values of hifn_, Daniel Zebralla (A.P.E. IT-Security - Hard- & Software Development)
• Source address based routing with PF, Matthias Scheler
  • Re: Source address based routing with PF, Jonathan A. Kollasch
    • Re: Source address based routing with PF, Matthias Scheler
• ipfilter breaks TCP connexions, Emmanuel Dreyfus
  • Re: ipfilter breaks TCP connexions, Emmanuel Dreyfus
• mbuf pool allocator can sleep in interrupt context, Thor Simon
  • Re: mbuf pool allocator can sleep in interrupt con, Darren Reed