Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #210698 > unrolled thread
| Started by | Gene Heskett <gheskett@shentel.net> |
|---|---|
| First post | 2019-07-04 03:10 +0200 |
| Last post | 2019-07-07 13:30 +0200 |
| Articles | 20 on this page of 94 — 14 participants |
Back to article view | Back to linux.debian.user
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Assorted arm-buster problems #1 Gene Heskett <gheskett@shentel.net> - 2019-07-04 03:10 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-04 09:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-04 10:50 +0200
Re: Assorted arm-buster problems - network configuration Felix Miata <mrmazda@earthlink.net> - 2019-07-04 11:30 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-04 11:50 +0200
Re: Assorted arm-buster problems - network configuration mick crane <mick.crane@gmail.com> - 2019-07-04 12:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-04 16:50 +0200
Re: Assorted arm-buster problems - network configuration mick crane <mick.crane@gmail.com> - 2019-07-04 19:20 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-05 06:00 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 12:40 +0200
Re: Assorted arm-buster problems - network configuration Jonas Smedegaard <jonas@jones.dk> - 2019-07-05 13:20 +0200
Re: Assorted arm-buster problems - network configuration Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-05 14:50 +0200
Re: Assorted arm-buster problems - network configuration Reco <recoverym4n@enotuniq.net> - 2019-07-05 15:10 +0200
Re: Assorted arm-buster problems - network configuration Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-05 15:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-06 02:30 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-06 02:20 +0200
Re: Assorted arm-buster problems - network configuration David Wright <deblis@lionunicorn.co.uk> - 2019-07-06 15:50 +0200
Re: Assorted arm-buster problems - network configuration Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-08 14:40 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-08 15:00 +0200
Re: Assorted arm-buster problems - network configuration David Wright <deblis@lionunicorn.co.uk> - 2019-07-08 16:30 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-06 07:30 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-04 17:50 +0200
Re: Assorted arm-buster problems - network configuration Reco <recoverym4n@enotuniq.net> - 2019-07-04 18:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-04 19:40 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-04 21:10 +0200
Re: Assorted arm-buster problems - network configuration Tixy <tixy@yxit.co.uk> - 2019-07-04 22:00 +0200
Re: Assorted arm-buster problems - network configuration <tomas@tuxteam.de> - 2019-07-04 22:10 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-04 22:50 +0200
Re: Assorted arm-buster problems - network configuration <tomas@tuxteam.de> - 2019-07-04 22:50 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 11:10 +0200
Re: Assorted arm-buster problems - network configuration Reco <recoverym4n@enotuniq.net> - 2019-07-05 09:00 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-05 11:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 17:20 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-05 19:30 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-05 20:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 13:00 +0200
Re: Assorted arm-buster problems - network configuration Tixy <tixy@yxit.co.uk> - 2019-07-05 13:40 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 17:40 +0200
Re: Assorted arm-buster problems - network configuration Jonas Smedegaard <jonas@jones.dk> - 2019-07-05 13:40 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 17:50 +0200
Re: Assorted arm-buster problems - network configuration Jonas Smedegaard <jonas@jones.dk> - 2019-07-05 19:10 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-06 03:30 +0200
Re: Assorted arm-buster problems - network configuration <tomas@tuxteam.de> - 2019-07-05 13:40 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 18:00 +0200
Re: Assorted arm-buster problems - network configuration Reco <recoverym4n@enotuniq.net> - 2019-07-05 14:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 20:40 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-06 06:40 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 10:40 +0200
Re: Assorted arm-buster problems - network configuration Curt <curty@free.fr> - 2019-07-05 11:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 16:30 +0200
Re: Assorted arm-buster problems - network configuration Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-05 15:10 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-06 02:20 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-05 21:30 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-05 22:20 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-05 22:30 +0200
Re: Assorted arm-buster problems - network configuration <tomas@tuxteam.de> - 2019-07-05 22:50 +0200
Re: Assorted arm-buster problems - network configuration Curt <curty@free.fr> - 2019-07-06 10:20 +0200
Re: Assorted arm-buster problems - network configuration <tomas@tuxteam.de> - 2019-07-06 12:50 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-06 21:40 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-07 08:50 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-08 19:40 +0200
Re: Assorted arm-buster problems - network configuration Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 20:10 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-08 20:50 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-08 21:50 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-08 23:20 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-08 21:20 +0200
Re: Assorted arm-buster problems - network configuration Curt <curty@free.fr> - 2019-07-07 11:00 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-08 19:50 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-06 03:40 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-06 21:40 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-07 00:20 +0200
Re: Assorted arm-buster problems - network configuration David Wright <deblis@lionunicorn.co.uk> - 2019-07-07 06:20 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-07 07:00 +0200
Re: Assorted arm-buster problems - network configuration David Wright <deblis@lionunicorn.co.uk> - 2019-07-07 17:10 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-07 09:00 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-07 13:20 +0200
Re: Assorted arm-buster problems - network configuration Jonas Smedegaard <jonas@jones.dk> - 2019-07-07 14:50 +0200
Re: Assorted arm-buster problems - network configuration Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-07 18:30 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-07 23:00 +0200
Re: Assorted arm-buster problems - network configuration Reco <recoverym4n@enotuniq.net> - 2019-07-07 22:00 +0200
Re: Assorted arm-buster problems - network configuration Brian <ad44@cityscape.co.uk> - 2019-07-08 20:30 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-04 23:00 +0200
Re: Assorted arm-buster problems - network configuration Lee <ler762@gmail.com> - 2019-07-04 19:50 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-04 22:50 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-05 12:10 +0200
Re: Assorted arm-buster problems - network configuration David Wright <deblis@lionunicorn.co.uk> - 2019-07-05 18:10 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-06 03:20 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-06 07:10 +0200
Re: Assorted arm-buster problems - network configuration David Wright <deblis@lionunicorn.co.uk> - 2019-07-06 18:10 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-07 02:40 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-07 03:40 +0200
Re: Assorted arm-buster problems - network configuration David Wright <deblis@lionunicorn.co.uk> - 2019-07-07 06:30 +0200
Re: Assorted arm-buster problems - network configuration andreimpopescu@gmail.com - 2019-07-07 09:10 +0200
Re: Assorted arm-buster problems - network configuration Gene Heskett <gheskett@shentel.net> - 2019-07-07 13:30 +0200
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2019-07-08 19:40 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhFMl-ZV-5@gated-at.bofh.it> |
| In reply to | #210881 |
On 7/7/19, andreimpopescu@gmail.com <andreimpopescu@gmail.com> wrote: > On Sb, 06 iul 19, 15:36:37, Lee wrote: >> >> "an accident waiting to happen" was from me and I also gave the rfc >> for mdns, so that's hardly "nothing of substance to support that >> view." If you're having trouble finding the rfc, it's here >> https://tools.ietf.org/html/rfc6762 > > Care to elaborate though? While reading about a security issue I came across the line "An insecure protocol will eventually be exploited." - which sounds right to me. And the standard q&a for most security issues involving an insecure protocol seems to be q: how do i prevent <bad thing> from happening? a: by not allowing it in the first place. Hopefully we're clear about my bias now :) > The dangers are not at all obvious to me, possibly because I haven't > used it much (if at all). Read the first three paragraph of the "Security Considerations" section https://tools.ietf.org/html/rfc6762#section-21 Assuming everything on the network is a trusted host is a dangerous assumption, so paragraph 1 is N/A Assuming a trusted host won't get hacked is a dangerous assumption, so paragraph 3 is N/A. All that's left is paragraph 2 -- and uninstalling whatever software uses mDNS :) Regards, Lee
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2019-07-08 20:10 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhGfn-1pj-3@gated-at.bofh.it> |
| In reply to | #211015 |
[Multipart message — attachments visible in raw view] — view raw
On Lu, 08 iul 19, 13:37:26, Lee wrote: > On 7/7/19, andreimpopescu@gmail.com <andreimpopescu@gmail.com> wrote: > > > The dangers are not at all obvious to me, possibly because I haven't > > used it much (if at all). > > Read the first three paragraph of the "Security Considerations" section > https://tools.ietf.org/html/rfc6762#section-21 > > Assuming everything on the network is a trusted host is a dangerous > assumption, so paragraph 1 is N/A > > Assuming a trusted host won't get hacked is a dangerous assumption, so > paragraph 3 is N/A. > > All that's left is paragraph 2 -- and uninstalling whatever software > uses mDNS :) Security is not a black/white thing, it's more like a balancing act. In my opinion mDNS/zeroconf can make perfect sense in some environments and be a complete no-go in others. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2019-07-08 20:50 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhGS5-1CP-3@gated-at.bofh.it> |
| In reply to | #211021 |
On 7/8/19, Andrei POPESCU <andreimpopescu@gmail.com> wrote: > On Lu, 08 iul 19, 13:37:26, Lee wrote: >> On 7/7/19, andreimpopescu@gmail.com <andreimpopescu@gmail.com> wrote: >> >> > The dangers are not at all obvious to me, possibly because I haven't >> > used it much (if at all). >> >> Read the first three paragraph of the "Security Considerations" section >> https://tools.ietf.org/html/rfc6762#section-21 >> >> Assuming everything on the network is a trusted host is a dangerous >> assumption, so paragraph 1 is N/A >> >> Assuming a trusted host won't get hacked is a dangerous assumption, so >> paragraph 3 is N/A. >> >> All that's left is paragraph 2 -- and uninstalling whatever software >> uses mDNS :) > > Security is not a black/white thing, it's more like a balancing act. Agreed > In my opinion mDNS/zeroconf can make perfect sense in some environments > and be a complete no-go in others. Apparently it's not clear that I agree :( I thought about concluding with something about different people making different assumptions & some not wanting or able to set up their own dns server & living with the risk, but it seemed like such an obvious conclusion that I didn't bother. Regards, Lee
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-07-08 21:50 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhHOa-2ce-1@gated-at.bofh.it> |
| In reply to | #211027 |
On Monday 08 July 2019 14:48:59 Lee wrote: > On 7/8/19, Andrei POPESCU <andreimpopescu@gmail.com> wrote: > > On Lu, 08 iul 19, 13:37:26, Lee wrote: > >> On 7/7/19, andreimpopescu@gmail.com <andreimpopescu@gmail.com> wrote: > >> > The dangers are not at all obvious to me, possibly because I > >> > haven't used it much (if at all). > >> > >> Read the first three paragraph of the "Security Considerations" > >> section https://tools.ietf.org/html/rfc6762#section-21 > >> > >> Assuming everything on the network is a trusted host is a dangerous > >> assumption, so paragraph 1 is N/A > >> > >> Assuming a trusted host won't get hacked is a dangerous assumption, > >> so paragraph 3 is N/A. > >> > >> All that's left is paragraph 2 -- and uninstalling whatever > >> software uses mDNS :) > > > > Security is not a black/white thing, it's more like a balancing act. > > Agreed > > > In my opinion mDNS/zeroconf can make perfect sense in some > > environments and be a complete no-go in others. > > Apparently it's not clear that I agree :( > > I thought about concluding with something about different people > making different assumptions & some not wanting or able to set up > their own dns server & living with the risk, but it seemed like such > an obvious conclusion that I didn't bother. > > Regards, > Lee If referring to my problem Lee, dns the way I have it setup since roughly 1998 works perfectly. Its the lack of a dhcpd-like server, which adds needless complexity IMO to an otherwise working system I've been using since before I retired my amiga in 2000. In my case, both avahi-daemon and dchpcd5 were inventing bogus ip addresses, and setting the metric very low, forcing the system to use the bogus 169.254.etc numbers. And they were cached, I suspect in /proc/network, so in order to achieve a working system, issueing the testing pings from the machines own address, asking the router for the NAT translation. The router of course is running dnsmasq so it caches the common stuff, and if it does not have it in the cache its asks my ISP's dns. Takes about 90 ms if it has to ask a shentel dns server. But both the router and the managed switch that connects the rest of my machines, respond only to 192.168.71.00/24 stuff, so 169 stuff is /dev/nulled as it should be. So I had no external network access from that machine. I do have a dhcpd server in the router, facing the radio when its turned on and supposedly responding only to the MAC's of my sons smartfones. So they can use my bandwidth when within range, but their smartfones can't see me. Most of the time they are 1000+ miles out of range. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2019-07-08 23:20 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhJdg-3bp-5@gated-at.bofh.it> |
| In reply to | #211039 |
On 7/8/19, Gene Heskett <gheskett@shentel.net> wrote: > On Monday 08 July 2019 14:48:59 Lee wrote: > >> On 7/8/19, Andrei POPESCU <andreimpopescu@gmail.com> wrote: >> > On Lu, 08 iul 19, 13:37:26, Lee wrote: >> >> On 7/7/19, andreimpopescu@gmail.com <andreimpopescu@gmail.com> > wrote: >> >> > The dangers are not at all obvious to me, possibly because I >> >> > haven't used it much (if at all). >> >> >> >> Read the first three paragraph of the "Security Considerations" >> >> section https://tools.ietf.org/html/rfc6762#section-21 >> >> >> >> Assuming everything on the network is a trusted host is a dangerous >> >> assumption, so paragraph 1 is N/A >> >> >> >> Assuming a trusted host won't get hacked is a dangerous assumption, >> >> so paragraph 3 is N/A. >> >> >> >> All that's left is paragraph 2 -- and uninstalling whatever >> >> software uses mDNS :) >> > >> > Security is not a black/white thing, it's more like a balancing act. >> >> Agreed >> >> > In my opinion mDNS/zeroconf can make perfect sense in some >> > environments and be a complete no-go in others. >> >> Apparently it's not clear that I agree :( >> >> I thought about concluding with something about different people >> making different assumptions & some not wanting or able to set up >> their own dns server & living with the risk, but it seemed like such >> an obvious conclusion that I didn't bother. >> >> Regards, >> Lee > > If referring to my problem Lee, Nope, this sub-thread is a result of my offering a hyperbolic opinion to someone else. You're very clearly in the "my network, my rules" camp, so I won't be offering any opinions on how you should/shouldn't run your own network :) Regards, Lee
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2019-07-08 21:20 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhHl7-22v-5@gated-at.bofh.it> |
| In reply to | #211015 |
On Mon 08 Jul 2019 at 13:37:26 -0400, Lee wrote: > On 7/7/19, andreimpopescu@gmail.com <andreimpopescu@gmail.com> wrote: > > On Sb, 06 iul 19, 15:36:37, Lee wrote: > >> > >> "an accident waiting to happen" was from me and I also gave the rfc > >> for mdns, so that's hardly "nothing of substance to support that > >> view." If you're having trouble finding the rfc, it's here > >> https://tools.ietf.org/html/rfc6762 > > > > Care to elaborate though? > > While reading about a security issue I came across the line "An > insecure protocol will eventually be exploited." - which sounds right > to me. And the standard q&a for most security issues involving an > insecure protocol seems to be > q: how do i prevent <bad thing> from happening? > a: by not allowing it in the first place. > > Hopefully we're clear about my bias now :) Indeed we are. Everyone has a bias of one sort or another. It is often what makes things interesting. > > > The dangers are not at all obvious to me, possibly because I haven't > > used it much (if at all). > > Read the first three paragraph of the "Security Considerations" section > https://tools.ietf.org/html/rfc6762#section-21 > > Assuming everything on the network is a trusted host is a dangerous > assumption, so paragraph 1 is N/A > > Assuming a trusted host won't get hacked is a dangerous assumption, so > paragraph 3 is N/A. > > All that's left is paragraph 2 -- and uninstalling whatever software > uses mDNS :) I am unsure your analysis necessarily leads to to the conclusion you make. Perhaps it does for you, but the section is, after all, dealing only with considerations. You have assessed them and come to a decision which fits your situation. Anyway, thank you for this diligent response. It is differs somewhat from > I'd also consider exterminating avahi with extreme prejudice, > i.e. 'aptpurge avahi-daemon'. Really simplifies things. Not > installing this software in the first place works even better. This lead only to boltstering the OP's inate prejudices against software he lacks understanding of and that does not fit into his world view.. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2019-07-07 11:00 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhbbA-7IW-13@gated-at.bofh.it> |
| In reply to | #210850 |
On 2019-07-06, Lee <ler762@gmail.com> wrote: > > "an accident waiting to happen" was from me and I also gave the rfc > for mdns, so that's hardly "nothing of substance to support that I see. So the totality of the mdns rfc (*somewhat* more succinct than a 19th century Russian novelistic endeavor) is the substantive foundation of your sound technical argument that avahi and its daemons are "an accident waiting to happen" (whatever that means exactly, but I fear to ask because you might refer me to Webster's Unabridged or the L.A. phone book circa 1974, which would entrain just too much summer reading for me, friend, as I prefer to do my wading through the sea). -- "These findings demonstrate that under appropriate conditions the isolated, intact large mammalian brain possesses an underappreciated capacity for restoration of microcirculation and molecular and cellular activity after a prolonged post-mortem interval." From a recent article in *Nature*. Holy shit.
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2019-07-08 19:50 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhFW3-13s-11@gated-at.bofh.it> |
| In reply to | #210885 |
On 7/7/19, Curt <curty@free.fr> wrote: > On 2019-07-06, Lee <ler762@gmail.com> wrote: >> >> "an accident waiting to happen" was from me and I also gave the rfc >> for mdns, so that's hardly "nothing of substance to support that > > I see. So the totality of the mdns rfc (*somewhat* more succinct than a > 19th century Russian novelistic endeavor) is the substantive foundation > of your sound technical argument that avahi and its daemons are "an > accident waiting to happen" (whatever that means exactly, but I fear to > ask because you might refer me to Webster's Unabridged or the L.A. phone > book circa 1974, which would entrain just too much summer reading for > me, friend, as I prefer to do my wading through the sea). In other words, you didn't even take a quick peek at the security considerations section. Right? Regards, Lee
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-07-06 03:40 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <ygHQe-7cp-5@gated-at.bofh.it> |
| In reply to | #210807 |
On Friday 05 July 2019 15:23:38 Brian wrote: > On Fri 05 Jul 2019 at 04:33:42 -0400, Gene Heskett wrote: > > On Thursday 04 July 2019 16:42:11 Brian wrote: > > > If nobody objects I would like to reword that statement. Many, > > > many users will have avahi-daemon on their systems; a few won't. > > > The idea that > > > > > > > Not installing this software in the first place works even > > > > better. > > > > > > requires clarification. > > > > Aha! Took several more hours but I found the SOB screwing my static > > network! Soooo.... > > I was rather hoping someone would clarify why not having avahi-daemon > in the first place was a good thing in general. Your problem doesn't > particularly interest me because it is probably something you have > brought on yourself due to previous actions. > > > Here is your Clarification: I used apt to purge avahi-daemon which > > took nsswitch with it, > > I stopped reading there. I am not into fantasy. Which proves another theorem of mine. Folks with a sheepskin on the office wall stop learning, and by your stopping without reading the explanation is evidence of that effect. I can lead you to the facts, but like the horse refusing to drink when led to water, I'll drop the reins. You may, or may not drink the water of knowledge. I can't control that. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2019-07-06 21:40 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <ygYHn-g0-5@gated-at.bofh.it> |
| In reply to | #210823 |
On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote: > On Friday 05 July 2019 15:23:38 Brian wrote: > > > I was rather hoping someone would clarify why not having avahi-daemon > > in the first place was a good thing in general. Your problem doesn't > > particularly interest me because it is probably something you have > > brought on yourself due to previous actions. > > > > > Here is your Clarification: I used apt to purge avahi-daemon which > > > took nsswitch with it, > > > > I stopped reading there. I am not into fantasy. > > Which proves another theorem of mine. Folks with a sheepskin on the > office wall stop learning, and by your stopping without reading the > explanation is evidence of that effect. I can lead you to the facts, but Your first "fact" is demonstrably incorrect and has been shown to be so. Indeed, you seem to have backed away from your claim that avahi-daemon is the cause of your difficulties. The only place you lead people is up the misleading garden path. A clear statement of what you did and what happened is more likely to bring results; making attacking software a lifestyle choice gets a bit boring after a while. > like the horse refusing to drink when led to water, I'll drop the reins. > You may, or may not drink the water of knowledge. I can't control that. Is this an attempt at some self-promotion as the fount of knowledge? I never thought I would live to see the day! -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-07-07 00:20 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yh1cd-1Pc-7@gated-at.bofh.it> |
| In reply to | #210851 |
On Saturday 06 July 2019 15:35:10 Brian wrote:
> On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote:
> > On Friday 05 July 2019 15:23:38 Brian wrote:
> > > I was rather hoping someone would clarify why not having
> > > avahi-daemon in the first place was a good thing in general. Your
> > > problem doesn't particularly interest me because it is probably
> > > something you have brought on yourself due to previous actions.
> > >
> > > > Here is your Clarification: I used apt to purge avahi-daemon
> > > > which took nsswitch with it,
> > >
> > > I stopped reading there. I am not into fantasy.
> >
> > Which proves another theorem of mine. Folks with a sheepskin on the
> > office wall stop learning, and by your stopping without reading the
> > explanation is evidence of that effect. I can lead you to the facts,
> > but
>
> Your first "fact" is demonstrably incorrect and has been shown to be
> so. Indeed, you seem to have backed away from your claim that
> avahi-daemon is the cause of your difficulties. The only place you
> lead people is up the misleading garden path. A clear statement of
> what you did and what happened is more likely to bring results; making
> attacking software a lifestyle choice gets a bit boring after a while.
>
> > like the horse refusing to drink when led to water, I'll drop the
> > reins. You may, or may not drink the water of knowledge. I can't
> > control that.
>
> Is this an attempt at some self-promotion as the fount of knowledge?
> I never thought I would live to see the day!
If you read the full thread, you will find where I found and fixed that
problem, by killing dhcpd5 with htop, and restarting networking, and the
problem was fixed, everything then worked correctly, but I have not
reinstalled avahi-daemon to see if it returns. Perhaps I should because
it appears there were 2 sources of that trash.
Yes, I purged what was left as it wouldn't reinstall, then reinstalled
avahi-daemon. results:
With avahi-daemon running. the trash in the ip a report was back after a
networking restart, BUT allthough it showed in an ip r report with a
metric of 202, I could still ping yahoo.com. I could not before.
So I service avahi-daemon stopped it, and restarted the networking, trash
169.254 junk gone. An yahoo.com still pinged.
So I've purged it again. And restarted the networking yet again.
ip a:
pi@picnc:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN group default qlen 1000
link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
ip r:
pi@picnc:~ $ ip r
default via 192.168.71.1 dev eth0 onlink
192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
So I now have a working network. Free of the bogus inventions of dhcpd5
and avahi. That _was_ the point of all this hoopla in the first place.
Now, I have learned what works to _my_ satisfaction.
Have you? Or did you quit reading the instant I went off the edge of your
menu?
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2019-07-07 06:20 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yh6OB-5eG-1@gated-at.bofh.it> |
| In reply to | #210859 |
On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote: > On Saturday 06 July 2019 15:35:10 Brian wrote: > > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote: > > > On Friday 05 July 2019 15:23:38 Brian wrote: > > > > I was rather hoping someone would clarify why not having > > > > avahi-daemon in the first place was a good thing in general. Your > > > > problem doesn't particularly interest me because it is probably > > > > something you have brought on yourself due to previous actions. > > > > > > > > > Here is your Clarification: I used apt to purge avahi-daemon > > > > > which took nsswitch with it, That was your claim. Then I read the following: Greg> Whatever Gene did, it's absolutely not normal or desirable for Greg> nsswitch.conf to vanish. I still think he deleted it by hand and then Greg> forgot the exact sequence of steps which led to its disappearance, so Greg> he simply blamed it on purging ahavi-daemon. Gene> I didn't say that. If I made that impression I didn't intend to. I Gene> removed it by hand about 2 hours back but that u-sd has not been Gene> inserted in the pi yet as I'm also the chief cook […] Gene> […] recycle the dishwasher. :( https://lists.debian.org/debian-user/2019/07/msg00306.html > > > > I stopped reading there. I am not into fantasy. > > > > > > Which proves another theorem of mine. Folks with a sheepskin on the > > > office wall stop learning, and by your stopping without reading the > > > explanation is evidence of that effect. I can lead you to the facts, > > > but > > > > Your first "fact" is demonstrably incorrect and has been shown to be > > so. Indeed, you seem to have backed away from your claim that > > avahi-daemon is the cause of your difficulties. The only place you > > lead people is up the misleading garden path. A clear statement of > > what you did and what happened is more likely to bring results; making > > attacking software a lifestyle choice gets a bit boring after a while. > > > > > like the horse refusing to drink when led to water, I'll drop the > > > reins. You may, or may not drink the water of knowledge. I can't > > > control that. > > > > Is this an attempt at some self-promotion as the fount of knowledge? > > I never thought I would live to see the day! > > If you read the full thread, you will find where I found and fixed that > problem, by killing dhcpd5 with htop, and restarting networking, and the > problem was fixed, everything then worked correctly, but I have not > reinstalled avahi-daemon to see if it returns. Perhaps I should because > it appears there were 2 sources of that trash. Perhaps you mean dhcpcd5? I thought you said that you're "the last one on the planet using hosts files and no dhcpd's of any kind". If you were running this, did you try using the -L or --noipv4ll option? > Yes, I purged what was left as it wouldn't reinstall, then reinstalled > avahi-daemon. results: > > With avahi-daemon running. the trash in the ip a report was back after a > networking restart, BUT allthough it showed in an ip r report with a > metric of 202, I could still ping yahoo.com. I could not before. > > So I service avahi-daemon stopped it, and restarted the networking, trash > 169.254 junk gone. An yahoo.com still pinged. > > So I've purged it again. And restarted the networking yet again. > ip a: > pi@picnc:~ $ ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff > inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0 > valid_lft forever preferred_lft forever > inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link > valid_lft forever preferred_lft forever > 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast > state DOWN group default qlen 1000 > link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff > > ip r: > pi@picnc:~ $ ip r > default via 192.168.71.1 dev eth0 onlink > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12 That looks very like what I posted, except for "onlink"; also I'm connected by wireless rather than wire. But my ps -ef listing and nsswitch.conf file show: $ ps -ef | grep avahi | grep -v grep ; grep hosts /etc/nsswitch.conf avahi 653 1 0 21:23 ? 00:00:00 avahi-daemon: running [wren.local] avahi 666 653 0 21:23 ? 00:00:00 avahi-daemon: chroot helper hosts: files mdns4_minimal [NOTFOUND=return] dns $ > So I now have a working network. Free of the bogus inventions of dhcpd5 > and avahi. That _was_ the point of all this hoopla in the first place. > > Now, I have learned what works to _my_ satisfaction. Glad to hear it. I still don't see that you've shown why you had to purge avahi to get your results above. > Have you? Or did you quit reading the instant I went off the edge of your > menu? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-07-07 07:00 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yh7rj-5u9-1@gated-at.bofh.it> |
| In reply to | #210875 |
On Sunday 07 July 2019 00:11:43 David Wright wrote: > On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote: > > On Saturday 06 July 2019 15:35:10 Brian wrote: > > > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote: > > > > On Friday 05 July 2019 15:23:38 Brian wrote: > > > > > I was rather hoping someone would clarify why not having > > > > > avahi-daemon in the first place was a good thing in general. > > > > > Your problem doesn't particularly interest me because it is > > > > > probably something you have brought on yourself due to > > > > > previous actions. > > > > > > > > > > > Here is your Clarification: I used apt to purge avahi-daemon > > > > > > which took nsswitch with it, > > That was your claim. Then I read the following: > > Greg> Whatever Gene did, it's absolutely not normal or desirable for > Greg> nsswitch.conf to vanish. I still think he deleted it by hand > and then Greg> forgot the exact sequence of steps which led to its > disappearance, so Greg> he simply blamed it on purging ahavi-daemon. > > Gene> I didn't say that. If I made that impression I didn't intend > to. I Gene> removed it by hand about 2 hours back but that u-sd has > not been Gene> inserted in the pi yet as I'm also the chief cook […] > Gene> […] recycle the dishwasher. :( > > https://lists.debian.org/debian-user/2019/07/msg00306.html > > > > > > I stopped reading there. I am not into fantasy. > > > > > > > > Which proves another theorem of mine. Folks with a sheepskin on > > > > the office wall stop learning, and by your stopping without > > > > reading the explanation is evidence of that effect. I can lead > > > > you to the facts, but > > > > > > Your first "fact" is demonstrably incorrect and has been shown to > > > be so. Indeed, you seem to have backed away from your claim that > > > avahi-daemon is the cause of your difficulties. The only place you > > > lead people is up the misleading garden path. A clear statement of > > > what you did and what happened is more likely to bring results; > > > making attacking software a lifestyle choice gets a bit boring > > > after a while. > > > > > > > like the horse refusing to drink when led to water, I'll drop > > > > the reins. You may, or may not drink the water of knowledge. I > > > > can't control that. > > > > > > Is this an attempt at some self-promotion as the fount of > > > knowledge? I never thought I would live to see the day! > > > > If you read the full thread, you will find where I found and fixed > > that problem, by killing dhcpd5 with htop, and restarting > > networking, and the problem was fixed, everything then worked > > correctly, but I have not reinstalled avahi-daemon to see if it > > returns. Perhaps I should because it appears there were 2 sources > > of that trash. > > Perhaps you mean dhcpcd5? I thought you said that you're "the last one > on the planet using hosts files and no dhcpd's of any kind". > That last as a qualifier was a bad reference too, as I now see the name of that function having been changed sometime in the last 20 years. > If you were running this, did you try using the -L or --noipv4ll > option? No, and whereintunket would I find that in reference to my problem?> > > Yes, I purged what was left as it wouldn't reinstall, then > > reinstalled avahi-daemon. results: > > > > With avahi-daemon running. the trash in the ip a report was back > > after a networking restart, BUT allthough it showed in an ip r > > report with a metric of 202, I could still ping yahoo.com. I could > > not before. > > > > So I service avahi-daemon stopped it, and restarted the networking, > > trash 169.254 junk gone. An yahoo.com still pinged. > > > > So I've purged it again. And restarted the networking yet again. > > ip a: > > pi@picnc:~ $ ip a > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > > group default qlen 1000 > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > inet 127.0.0.1/8 scope host lo > > valid_lft forever preferred_lft forever > > inet6 ::1/128 scope host > > valid_lft forever preferred_lft forever > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > > state UP group default qlen 1000 > > link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff > > inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0 > > valid_lft forever preferred_lft forever > > inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link > > valid_lft forever preferred_lft forever > > 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc > > pfifo_fast state DOWN group default qlen 1000 > > link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff > > > > ip r: > > pi@picnc:~ $ ip r > > default via 192.168.71.1 dev eth0 onlink > > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12 > > That looks very like what I posted, except for "onlink"; also I'm > connected by wireless rather than wire. But my ps -ef listing > and nsswitch.conf file show: > $ ps -ef | grep avahi | grep -v grep ; grep hosts /etc/nsswitch.conf > avahi 653 1 0 21:23 ? 00:00:00 avahi-daemon: running > [wren.local] avahi 666 653 0 21:23 ? 00:00:00 > avahi-daemon: chroot helper hosts: files mdns4_minimal > [NOTFOUND=return] dns > > > So I now have a working network. Free of the bogus inventions of > > dhcpd5 and avahi. That _was_ the point of all this hoopla in the > > first place. > > > > Now, I have learned what works to _my_ satisfaction. > > Glad to hear it. I still don't see that you've shown why you had to > purge avahi to get your results above. > > > Have you? Or did you quit reading the instant I went off the edge of > > your menu? > I ask because I've since found that if I give avahi a chance to pollute things, removeing it does no good until you've rebooted the machine and I have already found that out for dhcpcd5. Either one can pollute, but to get the full effect of removing it, you must reboot the machine. However I am reticent to do that as I then have to go to the machine and hand start ssh as it won't start on reboot even if told to. Why is that? I have had no such trouble with a realtime stretch. > Cheers, > David. Cheers yourself David Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2019-07-07 17:10 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhgXE-2W8-3@gated-at.bofh.it> |
| In reply to | #210878 |
On Sun 07 Jul 2019 at 00:57:58 (-0400), Gene Heskett wrote: > On Sunday 07 July 2019 00:11:43 David Wright wrote: > > On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote: > > > On Saturday 06 July 2019 15:35:10 Brian wrote: > > > > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote: > > > > > On Friday 05 July 2019 15:23:38 Brian wrote: > > > > > > I was rather hoping someone would clarify why not having > > > > > > avahi-daemon in the first place was a good thing in general. > > > > > > Your problem doesn't particularly interest me because it is > > > > > > probably something you have brought on yourself due to > > > > > > previous actions. > > > > > > > > > > > > > Here is your Clarification: I used apt to purge avahi-daemon > > > > > > > which took nsswitch with it, > > > > That was your claim. Then I read the following: > > > > Greg> Whatever Gene did, it's absolutely not normal or desirable for > > Greg> nsswitch.conf to vanish. I still think he deleted it by hand > > and then Greg> forgot the exact sequence of steps which led to its > > disappearance, so Greg> he simply blamed it on purging ahavi-daemon. > > > > Gene> I didn't say that. If I made that impression I didn't intend > > to. I Gene> removed it by hand about 2 hours back but that u-sd has > > not been Gene> inserted in the pi yet as I'm also the chief cook […] > > Gene> […] recycle the dishwasher. :( > > > > https://lists.debian.org/debian-user/2019/07/msg00306.html > > > > > > > > I stopped reading there. I am not into fantasy. > > > > > > > > > > Which proves another theorem of mine. Folks with a sheepskin on > > > > > the office wall stop learning, and by your stopping without > > > > > reading the explanation is evidence of that effect. I can lead > > > > > you to the facts, but > > > > > > > > Your first "fact" is demonstrably incorrect and has been shown to > > > > be so. Indeed, you seem to have backed away from your claim that > > > > avahi-daemon is the cause of your difficulties. The only place you > > > > lead people is up the misleading garden path. A clear statement of > > > > what you did and what happened is more likely to bring results; > > > > making attacking software a lifestyle choice gets a bit boring > > > > after a while. > > > > > > > > > like the horse refusing to drink when led to water, I'll drop > > > > > the reins. You may, or may not drink the water of knowledge. I > > > > > can't control that. > > > > > > > > Is this an attempt at some self-promotion as the fount of > > > > knowledge? I never thought I would live to see the day! > > > > > > If you read the full thread, you will find where I found and fixed > > > that problem, by killing dhcpd5 with htop, and restarting > > > networking, and the problem was fixed, everything then worked > > > correctly, but I have not reinstalled avahi-daemon to see if it > > > returns. Perhaps I should because it appears there were 2 sources > > > of that trash. > > > > Perhaps you mean dhcpcd5? I thought you said that you're "the last one > > on the planet using hosts files and no dhcpd's of any kind". > > > That last as a qualifier was a bad reference too, as I now see the name > of that function having been changed sometime in the last 20 years. > > > If you were running this, did you try using the -L or --noipv4ll > > option? > > No, and whereintunket would I find that in reference to my problem?> As you might guess, I don't have dhcpcd5 installed and have no interest in it, so I typed man dhcpcd5 into google. Kind of obvious really. > > > Yes, I purged what was left as it wouldn't reinstall, then > > > reinstalled avahi-daemon. results: > > > > > > With avahi-daemon running. the trash in the ip a report was back > > > after a networking restart, BUT allthough it showed in an ip r > > > report with a metric of 202, I could still ping yahoo.com. I could > > > not before. > > > > > > So I service avahi-daemon stopped it, and restarted the networking, > > > trash 169.254 junk gone. An yahoo.com still pinged. > > > > > > So I've purged it again. And restarted the networking yet again. > > > ip a: > > > pi@picnc:~ $ ip a > > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > > > group default qlen 1000 > > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > > inet 127.0.0.1/8 scope host lo > > > valid_lft forever preferred_lft forever > > > inet6 ::1/128 scope host > > > valid_lft forever preferred_lft forever > > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > > > state UP group default qlen 1000 > > > link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff > > > inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0 > > > valid_lft forever preferred_lft forever > > > inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link > > > valid_lft forever preferred_lft forever > > > 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc > > > pfifo_fast state DOWN group default qlen 1000 > > > link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff > > > > > > ip r: > > > pi@picnc:~ $ ip r > > > default via 192.168.71.1 dev eth0 onlink > > > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12 > > > > That looks very like what I posted, except for "onlink"; also I'm > > connected by wireless rather than wire. But my ps -ef listing > > and nsswitch.conf file show: > > $ ps -ef | grep avahi | grep -v grep ; grep hosts /etc/nsswitch.conf > > avahi 653 1 0 21:23 ? 00:00:00 avahi-daemon: running > > [wren.local] avahi 666 653 0 21:23 ? 00:00:00 > > avahi-daemon: chroot helper hosts: files mdns4_minimal > > [NOTFOUND=return] dns > > > > > > So I now have a working network. Free of the bogus inventions of > > > dhcpd5 and avahi. That _was_ the point of all this hoopla in the > > > first place. > > > > > > Now, I have learned what works to _my_ satisfaction. > > > > Glad to hear it. I still don't see that you've shown why you had to > > purge avahi to get your results above. > > > > > Have you? Or did you quit reading the instant I went off the edge of > > > your menu? > > > I ask because I've since found that if I give avahi a chance to pollute > things, removeing it does no good until you've rebooted the machine and > I have already found that out for dhcpcd5. Either one can pollute, but > to get the full effect of removing it, you must reboot the machine. > However I am reticent to do that as I then have to go to the machine and > hand start ssh as it won't start on reboot even if told to. > > Why is that? I have had no such trouble with a realtime stretch. As I said before: Dunno. What does journalctl tell you? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | andreimpopescu@gmail.com |
|---|---|
| Date | 2019-07-07 09:00 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yh9jr-6Aq-1@gated-at.bofh.it> |
| In reply to | #210859 |
[Multipart message — attachments visible in raw view] — view raw
On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote: > > If you read the full thread, you will find where I found and fixed that > problem, by killing dhcpd5 with htop, and restarting networking, and > the problem was fixed, everything then worked correctly, Did you ever find out why dhcpcd5 was even starting? As far as I know DHCP clients start only when called by network managing software (ifupdown, network-manager, etc.), or some custom networking scripts on your system. In this case it might show up again on the next reboot. BTW, it's still not clear to me whether this is about a clean buster install or some image based on buster. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-07-07 13:20 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhdn5-Kx-25@gated-at.bofh.it> |
| In reply to | #210882 |
On Sunday 07 July 2019 02:58:46 andreimpopescu@gmail.com wrote:
> On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote:
> > If you read the full thread, you will find where I found and fixed
> > that problem, by killing dhcpd5 with htop, and restarting
> > networking, and the problem was fixed, everything then worked
> > correctly,
>
> Did you ever find out why dhcpcd5 was even starting?
>
> As far as I know DHCP clients start only when called by network
> managing software (ifupdown, network-manager, etc.), or some custom
> networking scripts on your system. In this case it might show up again
> on the next reboot.
>
> BTW, it's still not clear to me whether this is about a clean buster
> install or some image based on buster.
>
Its the raspian image based on buster-rc2 AIUI.
And to get rid of the route poisoning that kills out of local networking
by making it use a 169.254.0.0/16 address for anything NOT in ones hosts
file, I have purged avahi-daemon and dhcpdc5 and whatever dependencies
they take out with them. And it takes a powerdown reboot to flush all
the poisoning and make it work for out-of-the-local-net addresses.
I have finally achieved an overnight uptime with a working network.
pi@picnc:/var/log $ ip r
default via 192.168.71.1 dev eth0 onlink
192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
pi@picnc:/etc/apt $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:fed3:472d/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
and I can
pi@picnc:/etc/apt $ ping -c1 yahoo.com
PING yahoo.com (98.137.246.7) 56(84) bytes of data.
64 bytes from media-router-fp1.prod1.media.vip.gq1.yahoo.com
(98.137.246.7): icmp_seq=1 ttl=50 time=87.2 ms
--- yahoo.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 87.205/87.205/87.205/0.000 ms
Reinstalling avahi-daemon or dhcpcd5 will poison the routing, making the
default route a 169.254.0.0/16 address that only gets past the router at
the dns phase, but the actual ping comes from the 169.254.0.0/16 address
block, and I am not sure it even gets to the cat6 plugged into the pi,
but for sure is blocked by the managed switch or the router connected to
the ARRIS cable modem upstream of the switch.
So it appears I finally have a working network.
But so far, no one has addressed the next problem. I do not have seating
in any shape in front of the pi's own monitor and keyboard, and my
standing time w/o excruciating back pain from two crushed disks in my
back is maybe 15 minutes. I would take a tall bar stool which there is
no room for to make the position usable for an hour.
Therefore its imperative that ssh start on a reboot, which it does not do
now, making me get out of this office chair, make my way to the other
end of the house and out the back door, then into the garage where this
pi is, stepping up on a $400 pile of mahogany for a furniture project
and back off just to get to its workstation and restart ssh.
Then just now I find that synaptic won't run on wayland. So whats the
substitute for synaptic? Something that will give me something graphical
in front of apt so that I can see what sources are available.
the next step after making ssh work, is building and installing an
rt-preempt version of this 4.19.50 kernel since its somewhat aware of
the newer video drivers that 4.14.91-rt-v7 likely knows nothing about .
I have tried RealtimePi 4 times now, but its newest kernel is
4.14.91-rt-v7, which when booted doesn't find the wireless keyboard or
mouse, nicely rendering it a quadraplegic. Meaning I've no clue if it
will work even if it did find my keyboard and mouse. That particular
keyboard nor mouse come in wired versions, and the square sided keys are
a basic requirement around machinery that throws metal chips as it
works, the slanted sides of all other keyboards keytop allow the metal
chips to follow the key down, then wedge the key in the down position,
an extremely dangerous situation thats cost me the loss of several hours
work several times and several hundred $ in broken cutting tools.
> Kind regards,
> Andrei
Thank you Andrei
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Jonas Smedegaard <jonas@jones.dk> |
|---|---|
| Date | 2019-07-07 14:50 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yheMa-1sQ-3@gated-at.bofh.it> |
| In reply to | #210897 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Gene Heskett (2019-07-07 13:17:33) > On Sunday 07 July 2019 02:58:46 andreimpopescu@gmail.com wrote: > > > On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote: > > > If you read the full thread, you will find where I found and fixed > > > that problem, by killing dhcpd5 with htop, and restarting > > > networking, and the problem was fixed, everything then worked > > > correctly, > > > > Did you ever find out why dhcpcd5 was even starting? > > > > As far as I know DHCP clients start only when called by network > > managing software (ifupdown, network-manager, etc.), or some custom > > networking scripts on your system. In this case it might show up again > > on the next reboot. > > > > BTW, it's still not clear to me whether this is about a clean buster > > install or some image based on buster. > > > Its the raspian image based on buster-rc2 AIUI. So *not* Debian. Have a nice day. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2019-07-07 18:30 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhid3-3Bc-1@gated-at.bofh.it> |
| In reply to | #210897 |
[Multipart message — attachments visible in raw view] — view raw
On Du, 07 iul 19, 07:17:33, Gene Heskett wrote: > On Sunday 07 July 2019 02:58:46 andreimpopescu@gmail.com wrote: > > > > BTW, it's still not clear to me whether this is about a clean buster > > install or some image based on buster. > > > Its the raspian image based on buster-rc2 AIUI. As suspected... > Reinstalling avahi-daemon Unlikely... > or dhcpcd5 will poison the routing, making the default route a > 169.254.0.0/16 address This I believe. It's most likely due to some Raspbian-specific startup script that tries to set up networking with DHCP. > So it appears I finally have a working network. > But so far, no one has addressed the next problem. I do not have seating > in any shape in front of the pi's own monitor and keyboard, and my > standing time w/o excruciating back pain from two crushed disks in my > back is maybe 15 minutes. I would take a tall bar stool which there is > no room for to make the position usable for an hour. > > Therefore its imperative that ssh start on a reboot, which it does not > do now, It's almost impossible to guess (remotely) what *other* changes have been done to the Raspbian image. You might want to try asking in the Raspbian support channels instead. Technically I could download the image and inspect it locally, assuming I can even find it (including at least a download link would have been nice). At the moment I do have other stuff to do which is (hopefully) helping more people actually running Debian. You might try that as well (running pure Debian that is). According to this page https://wiki.debian.org/RaspberryPi3 Debian runs unchanged on the Raspberry Pi 3. The images linked from there are not official, but they are build by a Debian Developer. The likelihood of custom scripts is, I believe, close to zero (though apparently this image is also set up for DHCP by default, have fun :) ). For a system that works as you expect it I suggest you do your own installation, either with Debian Installer or even with debootstrap. Thoroughly document in detail every step (e.g. using --variant=minbase for debootstrap can make a *huge* difference to the final image), or even better, script it. That way whenever you run into issues you can just post the script used and potential helpers will know what you did or did not. Good luck with fixing your ssh. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-07-07 23:00 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhmqm-60N-1@gated-at.bofh.it> |
| In reply to | #210930 |
On Sunday 07 July 2019 12:28:21 Andrei POPESCU wrote: > On Du, 07 iul 19, 07:17:33, Gene Heskett wrote: > > On Sunday 07 July 2019 02:58:46 andreimpopescu@gmail.com wrote: > > > BTW, it's still not clear to me whether this is about a clean > > > buster install or some image based on buster. > > > > Its the raspian image based on buster-rc2 AIUI. > > As suspected... > > > Reinstalling avahi-daemon > > Unlikely... > > > or dhcpcd5 will poison the routing, making the default route a > > 169.254.0.0/16 address > > This I believe. It's most likely due to some Raspbian-specific startup > script that tries to set up networking with DHCP. > > > So it appears I finally have a working network. > > But so far, no one has addressed the next problem. I do not have > > seating in any shape in front of the pi's own monitor and keyboard, > > and my standing time w/o excruciating back pain from two crushed > > disks in my back is maybe 15 minutes. I would take a tall bar stool > > which there is no room for to make the position usable for an hour. > > > > Therefore its imperative that ssh start on a reboot, which it does > > not do now, > > It's almost impossible to guess (remotely) what *other* changes have > been done to the Raspbian image. You might want to try asking in the > Raspbian support channels instead. > > Technically I could download the image and inspect it locally, > assuming I can even find it (including at least a download link would > have been nice). > > At the moment I do have other stuff to do which is (hopefully) helping > more people actually running Debian. > > You might try that as well (running pure Debian that is). According to > this page https://wiki.debian.org/RaspberryPi3 Debian runs unchanged > on the Raspberry Pi 3. > > The images linked from there are not official, but they are build by a > Debian Developer. The likelihood of custom scripts is, I believe, > close to zero (though apparently this image is also set up for DHCP by > default, have fun :) ). > > For a system that works as you expect it I suggest you do your own > installation, either with Debian Installer or even with debootstrap. > > Thoroughly document in detail every step (e.g. using --variant=minbase > for debootstrap can make a *huge* difference to the final image), or > even better, script it. > > That way whenever you run into issues you can just post the script > used and potential helpers will know what you did or did not. > > Good luck with fixing your ssh. > It has been fixed, and the last reboot finally mounted a 10Gig swap too, so thats another problem addressed as the default 100Meg swapfile on the u-sd card is not big enough to assemble all of the rs-274-D interpreter in linuxcnc. Add the 10G swap and it marches straight thru it on the build. Now we just need to work around the missing dependencies that buster for armv7 has thrown at us. And fixing that is well above my pay grade. Darnit. > Kind regards, > Andrei Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2019-07-07 22:00 +0200 |
| Subject | Re: Assorted arm-buster problems - network configuration |
| Message-ID | <yhlui-5rM-13@gated-at.bofh.it> |
| In reply to | #210882 |
Hi. On Sun, Jul 07, 2019 at 09:58:46AM +0300, andreimpopescu@gmail.com wrote: > On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote: > > > > If you read the full thread, you will find where I found and fixed that > > problem, by killing dhcpd5 with htop, and restarting networking, and > > the problem was fixed, everything then worked correctly, > > Did you ever find out why dhcpcd5 was even starting? I solved this mystery. Took an upgrade to buster, and somewhat botched network configuration in the result. But it was worth it. First, unlike ISC dhclient, which is the 'goto' DHCP client in Debian, Raspbian promoted dhcpcd5 into this role. Second, unlike dhclient, dhcpcd5 can work as a systemwide daemon, and if run like that it tries to get a lease on every network interface if it's UP and it's not a "lo". This can be changed via dhcpcd.conf, but it's not done by default. Third, /etc/init.d/dhcpcd contains a useful safeguard - a single interface defined as "inet dhcp" in e/n/i prevents systemwide daemon from running. In full accordance with Debian policy, dhcpcd5 tries to run such daemon by default. So far - so good, but buster's dhcpcd added fourth - a systemd unit that runs /usr/sbin/dhcpcd regardless of a safeguard. A result, assuming systemd as PID 1 - stretch's dhcpcd respects e/n/i, buster's - does not. As an added "bonus" - buster's dhcpcd does not respect "metric" setting in these circumstances. A fun parts here are: 1) Problem is easily solved with the usual "systemctl disable/systemctl stop" combo. 2) Debian does not exibit this behaviour by default, user has to install dhcpcd5 package (which I do, because $REASONS). 3) Raspbian seem to be broken by default in this regard, but … you're not supposed to edit e/n/i if using Raspbian as far as I understand. Because you can always get DHCP lease and it's confusing to the user and all that :) As an upside, they finally fixed dhcpcd's ntp hook - it was broken in stretch. Reco
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web