[OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

[Felix Fietkau]

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  
> http->https:
> 
> # /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  
> below:
> 
> # /bin/uclient-fetch -O-  
> 'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'
> Downloading  
> 'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'
> Connecting to 2001:470:0:193::3000:443
> Writing to stdout
> nochg 1.2.3.4Connection 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.

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel