Bug#692025: linux: internet connection refused after new route
On 11/12/2012 10:26 AM, Jonathan Nieder wrote: > Patrik Nilsson wrote: > >> Ping doesn't work to ip address 8.8.8.8. > > Let's start there. What is its output? > 100% Packet Loss. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a0c641.30...@gmail.com
Bug#692025: linux: internet connection refused after new route
Patrik Nilsson wrote: > Ping doesn't work to ip address 8.8.8.8. Let's start there. What is its output? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121112092612.GA9715@elie.Belkin
Bug#692025: linux: internet connection refused after new route
On 11/12/2012 10:06 AM, Jonathan Nieder wrote: > Thanks. I think you misunderstood, though: I meant that we need a > trace illustrating what it means that the connection just doesn't > work. > Example: nslookup doesn't work. Times out. Firefox can't look up Internet addresses. Firefox can't connect to websites. Firefox can't download webpages. Ping doesn't work to ip address 8.8.8.8. Thunderbird can't look up and download emails. Patrik -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a0c024.3040...@gmail.com
Bug#692025: linux: internet connection refused after new route
Patrik Nilsson wrote: > On 11/05/2012 02:59 AM, Jonathan Nieder wrote: >> Patrik Nilsson wrote: >>> No error messages or anything else is shown: The connection just doesn't >>> work [...] >>Also could you strace a >> program that tries to connect and fails in this scenario, so we can >> see what syscalls it makes and what response the kernel gives? [...] > 2012-11-11_134012 block/ > 2012-11-11_134012 block/traceiptablesdown.txt > 2012-11-11_134012 block/traceiptablesup.txt > 2012-11-11_134012 block/traceopenpvpn.txt > 2012-11-11_134012 block/traceresolvconfup.txt > 2012-11-11_134012 block/traceroutebefore.txt > 2012-11-11_134123 pass/ > 2012-11-11_134123 pass/traceiptablesdown.txt > 2012-11-11_134123 pass/traceiptablesup.txt > 2012-11-11_134123 pass/traceopenpvpn.txt > 2012-11-11_134123 pass/traceresolvconfup.txt > 2012-11-11_134123 pass/traceroutebefore.txt > account.txt > down.sh > ivacy-ca.crt > ivacy-client.crt > ivacy-client.key > ivacy-client.ovpn > ivacy-tls.key > start.sh > up.sh Thanks. I think you misunderstood, though: I meant that we need a trace illustrating what it means that the connection just doesn't work. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121112090600.GG3581@elie.Belkin
Bug#692025: linux: internet connection refused after new route
On Sun, 2012-11-04 at 17:59 -0800, Jonathan Nieder wrote: > Patrik Nilsson wrote: > > > No error messages or anything else is shown: The connection just doesn't > > work when I try it. It is why I suspect that if a (background) program > > holds a socket open, the kernel can't set the route. Although it reports > > the correct route. > > I don't know anything about these things --- Ben is the networking > expert here. :) While the existence of a socket can make the kernel hold onto routing information that has otherwise been deleed, this is not supposed to affect routing for any new sockets. Ben. > Anyway, could you send "ip r" output from before and after connecting > to your openvpn server, just to humor us? Also could you strace a > program that tries to connect and fails in this scenario, so we can > see what syscalls it makes and what response the kernel gives? -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#692025: linux: internet connection refused after new route
Patrik Nilsson wrote: > No error messages or anything else is shown: The connection just doesn't > work when I try it. It is why I suspect that if a (background) program > holds a socket open, the kernel can't set the route. Although it reports > the correct route. I don't know anything about these things --- Ben is the networking expert here. :) Anyway, could you send "ip r" output from before and after connecting to your openvpn server, just to humor us? Also could you strace a program that tries to connect and fails in this scenario, so we can see what syscalls it makes and what response the kernel gives? Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121105015923.GA6277@elie.Belkin
Bug#692025: linux: internet connection refused after new route
On 11/04/2012 07:00 PM, Jonathan Nieder wrote: > Hi Patrik, > I suspect there was a miscommunication here: if I understand > correctly, Ben was looking for a simple sequence of steps and, for > each step, a routing table from after that step. This would help him > to understand what was happening when you ran into this problem. > Perhaps he could run similar steps in a similar setup and compare, to > track down where the problem lies. > > See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for more > context. > > Thanks for your patience, and hope that helps. > Jonathan > Hi Jonathan, I would like to help, but the difference of what happens when it works and doesn't is seemingly none. No error messages or anything else is shown: The connection just doesn't work when I try it. It is why I suspect that if a (background) program holds a socket open, the kernel can't set the route. Although it reports the correct route. This error has also happened when I started Firefox to early and it checks for updates. When this error happens, I retry the connection (ctrl+c for openvpn and run it again). Sometimes I need to retry several (3-4) times, but usually one retry is enough. I have tested this bug with two different providers of openvpn-services and there is no difference. It has of course was easier to help the bug hunting, when the same error always happens in a sequence. Do you have any kind of dump program, to report all the status of all connections, which also reports the true state of the kernel? This error also exists in Ubuntu 11.04. (I haven't been using any later.) Best regards, Patrik -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5096cb81.20...@gmail.com
Bug#692025: linux: internet connection refused after new route
Hi Patrik, Ben Hutchings wrote: > On Thu, 2012-11-01 at 13:58 +0100, Patrik Nilsson wrote: >> I suspect this bug is when a task (i.e. ntp, virus updater, ...) tries >> to connect to the Internet through a socket using the first interface, >> holds it open, the kernel won't reroute to the new one and you need try >> to again. [...] >> Example: When one wlan connection is up and you try to connect throught an >> other one, you need to retry. >> >> I have tested both examples with lftp trying to connect to an IP-address >> and you cant' connect as long as lftp's socket is in effect. > > Please explain in more detail what you're doing: > - All the commands you run to reconfigure and use the network > - The routing table (as shown by 'ip r') after each reconfiguration I suspect there was a miscommunication here: if I understand correctly, Ben was looking for a simple sequence of steps and, for each step, a routing table from after that step. This would help him to understand what was happening when you ran into this problem. Perhaps he could run similar steps in a similar setup and compare, to track down where the problem lies. See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for more context. Thanks for your patience, and hope that helps. Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104180006.GA28816@elie.Belkin
Bug#692025: linux: internet connection refused after new route
Giving up on this as the submitter won't explain himself. Ben. -- Ben Hutchings No political challenge can be met by shopping. - George Monbiot signature.asc Description: This is a digitally signed message part
Bug#692025: linux: internet connection refused after new route
On 11/02/2012 06:22 AM, Ben Hutchings wrote: > You haven't sent this: > >>> - The routing table (as shown by 'ip r') after each reconfiguration > > Ben. > patrik@debian:~$ ip r 213.232.200.170 via 192.168.1.1 dev eth1 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 2 1.2.124.0/24 dev tun0 proto kernel scope link src 1.2.124.10 169.254.0.0/16 dev eth1 scope link metric 1000 1.0.0.0/8 via 1.2.124.1 dev tun0 default via 1.2.124.1 dev tun0 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5093f48a.8050...@gmail.com
Bug#692025: linux: internet connection refused after new route
You haven't sent this: > > - The routing table (as shown by 'ip r') after each reconfiguration Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Bug#692025: linux: internet connection refused after new route
On 11/01/2012 03:13 PM, Ben Hutchings wrote: > On Thu, 2012-11-01 at 13:58 +0100, Patrik Nilsson wrote: >> Package: linux >> Version: linux-image > > Can we have a real version number please? (/proc/version will show the > Debian package version for the running kernel). > Linux version 2.6.32-5-686 (Debian 2.6.32-46) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sun Sep 23 09:49:36 UTC 2012 >> Severity: important >> Tags: upstream >> >> When one lan interface is connected and you try to connect an other one, >> often you can't connect to the Internet after that. You need to retry the >> connection. >> >> I suspect this bug is when a task (i.e. ntp, virus updater, ...) tries >> to connect to the Internet through a socket using the first interface, >> holds it open, the kernel won't reroute to the new one and you need try >> to again. >> >> Example: When a openvpn connection is made and initiation is okey, but you >> can't connect to the Internet, through the openvpn-connection. Retrying it >> and you can connect. >> >> Example: When one wlan connection is up and you try to connect throught an >> other one, you need to retry. >> >> I have tested both examples with lftp trying to connect to an IP-address >> and you cant' connect as long as lftp's socket is in effect. > > Please explain in more detail what you're doing: > - All the commands you run to reconfigure and use the network > - The routing table (as shown by 'ip r') after each reconfiguration Openvpn reconfigurates the routing by itself, and no warnings are issued about the route or the connection. Everything seems to be okay. Example Openvpn: 1) Connect to an openvpn server using: /usr/sbin/openvpn --config $config --auth-user-pass account.txt --mute-replay-warnings 2) Almost every time the first connection attempt fails, and I need to retry the connection. Example WLAN: 1) Connect WLAN from your computer to a router 1 2) run lftp 192.168.0.123 -e "set ssl:verify-certificate no;set dns:fatal-timeout 1m; set net:idle 30s; set net:max-retries 10; set net:reconnect-interval-multiplier 1; set net:timeout 30s; set xfer:disk-full-fatal true; set net:reconnect-interval-base 5; cd \"test\"; mkdir -p \"test\"; set cmd:fail-exit yes; put -E -c \"test\" -o \"test\"; quit" 3) Connect WLAN to router 2 I have a script that does this for me. When the script is running, the connection change fails. Of course it didn't do it when I tried to get the bug showing from the command line. > > Ben. > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5092a39f.4090...@gmail.com
Bug#692025: linux: internet connection refused after new route
On Thu, 2012-11-01 at 13:58 +0100, Patrik Nilsson wrote: > Package: linux > Version: linux-image Can we have a real version number please? (/proc/version will show the Debian package version for the running kernel). > Severity: important > Tags: upstream > > When one lan interface is connected and you try to connect an other one, > often you can't connect to the Internet after that. You need to retry the > connection. > > I suspect this bug is when a task (i.e. ntp, virus updater, ...) tries > to connect to the Internet through a socket using the first interface, > holds it open, the kernel won't reroute to the new one and you need try > to again. > > Example: When a openvpn connection is made and initiation is okey, but you > can't connect to the Internet, through the openvpn-connection. Retrying it > and you can connect. > > Example: When one wlan connection is up and you try to connect throught an > other one, you need to retry. > > I have tested both examples with lftp trying to connect to an IP-address > and you cant' connect as long as lftp's socket is in effect. Please explain in more detail what you're doing: - All the commands you run to reconfigure and use the network - The routing table (as shown by 'ip r') after each reconfiguration Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Bug#692025: linux: internet connection refused after new route
Package: linux Version: linux-image Severity: important Tags: upstream When one lan interface is connected and you try to connect an other one, often you can't connect to the Internet after that. You need to retry the connection. I suspect this bug is when a task (i.e. ntp, virus updater, ...) tries to connect to the Internet through a socket using the first interface, holds it open, the kernel won't reroute to the new one and you need try to again. Example: When a openvpn connection is made and initiation is okey, but you can't connect to the Internet, through the openvpn-connection. Retrying it and you can connect. Example: When one wlan connection is up and you try to connect throught an other one, you need to retry. I have tested both examples with lftp trying to connect to an IP-address and you cant' connect as long as lftp's socket is in effect. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121101125833.3766.58520.reportbug@debian
