1109984368 N * Bertl_oO Bertl
1109984382 M * Bertl evening folks!
1109984541 M * Doener hi Bertl!
1109984615 M * Bertl hey Doener! recovered from ngnet yet?
1109984687 M * Doener i'm back at it ;)
1109984765 M * Doener btw the 9.2.4->9.2.5 delta is broken 
1109984765 M * Bertl excellent, I have some patches for that ...
1109984787 M * Doener guess that will make my ideas obsolete ;)
1109984801 M * Bertl I hope not, let me upload a 9.2->9.3 patch
1109984868 M * Bertl can you make use of that?
1109984893 M * Doener sure, i can always patch around to get anything :)
1109984896 M * Bertl or should I port it to 2.6.11-vs1.9.5-*
1109984923 A * Bertl is still at 2.6.11-rc5-vs1.9.4.7 ...
1109984930 M * Doener i'm using .11-rc5-vs1.9.4.9-ng9.2.7 atm
1109984971 M * Bertl okay, so you are going to pick out the changes between 9.2 and 9.3, is that fine for you?
1109985037 M * Doener i didn't understand what you mean, but i guess yes ;)
1109985070 M * Bertl that's the spirit! ;)
1109985096 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2-ng9.3.diff
1109985119 M * Bertl seems to do everything except forwarding the arp replies to the guest ...
1109985135 M * Bertl (which isn't implemented ;)
1109985374 M * Doener what about host<->guest communication?
1109985507 M * Bertl host<->guest and guest<->guest will require the vnet_vnet_xmit stiff
1109985511 M * Bertl *suff even
1109985518 M * Doener http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/ROUTE/linux-2.6/net/ipv4/netfilter/ipt_ROUTE.c?rev=3363&view=markup
1109985536 M * Doener maybe we could make use of that stuff
1109985601 M * Bertl hmm, please elaborate!
1109985727 M * Doener i've hacked the vnet_real_xmit thing, with the result that are at least showing up on the right interfaces (except send host->guest), but get dropped somewhere (probably i produced invalid skbs)
1109985785 M * Bertl diff?
1109985802 M * Doener now we are in the netfilter hook anyway when we reach the vnet_real_xmit thing, thus we may be able to adapt the skb-duplication and oif/iif modification stuff
1109985835 M * Doener uhm.. oops... i just killed that...
1109985845 A * Doener should have called the tree ng9.3
1109985926 M * Doener i basically did a lookup in the host's local routing table and if it matched, the packet was not emitted on the realdev but simply 'looped' via netif_rx
1109985938 M * Doener guess that was broken by concept ;)
1109985991 M * Doener i'll try to adapt the stuff from ipt_ROUTE now
1109986022 M * Doener ipt_MIRROR might be interesting, too (according to my understanding of the iptables manpage)
1109986025 M * Bertl hmm ...
1109986205 M * Bertl the host<->guest interaction is a speical form of the guest<->guest interaction
1109986229 M * Bertl and the guest<->guest interaction is based on two things:
1109986247 M * Bertl - a virtual arp answer to a real arp request
1109986266 M * Bertl - a deflection of the packet in vnet_vnet_xmit
1109986280 M * Bertl (at least in my design ;)
1109986427 M * Bertl so the idea here is the following:
1109986447 M * Bertl host sends to guest case:
1109986462 M * Bertl host broadcasts the arp request for the guest ip
1109986497 M * Bertl arp packet gets copied to the appropriate guest
1109986526 M * Bertl guest responds, which is copied back to the host
1109986537 M * Bertl after that both sides know the interfaces
1109986550 M * Bertl eth0, en0, and will transmit there
1109986743 M * Bertl I see two 'other' ways to solve this, and both have their pros and cons ...
1109986793 M * Bertl 1) create 'special' networks which are 'shared' by default, if you want guest/guest comminication
1109986832 M * Bertl 2) use the loopback device (and the vnet copies of them) to allow for guest/guest crosstalk
1109986896 M * Bertl I'm not sure if we should care about the host/guest case at all, because if we _really_ want to allow that, we could make the host a vnet context itself ...
1109986931 M * Bertl (i.e. switch on /sbin/init call into nfxid whatever)
1109986953 M * Bertl comments? questions? ideas?
1109987201 M * Doener hmm
1109987314 M * Doener which netfilter rules are applied to a locally generated packet?
1109987395 M * Bertl you mean hooks, I'd say output and input (if they are locally received too)
1109987416 M * Bertl and probably postrouting/prerouting in any case
1109987473 M * Bertl but the vnet tables are already outside those hooks
1109987603 M * Doener so, in the guest<->guest case, we match NF_IP_PRE_ROUTING and NF_IP_LOCAL_OUT, right?
1109987633 M * Bertl well, no, we match vnet (which is called on receipt)
1109987659 M * Bertl the question here is how to do a smart allow/deny which probably requires an extra set of rules
1109987706 M * Doener hm? hooknum is switched for NF_IP_PRE_ROUTING and NF_IP_LOCAL_OUT in vnet_target...
1109987731 M * Bertl yes, that's correct ..
1109987760 M * Doener so we'll match none, one or both... where does 'vnet' come from? isn't that the table?
1109987776 M * Bertl yes
1109987818 M * Doener hm, maybe we have a communication problem here, caused by my non-existing netfilter knowledge
1109987840 M * Bertl I guess we have some, but I'll try to explain with the code ...
1109988022 M * Bertl let's start with an incoming packet first
1109988034 M * Bertl (where incoming doesn't really say where it does come from)
1109988057 M * Bertl usually a 'received packet will be handed over to netif_receive_skb()
1109988075 M * Bertl (in net/core/dev.c)
1109988095 M * Bertl ngnet code now hijacks this procedure, and replaces it with it's own
1109988109 M * Bertl renaming the original to netif_receive_skb_ngnet()
1109988158 M * Bertl the new ngnet procedure now does the 'usual' stuff ...
1109988177 M * Bertl but runs a netfilter chain on the packets
1109988198 M * Bertl this is PRE_ROUTING chain of ngnet
1109988222 M * Bertl it's not advertised as the other chains, so it will not be called from any netfilter hook
1109988250 M * Bertl (this was actually the hardest part for me to get it working as expected)
1109988267 M * Bertl so now the question: why do we want/do that at all?
1109988291 M * Bertl simple, because we do not want already processed packets to traverse our filter again ...
1109988310 M * Bertl s/filter/classifier/
1109988381 M * Bertl now if the verdict is accept, we automagically call netif_receive_skb_ngnet() (the original function)
1109988400 M * Bertl otherwise we simply drop the packet ...
1109988416 M * Bertl as side effect, the packet was hopefully tagged
1109988453 M * Doener hm, will never happen...
1109988498 M * Bertl ?
1109988508 M * Doener the NF_IP_PREROUTING returns NF_STOLEN if it tags
1109988584 M * Bertl yes, that's the current implementation which reintroduces it to the 'proper' device
1109988674 M * Bertl once this works as expected, we can simplify the delivery significantly without losing any features
1109988691 M * Bertl (at least that's the idea behind it)
1109989059 M * Doener ok, something similar is placed somewhere in the code for packets being sent, right? just with NF_IP_LOCAL_OUT
1109989087 M * Bertl yes, basically the vnet device is the mediation point here
1109989105 M * Bertl currently the 'normal' NFHOOK is used for the tagging
1109989115 M * Bertl and the vnet device 'just' decides on the results
1109989158 M * Bertl in the future either per vnet device chains or tc queues could take that place
1109989186 M * Bertl (or if it prooves useful we keep the current setup)
1109989774 M * Bertl and IMHO the only 'critical' point now is the arp stuff
1109989796 M * Bertl maybe we should test a few setups with static neigh entries?
1109989856 M * Doener why not
1109989920 M * Bertl chcontext --ctx 10 ip neigh add 172.16.0.1 dev en0 lladdr 00:FF:79:4C:59:A5 nud permanent
1109989974 M * Bertl ip neigh add 172.16.0.10 dev tun0 lladdr 52:54:00:12:34:56 nud permanent
1109990019 M * Bertl ping in both directions works just fine (real<->guest)
1109990062 M * Bertl chcontext --ctx 10 sshd
1109990121 M * Bertl ssh login works to some extend ... there seems to be an issue
1109990165 M * Bertl sshd(pam_unix)[116]: session opened for user root by (uid=0)
1109990165 M * Bertl vxD: ip_queue_xmit(83e7da20[#65535])
1109990165 M * Bertl vxD: vnet_target(65535,#10) [101,3]
1109990165 M * Bertl vxD: vnet_get(101) = 83eece40[101,#10]
1109990165 M * Bertl vxD: neigh_connected_output(83e7da20[101,#10]) 83feed40,83ff3b80,83eecc00[en0,#10]
1109990168 M * Bertl vxD: vnet_start_xmit(83e7da20[101,#10],83eecc00[en0,#10])
1109990170 M * Bertl vxD: vnet_real_xmit(83e7da20) [101,#10]
1109990173 M * Bertl vxD: ip_queue_xmit(83e7d960[#65535])
1109990175 M * Bertl vxD: ip_route_output_flow(83e71cdc,83e71d30[#65535],83f20040[#10],0)
1109990178 M * Bertl vxD: __ip_route_output_key(#65535)
1109990180 M * Bertl vxD: __vx_loopback_dev(#65535) = 802fd9c0
1109990183 M * Bertl vxD: ip_route_output_slow()
1109990187 M * Bertl so packets after the syn seem to be untagged
1109990354 M * Bertl my idea to cope with the 'missing arp' stuff for now is the following:
1109990399 M * Bertl we do a loop over each non-lo vnet device, adn present the arp packet to the process_arp() for each xid there
1109990441 M * Bertl the neigh code 'knows' if it had issued an arp request before, so it will accept and handle the arp reply or reject it if not ...
1109990477 M * Bertl this is not the most performant solution (for now) but it should make the arp issues go away ...
1109990510 M * Bertl and let us focus on the _real_ issues (of course, static arp can do that as well, as you see)
1109990542 M * Bertl comments? 
1109990553 M * Doener sounds reasonable
1109990587 M * Bertl please don't let me walk over you, if you 'think' you have a great idea to improve any part of that design, step ahead and present it ...
1109990616 M * Doener no great idea yet
1109990635 M * Doener but i'll start screaming and yelling if i get one ;)
1109990651 M * Bertl okay, that sounds acceptable ;)
1109990717 M * Bertl so let's see why ip_queue_xmit() has the wrong tagging ...
1109990744 M * Bertl I have a feeling that this could need a vx_tag_dev_skb()
1109990761 M * Bertl or whatever I called that function ...
1109990972 M * Bertl tcp_transmit_skb() looks promising
1109991047 M * Bertl sk_stream_alloc_pskb
1109991080 M * Bertl guess that should tag the skb from the sk, what do you think?
1109991229 M * Doener yep
1109991249 M * Bertl I renamed the vx_tag_output_skb to just vx_tag_skb()
1109991270 M * Bertl maybe vx_tag_sock_skb() would be better?
1109991302 M * Doener if the other one's called vx_tag_dev_skb, yes
1109991516 M * Bertl maybe we should agree on some 'special' HW addresses for our tests, what do you think?
1109991516 Q * jd86 Read error: Connection reset by peer
1109991549 M * Doener Bertl: in an arp reply we should have the target ip address (i.e. the address of the sender of the arp rewuest)
1109991577 M * Doener right? if so, could we use that somehow?
1109991587 A * Doener just read up on arp...
1109991612 M * Doener s/rewuest/request/
1109991616 M * Bertl yes, that's correct, hardware and ip
1109991635 M * Bertl but for now I'd like to make that static ...
1109991660 M * Bertl qemu uses 52:54:00:12:34:56 for the eth0
1109991680 M * Bertl so we can keep that, but I though about something obvious like
1109991698 M * Bertl aa:aa:aa:00:00:01 for the first interface
1109991716 M * Bertl and maybe bb:bb:bb:00:00:01 for the tun
1109991725 M * Doener hmm...
1109991725 M * Doener SIOCSIFHWADDR: Device or resource busy
1109991726 M * Doener qdeb:~# ip l s eth0 down
1109991727 M * Bertl or the other way round
1109991741 M * Doener guess that was not the most clever thing to do on a ssh connection ;)
1109991753 M * Bertl hmm ... yeah ;)
1109991775 M * Bertl my favorite is /etc/init.d/network stop ;)
1109991805 M * Doener mii-tool eth0 -A eth0 is also nice :)
1109991828 M * Doener it complains that 'eth0' isn't valid and the connection dies
1109991837 M * Bertl heh, yes
1109991998 M * Doener 04:01:38 Bertl aa:aa:aa:00:00:01 for the first interface
1109992000 M * Bertl okay, I added the following to the qemu-ifup
1109992005 M * Bertl ifconfig $IF hw ether aa:aa:aa:00:00:$NR
1109992011 M * Doener do you mean a guest's interface?
1109992023 M * Bertl that makes it aa:aa:aa:00:00:00 (for the first qemu eth)
1109992061 M * Doener ah, you meant real and host...
1109992066 M * Bertl yep
1109992083 M * Bertl the host setup script now got:
1109992085 M * Bertl ifconfig eth0 hw ether bb:bb:bb:00:00:00
1109992120 M * Bertl chcontext --ctx 10 ip neigh add 172.16.0.1 dev en0 lladdr aa:aa:aa:00:00:00 nud permanent
1109992273 M * Bertl (and similar for the real to the guest)
1109992492 M * Bertl okay, seems to work fine here, for you too?
1109992503 M * Bertl (the setup, I mean)
1109992520 M * Doener no, i loose connectivity if i change the host's mac address
1109992558 M * Doener 00:00:00:00:00:01 is fine, bb:bb:bb:00:00:00 no
1109992564 M * Doener s/no/not
1109992577 M * Bertl host means?
1109992591 M * Doener the qemu system
1109992608 M * Doener i.e. eth0 in qemu
1109992615 M * Bertl yeah, just checking ...
1109992649 M * Bertl ifconfig lo 127.0.0.1
1109992649 M * Bertl ifconfig eth0 hw ether bb:bb:bb:00:00:00
1109992649 M * Bertl ifconfig eth0 10.0.0.2
1109992659 M * Bertl that's my start setup script on the host
1109992665 M * Doener neigh 87a07ac0 is probed.
1109992665 M * Doener neigh 87a07ac0 is suspected.
1109992665 M * Doener neigh 87a07ac0 is delayed.
1109992672 M * Doener in a loop
1109992711 M * Bertl hmm, okay, no idea, but if it works with a different one, just use that ...
1109992722 M * Bertl (or leave the default in qemu, it's fixed anyway
1109992995 M * Doener ok, got i setup now
1109993074 M * Doener btw, compared to the local route, the ssh failure is a regression
1109993087 M * Bertl hmm, I guess we should move those simple 'tagging' inlines into a separate file ...
1109993166 M * Bertl hmm, maybe over in include/linux/vserver/ngnet.h
1109993260 M * Bertl nah, we need a separate one to keep dependancies low
1109993530 M * Bertl okay, moved the vx_tag* into include/vserver/ngnet_skb.h
1109993684 M * Doener where did you put the tagging you suggested for sk_stream_alloc_pskb
1109993707 M * Doener i think it should actually be done in copy_skb_header
1109993712 M * Bertl that's what I am working on, because it's in include/net/sock.h
1109993724 M * Bertl yeah? sec
1109993993 M * Bertl I did put it in sk_stream_alloc_pskb()
1109994046 M * Bertl why copy_skb_header() =
1109994048 M * Bertl ?
1109994095 M * Bertl you mean that should make  aproper copy of the tag fields too?
1109994102 M * Doener yep
1109994116 M * Bertl yeah, I agree on that ... okay, let's try that first
1109994204 M * Bertl #ifdef CONFIG_VSERVER_NGNET
1109994204 M * Bertl         new->nfxid      = old->nfxid;
1109994204 M * Bertl         new->nfvnet     = old->nfvnet;
1109994204 M * Bertl #endif
1109994209 M * Bertl okay?
1109994283 M * Doener we may hit the tcp_transmit_skb call in tcp_retransmit_skb here 
1109994284 M * Doener where pskb_copy is called
1109994284 M * Doener yup
1109994312 M * Bertl so we want both, right?
1109994324 M * Doener probably
1109994468 M * Doener i guess that also explains the few !!! context #65535 not found ... i get when i ssh from real to host
1109994499 M * Doener still i wonder why it worked before
1109994701 M * Bertl I guess it was pure luck ;)
1109994752 M * Bertl at least I do not see any change which would have been wrong per se
1109995054 M * Doener i'm off to bed now, can't think clearly today... night!
1109995061 M * Bertl okay, good night!
1109995068 N * Doener Doener_zZz
1109997973 J * nox- ~nox@213.39.193.33
1109998299 Q * nox Ping timeout: 480 seconds
1109998331 N * nox- nox
1109999447 M * Bertl Doener_zZz: don#t use bb:bb:bb use cc:cc:cc instead ;)
1109999547 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1109999559 M * Bertl welcome flock!
1110000951 M * Bertl night everyone, off to bed now ...
1110000957 N * Bertl Bertl_zZ
1110002492 Q * sannes Read error: Connection reset by peer
1110006076 J * DaPhreak ~DaPhreak@pc-outside.uni-greifswald.de
1110008281 J * mhepp ~mhepp@r30s12p13.home.nbox.cz
1110008401 Q * DaPhreak Quit: leaving
1110008843 Q * mhepp Quit: KVIrc 3.0.1.99 'Realia'
1110008855 J * mhepp ~mhepp@r30s12p13.home.nbox.cz
1110009462 J * sannes ~ace@home.skarby.no
1110010926 Q * sannes Ping timeout: 480 seconds
1110011551 Q * mhepp Quit: KVIrc 3.0.1.99 'Realia'
1110012634 Q * aba Ping timeout: 480 seconds
1110014416 J * aba ~aba@sol.turmzimmer.net
1110014447 J * DaPhreak ~DaPhreak@pc-outside.uni-greifswald.de
1110017662 J * sannes ~ace@home.skarby.no
1110021781 J * yarihm ~yarihm@80-218-7-243.dclient.hispeed.ch
1110024991 J * prae ~prae@sherpadown.net
1110026003 Q * flock Read error: Operation timed out
1110027016 J * jd86 ~jim@ip68-9-97-23.ri.ri.cox.net
1110028984 Q * _are_ Read error: Operation timed out
1110029692 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1110029715 J * _are_ ~are@dsl-084-056-156-038.arcor-ip.net
1110029806 N * Bertl_zZ Bertl
1110029812 M * Bertl morning folks!
1110029827 M * DaPhreak morning Bertl :)
1110029879 M * Bertl hey DaPhreak!
1110030004 M * DaPhreak hmm grsec-vserver 2.6.11 compiles fine until builtin.o ;(
1110030032 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net
1110030040 M * Bertl welcome erwan_ho!
1110030049 M * erwan_ho lo Bertl 
1110030049 M * Bertl DaPhreak: means you messed up something?
1110030082 M * DaPhreak no idea Bertl :) thats why im that much confused :)
1110030341 M * Bertl yeah, well, my glass ball is broken again .. and saturday afternoon a wizard is hard to find ...
1110030413 M * DaPhreak wait a sec ... i try to compile it currently :)
1110030527 Q * erwan_ho Remote host closed the connection
1110031876 M * Bertl okay, back later ...
1110031880 N * Bertl Bertl_oO
1110035345 N * Doener_zZz Doener
1110035354 M * Doener morning folks!
1110035618 M * prae so ...
1110035633 M * prae I try to make patch vs+grsec for 2.6.11
1110035672 M * prae older grsec version have a security problem
1110035722 M * Doener you should join forces with DaPhreak ;)
1110035748 M * prae :)
1110035784 Q * lilo Quit: brb
1110035795 M * prae if I have a problem on some sections, I contact Daphreak  :)
1110035828 M * Doener 14:40:04 DaPhreak hmm grsec-vserver 2.6.11 compiles fine until builtin.o ;(
1110035843 M * Doener (that's about one and a half hour ago)
1110035847 M * prae :)
1110035870 M * prae with which version of vserver ?
1110035872 M * prae (url)
1110035889 M * Doener got to ask DaPhreak ;)
1110035900 M * prae :p
1110035907 M * prae DaPhreak: my deaaaaaaaaar !!!  :)
1110035912 M * prae DaPhreak: are you heeeeeere ?  :)
1110035979 M * prae nota bene : [grsec] grsecurity 2.1.2 released for 2.4.29/2.6.11 *CRITICAL UPDATE*
1110036238 J * lilo ~lilo@lilo.usercloak.oftc.net
1110036387 M * prae http://vserver.13thfloor.at/Experimental/patch-2.6.11-vs1.9.5-rc1.diff
1110036462 M * prae most recent ?
1110036585 M * Doener AFAICT yes, look at the topic ;)
1110036619 M * prae hmmm! sorry  ;-)
1110036674 M * prae with my irc client, I see only the 80 latest characters  :)
1110036717 M * Doener "latest stable 1.2.10, devel 1.9.5-rc1, ng9.2"
1110036924 M * prae :p
1110036957 M * prae Doener: You are a veritable mother for me  :))))
1110037135 M * DaPhreak yeah prae 
1110037138 M * DaPhreak im here :)
1110037141 M * prae =)
1110037148 M * DaPhreak what's the matter ?! :)
1110037159 M * prae for the 2.6.11, you use this patch : http://vserver.13thfloor.at/Experimental/patch-2.6.11-vs1.9.5-rc1.diff  ?
1110037161 M * prae or another ?
1110037224 M * DaPhreak hmm yeah
1110037230 M * DaPhreak is there any other ?! :)
1110037253 M * prae no  :)
1110037266 M * prae you see the latest news from grsec ?
1110037270 M * DaPhreak well i needed to correct some hunks since grsec changed some file .. but basically its the same
1110037282 M * DaPhreak yeah, already did that update
1110037430 J * prae_ ~prae@sherpadown.net
1110037446 M * prae I switch under my another station
1110037448 Q * prae Quit: Pwet
1110037451 N * prae_ prae
1110037468 M * prae *re*  :)
1110037532 M * DaPhreak wb prae 
1110043208 Q * prae Quit: leaving
1110043217 J * prae ~prae@sherpadown.net
1110043232 M * prae *back**
1110043763 M * prae DaPhreak: you are dead ?  :(
1110043830 J * Pazzo ~thomas@host130-250.pool8172.interbusiness.it
1110043850 M * Doener hi Pazzo !
1110043859 M * Pazzo Hi Doener!
1110043933 M * prae nouuhhouuuu DaPhreak issssss deaaaaadd
1110043935 M * prae :'(
1110043936 M * Pazzo Doener: I have the possibility to do some stress testing with 2.6.11-vs1.9.5-rc1 on a dual xeon 2,8 with 4 gigs ram and 6x143 gb scsi disks in a raid 5 ;-p
1110043948 M * Pazzo what kind of tortures would you use for doing so?
1110043956 M * prae :)
1110044020 M * Doener what about testing if it survives shipping it to me? *g*
1110044041 M * Pazzo good idea *gg*
1110044042 M * Doener no, seriously, i've no experience in stress testing
1110044178 N * Bertl_oO Bertl
1110044199 M * Pazzo Hi Bertl!
1110044207 M * Pazzo you can help me for sure :-)
1110044213 M * Pazzo (18:32:16) Pazzo: Doener: I have the possibility to do some stress testing with 2.6.11-vs1.9.5-rc1 on a dual xeon 2,8 with 4 gigs ram and 6x143 gb scsi disks in a raid 5 ;-p
1110044219 M * Pazzo any suggestion?
1110044381 M * Bertl hey folks!
1110044422 M * Bertl Pazzo: get the entire STP test suite and run it up and down, with and without the vserver patch .. then post the results/differences on the ml
1110044445 A * Pazzo is googling for the STP test suite
1110044475 M * Pazzo AX/4000 STP Conformance Test Suite ?????
1110044521 M * Pazzo The Spirent STP test suite???
1110044590 M * Pazzo sorry bertl - I know the Spanning Tree Protocol - but no idea where to look for the STP test suite!?
1110044602 Q * eyck Quit: Lost terminal
1110044686 M * DaPhreak Pazzo: maybe http://sourceforge.net/projects/stp ?
1110044693 J * eyck eyck@81.219.64.71
1110044730 M * Pazzo thnx DaPhreak!!
1110044745 M * Bertl yep!
1110044781 M * Pazzo thanks again folks!
1110044823 M * DaPhreak you're welcome :)
1110044839 M * Bertl yep! ;)
1110044844 M * Pazzo I'll try out this STP stuff tomorrow on cheap hardware tomorrow and on monday I'm allowed to burn down the xeons!
1110044860 M * Pazzo I have to leave now, cu all!
1110044864 M * Doener bye Pazzo 
1110044872 M * Pazzo bye doener!
1110044877 N * Pazzo PazZzzzooo
1110045582 Q * prae Quit: Pwet
1110045638 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net
1110045750 M * DaPhreak lo erwan_ho :)
1110045822 J * prae ~prae@sherpadown.net
1110045833 M * prae DaPhreak: it's ok :p
1110045839 M * DaPhreak haha :)
1110045843 M * DaPhreak great :)
1110045915 M * DaPhreak and this really works ?! *amazing*
1110045953 M * prae *It's incredible !!!*  :)
1110046497 M * prae DaPhreak: the latest version of you patch is same url ? (with fixbug)
1110046527 M * DaPhreak wait a sec :) currently uploading :)
1110046560 M * prae =)
1110046595 M * DaPhreak so, now its up
1110046623 M * erwan_ho lo DaPhreak 
1110046627 M * erwan_ho prae
1110046633 M * erwan_ho prae: tu fais qqchse ce soir ?
1110046774 M * prae erwan_ho: I'm go to rue de lappe, at "tribar"
1110046796 M * prae If you want, you can go with me  :)
1110046826 M * prae DaPhreak: you can paste again url  :)
1110046837 J * DuckKing ~Duck@dyn-83-157-198-109.ppp.tiscali.fr
1110046997 M * prae https://141.53.8.70/~heim/Experimental/patch-2.6.11-vs1.9.5-rc1-grsec-2.1.2-200503041925.diff   <-- it's ok ?
1110047038 Q * DuckMaster Read error: Operation timed out
1110047056 M * DaPhreak yeah :)
1110047063 M * prae ok :)
1110047076 M * DaPhreak but there's again a new release :)
1110047077 M * DaPhreak -2.6.11-200503051216
1110047079 M * DaPhreak ;)
1110047300 M * prae ok :)
1110047367 M * prae https://141.53.8.70/~heim/Experimental/patch-2.6.11-vs1.9.5-rc1-grsec-2.1.2-200503041926.diff  ?!!
1110047369 M * prae are you sure ?
1110047454 M * Doener hm, the have the same md5 sum? did you master breaking md5? ;)
1110047466 M * Doener s/the have/the have/
1110047471 M * prae =)
1110047478 J * monrad ~monrad@213083190130.sonofon.dk
1110047486 M * daniel_hozac lol
1110047487 A * Doener .oO( maybe i should just give up trying... )
1110047492 A * DaPhreak doesn't know if the have the same sum :p
1110047512 M * Doener s/the have/they have/
1110047532 M * DaPhreak you are right :)
1110047541 M * DaPhreak they have ...
1110048715 M * Bertl off now, back later ...
1110048722 N * Bertl Bertl_oO
1110049891 Q * erwan_ho Ping timeout: 480 seconds
1110049984 J * kjo nobody@pD95EB85E.dip.t-dialin.net
1110052018 N * Bertl_oO Bertl
1110052023 M * Bertl evening folks!
1110052027 M * Bertl greetings kjo!
1110052050 M * Bertl kjo: you've got mail!
1110052090 M * Doener wb Bertl 
1110052111 M * Bertl tx, you got my message?
1110052129 M * Bertl (regarding the MAC)
1110052196 Q * kjo Ping timeout: 480 seconds
1110052229 M * Doener yep
1110052272 M * Bertl okay, I tested ssh, http, and udp and it works fine real<->guest
1110052298 M * Bertl of course, the icmp ping works fine too ...
1110052360 M * Bertl okay, off again now, back later ...
1110052372 N * Bertl Bertl_oO
1110053546 J * mhepp ~mhepp@r30s12p13.home.nbox.cz
1110053682 J * shuri ~shuri@dsl.speedline209.226.electronicbox.net
1110054083 Q * shuri Remote host closed the connection
1110054102 J * shuri ~shuri@dsl.speedline209.226.electronicbox.net
1110054122 Q * shuri Remote host closed the connection
1110054659 J * shuri ~shuri@dsl.speedline209.226.electronicbox.net
1110056503 Q * mhepp Quit: KVIrc 3.0.1.99 'Realia'
1110058554 J * pulsar ~pulsar@213.184.238.34
1110058966 M * ola Hello
1110059617 M * pulsar hi
1110059688 M * ola I have now finally uploaded kernel patches to debian experimental. The problem is that it have to await approval from the FTP masters.
1110059688 Q * shuri Read error: Connection reset by peer
1110059701 M * ola I hope that it will be approved in a month or so at least.
1110060424 M * aba the approval speed will increase soon
1110062148 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net
1110062471 Q * yarihm Quit: Leaving
1110062840 J * shuri ~shuri@dsl.speedline209.226.electronicbox.net
1110063162 N * DaPhreak phreak_zZz
1110065934 Q * pulsar Quit: Leaving
1110065939 M * nox wg vserver
1110065945 M * nox ups sorry
1110066691 J * wishes ~wishes@debian.geek.nz
1110066919 M * Doener night folks
1110066923 N * Doener Doener_zZz