Re: Help needed: pkg_add dropps connections
On Tue, 17 Feb 2015 15:15:14 +0100, Stefan Wollny wrote: Hello! I'd like to pick up an issue that is bugging me for some time now: Whenever I run 'pkg_add -ui' my connection gets terminated soon, reliably at the latest once packages starting with g are checked. I suspect it is in my pf.conf but it is not obvious to me. I'll get terminated connection error and route not found from pkg_add from some mirrors, e.g. http://mirror.team-cymru.org/pub/OpenBSD/, but others OK e.g. http://mirrors.gigenet.com/pub/OpenBSD/ Single file fetches will work though. # pfctl -d pfctl: pf not enabled # # export PKG_PATH=http://mirror.team-cymru.org/pub/OpenBSD/snapshots/ amd64/ # pkg_add -ui Error from http://mirror.team-cymru.org/pub/OpenBSD/snapshots/amd64/ ftp: connect: No route to host # ftp http://mirror.team-cymru.org/pub/OpenBSD/snapshots/amd64/ INSTALL.amd64 Trying 38.229.66.100... Requesting http://mirror.team-cymru.org/pub/OpenBSD/snapshots/amd64/ INSTALL.amd64 100% |**| 46518 00:00 46518 bytes received in 0.07 seconds (628.23 KB/s) export PKG_PATH=http://mirrors.gigenet.com/pub/OpenBSD/snapshots/ packages/amd64 # pkg_add -ui Checking packages|No change in aspell-0.60.6.1p1 Checking packages|No change in blas-1.0p6 Checking packages|No change in gimp-2.8.14Checking packages|No change in blas-1.0p6 Use debugging for ftp command: # export FETCH_CMD=/usr/bin/ftp -d # pkg_add -ui Error from http://mirror.team-cymru.org/pub/OpenBSD/snapshots/amd64/ host mirror.team-cymru.org, port (null), path pub/OpenBSD/snapshots/ amd64/, save as -, auth (null). Host: mirror.team-cymru.org User-Agent: OpenBSD ftp received 'HTTP/1.0 200 OK' received 'Content-Type: text/html' received 'Content-Length: 5209' received 'Connection: close' received 'Date: Sat, 21 Feb 2015 21:24:27 GMT' received 'Server: mirror.team-cymru.org' http://mirror.team-cymru.org/pub/OpenBSD/snapshots/amd64/ is empty # uname -a OpenBSD puffy-san.rsiegler.net 5.7 GENERIC.MP#858 amd64 # OpenBSD 5.7-beta (GENERIC.MP) #0: Mon Feb 16 16:14:55 CST 2015 r...@puffy-san.rsiegler.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17162633216 (16367MB) avail mem = 16701853696 (15928MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfd3f0 (50 entries) bios0: vendor American Megatrends Inc. version V1.10 date 02/28/2011 bios0: MICRO-STAR INTERNATIONAL CO.,LTD MS-7596 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7 (S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PSKE(S4) PSMS(S4) ECIR (S4) PS2K(S1) PS2M(S1) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X6 1075T Processor, 3000.62 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH, MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2, 3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/ line 16-way L2 cache, 6MB 64b/line 48-way L3 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X6 1075T Processor, 3000.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX, FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW, LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/ line 16-way L2 cache, 6MB 64b/line 48-way L3 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Phenom(tm) II X6 1075T Processor, 3000.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV, PAT,PSE36,CFLUSH,MMX, FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW, LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/ line 16-way L2 cache, 6MB 64b/line 48-way L3 cache cpu2: ITLB 32
Re: Help needed: pkg_add dropps connections
On 2015-02-18, Stefan Wollny stefan.wol...@web.de wrote: Am 02/18/15 um 17:08 schrieb Stuart Henderson: On 2015-02-18, Stefan Wollny stefan.wol...@web.de wrote: Could mss 1460 be the core of the issue? I have the following: ~ $ sudo cat /etc/pf.conf | grep mss match in all scrub (no-df random-id max-mss 1440) ~ $ sudo cat /etc/sysctl.conf | grep mss net.inet.tcp.mssdflt=1440 Neither of these make sense on a typical laptop, and they make me query what else you might have changed on the system. Oh, so I see where you got these now. PLEASE IGNORE CALOMEL DOT ORG, THE SITE GIVES BAD ADVICE. What does pfctl -si say? When you get the no route to host, what does e.g. route -n get 8.8.8.8 say? (i.e. some host on the internet). Are you able to ping your fritzbox or the proxy-server at that time? Hi Stuart, to answer your question: No, the line is dead - I can't ping anything. Well, I asked several questions, in the hope of trying to find out what's actually going on rather than working around by bouncing the connections off another machine. Oh well. But I just received off-list the suggestion from Gene that the environment variables might not being passed on to root. I followed his advice like so: Yes various people had already mentioned that about sudo on-list too ;)
Re: Help needed: pkg_add dropps connections
On 2015/02/19 15:02, Stefan Wollny wrote: Sorry for top-posting: The web-mailer I have to use at present is pretty dump... :-( Now that you mention it, I remember vaguely that I saw it on that site too, a lng time ago. But this sysctl.conf-setting I found on bsdnow.tv: http://www.bsdnow.tv/tutorials/openbsd-router Thank you for (again) pinpointing to this being no good advice. I am not shure where I read the hint on pf.conf's max-mss to meet the sysctl.conf-entry. If this is BS should I delete the entry in both conf-files or only in the sysctl.conf? On an end-host I would remove them both. On a router, you might need scrub (max-mss), it can be useful where the upstream interface has restricted MTU (often happens with vpn and pppoe interfaces depending on the configuration).
Re: Help needed: pkg_add dropps connections
Am Mittwoch, den 18.02.2015, 08:46 +0100 schrieb Stefan Wollny: Only with 'pkg_add' the connection is entirely gone and 'pkg_add' subsequently complains about 'No route to host'... and only on this particular machine. Just wildly guessing here: At least on Linux, the kernel will reply No route to host not only if there is no route in the routing table, but also if it received an ICMP dest unreach, including admin prohibited. Maybe it would be useful tcpdump the the line (maybe add lo0 in case it's something locally generated) to see if something suspicious is happening when the connection terminates. -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 01:40 schrieb Nick Holland: On 02/17/15 18:59, Stefan Wollny wrote: ftp: connect: No route to host you need to fix that before you worry about anything. Once you get THAT fixed, then you can get back to worrying about your dropping connections. Gotta make it before you can drop it. Mmmmh - it may not be related to the issue of this thread, but /var/log/messages has nothing when the connection is lost. At connect there are two complaints from avahi-daemon and adsuck: ~ $ date sh reconnect Wed Feb 18 11:56:45 CET 2015 ifconfig: SIOCGIFFLAGS: Device not configured loopback localhostdone BASE-ADDRESS.MCAST.N link#5 done ::/128 localhostdone ::/128 localhostdone ::127.0.0.0/128 localhostdone ::224.0.0.0/128 localhostdone ::255.0.0.0/128 localhostdone :::0.0.0.0/128 localhostdone 2002::/128 localhostdone 2002:7f00::/128 localhostdone 2002:e000::/128 localhostdone 2002:ff00::/128 localhostdone fe80::/128 localhostdone fec0::/128 localhostdone ff01::/128 localhostdone ff02::/128 localhostdone ifconfig: SIOCSTRUNKPORT: Device busy ifconfig: SIOCSTRUNKPORT: Device busy DHCPREQUEST on trunk0 to 255.255.255.255 DHCPREQUEST on trunk0 to 255.255.255.255 DHCPACK from 192.168.178.1 (00:24:fe:31:e3:ea) bound to 192.168.178.31 -- renewal in 432000 seconds. ~ $ date tail -f /var/log/messages Wed Feb 18 11:56:43 CET 2015 [... older stuff omitted .. ] Feb 18 11:56:45 idefix dhclient[26941]: trunk0 down; exiting Feb 18 11:56:45 idefix avahi-daemon[12643]: IP_DROP_MEMBERSHIP failed: Can't assign requested address Feb 18 11:56:45 idefix adsuck[16092]: can't convert wire packet to struct I'd like to point out that the connection is lost too when running 'pkg_add' right on the console. And YES - I had tried without adsuck enabled before. I had posted it yesterday but here is once more the reconnect-script: ~ $ cat reconnect #/bin/sh sudo /sbin/ifconfig em0 down sudo /sbin/ifconfig wpi0 down sudo /sbin/ifconfig rsu0 down sudo /sbin/ifconfig trunk0 down sudo /sbin/route flush sudo sh /etc/netstart
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 10:19 schrieb David Dahlberg: Am Mittwoch, den 18.02.2015, 08:46 +0100 schrieb Stefan Wollny: Only with 'pkg_add' the connection is entirely gone and 'pkg_add' subsequently complains about 'No route to host'... and only on this particular machine. Just wildly guessing here: At least on Linux, the kernel will reply No route to host not only if there is no route in the routing table, but also if it received an ICMP dest unreach, including admin prohibited. Maybe it would be useful tcpdump the the line (maybe add lo0 in case it's something locally generated) to see if something suspicious is happening when the connection terminates. Hi David, thank you for your suggestions. Well - I am just an ordinary OpenBSD-user lacking any knowledge of the kernel's interna. So I can't really comment on that, except that I have pass on $ext_if inet proto icmp all icmp-type 8 code 0 in my pf.conf. I picked up your suggestion on watching lo0 as well (pflog0 has nothing!). Here are the last lines before the connection is lost (below this I post the output of netstat): Feb 18 11:27:22.550315 127.0.0.1.53 127.0.0.1.7621: 27100 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:22.825300 127.0.0.1.44811 127.0.0.1.53: 43221+ A? ftp.hostserver.de. (35) Feb 18 11:27:22.827907 127.0.0.1.53 127.0.0.1.44811: 43221 1/0/0 A 217.31.80.35 (68) Feb 18 11:27:22.828023 127.0.0.1.34231 127.0.0.1.53: 50848+ ? ftp.hostserver.de. (35) Feb 18 11:27:22.831648 127.0.0.1.53 127.0.0.1.34231: 50848 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:23.098915 127.0.0.1.16511 127.0.0.1.53: 8621+ A? ftp.hostserver.de. (35) Feb 18 11:27:23.101493 127.0.0.1.53 127.0.0.1.16511: 8621 1/0/0 A 217.31.80.35 (68) Feb 18 11:27:23.101653 127.0.0.1.46720 127.0.0.1.53: 2234+ ? ftp.hostserver.de. (35) Feb 18 11:27:23.105205 127.0.0.1.53 127.0.0.1.46720: 2234 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:23.405236 127.0.0.1.45409 127.0.0.1.53: 4242+ A? ftp.hostserver.de. (35) Feb 18 11:27:23.407778 127.0.0.1.53 127.0.0.1.45409: 4242 1/0/0 A 217.31.80.35 (68) Feb 18 11:27:23.407947 127.0.0.1.16371 127.0.0.1.53: 8430+ ? ftp.hostserver.de. (35) Feb 18 11:27:23.411508 127.0.0.1.53 127.0.0.1.16371: 8430 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:23.679032 127.0.0.1.2311 127.0.0.1.53: 25995+ A? ftp.hostserver.de. (35) Feb 18 11:27:23.681589 127.0.0.1.53 127.0.0.1.2311: 25995 1/0/0 A 217.31.80.35 (68) Feb 18 11:27:23.681730 127.0.0.1.37804 127.0.0.1.53: 28055+ ? ftp.hostserver.de. (35) Feb 18 11:27:23.685347 127.0.0.1.53 127.0.0.1.37804: 28055 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:24.100921 127.0.0.1.18524 127.0.0.1.53: 55509+ A? ftp.hostserver.de. (35) Feb 18 11:27:24.103570 127.0.0.1.53 127.0.0.1.18524: 55509 1/0/0 A 217.31.80.35 (68) Feb 18 11:27:24.103721 127.0.0.1.36652 127.0.0.1.53: 48339+ ? ftp.hostserver.de. (35) Feb 18 11:27:24.107271 127.0.0.1.53 127.0.0.1.36652: 48339 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:24.461192 127.0.0.1.45534 127.0.0.1.53: 8946+ A? ftp.hostserver.de. (35) Feb 18 11:27:24.463762 127.0.0.1.53 127.0.0.1.45534: 8946 1/0/0 A 217.31.80.35 (68) Feb 18 11:27:24.463896 127.0.0.1.13402 127.0.0.1.53: 38619+ ? ftp.hostserver.de. (35) Feb 18 11:27:24.467481 127.0.0.1.53 127.0.0.1.13402: 38619 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:25.022575 127.0.0.1.48140 127.0.0.1.53: 44181+ A? ftp.hostserver.de. (35) Feb 18 11:27:25.025149 127.0.0.1.53 127.0.0.1.48140: 44181 1/0/0 A 217.31.80.35 (68) Feb 18 11:27:25.025271 127.0.0.1.46973 127.0.0.1.53: 5352+ ? ftp.hostserver.de. (35) Feb 18 11:27:25.028825 127.0.0.1.53 127.0.0.1.46973: 5352 1/0/0 2a00:15a8:0:100:d91f:5023:0:1 (80) Feb 18 11:27:42.868652 127.0.0.1.17889 127.0.0.1.53: 46223+ TXT? current.cvd.clamav.net. (40) Feb 18 11:27:47.877392 127.0.0.1.21280 127.0.0.1.53: 46223+ TXT? current.cvd.clamav.net. (40) Feb 18 11:27:53.384447 127.0.0.1.44956 127.0.0.1.53: 48829+ A? imap.web.de. (29) Feb 18 11:27:57.887443 127.0.0.1.8685 127.0.0.1.53: 46223+ TXT? current.cvd.clamav.net. (40) Feb 18 11:27:58.387460 127.0.0.1.39806 127.0.0.1.53: 48829+ A? imap.web.de. (29) Feb 18 11:27:57.887443 127.0.0.1.8685 127.0.0.1.53: 46223+ TXT? current.cvd.clamav.net. (40) Feb 18 11:27:58.387460 127.0.0.1.39806 127.0.0.1.53: 48829+ A? imap.web.de. (29) Feb 18 11:28:08.397608 127.0.0.1.24938 127.0.0.1.53: 48829+ A? imap.web.de. (29) Feb 18 11:28:12.928554 127.0.0.1.53 127.0.0.1.17889: 46223 NXDomain*- 0/1/0 (147) Feb 18 11:28:12.928576 127.0.0.1 127.0.0.1: icmp: 127.0.0.1 udp port 17889 unreachable Feb 18 11:28:17.897755 127.0.0.1.45338 127.0.0.1.53: 46223+ TXT? current.cvd.clamav.net. (40) Feb 18 11:28:17.938892 127.0.0.1.53 127.0.0.1.21280: 46223 NXDomain*- 0/1/0 (147) Feb 18 11:28:17.938915 127.0.0.1 127.0.0.1: icmp: 127.0.0.1 udp port 21280 unreachable Feb 18 11:28:23.448486 127.0.0.1.53 127.0.0.1.44956: 48829
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 17:20 schrieb Stefan Wollny: # pkg_add -ui quirks-2.52 signed on 2015-02-17T13:51:20Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/adsuck-2.5.0p2.tgz ftp: Error retrieving file: 403 Forbidden # * S U C C E S S * (I don't care for that one file - the connection didn't fail!) Now we have to figure out how to make that permanent... For the records: Gene gave me a hint on using 'env_keep'. I had to do my homework first as I never had taken notice of this before 8-) Long story short: If I am at home where I use the http_proxy, enabling this in the sudoers file by env_keep makes my day. (Very 'difficult' to achieve - uncomment one line!). But if I go without the http_proxy-variable set like e.g. in a hotel the connections still gets lost. Only difference this time is the error-note which now says no address associated with name' and no longer 'No route to host. Again: A big THANK YOU to you all who helped with you time and knowledge! Best, STEFAN
Re: Help needed: pkg_add dropps connections
On Wed, Feb 18, 2015 at 10:27:12AM -0500, Alan Corey wrote: This is probably unrelated but I've noticed that the fetching that happens with make install in ports seems less robust than it used to be. If my internet provider disconnects or the connection gets reset beyond that, it doesn't resume the download. And I've tried setting FETCH_CMD to wget -c, it doesn't help much (in 5.6, that's what I have my 5.2 machine set to). So I do a make install, wait until I've got a working URL, then ctrl-c to stop it, copy the url, open another rxvt in the distfiles dir, type wget, paste the URL. wget very rarely fails. I've got portsql installed and was able to make myself some partial fetchlists from that but my query didn't find dependencies of dependencies. A scratch install of 5.6 still took a couple months. Fetching large subsets of distfiles just works handsomely with dpb -F
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 17:08 schrieb Stuart Henderson: On 2015-02-18, Stefan Wollny stefan.wol...@web.de wrote: Could mss 1460 be the core of the issue? I have the following: ~ $ sudo cat /etc/pf.conf | grep mss match in all scrub (no-df random-id max-mss 1440) ~ $ sudo cat /etc/sysctl.conf | grep mss net.inet.tcp.mssdflt=1440 Neither of these make sense on a typical laptop, and they make me query what else you might have changed on the system. What does pfctl -si say? When you get the no route to host, what does e.g. route -n get 8.8.8.8 say? (i.e. some host on the internet). Are you able to ping your fritzbox or the proxy-server at that time? Hi Stuart, to answer your question: No, the line is dead - I can't ping anything. But I just received off-list the suggestion from Gene that the environment variables might not being passed on to root. I followed his advice like so: # export http_proxy=http://192.168.178.23:3128 # export ftp_proxy=http://192.168.178.23:3128 # export PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/ # print $http_proxy http://192.168.178.23:3128 # print $ftp_proxy http://192.168.178.23:3128 # print $PKG_PATH http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/ # pkg_add -ui quirks-2.52 signed on 2015-02-17T13:51:20Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/adsuck-2.5.0p2.tgz ftp: Error retrieving file: 403 Forbidden # * S U C C E S S * (I don't care for that one file - the connection didn't fail!) Now we have to figure out how to make that permanent... At this point already I'd like to THANK YOU all who took some time to help me! Best, STEFAN
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 13:51 schrieb Marc Espie: On Tue, Feb 17, 2015 at 02:44:42PM -0800, Gene wrote: quirks-2.52 signed on 2015-02-14T12:43:06Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz ftp: connect: No route to host It's using ftp. I'm not familiar with how package management works with OpenBSD, so I don't know if this is a weird quirk of the pkg_add command or if he's not setting his package source properly. pkg_add does not do network connections directly for protocols where ftp(1) does know how to deal. pkg_add, however, closes connections aggressively when it's got the info it needs. If, somehow, your ftp setup is broken, then you might overflow the server with 100s of connections. Just do something like: ftp http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz (manually) close it halfway thru using ^C. If you don't see the connection being terminated properly, then you don't need to look further. That's your whole issue. or do it on something larger like http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/texlive_base-2013p3.tgz so that you have time to abort before the whole transfer is finished. OK: To rule out any implications I disabled the http-proxy in my .profile first. I checked for - ftp ftp://... - ftp http://... Both connections were terminated after 95 seconds (according to pftop) after closing with ^C. Now with http-proxy-variable being unset I gave 'pkg_add' another try: With 145 open connections the connection to the internet was lost.
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 15:07 schrieb Marc Espie: On Wed, Feb 18, 2015 at 02:32:39PM +0100, Stefan Wollny wrote: I checked for - ftp ftp://... - ftp http://... Both connections were terminated after 95 seconds (according to pftop) after closing with ^C. Now with http-proxy-variable being unset I gave 'pkg_add' another try: closing should be synchronous with the ^C giving you back the shell prompt. If it waits for 95 seconds, your network setup is fucked up. My mistake: Bad wording... The shell-prompt is back within 2~3 seconds. In a second xterm I had pftop running showing me that the connection was closed after the '95 seconds' I mentioned. Maybe I should change the SDD to another one and test with a fresh installation...
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 12:09 schrieb Stefan Wollny: Am 02/18/15 um 01:40 schrieb Nick Holland: On 02/17/15 18:59, Stefan Wollny wrote: ftp: connect: No route to host you need to fix that before you worry about anything. Once you get THAT fixed, then you can get back to worrying about your dropping connections. Gotta make it before you can drop it. Mmmmh - it may not be related to the issue of this thread, but /var/log/messages has nothing when the connection is lost. At connect there are two complaints from avahi-daemon and adsuck: ~ $ date sh reconnect Wed Feb 18 11:56:45 CET 2015 ifconfig: SIOCGIFFLAGS: Device not configured loopback localhostdone BASE-ADDRESS.MCAST.N link#5 done ::/128 localhostdone ::/128 localhostdone ::127.0.0.0/128 localhostdone ::224.0.0.0/128 localhostdone ::255.0.0.0/128 localhostdone :::0.0.0.0/128 localhostdone 2002::/128 localhostdone 2002:7f00::/128 localhostdone 2002:e000::/128 localhostdone 2002:ff00::/128 localhostdone fe80::/128 localhostdone fec0::/128 localhostdone ff01::/128 localhostdone ff02::/128 localhostdone ifconfig: SIOCSTRUNKPORT: Device busy ifconfig: SIOCSTRUNKPORT: Device busy DHCPREQUEST on trunk0 to 255.255.255.255 DHCPREQUEST on trunk0 to 255.255.255.255 DHCPACK from 192.168.178.1 (00:24:fe:31:e3:ea) bound to 192.168.178.31 -- renewal in 432000 seconds. ~ $ date tail -f /var/log/messages Wed Feb 18 11:56:43 CET 2015 [... older stuff omitted .. ] Feb 18 11:56:45 idefix dhclient[26941]: trunk0 down; exiting Feb 18 11:56:45 idefix avahi-daemon[12643]: IP_DROP_MEMBERSHIP failed: Can't assign requested address Feb 18 11:56:45 idefix adsuck[16092]: can't convert wire packet to struct I'd like to point out that the connection is lost too when running 'pkg_add' right on the console. And YES - I had tried without adsuck enabled before. I had posted it yesterday but here is once more the reconnect-script: ~ $ cat reconnect #/bin/sh sudo /sbin/ifconfig em0 down sudo /sbin/ifconfig wpi0 down sudo /sbin/ifconfig rsu0 down sudo /sbin/ifconfig trunk0 down sudo /sbin/route flush sudo sh /etc/netstart OK - I changed pf.conf to log on all allowed connections. Here are the last lines from 'tcpdump -nettti pflog0' before the connection is lost: Feb 18 12:28:09.752328 rule 20/(match) pass out on trunk0: 192.168.178.31.26112 217.31.80.35.80: S 2557329514:2557329514(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 965690760[|tcp] (DF) Feb 18 12:28:10.063647 rule 20/(match) pass out on trunk0: 192.168.178.31.11874 217.31.80.35.80: S 264716856:264716856(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2436088594[|tcp] (DF) Feb 18 12:28:10.376068 rule 20/(match) pass out on trunk0: 192.168.178.31.30104 217.31.80.35.80: S 2435427941:2435427941(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 47943579[|tcp] (DF) Feb 18 12:28:10.655702 rule 20/(match) pass out on trunk0: 192.168.178.31.40737 217.31.80.35.80: S 2432567211:2432567211(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 1107182930[|tcp] (DF) Feb 18 12:28:10.930614 rule 20/(match) pass out on trunk0: 192.168.178.31.41772 217.31.80.35.80: S 1999637066:1999637066(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2831739904[|tcp] (DF) Feb 18 12:28:12.941274 rule 20/(match) pass out on trunk0: 192.168.178.31.41934 217.31.80.35.80: S 1637879660:1637879660(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2522921076[|tcp] (DF) Feb 18 12:28:13.274194 rule 20/(match) pass out on trunk0: 192.168.178.31.15493 217.31.80.35.80: S 3826414152:3826414152(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 1932273166[|tcp] (DF) Feb 18 12:28:13.563635 rule 20/(match) pass out on trunk0: 192.168.178.31.12790 217.31.80.35.80: S 1899274144:1899274144(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 771850913[|tcp] (DF) Feb 18 12:28:13.894579 rule 20/(match) pass out on trunk0: 192.168.178.31.34868 217.31.80.35.80: S 220640463:220640463(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 1280756876[|tcp] (DF) Feb 18 12:28:14.069995 rule 20/(match) pass out on trunk0: 192.168.178.31.20335 217.31.80.35.80: S 726036165:726036165(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 391830302[|tcp] (DF) Feb 18 12:28:14.349303 rule 20/(match) pass out on trunk0: 192.168.178.31.2050 217.31.80.35.80: S 2533225330:2533225330(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 3452245743[|tcp] (DF) Feb 18 12:28:14.696570 rule 20/(match) pass out on trunk0:
Re: Help needed: pkg_add dropps connections
On Tue, Feb 17, 2015 at 03:15:14PM +0100, Stefan Wollny wrote: Hello! I'd like to pick up an issue that is bugging me for some time now: Whenever I run 'pkg_add -ui' my connection gets terminated soon, reliably at the latest once packages starting with g are checked. I suspect it is in my pf.conf but it is not obvious to me. My system: Lenovo T60 running amd64-current. Below I provide the obligatory dmesg, pf.conf, rc.conf.local and sysctl.conf. Checking what is going on with 'pftop' I noticed that 'pkg_add' opens up hundreds of connections, all with state 'TIME_WAIT:TIME_WAIT' or 'FIN_WAIT_2:FIN_WAIT_2'. Once around 100 such states are established the connection will be dropped soon. I've tried ftp.hostserver.de, openbsd.cs.fau.de and ftp.openbsd.org - all show the same behaviour. E.g. PKG_PATH is set in my .profile like so: PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/ All those connections get closed by pkg_add. If you don't see them closing in your pf log, you need to figure out why.
Re: Help needed: pkg_add dropps connections
On Wed, Feb 18, 2015 at 02:32:39PM +0100, Stefan Wollny wrote: I checked for - ftp ftp://... - ftp http://... Both connections were terminated after 95 seconds (according to pftop) after closing with ^C. Now with http-proxy-variable being unset I gave 'pkg_add' another try: closing should be synchronous with the ^C giving you back the shell prompt. If it waits for 95 seconds, your network setup is fucked up.
Re: Help needed: pkg_add dropps connections
On Tue, Feb 17, 2015 at 02:44:42PM -0800, Gene wrote: quirks-2.52 signed on 2015-02-14T12:43:06Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz ftp: connect: No route to host It's using ftp. I'm not familiar with how package management works with OpenBSD, so I don't know if this is a weird quirk of the pkg_add command or if he's not setting his package source properly. pkg_add does not do network connections directly for protocols where ftp(1) does know how to deal. pkg_add, however, closes connections aggressively when it's got the info it needs. If, somehow, your ftp setup is broken, then you might overflow the server with 100s of connections. Just do something like: ftp http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz (manually) close it halfway thru using ^C. If you don't see the connection being terminated properly, then you don't need to look further. That's your whole issue. or do it on something larger like http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/texlive_base-2013p3.tgz so that you have time to abort before the whole transfer is finished.
Re: Help needed: pkg_add dropps connections
Have you also tried without the proxy? On 2015-02-18 13:47:26, Marc Espie wrote: On Tue, Feb 17, 2015 at 03:15:14PM +0100, Stefan Wollny wrote: Hello! I'd like to pick up an issue that is bugging me for some time now: Whenever I run 'pkg_add -ui' my connection gets terminated soon, reliably at the latest once packages starting with g are checked. I suspect it is in my pf.conf but it is not obvious to me. My system: Lenovo T60 running amd64-current. Below I provide the obligatory dmesg, pf.conf, rc.conf.local and sysctl.conf. Checking what is going on with 'pftop' I noticed that 'pkg_add' opens up hundreds of connections, all with state 'TIME_WAIT:TIME_WAIT' or 'FIN_WAIT_2:FIN_WAIT_2'. Once around 100 such states are established the connection will be dropped soon. I've tried ftp.hostserver.de, openbsd.cs.fau.de and ftp.openbsd.org - all show the same behaviour. E.g. PKG_PATH is set in my .profile like so: PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/ All those connections get closed by pkg_add. If you don't see them closing in your pf log, you need to figure out why.
Re: Help needed: pkg_add dropps connections
On Tue, Feb 17, 2015 at 06:10:37PM -0500, Nick Holland wrote: it's using the ftp(1) FTP client, which (in OpenBSD) does a wonderful job of fetching things via the HTTP protocol as well as the FTP protocol. now, he says it is blowing up after around 100 states. Sounds like his firewall/proxy/whatever is limiting the state count per station. Goodness knows this works very well usually, so it's something different between his system and mine...and I'm putting my money on his firewall or proxy. Now, pkg_add has a whole lot of magic to limit the number of active connections to a given site down to ONE single active connection at any given time. *however* it *does* close connections abruptly, just closing the fd connected to ftp(1), and letting it die. *If* those connections are not dropped properly (having to do with the machine setup), *then* you will end up with 100s of unterminated connections... which at some point is going to overflow the machine, of course. This has nothing to do with ftp:// , which is another can of trouble entirely. Aggressive NATs tend to break ftp, as any big package will have a DATA connection active for long, and will tend to terminate the CTRL connection early, unless the NAT knows about ftp (which is why ftp proxies are a good idea, and which is why I implemented the ftp-level keep-alive hack, which actually sends NOP commands vryyy slowly on the CTRL connection while the DATA connection is going on, to avoid this drop). Again, there CAN be an issue with closing ftp connections early, as those depend on telnet urgent signaling mechanisms, which tend to be bungled by a lot of proxies (hey, why read the RFC when we can do a FUCKED UP UNTESTED JOB OF writing TESTOSTERONE ladden shit ?) As for http, well, there was some hope in using HTTP 1.1 to not terminate the connection. Unfortunately, most http servers screwed the pooch by being vulnerable to Byte-Range attacks (yeah, no-one learnt from the TCP fragmentation attacks from 15 years ago. But you know, man, http is all shiny and new, and the new generation doesn't even care about the lower layers as long as they've got their shiny JSON and node.js, and go/rust shitz)... so direct http 1.1 usage from pkg_add never went beyond the planning stage, as most http servers out there will just terminate http 1.1 connections early in a fairly random way). TL;DR: you got to fix your network setup so you can abort partial fetches thru ftp(1) without any dangling network state remaining after the ^C. That's what's screwed in that specific situation.
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 16:27 schrieb Alan Corey: This is probably unrelated but I've noticed that the fetching that happens with make install in ports seems less robust than it used to be. If my internet provider disconnects or the connection gets reset beyond that, it doesn't resume the download. And I've tried setting FETCH_CMD to wget -c, it doesn't help much (in 5.6, that's what I have my 5.2 machine set to). So I do a make install, wait until I've got a working URL, then ctrl-c to stop it, copy the url, open another rxvt in the distfiles dir, type wget, paste the URL. wget very rarely fails. I've got portsql installed and was able to make myself some partial fetchlists from that but my query didn't find dependencies of dependencies. A scratch install of 5.6 still took a couple months. On 2/18/15, owner-m...@openbsd.org owner-m...@openbsd.org wrote: chopped many K Credit is the root of all evil. - AB1JX Oh dear ... a couple of month for a scratch install??? Why don't you just take the CD from the shelf? I'd rather stay with stable than fiddling for month. You see - reconneting 10~15 times while pkg_add -ui updates my installed packages is a major annoyance, but actually I am done on a slow hotel-WLAN within 3~4 hours. It can be achieved if there is s.th. interesting on TV. At home with a modest fast line I am done within 30 minutes or so and my system runs with the latest current-amd64. What bothers me most is that I just can't figure out _why_ the connection gets lost...
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 15:16 schrieb Stefan Wollny: Am 02/18/15 um 15:07 schrieb Marc Espie: On Wed, Feb 18, 2015 at 02:32:39PM +0100, Stefan Wollny wrote: I checked for - ftp ftp://... - ftp http://... Both connections were terminated after 95 seconds (according to pftop) after closing with ^C. Now with http-proxy-variable being unset I gave 'pkg_add' another try: closing should be synchronous with the ^C giving you back the shell prompt. If it waits for 95 seconds, your network setup is fucked up. My mistake: Bad wording... The shell-prompt is back within 2~3 seconds. In a second xterm I had pftop running showing me that the connection was closed after the '95 seconds' I mentioned. Maybe I should change the SDD to another one and test with a fresh installation... Just as a follow up: Before setting up a fresh system I did another test (actually again) without adsuck enabled: Long story short: Still the connection gets dropped running 'pkg_add -ui'
Re: Help needed: pkg_add dropps connections
On 2015-02-18, Stefan Wollny stefan.wol...@web.de wrote: Could mss 1460 be the core of the issue? I have the following: ~ $ sudo cat /etc/pf.conf | grep mss match in all scrub (no-df random-id max-mss 1440) ~ $ sudo cat /etc/sysctl.conf | grep mss net.inet.tcp.mssdflt=1440 Neither of these make sense on a typical laptop, and they make me query what else you might have changed on the system. What does pfctl -si say? When you get the no route to host, what does e.g. route -n get 8.8.8.8 say? (i.e. some host on the internet). Are you able to ping your fritzbox or the proxy-server at that time?
Re: Help needed: pkg_add dropps connections
This is probably unrelated but I've noticed that the fetching that happens with make install in ports seems less robust than it used to be. If my internet provider disconnects or the connection gets reset beyond that, it doesn't resume the download. And I've tried setting FETCH_CMD to wget -c, it doesn't help much (in 5.6, that's what I have my 5.2 machine set to). So I do a make install, wait until I've got a working URL, then ctrl-c to stop it, copy the url, open another rxvt in the distfiles dir, type wget, paste the URL. wget very rarely fails. I've got portsql installed and was able to make myself some partial fetchlists from that but my query didn't find dependencies of dependencies. A scratch install of 5.6 still took a couple months. On 2/18/15, owner-m...@openbsd.org owner-m...@openbsd.org wrote: chopped many K Credit is the root of all evil. - AB1JX
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 23:47 schrieb Gene: On Tue, Feb 17, 2015 at 2:40 PM, Stefan Wollny stefan.wol...@web.de wrote: Am 02/17/15 um 23:25 schrieb Gene: That is not the extent of the sudo settings. You have to look at the sudoers file to check whether the env settings are kept or not. ??? Sorry - it was a looong day: What _exactly_ do I have to look at? That line %wheel ALL=(ALL) NOPASSWD: SETENV: ALL was right from the sudoers-file. Look at the entire sudoers file, not just one line. Specifically look for env_reset and env_keep. Well: It is the standard OpenBSD-sudoers-file with exactly this one line adjusted. Nevertheless: Here is the entire file: # $OpenBSD: sudoers,v 1.28 2014/04/08 13:26:28 espie Exp $ # # sudoers file. # # This file MUST be edited with the 'visudo' command as root. # Failure to use 'visudo' may result in syntax or file permission errors # that prevent sudo from running. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification # Defaults specification Defaults env_keep +=FTPMODE PKG_CACHE PKG_PATH SM_PATH SSH_AUTH_SOCK # Non-exhaustive list of variables needed to build release(8) and ports(7) Defaults:%wsrc env_keep +=DESTDIR DISTDIR FETCH_CMD FLAVOR GROUP MAKE MAKECONF Defaults:%wsrc env_keep +=MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_DBDIR Defaults:%wsrc env_keep +=PKG_DESTDIR PKG_TMPDIR PORTSDIR RELEASEDIR SHARED_ONLY Defaults:%wsrc env_keep +=SUBPACKAGE WRKOBJDIR SUDO_PORT_V1 # Uncomment to preserve the default proxy host variable #Defaults env_keep +=ftp_proxy http_proxy # Uncomment to disable the lecture the first time you run sudo #Defaults !lecture # Uncomment to preserve the environment for users in group wheel #Defaults:%wheel !env_reset # Runas alias specification # User privilege specification rootALL=(ALL) SETENV: ALL # Uncomment to allow people in group wheel to run all commands # and set environment variables. # %wheelALL=(ALL) SETENV: ALL # Same thing without a password %wheel ALL=(ALL) NOPASSWD: SETENV: ALL # Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now
Re: Help needed: pkg_add dropps connections
On 2/17/15, Gene gh5...@gmail.com wrote: On Tue, Feb 17, 2015 at 2:37 PM, trondd tro...@gmail.com wrote: He's using http protocol. Just because the hostname has ftp in it, doesn't mean it's the ftp protocol. It's not just the hostname I'm basing it off of, it's the error message: ~ $ sudo pkg_add -ui quirks-2.52 signed on 2015-02-14T12:43:06Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz ftp: connect: No route to host It's using ftp. I'm not familiar with how package management works with OpenBSD, so I don't know if this is a weird quirk of the pkg_add command or if he's not setting his package source properly. To clarify, pkg_add is using the ftp application to connect using the http protocol. He's specifying http://something and his output near the beginning of the thread shows his connections to port 80.
Re: Help needed: pkg_add dropps connections
On Tue, Feb 17, 2015 at 2:40 PM, Stefan Wollny stefan.wol...@web.de wrote: Am 02/17/15 um 23:25 schrieb Gene: That is not the extent of the sudo settings. You have to look at the sudoers file to check whether the env settings are kept or not. ??? Sorry - it was a looong day: What _exactly_ do I have to look at? That line %wheel ALL=(ALL) NOPASSWD: SETENV: ALL was right from the sudoers-file. Look at the entire sudoers file, not just one line. Specifically look for env_reset and env_keep. Try bypassing sudo entirely: $ sudo su - # export http_proxy=http://192.168.178.23:3128 # export ftp_proxy=http://192.168.178.23:3128 # pkg_add -ui So effectively you suggest running with root-privileges? OK, let's go: You're doing it with root privileges regardless. That's how sudo works. ~ $ sudo su - # export http_proxy=http://192.168.178.23:3128 # export ftp_proxy=http://192.168.178.23:3128 # pkg_add -ui Couldn't find updates for GraphicsMagick-1.3.20, ImageMagick-6.7.7.7p8, OpenEXR-1.6.1p2, R-3.1.2, Xaw3d-1.5p2, ... [ all the other packages ] Nope - this did not do the trick... (at least the connect was not lost). Okay, so now it's an issue of how you have your package source defined I believe. I'm guessing it's defined in your personal .profile and not in root's. How do you have the package source defined? Best, STEFAN
Re: Help needed: pkg_add dropps connections
On Tue, Feb 17, 2015 at 2:37 PM, trondd tro...@gmail.com wrote: He's using http protocol. Just because the hostname has ftp in it, doesn't mean it's the ftp protocol. It's not just the hostname I'm basing it off of, it's the error message: ~ $ sudo pkg_add -ui quirks-2.52 signed on 2015-02-14T12:43:06Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz ftp: connect: No route to host It's using ftp. I'm not familiar with how package management works with OpenBSD, so I don't know if this is a weird quirk of the pkg_add command or if he's not setting his package source properly. Also, yes, I believe sudo only carries over the environment variables explicitly told to do so. Can you download packages with a web browser? Have you tried using the ftp program directly? When you loose connection, can you get to other web sites or is your entire network connection down? Do you have access to the Fitz!Box or whatever to see what it's doing?
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 23:25 schrieb Gene: That is not the extent of the sudo settings. You have to look at the sudoers file to check whether the env settings are kept or not. ??? Sorry - it was a looong day: What _exactly_ do I have to look at? That line %wheel ALL=(ALL) NOPASSWD: SETENV: ALL was right from the sudoers-file. Try bypassing sudo entirely: $ sudo su - # export http_proxy=http://192.168.178.23:3128 # export ftp_proxy=http://192.168.178.23:3128 # pkg_add -ui So effectively you suggest running with root-privileges? OK, let's go: ~ $ sudo su - # export http_proxy=http://192.168.178.23:3128 # export ftp_proxy=http://192.168.178.23:3128 # pkg_add -ui Couldn't find updates for GraphicsMagick-1.3.20, ImageMagick-6.7.7.7p8, OpenEXR-1.6.1p2, R-3.1.2, Xaw3d-1.5p2, ... [ all the other packages ] Nope - this did not do the trick... (at least the connect was not lost). Best, STEFAN
Re: Help needed: pkg_add dropps connections
On 02/17/15 17:44, Gene wrote:
On Tue, Feb 17, 2015 at 2:37 PM, trondd tro...@gmail.com wrote:
He's using http protocol. Just because the hostname has ftp in it,
doesn't mean it's the ftp protocol.
It's not just the hostname I'm basing it off of, it's the error message:
good try, but no.
~ $ sudo pkg_add -ui
quirks-2.52 signed on 2015-02-14T12:43:06Z
Error from
http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz
The URL used: clearly http.
ftp: connect: No route to host
^^^ The program that produced that error message.
It's using ftp. I'm not familiar with how package management works with
OpenBSD, so I don't know if this is a weird quirk of the pkg_add command or
if he's not setting his package source properly.
it's using the ftp(1) FTP client, which (in OpenBSD) does a wonderful
job of fetching things via the HTTP protocol as well as the FTP protocol.
now, he says it is blowing up after around 100 states. Sounds like his
firewall/proxy/whatever is limiting the state count per station.
Goodness knows this works very well usually, so it's something different
between his system and mine...and I'm putting my money on his firewall
or proxy.
Nick.
Also, yes, I believe sudo only carries over the environment variables
explicitly told to do so.
Can you download packages with a web browser? Have you tried using
the ftp program directly?
When you loose connection, can you get to other web sites or is your
entire network connection down? Do you have access to the Fitz!Box or
whatever to see what it's doing?
Re: Help needed: pkg_add dropps connections
On 02/17/15 18:59, Stefan Wollny wrote: ftp: connect: No route to host you need to fix that before you worry about anything. Once you get THAT fixed, then you can get back to worrying about your dropping connections. Gotta make it before you can drop it.
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 22:20 schrieb Gene: It looks like http_proxy is being set, but you're getting packages from an ftp server. You need to define the ftp_proxy variable as well. Hi Gene, Hi Gene, thanks for your advice. I am not shure if setting an ftp_proxy-variable might help here as the http-proxy is not 'in-between'. I'll try to describe the layout: +---Laptop Internet -- Fritz!Box --| +---Squid-Server For anything http-related Laptop gets the pages from Squid-server, everything else (like ftp-related matter, e.g. pkg_add) goes directly via Fritz!Box to the 'net. From what I know the Fritz!Box does not act as an ftp-server. Beside this: pkg_add from Squid-server 'just works' (tm). There is s.th. wrong with the Laptop - but I am lost by now... =-(
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 23:37 schrieb trondd: He's using http protocol. Just because the hostname has ftp in it, doesn't mean it's the ftp protocol. Precisely: Looking at the information I provided with the second post you'll notice that 192.168.178.31:4561 - 217.31.80.35:80 is using the http-protocol. Also, yes, I believe sudo only carries over the environment variables explicitly told to do so. Can you download packages with a web browser? Yes - single packages can be downloaded. Have you tried using the ftp program directly? Yes - single packages can be downloaded. When you loose connection, can you get to other web sites or is your entire network connection down? The entire network is down. Do you have access to the Fitz!Box or whatever to see what it's doing? Yes - everything is at my command :-) This does not imply that I always know what I am doing ;-) ... no serious: Of course have I checked the logs from the Fritz!Box - nothing to be reported here...
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 00:05 schrieb Todd C. Miller: One thing to check is the MTU on the Fritz!Box. If the MTU is set to, for example, 1448 instead of 1500 you may need to reduce the MTU on your laptop to match. - todd Hi Todd, thank you for caring! Well - the Fritz!Box-web-interface is not really telling... So I go with what it's dhcpd gives me. Here is what 'ifconfig' shows for em0, wpi0 and trunk0: em0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:15:58:81:15:fb priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause) status: active wpi0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:15:58:81:15:fb priority: 4 trunk: trunkdev trunk0 groups: wlan media: IEEE802.11 autoselect (DS1 mode 11b) status: active ieee80211: nwid dlink chan 11 bssid 00:1b:11:61:cf:a1 15dBm wpakey not displayed wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:15:58:81:15:fb priority: 0 trunk: trunkproto failover trunkport wpi0 trunkport em0 master,active groups: trunk egress media: Ethernet autoselect status: active inet 192.168.178.31 netmask 0xff00 broadcast 192.168.178.255 Everything is set to 'mtu 1500' You know ...- what puzzles me is the fact that the OpenBSD-run server running in parallel (amd64-current as well) does not show the same behaviour! Strange ...
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 22:28 schrieb Stefan Wollny: [ ... ] Well ... it should be nonsense but I will change the way I connect to the net: Disable 'trunk0' and connect directly via 'em0' (feel my desperation?). OK - changed the standard of connecting to the internet via trunk0 to the physical interface em0: ~ $ sudo pkg_add -ui quirks-2.52 signed on 2015-02-17T13:51:20Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/claws-mail-3.11.1.tgz ftp: connect: No route to host Just as expected by any sane mind: 'trunk0' is not the cause of the problem. I am done for tonight - hope to get your help tomorrow as well! Thank you all! STEFAN
Re: Help needed: pkg_add dropps connections
Am 02/18/15 um 01:40 schrieb Nick Holland: On 02/17/15 18:59, Stefan Wollny wrote: ftp: connect: No route to host you need to fix that before you worry about anything. Once you get THAT fixed, then you can get back to worrying about your dropping connections. Gotta make it before you can drop it. Well yes: This is why I had to come here for. The connections are never dropped by any other program. Only with 'pkg_add' the connection is entirely gone and 'pkg_add' subsequently complains about 'No route to host'... and only on this particular machine. I know that 'pkg_add' is a lot of Perl-magic: Anything in this direction that should be checked? I am stuck /:
Re: Help needed: pkg_add dropps connections
Let me illustrate what I see: ~ $ sudo pkg_add -ui quirks-2.52 signed on 2015-02-14T12:43:06Z Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/curl-7.40.0.tgz ftp: connect: No route to host sw@idefix ~ $ sudo pfctl -s states trunk0 tcp 192.168.178.31:48407 - 192.168.178.23:22 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:22700 - 212.227.17.178:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:27574 - 212.227.17.178:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:42673 - 89.146.220.134:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:15019 - 89.146.220.134:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:31753 - 89.146.220.134:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:28317 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:31534 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:46772 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:21745 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:15217 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:18147 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:11549 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:9781 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:30676 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:3543 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:4944 - 89.146.220.134:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:48204 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:35025 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:17964 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:26586 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:32833 - 192.168.178.23:3128 ESTABLISHED:FIN_WAIT_2 trunk0 tcp 192.168.178.31:37156 - 212.227.17.162:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:30378 - 212.227.17.178:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:18543 - 212.227.17.178:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:17598 - 89.146.220.134:993 ESTABLISHED:ESTABLISHED trunk0 tcp 192.168.178.31:25238 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:39802 - 217.31.80.35:80 FIN_WAIT_2:FIN_WAIT_2 trunk0 tcp 192.168.178.31:47568 - 217.31.80.35:80 FIN_WAIT_2:FIN_WAIT_2 trunk0 tcp 192.168.178.31:18460 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:10488 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:20855 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:7246 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:43478 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:22766 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:7010 - 217.31.80.35:80 FIN_WAIT_2:FIN_WAIT_2 trunk0 tcp 192.168.178.31:25676 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:28532 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:24557 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:16459 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:19879 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:40664 - 217.31.80.35:80 FIN_WAIT_2:FIN_WAIT_2 trunk0 tcp 192.168.178.31:11882 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:2575 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:46612 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:42334 - 217.31.80.35:80 FIN_WAIT_2:FIN_WAIT_2 trunk0 tcp 192.168.178.31:4561 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:4842 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:6889 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:13576 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:3984 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:25350 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:38572 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:4927 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:15981 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:33438 - 217.31.80.35:80 FIN_WAIT_2:FIN_WAIT_2 trunk0 tcp 192.168.178.31:31926 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:43729 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:44741 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:47491 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:11804 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:9868 - 217.31.80.35:80 TIME_WAIT:TIME_WAIT trunk0 tcp 192.168.178.31:36760 -
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 20:36 schrieb trondd: When you are behind your server are you using NAT to get to the internet or a proxy? If proxy, do you have the proxy environment variables set? Tim. Hi Tim, thanks for caring. No - I am not behind the server: It is just another machine in the same internal net. So no NAT. But yes - the proxy-variable is set: ~ $ cat .profile | grep proxy export http_proxy=http://192.168.178.23:3128 BUT - if you check my second post you will notice that pkg_add does NOT get in contact with the squid (port 3128) but directly to 217.31.80.35:80 (being ftp.hostserver.de) Another friendly guy suggested to disable pf and give pkg_add a try without - I did so but at gnome-keyrings the connection was lost. The logs from pflog0 did not provide anything interesting from pkg_add running. I just found out that firefox somehow makes own requests to Google's DNS-servers (8.8.8.8,...). This is now blocked via pf.conf :-) So we are not yet there... Best, STEFAN
Re: Help needed: pkg_add dropps connections
When you are behind your server are you using NAT to get to the internet or a proxy? If proxy, do you have the proxy environment variables set? Tim.
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 19:30 schrieb Vadim Zhukov: Please check/diff/show us output of sysctl net on both machines. Hi Vadim, thank you for replying! Below you'll find first the output of 'sysctl net' from the laptop, then the same from the server. At the end I add the dmesg of the server, just so you don't have to ask. Hope it helps to proceed. Best, STEFAN ~~~ +++ L A P T O P +++ ~~~ net.inet.ip.forwarding=0 net.inet.ip.redirect=0 net.inet.ip.ttl=64 net.inet.ip.sourceroute=0 net.inet.ip.directed-broadcast=0 net.inet.ip.portfirst=1024 net.inet.ip.portlast=49151 net.inet.ip.porthifirst=49152 net.inet.ip.porthilast=65535 net.inet.ip.maxqueue=300 net.inet.ip.encdebug=0 net.inet.ip.ipsec-expire-acquire=30 net.inet.ip.ipsec-invalid-life=60 net.inet.ip.ipsec-pfs=1 net.inet.ip.ipsec-soft-allocs=0 net.inet.ip.ipsec-allocs=0 net.inet.ip.ipsec-soft-bytes=0 net.inet.ip.ipsec-bytes=0 net.inet.ip.ipsec-timeout=86400 net.inet.ip.ipsec-soft-timeout=8 net.inet.ip.ipsec-soft-firstuse=3600 net.inet.ip.ipsec-firstuse=7200 net.inet.ip.ipsec-enc-alg=aes net.inet.ip.ipsec-auth-alg=hmac-sha1 net.inet.ip.mtudisc=1 net.inet.ip.mtudisctimeout=600 net.inet.ip.ipsec-comp-alg=deflate net.inet.ip.ifq.len=0 net.inet.ip.ifq.maxlen=1024 net.inet.ip.ifq.drops=0 net.inet.ip.mforwarding=0 net.inet.ip.multipath=0 net.inet.ip.mrtproto=19 net.inet.ip.arpqueued=0 net.inet.icmp.maskrepl=0 net.inet.icmp.bmcastecho=0 net.inet.icmp.errppslimit=100 net.inet.icmp.rediraccept=0 net.inet.icmp.redirtimeout=600 net.inet.icmp.tstamprepl=1 net.inet.ipip.allow=0 net.inet.tcp.rfc1323=1 net.inet.tcp.keepinittime=150 net.inet.tcp.keepidle=100 net.inet.tcp.keepintvl=150 net.inet.tcp.slowhz=2 net.inet.tcp.baddynamic=1,7,9,11,13,15,17,18,19,20,21,22,23,25,37,42,43,49,53,57,67,68,70,77,79,80,87,88,95,101,102,103,104,105,106,107,109,110,111,113,115,117,119,123,129,135,137,138,139,143,152,163,164,177,178,179,191,194,199,201,202,204,206,210,213,220,372,389,427,433,443,444,445,464,465,468,512,513,514,515,521,526,530,531,532,540,543,544,545,548,554,556,587,631,636,646,706,749,750,751,754,760,871,873,888,901,993,995,1080,1109,1127,1433,1434,1524,1525,1529,1723,1900,2049,2105,2106,2108,2110,2111,2112,2120,2121,2401,2600,2601,2602,2603,2604,2605,2606,2607,2608,2627,2983,3031,3109,3260,3306,3389,3517,3689,3690,4190,,4500,4559,5002,5060,5222,5269,5280,5298,5353,5354,5432,5680,5900,6000,6001,6002,6003,6004,6005,6006,6007,6008,6009,6010,6514,6566,7000,7001,7002,7003,7004,7005,7006,7007,7008,7009,7326,8025,8026,8140,8953,9418,10050,10051,16992,16993,16994,16995,20005 net.inet.tcp.sack=1 net.inet.tcp.mssdflt=1440 net.inet.tcp.rstppslimit=100 net.inet.tcp.ackonpush=0 net.inet.tcp.ecn=0 net.inet.tcp.syncachelimit=10255 net.inet.tcp.synbucketlimit=105 net.inet.tcp.rfc3390=2 net.inet.tcp.reasslimit=3072 net.inet.tcp.sackholelimit=32768 net.inet.tcp.always_keepalive=1 net.inet.udp.checksum=1 net.inet.udp.baddynamic=7,9,13,18,19,22,37,39,49,53,67,68,69,70,80,88,105,107,109,110,111,123,129,135,137,138,139,143,161,162,163,164,177,178,179,191,194,199,201,202,204,206,210,213,220,372,389,427,444,445,464,468,500,512,513,514,517,518,520,525,533,546,547,548,554,587,623,631,636,646,664,706,749,750,751,993,995,1433,1434,1524,1525,1645,1646,1701,1723,1812,1813,1900,2049,2401,3031,3517,3689,4190,,4500,4559,4789,5002,5060,5298,5353,5354,5432,7000,7001,7002,7003,7004,7005,7006,7007,7008,7009,8025,8067,9418,10050,10051,16992,16993,16994,16995,20005,26740 net.inet.udp.recvspace=41600 net.inet.udp.sendspace=9216 net.inet.gre.allow=0 net.inet.gre.wccp=0 net.inet.esp.enable=1 net.inet.esp.udpencap=1 net.inet.esp.udpencap_port=4500 net.inet.ah.enable=1 net.inet.mobileip.allow=0 net.inet.etherip.allow=0 net.inet.ipcomp.enable=0 net.inet.carp.allow=1 net.inet.carp.preempt=0 net.inet.carp.log=2 net.inet.divert.recvspace=65636 net.inet.divert.sendspace=65636 net.inet6.ip6.forwarding=0 net.inet6.ip6.redirect=1 net.inet6.ip6.hlim=64 net.inet6.ip6.mrtproto=103 net.inet6.ip6.maxfragpackets=200 net.inet6.ip6.log_interval=5 net.inet6.ip6.hdrnestlimit=10 net.inet6.ip6.dad_count=1 net.inet6.ip6.auto_flowlabel=1 net.inet6.ip6.defmcasthlim=1 net.inet6.ip6.use_deprecated=1 net.inet6.ip6.rr_prune=5 net.inet6.ip6.v6only=1 net.inet6.ip6.maxfrags=200 net.inet6.ip6.mforwarding=0 net.inet6.ip6.multipath=0 net.inet6.ip6.multicast_mtudisc=0 net.inet6.ip6.neighborgcthresh=2048 net.inet6.ip6.maxifprefixes=16 net.inet6.ip6.maxifdefrouters=16 net.inet6.ip6.maxdynroutes=4096 net.inet6.ip6.dad_pending=0 net.inet6.ip6.mtudisctimeout=600 net.inet6.ip6.ifq.len=0 net.inet6.ip6.ifq.maxlen=256 net.inet6.ip6.ifq.drops=0 net.inet6.icmp6.redirtimeout=600 net.inet6.icmp6.nd6_prune=1 net.inet6.icmp6.nd6_delay=5 net.inet6.icmp6.nd6_umaxtries=3 net.inet6.icmp6.nd6_mmaxtries=3 net.inet6.icmp6.errppslimit=100 net.inet6.icmp6.nd6_maxnudhint=0 net.inet6.icmp6.mtudisc_hiwat=1280 net.inet6.icmp6.mtudisc_lowat=256 net.inet6.icmp6.nd6_debug=0 net.inet6.divert.recvspace=65636
Re: Help needed: pkg_add dropps connections
On 2/17/15, Stefan Wollny stefan.wol...@web.de wrote: Am 02/17/15 um 20:36 schrieb trondd: When you are behind your server are you using NAT to get to the internet or a proxy? If proxy, do you have the proxy environment variables set? Tim. Hi Tim, thanks for caring. No - I am not behind the server: It is just another machine in the same internal net. So no NAT. But yes - the proxy-variable is set: ~ $ cat .profile | grep proxy export http_proxy=http://192.168.178.23:3128 BUT - if you check my second post you will notice that pkg_add does NOT get in contact with the squid (port 3128) but directly to 217.31.80.35:80 (being ftp.hostserver.de) Yeah, but it also show you have a 192.168 IP address which is not routable. You have to be connecting to the internet through something. Another friendly guy suggested to disable pf and give pkg_add a try without - I did so but at gnome-keyrings the connection was lost. So you can reach the server and get some packages?
Re: Help needed: pkg_add dropps connections
Am 02/17/15 um 21:58 schrieb trondd:
On 2/17/15, Stefan Wollny stefan.wol...@web.de wrote:
Am 02/17/15 um 20:36 schrieb trondd:
When you are behind your server are you using NAT to get to the
internet or a proxy? If proxy, do you have the proxy environment
variables set?
Tim.
Hi Tim,
thanks for caring.
Yeah, but it also show you have a 192.168 IP address which is not
routable. You have to be connecting to the internet through
something.
Another friendly guy suggested to disable pf and give pkg_add a try
without - I did so but at gnome-keyrings the connection was lost.
So you can reach the server and get some packages?
Yepp - and then (around packages starting with letter 'g' at the latest)
the connection is lost... :-(
My internal net is 192.168.178.xxx. The NAT is provided by a Fritz!Box.
Here is a copy from xterm:
~ $ sudo pkg_add -ui
quirks-2.52 signed on 2015-02-17T13:51:20Z
quirks-2.52-2.52: ok
cmake-3.1.2-3.1.3: ok
Error from
http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/libxml-2.9.2p0.tgz
ftp: connect: No route to host
cups-2.0.2:foomatic-db-engine-4.0.11p0-4.0.12: ok
cups-2.0.2:cups-filters-1.0.63-1.0.65: ok
cups-2.0.2-2.0.2: ok
.libs1-farstream-0.2.4+farstream-0.2.6-farstream-0.2.7: ok
Error from
http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/freetds-0.92.79.tgz
ftp: connect: No route to host
~~
AT EACH LINE 'ftp: connect: No route to host' THE CONNECTION WAS LOST!
~~
Here is my little script to reconnect:
~ $ cat reconnect
#/bin/sh
sudo /sbin/ifconfig em0 down
sudo /sbin/ifconfig wpi0 down
sudo /sbin/ifconfig rsu0 down
sudo /sbin/ifconfig trunk0 down
sudo /sbin/route flush
sudo sh /etc/netstart
After having run this script 'pkg_add' continues as shown in the example
('cups-2.0.2:foomatic-db-engine-4.0.11p0-4.0.12: ok')
It's been just a few moments ago. I quit 'pkg_add' after the second 'No
route to host'.
Well ... it should be nonsense but I will change the way I connect to
the net: Disable 'trunk0' and connect directly via 'em0' (feel my
desperation?).
Re: Help needed: pkg_add dropps connections
It looks like http_proxy is being set, but you're getting packages from an ftp server. You need to define the ftp_proxy variable as well. -Gene On Tue, Feb 17, 2015 at 12:58 PM, trondd tro...@gmail.com wrote: On 2/17/15, Stefan Wollny stefan.wol...@web.de wrote: Am 02/17/15 um 20:36 schrieb trondd: When you are behind your server are you using NAT to get to the internet or a proxy? If proxy, do you have the proxy environment variables set? Tim. Hi Tim, thanks for caring. No - I am not behind the server: It is just another machine in the same internal net. So no NAT. But yes - the proxy-variable is set: ~ $ cat .profile | grep proxy export http_proxy=http://192.168.178.23:3128 BUT - if you check my second post you will notice that pkg_add does NOT get in contact with the squid (port 3128) but directly to 217.31.80.35:80 (being ftp.hostserver.de) Yeah, but it also show you have a 192.168 IP address which is not routable. You have to be connecting to the internet through something. Another friendly guy suggested to disable pf and give pkg_add a try without - I did so but at gnome-keyrings the connection was lost. So you can reach the server and get some packages?
Re: Help needed: pkg_add dropps connections
Squid can work as an FTP proxy, and I imagine in your case it probably does. Try setting it and trying the pkg_add command again. Additionally, you'll want to make sure that your proxy environment variables are being passed through sudo. If sudo is configured to use env_reset and env_keep and it isn't retaining those variables then the proxy won't be used at all. -Eugene On Tue, Feb 17, 2015 at 1:42 PM, Stefan Wollny stefan.wol...@web.de wrote: Am 02/17/15 um 22:20 schrieb Gene: It looks like http_proxy is being set, but you're getting packages from an ftp server. You need to define the ftp_proxy variable as well. Hi Gene, Hi Gene, thanks for your advice. I am not shure if setting an ftp_proxy-variable might help here as the http-proxy is not 'in-between'. I'll try to describe the layout: +---Laptop Internet -- Fritz!Box --| +---Squid-Server For anything http-related Laptop gets the pages from Squid-server, everything else (like ftp-related matter, e.g. pkg_add) goes directly via Fritz!Box to the 'net. From what I know the Fritz!Box does not act as an ftp-server. Beside this: pkg_add from Squid-server 'just works' (tm). There is s.th. wrong with the Laptop - but I am lost by now... =-(
Re: Help needed: pkg_add dropps connections
Also, note that the value between the two variables will be the same: e.g. http_proxy=http://192.168.178.23:3128 ftp_proxy=http://192.168.178.23:3128 -Gene On Tue, Feb 17, 2015 at 1:54 PM, Gene gh5...@gmail.com wrote: Squid can work as an FTP proxy, and I imagine in your case it probably does. Try setting it and trying the pkg_add command again. Additionally, you'll want to make sure that your proxy environment variables are being passed through sudo. If sudo is configured to use env_reset and env_keep and it isn't retaining those variables then the proxy won't be used at all. -Eugene On Tue, Feb 17, 2015 at 1:42 PM, Stefan Wollny stefan.wol...@web.de wrote: Am 02/17/15 um 22:20 schrieb Gene: It looks like http_proxy is being set, but you're getting packages from an ftp server. You need to define the ftp_proxy variable as well. Hi Gene, Hi Gene, thanks for your advice. I am not shure if setting an ftp_proxy-variable might help here as the http-proxy is not 'in-between'. I'll try to describe the layout: +---Laptop Internet -- Fritz!Box --| +---Squid-Server For anything http-related Laptop gets the pages from Squid-server, everything else (like ftp-related matter, e.g. pkg_add) goes directly via Fritz!Box to the 'net. From what I know the Fritz!Box does not act as an ftp-server. Beside this: pkg_add from Squid-server 'just works' (tm). There is s.th. wrong with the Laptop - but I am lost by now... =-(
Fwd: Re: Help needed: pkg_add dropps connections
Ooops - overlooked to cc: to misc@ Weitergeleitete Nachricht Betreff: Re: Help needed: pkg_add dropps connections Datum: Tue, 17 Feb 2015 23:14:51 +0100 Von: Stefan Wollny stefan.wol...@web.de An: Gene gh5...@gmail.com Am 02/17/15 um 22:54 schrieb Gene: Squid can work as an FTP proxy, and I imagine in your case it probably does. Try setting it and trying the pkg_add command again. Additionally, you'll want to make sure that your proxy environment variables are being passed through sudo. If sudo is configured to use env_reset and env_keep and it isn't retaining those variables then the proxy won't be used at all. -Eugene Hi Eugene, thank you for your time - really appreciate it! Of course I gave your suggestion a try, even though I was shure it would not make a difference: I have described the situation right now at home - but the very same behaviour could be reported while being in a hotel using their WLAN. SUDO-settings: %wheel ALL=(ALL) NOPASSWD: SETENV: ALL (this is not a server but my personal laptop to this seems to be OK) ~ $ cat .profile | grep proxy export http_proxy=http://192.168.178.23:3128 export ftp_proxy=http://192.168.178.23:3128 ~ $ sudo pkg_add -ui quirks-2.52 signed on 2015-02-17T13:51:20Z g++-4.8.4p1:.libs1-gcc-4.8.3p1+.libs1-gcc-4.8.3p3+gcc-4.8.4p1-gcc-4.8.4p2: ok g++-4.8.4p1-4.8.4p1: ok gcj-4.8.4p1-4.8.4p1: ok hpijs-3.15.2-3.15.2: ok Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/icu4c-54.1p3.tgz ftp: connect: No route to host Bm! Connection lost again. (As I had a 'pkg_add'-run before we reached letter 'h' this time...) I think 'ftp_proxy' can be ruled out. Nevertheless it was worth trying. Thank you and have a nice day! STEFAN
Re: Help needed: pkg_add dropps connections
That is not the extent of the sudo settings. You have to look at the sudoers file to check whether the env settings are kept or not. Try bypassing sudo entirely: $ sudo su - # export http_proxy=http://192.168.178.23:3128 # export ftp_proxy=http://192.168.178.23:3128 # pkg_add -ui -Gene On Tue, Feb 17, 2015 at 2:14 PM, Stefan Wollny stefan.wol...@web.de wrote: Am 02/17/15 um 22:54 schrieb Gene: Squid can work as an FTP proxy, and I imagine in your case it probably does. Try setting it and trying the pkg_add command again. Additionally, you'll want to make sure that your proxy environment variables are being passed through sudo. If sudo is configured to use env_reset and env_keep and it isn't retaining those variables then the proxy won't be used at all. -Eugene Hi Eugene, thank you for your time - really appreciate it! Of course I gave your suggestion a try, even though I was shure it would not make a difference: I have described the situation right now at home - but the very same behaviour could be reported while being in a hotel using their WLAN. SUDO-settings: %wheel ALL=(ALL) NOPASSWD: SETENV: ALL (this is not a server but my personal laptop to this seems to be OK) ~ $ cat .profile | grep proxy export http_proxy=http://192.168.178.23:3128 export ftp_proxy=http://192.168.178.23:3128 ~ $ sudo pkg_add -ui quirks-2.52 signed on 2015-02-17T13:51:20Z g++-4.8.4p1:.libs1-gcc-4.8.3p1+.libs1-gcc-4.8.3p3+gcc-4.8.4p1-gcc-4.8.4p2: ok g++-4.8.4p1-4.8.4p1: ok gcj-4.8.4p1-4.8.4p1: ok hpijs-3.15.2-3.15.2: ok Error from http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/icu4c-54.1p3.tgz ftp: connect: No route to host Bm! Connection lost again. (As I had a 'pkg_add'-run before we reached letter 'h' this time...) I think 'ftp_proxy' can be ruled out. Nevertheless it was worth trying. Thank you and have a nice day! STEFAN
Help needed: pkg_add dropps connections
He's using http protocol. Just because the hostname has ftp in it, doesn't mean it's the ftp protocol. Also, yes, I believe sudo only carries over the environment variables explicitly told to do so. Can you download packages with a web browser? Have you tried using the ftp program directly? When you loose connection, can you get to other web sites or is your entire network connection down? Do you have access to the Fitz!Box or whatever to see what it's doing?
