[OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
nbd at openwrt.org
Fri Jan 22 19:25:56 EST 2016
On 2016-01-23 00:45, Arjen de Korte wrote:
> Citeren Felix Fietkau <nbd at openwrt.org>:
>> On 2016-01-22 22:29, edgar.soldin at web.de wrote:
>>> On 22.01.2016 16:20, Felix Fietkau wrote:
>>>> On 2016-01-22 16:03, edgar.soldin at web.de wrote:
>>>>> On 22.01.2016 14:32, Weedy wrote:
>>>>>>> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
>>>>>> with the removal of wget from it. Therefore, the uclient-fetch binary
>>>>>> swapout causes a 46,379 byte increase in size. I assume the
>>>>>> desire to move
>>>>>> to uclient-fetch from busybox is for the SSL support? If so, it
>>>>>> still does
>>>>>> not support SSL without also building ustream-ssl.
>>>>> yeah. an ssl capable wget (whatever it's called) out of the box
>>>>> would be greatly appreciated.
>>>>> @Felix: is that on the table?
>>>> It's already done. With uclient-fetch, you can simply install any
>>>> ustream-ssl variant (along with ca-certificates if you want to have
>>>> proper validation), and it'll immediately be SSL capable. That was my
>>>> main motivation behind replacing wget with ustream-ssl.
>>>> The aforementioned size increase is probably either a bug or a
>>>> measurement error (see my other mail regarding that subject).
>>> nice! is there a possibility to create a wget wrapper? i assume not
>>> everyone is familiar with uclient-fetch, so at least a stub noting to
>>> use uclient-fetch might probably help when users are confused that wget
>>> isn't there.
>> You keep asking for things that are already there :)
>> The uclient-fetch package provides a symlink to wget and it is fully
>> command line compatible as well. Users don't have to change their habits
>> and scripts that don't hardcode the path will continue to work as well.
> Not entirely. It (r48456) segfaults on receiving a 301 redirect for
> # /bin/uclient-fetch -O- 'http://de-korte.org/robots.txt'
> Downloading 'http://de-korte.org/robots.txt'
> Connecting to 2001:470:7ad2::10:80
> Segmentation fault
That's an error handling bug - the hostname of the URL it redirects to
is invalid. I've pushed a fix to uclient.git
> It also behaves differently with the http://dyn.dns.he.net servers
> (returning a Connection failure, despite also returning a result). See
> # /bin/uclient-fetch -O-
> Connecting to 2001:470:0:193::3000:443
> Writing to stdout
> nochg 220.127.116.11Connection error: Connection failed
> I'm not too concerned about the first, but the latter is a bit
> inconvenient. I suspect the HE servers close the connection
> immediately after sending the result and that this is not expected.
I'll make an account and look into that soon.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel