| Kilos | morning all | 05:52 |
|---|---|---|
| Kilos | hi henkj | 06:20 |
| superfly | morning oom Kilos | 06:58 |
| Kilos | morning superfly all good there? | 06:58 |
| superfly | pretty much | 06:59 |
| Kilos | hi nlsthzn | 07:19 |
| nlsthzn | hey uncle Kilos , how are you? | 07:19 |
| Kilos | good ty nlsthzn and you? | 07:20 |
| nlsthzn | I am fine... @ work and would rather be home to be able to watch the rugby :/ | 07:20 |
| Kilos | aw | 07:20 |
| nlsthzn | not so bad... | 07:41 |
| Kilos | ya thats life i spose | 07:41 |
| Kilos | we should beat them ausies | 07:41 |
| nlsthzn | if we can beat them and get 4 tries then the series is on vs NZ | 07:46 |
| Kilos | yeah | 07:56 |
| Kilos | hi Vince-0 | 10:58 |
| Vince-0 | Hi! | 10:59 |
| charl_ | good afternoon | 11:27 |
| charl_ | Maaz: coffee on | 11:27 |
| * Maaz flips the salt-timer | 11:27 | |
| Kilos | hi charl_ | 11:27 |
| Kilos | Maaz, coffee please | 11:27 |
| Maaz | Kilos: Sure | 11:27 |
| charl_ | hi Kilos | 11:28 |
| charl_ | ich bin kaput | 11:28 |
| charl_ | i just arrived this morning back from munich | 11:28 |
| Kilos | what made you kaput | 11:28 |
| Kilos | travelling? | 11:28 |
| charl_ | octoberfest ist total verrückt | 11:28 |
| charl_ | *oktoberfest | 11:29 |
| Kilos | you sposed to use trains not run | 11:29 |
| charl_ | lol | 11:29 |
| Kilos | oh well, self inflicted punishment | 11:29 |
| charl_ | yes i took the train from the netherlands all the way to munchen hauptbahnhof | 11:29 |
| charl_ | theresienwiese is very close to the station (walking distance) | 11:29 |
| charl_ | took two overnight trains | 11:30 |
| Kilos | ah | 11:30 |
| charl_ | arrived 7 in the morning and left at 10 in the evening | 11:30 |
| charl_ | hotels are almost impossible to come by in munich at the moment | 11:30 |
| Maaz | Coffee's ready for charl_ and Kilos! | 11:31 |
| charl_ | Maaz: thanks | 11:31 |
| Maaz | charl_: Okay :-) | 11:31 |
| Kilos | Maaz, danke | 11:31 |
| Maaz | Bitteschön | 11:31 |
| charl_ | i sat in the Hacker-Pschorr tent | 11:31 |
| charl_ | it's funny because it contains the word "hacker" | 11:31 |
| Kilos | lol | 11:32 |
| charl_ | in the hacker-tent hahaha http://www.hacker-pschorr.com/en/oktoberfest/hacker-tent | 11:32 |
| Kilos | hi captine | 12:24 |
| captine | Hi there | 12:25 |
| charl_ | hi captine | 12:39 |
| captine | hi there | 12:40 |
| charl_ | how's it going | 12:41 |
| charl_ | ok photos uploaded http://imgur.com/a/z5TcB | 14:04 |
| charl_ | there are a bunch that were taken in hannover too at the start | 14:04 |
| charl_ | i traveled through hannover | 14:05 |
| magespawn | Good evening | 17:03 |
| Kilos | hi magespawn wb | 17:03 |
| Kilos | we won nlsthzn | 17:03 |
| nlsthzn | I saw uncle Kilos ... but we needed one more try :/ | 17:04 |
| Kilos | yeah | 17:04 |
| magespawn | Hi Kilos | 17:04 |
| magespawn | Hi nlsthzn | 17:04 |
| Kilos | if they only get 4 points against argentina then we even | 17:04 |
| nlsthzn | then they are 4 points ahead... | 17:04 |
| nlsthzn | if they got bonus point they are now 5 points ahead | 17:05 |
| nlsthzn | alo magespawn | 17:05 |
| Kilos | the comms okes just said if they get for we just need to beat them but if they get 5 we then need to win with bonus | 17:05 |
| Kilos | hows things magespawn | 17:06 |
| magespawn | Busy and you Kilos? Bit chilly tonight. | 17:07 |
| Kilos | im cruising ty. temp lekker here | 17:07 |
| nlsthzn | all depends on what they do in the next game uncle Kilos | 17:07 |
| Kilos | yeah | 17:07 |
| Kilos | lets hope | 17:07 |
| magespawn | Actually had to get the fleece out, and I am trying Kali | 17:08 |
| nlsthzn | lol me watching smite and kali is a character in it... I was like oO | 17:09 |
| magespawn | Lol | 17:09 |
| magespawn | Nope does not work, it is the 64 iso and i need the 32 | 17:26 |
| Kilos | aw | 17:27 |
| magespawn | Not a waste though, have it for the future | 17:27 |
| Kilos | oh you got a cold front over you magespawn | 17:27 |
| Kilos | and rain | 17:27 |
| magespawn | Yup, noot much rain though, need more | 17:28 |
| magespawn | S/noot/not | 17:28 |
| Kilos | gonna be gone tomorrow | 17:28 |
| magespawn | Apparently durban is also wet, so we might get more of that | 17:29 |
| Kilos | night all. sleep tight | 17:41 |
| === wiseman is now known as Guest6157 | ||
| Guest6157 | hi guys, I have the weirdest problem on 12.04 server. I have setup the server as an Internet gateway/fw with a proxy service. The weird problem is that I can connect perfectly from the fw to anywhere and I can ping from internal pc's to anywhere but as soon as I try to pull down real data it just hangs. Anyone out there with this experience? | 18:52 |
| Tonberry_ | can the firewall pull real data? | 18:53 |
| Guest6157 | Yup firewall can connect anywhere and pull any data. | 18:54 |
| Guest6157 | Here is an example to highlight the problem... | 18:54 |
| Guest6157 | I telnet to pop server at Afrihost from the gateway/fw and I connect and retr a message | 18:55 |
| Guest6157 | When I telnet from internal pc to the same pop server I connect fine. | 18:55 |
| Guest6157 | I type in user and pass and even list all the messages - no prob | 18:56 |
| Guest6157 | I retr a 900byte message - no problem | 18:56 |
| Guest6157 | When I try to retrieve a 14kb message it just hangs | 18:57 |
| Guest6157 | Any ideas? This is really wierd | 18:57 |
| Tonberry_ | does http work? | 18:57 |
| Guest6157 | I have masquerading turned on in iptables on ppp0 (i'm originating the pppoe from the fw) | 18:58 |
| Guest6157 | ALl protocols suffer the same problem. If I http via the proxy - no problem | 18:59 |
| Guest6157 | If I bypass the proxy it just hangs after the initial connection setup (about 4 packets each way) | 18:59 |
| Tonberry_ | wireshark/tcpdump showing anything interesting? | 19:01 |
| Guest6157 | Nothing I can figure, here is the dump with a telnet on port 80 | 19:01 |
| Guest6157 | root@gateway:~# tcpdump -n -i ppp0 port 80 and host www.perfecthideaways.co.za tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 21:02:48.135726 IP 197.242.144.109.80 > 105.236.125.92.52397: Flags [S.], seq 985820861, ack 3455156208, win 14480, options [mss 1460,sackOK,TS val 3833888364 ecr 6018902,nop,wscale 7], length 0 21 | 19:03 |
| Guest6157 | 21:02:48.135921 IP 105.236.125.92.52397 > 197.242.144.109.80: Flags [.], ack 1, win 115, options [nop,nop,TS val 6018911 ecr 3833888364], length 0 21:02:49.134833 IP 197.242.144.109.80 > 105.236.125.92.52397: Flags [S.], seq 985820861, ack 3455156208, win 14480, options [mss 1460,sackOK,TS val 3833889364 ecr 6018911,nop,wscale 7], length 0 | 19:04 |
| Tonberry_ | pastebin might be a better medium for this | 19:05 |
| Guest6157 | OK :) you gonna have to help me - my first time on IRC | 19:05 |
| Tonberry_ | http://slexy.org or something similar. | 19:06 |
| Tonberry_ | Paste it there and paste the url here. | 19:06 |
| Guest6157 | http://slexy.org/raw/s21ZYC3JBv | 19:08 |
| Guest6157 | I ran a tcpdump on the inside interface as well and it is (afaik) the same | 19:09 |
| Guest6157 | I have checked the MTU's on interfaces incl ppp | 19:11 |
| Guest6157 | No mtu limit set in etc/ppp/options | 19:14 |
| Tonberry_ | have you tried pings with large lengths? | 19:14 |
| Guest6157 | Yup 5k pings run fine but obviously take a little longer to come back | 19:15 |
| Tonberry_ | no other strange iptables rules that could start dropping packets? | 19:17 |
| Guest6157 | Just ran a 15k ping and runs fine - it gets chopped into 20 packets - but all normal | 19:18 |
| Guest6157 | I am running my own simple iptables rules to firewall the thing. | 19:18 |
| Guest6157 | I am running the exact same rules on the orginal fw - this one is the replacement | 19:19 |
| Tonberry_ | then i am out of ideas | 19:20 |
| Guest6157 | hmmm, your comment made me ahve another look and I see some of the rules were using eth1 - not eth3 of outside if | 19:22 |
| Guest6157 | let em test quick | 19:22 |
| magespawn | Rubber duck. | 19:23 |
| Guest6157 | shoot that broke it - need to check out where the break is | 19:25 |
| Guest6157 | OK, it reinstated the port 80 block to enforce proxy use | 19:35 |
| superfly | Guest6157: for a light-weight firewall that is easy to configure, I recommend Arno's IP Tables Firewall, it's in the repos | 19:35 |
| superfly | Guest6157: it does NAT, forwarding, etc. | 19:35 |
| Guest6157 | problem still exactly the same -- any ideas? | 19:35 |
| Tonberry_ | anything odd in kernel logs? | 19:37 |
| Guest6157 | I'll take a look - at the risk of security I have posted the rules in case you guys can see something schupit - http://slexy.org/raw/s20Vcz8JKq | 19:42 |
| Guest6157 | nothing popping up in kern logs | 19:45 |
| Guest6157 | Here is something interesting - when I download a 1039byte email I see this | 19:54 |
| Guest6157 | 21:51:43.264805 IP 197.242.144.109.110 > 105.236.125.92.35805: Flags [P.], seq 1161:2220, ack 73, win 114, options [nop,nop,TS val 3836823444 ecr 6752746], length 1059 | 19:54 |
| Guest6157 | You see the 1059 byte packet | 19:54 |
| Guest6157 | When I download a 4542byte email I see this | 19:55 |
| Tonberry_ | iptables -t filter -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT | 19:55 |
| Guest6157 | 21:52:25.929352 IP 197.242.144.109.110 > 105.236.125.92.35805: Flags [P.], seq 6564:6782, ack 82, win 114, options [nop,nop,TS val 3836866111 ecr 6763413], length 218 | 19:55 |
| Tonberry_ | what happens with that one if you change it to eth3? | 19:55 |
| Guest6157 | Only a 218 byte packet followed by ack 2220bytes | 19:56 |
| Guest6157 | Hmm let me see why that is there | 19:58 |
| Guest6157 | That rule is supposed to only allow 'state' traffic inbound to inside interface | 20:02 |
| Tonberry_ | you already have iptables -t filter -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT | 20:03 |
| Tonberry_ | higher up | 20:03 |
| Guest6157 | hmmm, let me delete and see | 20:03 |
| Tonberry_ | I don't think it should make a difference but then again your setup should work | 20:04 |
| Guest6157 | Ya that didn't change anything | 20:07 |
| Guest6157 | It is almost certainly got to do with the packet size | 20:11 |
| Tonberry_ | yeah that is weird | 20:11 |
| Tonberry_ | why does it ack for so much data? | 20:14 |
| Guest6157 | Good point, let me see the packets going out before they get to the fw | 20:15 |
| Guest6157 | Same packets inside (pc interface) and outside (ppp0) | 20:21 |
| Guest6157 | The packet with length 218 is returning packet from the server | 20:24 |
| Guest6157 | Let's see what the packets direct from the gateway look like | 20:24 |
| Guest6157 | Here is the comparison between the pc and the fw downloading the same email message using retr | 20:30 |
| Guest6157 | http://slexy.org/raw/s20wXm94lw | 20:30 |
| Guest6157 | This is the first packet coming back from the pop server (fw connection) | 20:32 |
| Guest6157 | 22:27:04.181099 IP 197.242.144.109.110 > 105.236.125.92.38959: Flags [.], seq 1:1441, ack 9, win 114, options [nop,nop,TS val 3838944325 ecr 7553708], length 1440 | 20:32 |
| Tonberry_ | it looks like the pc is only getting the very last packet | 20:33 |
| Guest6157 | This is the first packet coming back from the server (pc inside) | 20:33 |
| Guest6157 | 22:19:54.266592 IP 197.242.144.109.110 > 10.1.1.6.35807: Flags [P.], seq 5625:5843, ack 73, win 114, options [nop,nop,TS val 3838422348 ecr 7152511], length 218 | 20:33 |
| Tonberry_ | is this the same connections as seen from the server and pc? | 20:34 |
| Tonberry_ | or is this the pc attempting it and the server attempting it? | 20:34 |
| Guest6157 | This is seperate connections | 20:36 |
| Guest6157 | But I think you are onto something because the serial nos don;t line up | 20:37 |
| Tonberry_ | the pc also ack 1281 twice | 20:37 |
| Tonberry_ | looks like it trying to go for a fast retransmit | 20:37 |
| Tonberry_ | acks* | 20:38 |
| Tonberry_ | still looks a lot like a mtu issue | 20:38 |
| Tonberry_ | what happens when you force the ppp device mtu to 500 | 20:39 |
| Tonberry_ | ? | 20:39 |
| Tonberry_ | what is the MTU on your internal network interfaces? | 20:41 |
| Tonberry_ | eth3 if I understand your server correctly | 20:41 |
| Guest6157 | can't force a higher mtu on the ppp interface - can only set the max limit but it will auto negotiate a lower one if it feels needs to | 20:43 |
| Tonberry_ | the default is lower than 500? | 20:44 |
| Guest6157 | both phys interfaces have 1500 mtu - let me check the ppp settings again | 20:45 |
| Guest6157 | inet addr:105.236.125.92 P-t-P:105.236.10.129 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 | 20:46 |
| Tonberry_ | I think its worth a try to test with a lower mtu on the ppp interface | 20:48 |
| Tonberry_ | ip link set dev ppp? mtu 500 | 20:48 |
| Tonberry_ | or something similar | 20:48 |
| Tonberry_ | 500 is usually small enough to keep anything happy | 20:49 |
| Guest6157 | Oh you think I should bring it down? Let me do that | 20:49 |
| Tonberry_ | to me it looks like the large packets go missing, if the MTU is smaller then the server should only respond with packets that it thinks will fit the MTU | 20:50 |
| Guest6157 | # Set the MTU [Maximum Transmit Unit] value to <n>. Unless the peer # requests a smaller value via MRU negotiation, pppd will request that # the kernel networking code send data packets of no more than n bytes # through the PPP network interface. | 20:52 |
| Guest6157 | ifconfig still shows MTU 1492 on PPP0 | 20:53 |
| Guest6157 | I'm trying the connection | 20:53 |
| Guest6157 | When I download 4542byte message the first return packet seen on ppp0 is seq no 4345:4563 (218 bytes) - I think it is the last packet for some reason as you said | 20:59 |
| Tonberry_ | try running | 20:59 |
| Tonberry_ | ip link set dev ppp0 mtu 500 | 20:59 |
| Tonberry_ | while the connection is active | 20:59 |
| Guest6157 | Why would it be withholding those packets? | 20:59 |
| Tonberry_ | and see if that makes any difference to the mtu/packets | 21:00 |
| Tonberry_ | something has to be dropping them for some reason | 21:00 |
| Tonberry_ | mmm | 21:00 |
| Guest6157 | Yup I'll try but it's not like I'm seeing the packets and then they are getting chopped. I just never see them | 21:01 |
| Tonberry_ | an interface somewhere that refuses to fragment packets? | 21:01 |
| Tonberry_ | my theory is that with a low enough MTU there should never be any big packets sent to you | 21:01 |
| Tonberry_ | also in the cases it does work the final packet is 242 bytes while in the not working cases it is 218 | 21:02 |
| Tonberry_ | so the packets that do not get through have to be bigger | 21:03 |
| Guest6157 | 1st packet back from server still seq 4586:4804 (218 bytes) | 21:05 |
| Tonberry_ | ok | 21:06 |
| Guest6157 | I noticed that this packet acks seq 65 which is the last packet from the pc - so no missing packets | 21:06 |
| Tonberry_ | ok try lower the MTU of the pc | 21:07 |
| Guest6157 | OK that may bring up something - just before we do that I'm going to increase the snap len to catch the whole packet and dig in the contents to see if the 1st outgoing packet is different | 21:09 |
| Tonberry_ | ok | 21:09 |
| Tonberry_ | try allowing inbound icmp fragment packets in iptables | 21:17 |
| Guest6157 | It is still the last packet that comes back (although trancated to 218 bytes as you say) but the data is the almost last words form the email | 21:22 |
| Guest6157 | Good point on the icmp - let me see if those packets are coming back or going to the server) | 21:23 |
| Guest6157 | I looked at the raw packet data and it has some differences but I cannot tell what - let me see if I can interpret with tcpdump | 21:24 |
| Tonberry_ | you could try saving it to pcap and opening the capture with wireshark | 21:25 |
| Guest6157 | Not familiar with wireshark (is it gui?) | 21:31 |
| Tonberry_ | yes | 21:31 |
| Guest6157 | But I have looked through using some tcpdump options to give ASCII printout | 21:31 |
| Guest6157 | Can;t see anything useful in the outgoing packet | 21:31 |
| Tonberry_ | you can use it to capture packets directly or view pre captured packets | 21:31 |
| Guest6157 | I'll put it on slexy | 21:32 |
| Tonberry_ | i suspect your ISP has a router somewhere that drops packets instead of fragmenting them | 21:32 |
| Guest6157 | Yes but how would that explain the packets working fine when originating from the fw | 21:33 |
| Tonberry_ | the ppp device has a slightly lower mtu than the ethernet device | 21:33 |
| Guest6157 | From the network pov it is the same IP address | 21:33 |
| Tonberry_ | so when the firewall directly negotiates the tcp connection it tells the server the MTU of the interface it is using | 21:33 |
| Guest6157 | we dropped the mtu to 500 so there should be no fragementation | 21:33 |
| Tonberry_ | when the pc does negotiates it tells the server its mtu is 1500 | 21:34 |
| Tonberry_ | an for some reason the usual fragmentation/mtu discovery is not picking this up and fixing it | 21:34 |
| Guest6157 | Wait, we dropped the mtu of the ppp int - which means all internal packets will be fragmented | 21:34 |
| Tonberry_ | thats my best guess | 21:35 |
| Guest6157 | we should drop the mtu of the internal if | 21:35 |
| Tonberry_ | that could work | 21:35 |
| Guest6157 | and put the ppp back to max | 21:35 |
| Tonberry_ | you could also try something like http://lartc.org/howto/lartc.cookbook.mtu-mss.html | 21:36 |
| Guest6158 | Hey Tonberry_ you still there - I think all the messing around dropped my login | 21:54 |
| Guest6158 | I implemented the iptables hack but did not have an effect | 21:55 |
| Tonberry_ | ah, any luck so far? | 21:55 |
| Guest6158 | the MTU on the internal interface to 500 also didn;t work | 21:56 |
| Guest6158 | if I send you the raw packets could you push them through wireshark and see if anything jumps out at you? | 21:57 |
| Tonberry_ | i could have a look | 21:57 |
| Guest6158 | Gonna need some pointers again - whats the best way? | 21:58 |
| Tonberry_ | mmm, good question | 21:59 |
| Guest6158 | you can text/whatsapp me your email on 0828881734 | 22:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!