GNU bug report logs - #39448
26.1; ERC connect wierdness

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39448 in the body.
You can then email your comments to 39448 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; ERC connect wierdness
Date: Wed, 5 Feb 2020 23:37:43 -0600

[Message part 1 (text/plain, inline)]

*** E-Mail body has been placed on clipboard, please paste it here! ***



Greetings!  I'm reporting at the request of Bandali although I don't
have a great deal of information, I'm afraid.  I suspect a coorilation
to a major update of MELPA/ELPA packages I did on Sunday - I haven't
successfully connected to ERC since.  That said, problem exists also
under -Q

[Start Emacs from Git Bash prompt; same under cmd.exe and this is easier)

/d/emax64/bin/runemacs.exe -Q --eval '(setq erc-debug-irc-protocol
t)(raise-frame)'

;; the raise frame was an error but I didn't worry about it
;; making my report.  Hope that doesn't cause confusion.

[Once Emacs is up, I pulled and evaled two bits of code from my startup
sequence one at a time in the order shown:]

;; from emacswiki
(defmacro asf-erc-bouncer-connect (command server port nick ssl pass)
   "Create interactive command `COMMAND'.
Connect to IRC `SERVER` on `PORT`as `NICK` with `SSL` or `PASS`.
The command uses interactive mode if passed an argument."
   (fset command
         `(lambda (arg)
           (interactive "p")
  (if (not (= 1 arg))
      (call-interactively 'erc)
    (let ((erc-connect-function ',(if ssl
      'erc-open-ssl-stream
    'open-network-stream)))
        (erc :server ,server :port ,port :nick ,nick :password ,pass))))))

(asf-erc-bouncer-connect erc-fn
                         "irc.freenode.net"
                         6667
                         "mplsCorwin" nil
                         "q[corwin]:exactlythatsmart")

[Then, finally:]

M-x erc-fn RET

Which results in my making various notes shown here in fairly haphazard
form.  Sorry.

1. ERC appears to start, ERC: CLOSED shown in the mode-line, "Connecting
[...]" in the minibuffer.

2. It appears to just sit there

3. I join freenode.net from a web-client while playing with this last
night and saw myself join and then connection timeout three times in
fairly rapid succession but this didn't happen while testing under -Q
AFICT.  There is *no* indication that any server activity is occuring,
e.g. no updates to the irc.freenode.net:6667 and no process buffers I
can find.

4. Today preping this report I got a slightly different output at the
end:

  *** ERC terminated: failed with code 10060

5. After confirming this problem didn't go away over night (also under
-Q but before preping this bug report, which I did under a fresh
session), I connected to freenode and chatted with bandali using rcirc
which had no connection difficulties I noticed.

6. I think I'm starting to get somewhere with lisp but my foundational
Emacs knowledge is weak.  Moreover, I'm running under Windows 10 and
don't (yet) know how to compile from sources locally.  That said let me
know any other information, tests, etc which would be helpful and I'll
do my best (not withstanding $life & whatnot) to respond promply.

7. My next step, again at Bandali's advice, is to play with tls.
Obviously, if that changes things I'll report back in.


In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-13 built on TPW550S
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
Recent messages:
Connecting to irc.freenode.net:6667...
Logging in as `mplsCorwin'...
<M-insert> is undefined
Connecting to irc.freenode.net:6667...
Logging in as `mplsCorwin'...
Connecting to irc.freenode.net:6667...
Logging in as `mplsCorwin'...
<left-fringe> <drag-mouse-1> is undefined
Mark set
Making completion list...

Configured using:
 'configure --without-compress-install --without-dbus --with-modules
 'CFLAGS= -O2 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND NOTIFY ACL GNUTLS LIBXML2
ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: cp1252

Major mode: ERC

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils misearch multi-isearch erc-list erc-menu
easymenu erc-join erc-ring erc-networks erc-pcomplete pcomplete comint
ansi-color ring erc-track erc-match erc-button wid-edit erc-fill
erc-stamp erc-netsplit erc-goodies erc erc-backend erc-compat
format-spec auth-source cl-seq eieio byte-opt bytecomp byte-compile
cconv eieio-core cl-macs gv eieio-loaddefs cl-loaddefs cl-lib
password-cache thingatpt pp elec-pair time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify w32 lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 131403 9951)
 (symbols 56 23563 1)
 (miscs 48 64 161)
 (strings 32 39139 913)
 (string-bytes 1 1036867)
 (vectors 16 18196)
 (vector-slots 8 526999 16844)
 (floats 8 62 195)
 (intervals 56 665 14)
 (buffers 992 16))

[Message part 2 (text/html, inline)]

Message #8 received at 39448 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: 39448 <at> debbugs.gnu.org
Subject: Re: bug#39448: 26.1; ERC connect wierdness
Date: Sat, 8 Feb 2020 13:29:11 -0600

