[BALUG-Admin] Comcast Business apparently blocking 5353 UDP Re: linuxmafia.com "retry limit exceeded"

Mon Jun 3 08:23:34 UTC 2024

Rick,

I found non-Comcast Business client I could test from and ...:
$ curl -s https://ipv4.balug.org/myip && dig -p 5353 +nomultiline
@96.86.170.229 +noall +answer sflug.com. SOA
54.149.53.111
sflug.com.    172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812
10800 3600 3600000 86400
$ sudo traceroute -f 13 -nUp 5353 96.86.170.229
traceroute to 96.86.170.229 (96.86.170.229), 30 hops max, 60 byte packets
13  96.110.41.78  22.205 ms 68.85.191.206  23.194 ms 96.110.41.74  21.052 ms
14  162.151.86.58  23.357 ms 162.151.78.186  22.058 ms 162.151.86.58  22.490 ms
15  162.151.78.186  22.559 ms 96.86.170.229  35.853 ms  40.269 ms
$

Works fine from there.  So, alas, looks like issue on/towards your
Comcast Business side/end of things.
So ... feel free to follow-up with Comcast Business at your convenience.
Might also want to have them cross-reference:
Ticket #: CR145359298
If that's useful.  They don't seem to (thus far) give me a way to
update that on-line,
but when they call, I'll let 'em know to call off the dogs on this side
of it - and looks like issue on/towards your Comcast Business side of things.

On Mon, Jun 3, 2024 at 12:20 AM Michael Paoli
<michael.paoli@berkeley.edu> wrote:
>
> Rick,
>
> I've opened case with Comcast Business,
> Ticket #: CR145359298
> I tried their on-line chat, that basically walked me through some basic
> checks, then to a not available at this time, call, or ... so, called ...
> got someone nice enough ... not incompetent but no expert, and yeah,
> "of course" quite limited in what they could do ...
> did eventually get it escalated to create the ticket ... as about the
> only option
> 1st tier had left would be to dispatch hardware tech ... which would probably be
> total waste of everyone's time, as was working perfectly fine before, no changes
> in hardware, and works fine on UDP port 53, but not 5353 (and works on TCP).
> Also, did dig a little further ... traceroute ...
> packets actually are in fact making it to the server ... but not back to client,
> so, ... not really sure where the issue would be - could be anywhere between
> "my" Comcast "router", and "yours".
> At first I was thinking most likely at/around my end based upon the
> tracroute data,
> but checking server and seeing it gets packets and responds ...
> could be getting lost/blocked anywhere between - and without ability to
> capture along hops along the way on network, dear knows where.  I'd guess
> most likely at/near one of the two ends, but who knows, some security/firewall
> (dis)services push that filtering further away from the endpoints,
> even if they're
> (generally) driven by customers (whether that's penultimate ISP
> end-user customer)
> or smaller to fair sized businesses or ISPs pushing the filtering
> further away from the
> endpoints to aid in more efficient filtering (less undesired traffic -
> when it's not desired,
> better handling of DDoS, etc.).
>
> So, e.g., on server I see:
> 07:14:36.728454 IP 96.95.217.98.55659 > 96.86.170.229.5353: 16449 op8
> [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain]
> 07:14:36.728465 IP 96.95.217.98.57523 > 96.86.170.229.5353: 16449 op8
> [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain]
> 07:14:36.729032 IP 96.86.170.229.5353 > 96.95.217.98.48836: 16449 op8
> FormErr- [0q] 0/0/0 (12)
> 07:14:36.729165 IP 96.86.170.229.5353 > 96.95.217.98.55659: 16449 op8
> FormErr- [0q] 0/0/0 (12)
> 07:14:36.729272 IP 96.86.170.229.5353 > 96.95.217.98.57523: 16449 op8
> FormErr- [0q] 0/0/0 (12)
>
> Curious if Al and/or others have same issue with 96.86.170.229.5353
> UDP (which would make
> it more probable issue is on/towards my end), or if it might be more
> specific to the
> linuxmafia.com / guido side of things - in which it might be closer to
> that (Comcast Business) end of things.
>
> On Sun, Jun 2, 2024 at 10:34 PM Michael Paoli via BALUG-Admin
> <balug-admin@lists.balug.org> wrote:
> >
> > +Al
> > Uh oh ...
> > the TLDR:
> > looks like most likely it's a Comcast Business issue on my end.
> > Anyway, I'll see if this apparently relatively new disservice that
> > they've enabled that I never requested nor wanted, is anything I've got
> > relatively simple access to disable that crud.  And if that's not the case,
> > looks like it'll be time for me to open a support ticket with 'em.
>
> > And from guido:
> >
> > # traceroute -nUp 53 -m 15 96.86.170.229
> > traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets
> >  1  96.95.217.102  1.567 ms  1.714 ms  2.000 ms
> >  2  10.61.209.67  10.034 ms  17.091 ms  17.308 ms
> >  3  96.216.9.141  15.642 ms  16.185 ms  16.438 ms
> >  4  68.85.154.113  15.559 ms  15.263 ms 68.85.154.117  17.271 ms
> >  5  96.108.99.245  21.485 ms 96.108.99.249  23.446 ms  23.462 ms
> >  6  68.86.143.89  21.394 ms  20.951 ms 68.86.143.93  20.611 ms
> >  7  162.151.87.226  21.823 ms 162.151.86.58  18.559 ms 162.151.87.226  13.063 ms
> >  8  162.151.78.186  17.808 ms  17.503 ms 162.151.79.134  19.191 ms
> >  9  68.85.191.206  19.451 ms 68.85.103.154  19.450 ms 68.85.191.206  18.210 ms
> > 10  73.189.65.18  25.648 ms  30.850 ms  30.607 ms
> > 11  96.86.170.229  38.275 ms  38.315 ms  36.705 ms
> > # traceroute -nUp 5353 -m 15 96.86.170.229
> > traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets
> >  1  96.95.217.102  1.510 ms  1.671 ms  1.922 ms
> >  2  10.61.209.67  10.667 ms 10.61.209.66  16.563 ms 10.61.209.67  17.305 ms
> >  3  96.216.9.141  16.927 ms 96.216.9.137  16.745 ms  16.855 ms
> >  4  * 68.85.154.113  17.025 ms  17.141 ms
> >  5  96.108.99.245  20.670 ms 96.108.99.249  51.907 ms 96.108.99.245  31.021 ms
> >  6  68.86.143.89  19.265 ms  18.382 ms 68.86.143.93  16.142 ms
> >  7  162.151.87.226  18.098 ms 162.151.86.58  12.378 ms  12.306 ms
> >  8  162.151.78.186  11.393 ms  11.518 ms  16.363 ms
> >  9  68.85.191.206  16.545 ms  16.623 ms  17.228 ms
> > 10  73.189.65.18  32.347 ms  24.524 ms  30.043 ms
> > 11  * * *
> > 12  * * *
> > 13  * * *
> > 14  * * *
> > 15  * * *
> > #
> > Bloody damn hell ...
> > looks like most likely it's a Comcast Business issue on my end.
> > I've got nothin' firewalling that, and should work fine.