Add support for Unihertz Jelly2 [0e8d:2008]
It appears to be a pretty bog-standard Android phone that should present as an MTP device. Output from dmesg says ugen0 at uhub1 port 2 "Unihertz Jelly2" rev 2.10/2.23 addr 3 usbdevs says it's a addr 03: 0e8d:2008 Unihertz, Jelly2 I'm not sure how to go about adding those USB IDs, but hopefully this is enough to get it listed in the right place. This is on "7.0 GENERIC.MP#232 amd64" (generic -RELEASE). My hope is to get a simple-mtpfs mount at a minimum. I can provide further information if needed. Thanks, -tkc
Re: NSD exit status 11 on 7.0
Hi All,
Just to confirm that the below patch has been working like a charm.
Since the patch was applied, and only this patch, NSD has been behaving
properly.
Mischa
On 2021-10-20 12:33, Florian Obser wrote:
On 2021-10-20 07:55 +02, Otto Moerbeek wrote:
On Wed, Oct 20, 2021 at 07:47:30AM +0200, Mischa wrote:
Unfortunately our joy was short lived. This morning I noticed a lot
of
Oct 20 07:44:15 name1 nsd[80814]: server 76410 died unexpectedly with
status
11, restarting
It looks like there is a potentially fixed in version 4.3.8.
https://github.com/NLnetLabs/nsd/issues/195
https://github.com/NLnetLabs/nsd/issues/189
https://github.com/NLnetLabs/nsd/blob/NSD_4_3_8_REL/doc/ChangeLog
23 August 2021: Wouter
- Fix #189: nsd 4.3.7 crash answer_delegation: Assertion
`query->delegation_rrset' failed.
(Thanx Roger!)
That is not the correct fix, it only hides the problem and worse,
produces wrong results. Please try this, which is the fix for
https://github.com/NLnetLabs/nsd/issues/194
diff --git namedb.c namedb.c
index 06bef71147c..772e038b16d 100644
--- namedb.c
+++ namedb.c
@@ -583,10 +583,13 @@ domain_find_ns_rrsets(domain_type* domain,
zone_type* zone, rrset_type **ns)
{
/* return highest NS RRset in the zone that is a delegation above */
domain_type* result = NULL;
+ rrset_type* rrset = NULL;
while (domain && domain != zone->apex) {
- *ns = domain_find_rrset(domain, zone, TYPE_NS);
- if (*ns)
+ rrset = domain_find_rrset(domain, zone, TYPE_NS);
+ if (rrset) {
+ *ns = rrset;
result = domain;
+ }
domain = domain->parent;
}
As far as I can tell from the things Martijn found it might be the
case.
Will give that a try and report back.
Mischa
Are you going to try just the one line fix or the whole of 4.3.8?
I suppose if we want to backport to -stable the one-line fix is
preferred.
Yes, except, we should go with the correct fix above ;) Nothing else is
interesting to backport in 4.3.8 as far as I can tell.
-Otto
I provided an explanation what's going on in
https://github.com/NLnetLabs/nsd/issues/195#issuecomment-947505367
Reproduced here (slightly edited):
712296f (the one-line-fix) only hides the problem, it doesn't fix
anything. The real fix is ba0002e (the diff above).
f.9.1.1.0.0.2.ip6.arpa. is an ENT in ip6.arpa. and so is 2.ip6.arpa.
In line 1420 in query.c we haveq->delegation_domain =
domain_find_ns_rrsets(
and the unfixed domain_find_ns_rrsets would find the NS RRset for
9.1.1.0.0.2.ip6.arpa.
But it would then continue searching upwards, overwriting *ns which is
>delegation_rrset. Until it hits 2.ip6.arpa. which has no NS
records. So q->delegation_rrset = NULL but at the same time result !=
NULL because we did find a delegation RRset along the way, we just
ignored it (at least for 9.1.1.0.0.2.ip6.arpa., I didn't check if there
was one further up).
domain_find_ns_rrsets returns non-NULL which means we found a
delegation, but at the same time it doesn't give us the delegation NS
RRset.
It is probably best to revert 712296f since on its own it produces
wrong
results. I.e. adding it to 4.3.7 gives this:
$ dig @192.168.178.219 +norec f.9.1.1.0.0.2.ip6.arpa NS
; <<>> dig 9.10.8-P1 <<>> @192.168.178.219 +norec
f.9.1.1.0.0.2.ip6.arpa NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10923
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS
;; AUTHORITY SECTION:
ip6.arpa.3600INSOAb.ip6-servers.arpa.
nstld.iana.org. 2021100154 1800 900 604800 3600
;; Query time: 0 msec
;; SERVER: 192.168.178.219#53(192.168.178.219)
;; WHEN: Wed Oct 20 10:24:56 CEST 2021
;; MSG SIZE rcvd: 115
But the correct answer is this:
dig @::1 +norec f.9.1.1.0.0.2.ip6.arpa NS
; <<>> dig 9.10.8-P1 <<>> @::1 +norec f.9.1.1.0.0.2.ip6.arpa NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48090
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS
;; AUTHORITY SECTION:
9.1.1.0.0.2.ip6.arpa.86400INNSr.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSu.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSx.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSy.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSz.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSarin.authdns.ripe.net.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 20 10:24:16 CEST 2021
;; MSG SIZE rcvd: 171
Re: run(4) panic: null node
On Thu, 28 Oct 2021 10:10:23 + Klemens Nanni wrote:
> On Tue, Sep 14, 2021 at 05:52:08PM -0400, James Hastings wrote:
> > >Synopsis: run(4): connecting to WEP network. panic: null node
> > >Category: kernel
> > >Environment:
> > System : OpenBSD 7.0
> > Details : OpenBSD 7.0-beta (GENERIC.MP) #206: Thu Sep 9 09:24:02
> > MDT 2021
> >
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > I was testing various networks with a Ralink RT5370 USB run(4) device.
> > Connecting to a WEP-enabled SSID reliably produces the following kernel
> > panic:
>
> I looked at this out of curiosity and the code seems obviously wrong.
>
> > panic: null node
> > Stopped at db_enter+0x10: popq%rbp
> > TID PIDUID PRFLAGS PFLAGS CPU COMMAND
> > *515938 8927 0 0x14000 0x2003K usbtask
> > db_enter() at db_enter+0x10
> > panic(81e29b27) at panic+0xbf
> > ieee80211_send_mgmt(80e7d048,0,c0,3,0) at ieee80211_send_mgmt+0x3aa
> > run_set_key_cb(80e7d000,80e7fe00) at run_set_key_cb+0x76
> > run_task(80e7d000) at run_task+0xa9
> > usb_task_thread(800022d72550) at usb_task_thread+0x135
> > end trace frame: 0x0, count: 9
>
> run_init() does this
>
> if (ic->ic_flags & IEEE80211_F_WEPON) {
> /* install WEP keys */
> for (i = 0; i < IEEE80211_WEP_NKID; i++)
> (void)run_set_key(ic, NULL, >ic_nw_keys[i]);
> }
>
> run_set_key() passes that NULL argument unaltered to run_set_key_cb()
> which eventually calls ieee80211_send_mgmt() with a NULL `ni' argument
> which hits the panic.
>
> I don't see how this can work; maybe an oversight whenever run(4) or
> 802.11 was touched last?
Yes, apparently before
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_run.c.diff?r1=1.131=1.132=h
run_set_key_cb() wouldn't even look at 'cmd->ni'.
>
> > >How-To-Repeat:
> > $ doas ifconfig run0 nwid MYWEPSSID nwkey 0xXX
> > $ doas ifconfig run0 up
> >
> > >Fix:
> > Unknown at this time.
>
smime.p7s
Description: S/MIME cryptographic signature
Re: run(4) panic: null node
On Tue, Sep 14, 2021 at 05:52:08PM -0400, James Hastings wrote:
> >Synopsis:run(4): connecting to WEP network. panic: null node
> >Category:kernel
> >Environment:
> System : OpenBSD 7.0
> Details : OpenBSD 7.0-beta (GENERIC.MP) #206: Thu Sep 9 09:24:02
> MDT 2021
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> I was testing various networks with a Ralink RT5370 USB run(4) device.
> Connecting to a WEP-enabled SSID reliably produces the following kernel
> panic:
I looked at this out of curiosity and the code seems obviously wrong.
> panic: null node
> Stopped at db_enter+0x10: popq%rbp
> TID PIDUID PRFLAGS PFLAGS CPU COMMAND
> *515938 8927 0 0x14000 0x2003K usbtask
> db_enter() at db_enter+0x10
> panic(81e29b27) at panic+0xbf
> ieee80211_send_mgmt(80e7d048,0,c0,3,0) at ieee80211_send_mgmt+0x3aa
> run_set_key_cb(80e7d000,80e7fe00) at run_set_key_cb+0x76
> run_task(80e7d000) at run_task+0xa9
> usb_task_thread(800022d72550) at usb_task_thread+0x135
> end trace frame: 0x0, count: 9
run_init() does this
if (ic->ic_flags & IEEE80211_F_WEPON) {
/* install WEP keys */
for (i = 0; i < IEEE80211_WEP_NKID; i++)
(void)run_set_key(ic, NULL, >ic_nw_keys[i]);
}
run_set_key() passes that NULL argument unaltered to run_set_key_cb()
which eventually calls ieee80211_send_mgmt() with a NULL `ni' argument
which hits the panic.
I don't see how this can work; maybe an oversight whenever run(4) or
802.11 was touched last?
> >How-To-Repeat:
> $ doas ifconfig run0 nwid MYWEPSSID nwkey 0xXX
> $ doas ifconfig run0 up
>
> >Fix:
> Unknown at this time.
Re: dhcpleased: No ipv4 address after sysupgrade 6.9 -> 7.0. parse_dhcp: invalid ports used
On Thu, Oct 28, 2021 at 04:02:33AM +0900, Roc Vallès wrote: > Yes, it does. It gets an IPv4 address with the check removed. Fixed, thanks for the report.
