==NULL/npch ==NULL/npch ==NULL/npch ==NULL

[kvic]

ASUS:

From time to time users of your ARM routers on this forum report syslog spammed with messages similar to the following:

Jul 24 12:57:59 kernel: [truncated] L/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch

I don't know if any customer had reported to you through other media or you got the chance to look into this. The issue is coming from:

src-t-6.x.4708/linux-2.6.36/drivers/net/ppp_generic.c

   2959 #if defined(CTF_PPTP) || defined(CTF_L2TP)
   2960 int
   2961 ppp_get_conn_pkt_info(void *pppif, struct ctf_ppp *ctfppp){
   2962         struct pppox_sock *po = NULL;
   2963         struct sock *sk = NULL;
   2964         struct ppp *ppp = NULL;
   2965         struct channel *pch = NULL;
   2966         struct ppp_net *pn;
   2967         const char *vars;
   2968
   2969         ppp = (struct ppp *)netdev_priv((const struct net_device *)pppif);
   2970         if(ppp) pch = ppp->ctfpch;
   2971
   2972         if (pch == NULL){
   2973                 printk("pch ==NULL/n");
   2974                 return (BCME_ERROR);
   2975         }

First at line 2973, there is a typo. Shall be "\n" instead of "/n". Second, if this error occurs so frequent and deemed not causing functionality loss, could the printk statement be removed or changed to only available in your debug build?

If you find another way to clear the spam, your users will appreciate too.

Cheers

 

[RMerlin]

This isn't the only source of that error, as I've also experienced it without using PPP. In my case, it seemed tied to either the Trend Micro engine or IPv6. And if you notice, this code uses printk(), while what we experience is from syslog.

 

[Puppa]

This isn't the only source of that error, as I've also experienced it without using PPP. In my case, it seemed tied to either the Trend Micro engine or IPv6. And if you notice, this code uses printk(), while what we experience is from syslog.

I saw this with IPv6 on and all Trend Micro features turned off on a non-PPP connection, so IPv6 seems a likely suspect.

 

[kvic]

I saw this with IPv6 on and all Trend Micro features turned off on a non-PPP connection, so IPv6 seems a likely suspect.

Do you happen to run OpenVPN client or server?

 

[Puppa]

Do you happen to run OpenVPN client or server?

Neither

 

[Goobi]

I am seeing these errors when using openvpn. I occasionally see it when using the openvpn server, but now that I am using the openvpn client on the router I see this all the time. It is flooding my log file. If I turn off the openvpn clients the errors stop. When I restart the clients the errors start right back up again. The errors do no appear to affect functionality. Is this a openvpn bug? Not much out there on these errors. I am running the latest Merlin firmware on the AC68U.

 

[Goobi]

Any input from Asus on this issue? Log is overrun with these messages making it very difficult to view relevant messages.

 

[oric1]

I noticed this is related to VPN.

I've Astrill Applet installed on Merlin firmware and whenever my Apple TV is connected to the Internet via the Astrill VPN, I'll get a bunch of these messages no-stop. The moment I switched off the Apple TV, the messages also stopped.

 

[Goobi]

I did notice that these errors started when using the openvpn client on the router so it does appears that VPN seems to somehow trigger this. Turn off VPN and messages go away so this is easily reproduced at least on my end.

 

[Mike65]

I did notice that these errors started when using the openvpn client on the router so it does appears that VPN seems to somehow trigger this. Turn off VPN and messages go away so this is easily reproduced at least on my end.

I just found out that deactivating NAT Acceleration removed this messages completely and raised the vpn throughput significant. (At least for me)

Kind regards,

Mike

 

[Veldkornet]

I just found out that deactivating NAT Acceleration removed this messages completely and raised the vpn throughput significant. (At least for me)

Kind regards,

Mike

Was this the final solution? Or did anyone find out any more information on why this occurs? I still get this on the latest 380.58 every so often.


Sent from my iPhone using Tapatalk

 

[kvic]

Disabling NAT Acceleration is not really a solution. It's like "chopping toes to avoid sands."

The solution is already outlined in post #1. Did I sound too nice or not giving enough emphasis in my original post? Simply remove line 2973, and recompile the firmware. The retarded error message will be gone in syslog and it has been working well for me for the past half year.

Broadcom has realized their mistake and made the correction in newer codes. My impression of ASUS is that they won't have balls to make any change (even as simple as this one) in the kernel. I don't know..perhaps their contract with broadcom prohibits such changes in kernel or loses support from broadcom.

Third party firmware such as Merlin build is beyond my comprehension not to make such a simple fix for their users.

At the moment, compiling your own firmware or having a friend doing it for you is one way out.

 

[RMerlin]

The solution is already outlined in post #1. Did I sound too nice or not giving enough emphasis in my original post? Simply remove line 2973, and recompile the firmware. The retarded error message will be gone in syslog and it has been working well for me for the past half year.

See my reply.

 

[kvic]

See my reply.

Your comments in post #2 didn't sound right to me..

Removing line 2973 does more good than hurt (if any). That's one reason puzzling me that you haven't actioned for so long even though quite a few users reported seeing in their syslog.