[Message part 1 (text/plain, inline)]

Hi again,

On Wed, Feb 5, 2020 at 11:39 PM Corwin Brust <corwin <at> bru.st> wrote:

> Greetings!  I'm reporting at the request of Bandali
>

Adding detail, again at the request of Bandali.

/d/emax64/bin/runemacs.exe -Q --eval '(setq erc-debug-irc-protocol
> t)(raise-frame)'
>
[...]

> 1. ERC appears to start, ERC: CLOSED shown in the mode-line, "Connecting
> [...]" in the minibuffer.
>
> 2. It appears to just sit there
>
[... ]

>   *** ERC terminated: failed with code 10060
>
[... etc ...]

I found that my ISP, Comcast, has added a service they call "Protected
Browsing" or "Safe Browsing" or "xFi Advanced Security" depending on
whether you are the web portal, the documentation for the web portal, or at
their marketing, etc.

Here's a forum thread with details for turning this off:

https://forums.xfinity.com/t5/Email-Web-Browsing/Unblock-all-websites/td-p/3292083

Looking at the web portal I could see that lots of requests to port 113
were getting blocked (many with alarming log commentary about "China" and
"Australia" and other parts foreign.  The horror).

Once I completely disabled the Comcast security feature, whatever it's
called, ERC connects without difficulty.

I think this may still be a valid bug, however, as I was able to connect to
Freenode (used for testing in all cases) from rcirc even while Comcast's
anti-productivity software was active.  I'm curious how the two different
IRC implementations handle/depend on IDENT.  I'll dig into this if I can
and report with such clues or questions as I find.

Regards,
-- 
*Corwin*
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
*corwin.brust (skype)corwin <at> bru.st <corwin <at> bru.st>*

[Message part 2 (text/html, inline)]

Message #11 received at 39448 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Corwin Brust <corwin <at> bru.st>
Cc: 39448 <at> debbugs.gnu.org
Subject: Re: bug#39448: 26.1; ERC connect wierdness
Date: Thu, 20 Feb 2020 14:34:15 +0100

Corwin Brust <corwin <at> bru.st> writes:

> Once I completely disabled the Comcast security feature, whatever it's called,
> ERC connects without difficulty.  
>
> I think this may still be a valid bug, however, as I was able to
> connect to Freenode (used for testing in all cases) from rcirc even
> while Comcast's anti-productivity software was active.  I'm curious
> how the two different IRC implementations handle/depend on IDENT.
> I'll dig into this if I can and report with such clues or questions as
> I find.

Whatever "security" software they were using could be using deep packet
inspection; i.e., blocking the connection based on the protocol contents
of the packets.  It does sound rather unlikely that anybody would bother
to do that for IRC, but who knows these days...

Did you find any further clues?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #16 received at 39448 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39448 <at> debbugs.gnu.org
Subject: Re: bug#39448: 26.1; ERC connect wierdness
Date: Thu, 20 Feb 2020 07:38:34 -0600

[Message part 1 (text/plain, inline)]

I haven't yet.  More, I upgraded to 27.0.50 from 26.3 and everything is so
snappy and nice -  I maybe won't dig too hard anymore.

Shall we close this or is it better that I do try further digging?

On Thu, Feb 20, 2020, 07:34 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Corwin Brust <corwin <at> bru.st> writes:
>
> > Once I completely disabled the Comcast security feature, whatever it's
> called,
> > ERC connects without difficulty.
> >
> > I think this may still be a valid bug, however, as I was able to
> > connect to Freenode (used for testing in all cases) from rcirc even
> > while Comcast's anti-productivity software was active.  I'm curious
> > how the two different IRC implementations handle/depend on IDENT.
> > I'll dig into this if I can and report with such clues or questions as
> > I find.
>
> Whatever "security" software they were using could be using deep packet
> inspection; i.e., blocking the connection based on the protocol contents
> of the packets.  It does sound rather unlikely that anybody would bother
> to do that for IRC, but who knows these days...
>
> Did you find any further clues?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[Message part 2 (text/html, inline)]

Message #19 received at 39448 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Corwin Brust <corwin <at> bru.st>
Cc: 39448 <at> debbugs.gnu.org
Subject: Re: bug#39448: 26.1; ERC connect wierdness
Date: Thu, 20 Feb 2020 14:56:19 +0100

Corwin Brust <corwin <at> bru.st> writes:

> I haven't yet.  More, I upgraded to 27.0.50 from 26.3 and everything is so
> snappy and nice -  I maybe won't dig too hard anymore.  
>
> Shall we close this or is it better that I do try further digging?

It sounds unlikely that we'll make more progress here, so I'll close the
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.