Resolver 0.73 is broken
Pages: 1 2
Dave Higton (1515) 3496 posts |
Resolver 0.73 is broken. There are two symptoms of failure: one is that entries in the Hosts file are correctly looked up, but must be matched case sensitively; the other is that lookups in the Hosts file can fail completely. Note that, if something is being looked up that is in the Hosts file and also in an external resolver (e.g. one’s router), it will be looked up case insensitively in the external resolver, and may mislead one into thinking that Resolver 0.73 is working. See the thread in Community Support, “Is Resolver 0.73 broken?”. |
djp (9726) 54 posts |
Resolver 0.73 change log |
Dave Higton (1515) 3496 posts |
I may have misunderstood, but it looks like the real code is a binary blob, for which we can’t see the sources. © Ant Ltd. They’ve been updated, hence the header going from 0.72 to 0.73. |
Steve Pampling (1551) 8154 posts |
Well, that code from Ant has been broken in a variety of ways for over 20 years, one more peculiarity is just a small bit of decoration on the icing on the cake. |
Dave Higton (1515) 3496 posts |
Yes, but it has just gone from working to not working. Pretty clearly. |
Dave Higton (1515) 3496 posts |
The important questions are about who will fix it, and when. All the open source parts of RISC OS are available for diagnosis, fixing and review by anyone. Not the binary blobs, though. So who kicks off a fix? Do we need to notify ROOL so that they can? We can’t rely on them reading here AFAIAA. |
Andrew Conroy (370) 725 posts |
Hopefully the same person who broke it in the first place, as they should know what they did and so can undo it! |
Rick Murray (539) 13805 posts |
Another important question being why was this apparent change not mentioned in the change log? Because neither “Drop COMPAT_INET4 support” nor “built with cc 5.89” should have changed the behaviour (unless something is very wrong). |
Steve Pampling (1551) 8154 posts |
Unless the previous behaviour is INET4 compatibility and anything now sending queries to Resolver is expected to deal with mixed case response to a mixed case query. |
Dave Higton (1515) 3496 posts |
Which was the buggy version of the compiler? |
Rick Murray (539) 13805 posts |
Case shouldn’t matter. |
Doug Webb (190) 1158 posts |
Looking at the bug tracker I can’t see any entry for this issue so I am assuming that none has been made but it is expected that magically discussing it here should get it fixed? Out of interest has a test been made with a totally clean install of both the ROM/Firmware elements as well as the latest hard disc images just to further help narrow anything down that may or may not be interacting with Resolver 0.73? Normally I used to be in the habit of testing the new ROM’s and Hard Disc images each day they became live but have fallen out of that recent and on this one may not have seen it anyway as i am testing the ROD stack as well. |
Alan Adams (2486) 1147 posts |
My reading of that is slightly different – I think it says a name in all uppercase must match an uppercase or lowercase version, and similarly an all lowercase name must match either all uppercase or all lowercase versions. I don’t see anything that allows mixed case names to be matched against either all uppercase or all lowercase. |
Stuart Swales (8827) 1348 posts |
The case-insensitive comparison is done on a per-byte (octet) basis. And that’s immaterial to whether Resolver appears to be using Hosts at all, even when the same case name is given as that in the file. |
Rick Murray (539) 13805 posts |
Section 3: That is to say, a lookup string octet with a value in the inclusive range from 0×41 to 0×5A, the uppercase ASCII letters, MUST match the identical value and also match the corresponding value in the inclusive range from 0×61 to 0×7A, the lowercase ASCII letters. A lookup string octet with a lowercase ASCII letter value MUST similarly match the identical value and also match the corresponding value in the uppercase ASCII letter range.I’ve highlighted the pertinent parts. It’s not saying a string that IS ALL UPPERCASE or is all lowercase must match, it’s saying a value within the string as reading it character by character must match. In other words, case insensitive (at least for regular ASCII). But, yeah, there appear to be “other issues” too. |
Alan Adams (2486) 1147 posts |
Indeed. However A-umlaut might be expected to match a-umlaut, and maybe also A or a, which from the above would not happen. When I first encountered DNS (1980’s?) I seem to recall the character set was limited to uppercase and lowercase ASCII, numbers and one of minus or underscore – I can’t remember which. Things change… |
Steve Pampling (1551) 8154 posts |
Not as clear-cut as “it’s all case-insensitive” As Alan notes:
and then the document Rick quoted a part of, but omitted other bits. 2. Case Insensitivity of DNS Labels and for extra fun: 4. Case on Input and Output Which looks rather like the Resolver is supposed to preserve case, but what other bits do with that preserved case string in comparisons is up to the other bits – i.e. as I said earlier the update in the Resolver is highlighting a case sensitivity problem elsewhere. |
Dave Higton (1515) 3496 posts |
I’ve filed ticket 576. |
Doug Webb (190) 1158 posts |
Hopefully that will get even more attention. Also given this statement:
Would it not be prudent as I said earlier to just do a new sdcard build using the latest ROM and Hard Disc image and see if the issue is still there? |
Charles Ferguson (8243) 427 posts |
It looks just broken to me. Doing a eg: ResolverConfig Resources:$.Resources.Resolver.Messages BadSWI %.*s.%.*s /etc/hosts Inet$HostName /etc/hosts Inet$SearchDomains Inet$LocalDomain If I compare this to the Resolver module I have lying around (an old Select one, but it’ll be approximately the same… gethostname Inet$HostName makehost _gethtent _gethtbyname InetDBase:hosts _inetaddr _inetraddr _gethtbyaddr _getfwbyname _getfwbyaddr freeway_init freeway_final _getnbbyname getanswer res_query res_search res_querydomain %.*s.%.*s res_launch hostclear cacheclear cachemerge cachecheckpurge cachefind InetDBase:hosts cacheadd cacheinit cachefini However, we can be clearer with this and actually link the module and use it. Using the build script: #!/bin/bash set -e riscos-kitten Resources.UK.Messages Resources.UK.CmdHelp > resjoined riscos-resgen -apcs 3/32/nonreent/fp/swst Resources aof/resources resjoined Resources.Resolver.Messages riscos-link -verbose -rmf aof/ResolverSA aof/resources C:o.stubsG -o Resolver,ffa And then if I turn some FS debug on and load the module, issuing a ResolverConfig and printing the SHA of the repo I was testing… charles@laputa ~/external/ResolverBlob (master)> pyrodev --common --command 'rmload Resolver' --command gos --boot-debug osfile,osfind Read catalogue info with path Filename = 'Resolver' Path = None DirEntry = <DirectoryEntryNative('Resolver'/'Resolver,ffa', 1, &fffffa5a, &52c27f0f, 20300, &33)> Load file Filename = 'Resolver' Path = '@.' Read catalogue info with path Filename = '/etc/hosts' Path = None DirEntry = <DirectoryEntry('/etc/hosts', 0, &00000000, &00000000, 0, &0)> Read catalogue info with path Filename = '/etc/hosts' Path = None DirEntry = <DirectoryEntry('/etc/hosts', 0, &00000000, &00000000, 0, &0)> Supervisor *help resolver ==> Help on keyword 'Resolver' (Module) Module is: Resolver 0.73 (16 May 2022) (Acorn) © ANT Ltd, 1997 Commands provided: ResolverConfig *resolverconfig Read catalogue info with path Filename = '/etc/hosts' Path = None DirEntry = <DirectoryEntry('/etc/hosts', 0, &00000000, &00000000, 0, &0)> *git rev-parse HEAD 1c33b5a299d5dba129bbcc18e118f3ab42428dfb I don’t think I really need to go any further. The module as is presently on that branch is just stuffed. I don’t quite see how you’re getting to the point of finding case insensitiveness being an issue as it shouldn’t even be able to read the hosts file, but that’s where I’d start looking for what the problem might be. I may be a broken record, but… automated testing? |
Doug Webb (190) 1158 posts |
The sound of common sense again is heard :-) |
Rick Murray (539) 13805 posts |
I may be a broken record, but… FTFY. |
Doug Webb (190) 1158 posts |
Any testing is better than none but you have to have a plan or a set of criteria on which you are going to test and the expected outcomes you have if you want to do it correctly. Are you testing new features? Just getting something out and then thinking because you have no feedback it is Ok isn’t the best option. As I said I used to test the new daily ROM’s and hard disc components as they came out but have got out of that habit for one reason or another and perhaps that has replicated a bit across all regular users. Compounding this specific issue is that I, like I guess many users, just do DHCP and I also have the ROD stack I am testing/have tested. Anyway hopefully now it is highlighted thanks to Dave then this can be fixed. |
Charles Ferguson (8243) 427 posts |
To be clear, my own tests that check the RISC OS Pyromaniac resolver’s Hosts file implementation checked whether the addresses could be looked up in the configured file, whether the entries worked for named hosts and for aliased hosts, and that comments were ignored, plus a few of the different ways that the SWI calls can be used. I did not have any tests for the behaviour being correct when different character cases were used, nor for checking whether the |
Steve Pampling (1551) 8154 posts |
1 I have literally lost count of the occasions where suppliers did not follow the instruction to “set to DHCP” and were surprised when what they did failed to work because they missed a critical aspect or mistyped a value or two. Or their system didn’t properly register in DNS and parts of our config relied on the FQDN rather than a fixed IP. |
Pages: 1 2