HP LaserJet 400 MFP M425dn: bug in MTU path discovery, printer reboots via web interface

[DKazarov]

 Firmware Datecode: 20121205

1. We can not access this MFU over VPN link. Otherer devices are accessed successfully.

As far as I understand there is an error in MTU Path Discovery.

tcpdump logs are attached.

Is there a way to change MTU of this device?

2. This MFU a  reboots when I open page "Settings" of "Networking" submenu (/hp/device/set_config_networkSettings.html?tab=Networking&menu=NetSettings) if option "System" -> "System Setup" -> "Language" is "Russian". But this looks like a very good feature since I've have not found the way to reboot this printer remotely.

Here I was tring to access web interface over VPN (IPSec), 192.168.4.135 is IP of my comp, 192.168.160.200 - is IP of MFU, 192.168.160.254 is a gateway:
 

$ tcpdump -n -r printer-1.pcap
reading from file printer-1.pcap, link-type EN10MB (Ethernet)
17:20:29.337867 IP 192.168.4.135.54147 > 192.168.160.200.80: Flags [S], seq 2356029847, win 8192, options [mss 1460,nop,nop,sackOK], length 0
17:20:29.338026 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [S.], seq 614551948, ack 2356029848, win 8760, options [mss 1460,nop,nop,sackOK], length 0
17:20:29.344909 IP 192.168.4.135.54147 > 192.168.160.200.80: Flags [.], ack 1, win 64240, length 0
17:20:29.348488 IP 192.168.4.135.54147 > 192.168.160.200.80: Flags [P.], seq 1:304, ack 1, win 64240, length 303
17:20:29.348564 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [.], ack 304, win 8457, length 0
17:20:29.378872 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [P.], seq 1:513, ack 304, win 8457, length 512
17:20:29.379063 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 513:1973, ack 304, win 8457, length 1460
17:20:29.379100 IP 192.168.160.254 > 192.168.160.200: ICMP 192.168.4.135 unreachable - need to frag (mtu 1280), length 48
17:20:29.379103 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 1973:3433, ack 304, win 8457, length 1460
17:20:29.379135 IP 192.168.160.254 > 192.168.160.200: ICMP 192.168.4.135 unreachable - need to frag (mtu 1280), length 48
17:20:29.379251 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 1:1461, ack 304, win 8457, length 1460
17:20:29.379272 IP 192.168.160.254 > 192.168.160.200: ICMP 192.168.4.135 unreachable - need to frag (mtu 1280), length 48
17:20:29.379274 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 1461:2921, ack 304, win 8457, length 1460
17:20:29.379304 IP 192.168.160.254 > 192.168.160.200: ICMP 192.168.4.135 unreachable - need to frag (mtu 1280), length 48
17:20:29.379306 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 2921:4381, ack 304, win 8457, length 1460
17:20:29.379335 IP 192.168.160.254 > 192.168.160.200: ICMP 192.168.4.135 unreachable - need to frag (mtu 1280), length 48
17:20:29.379338 IP 192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 1:1461, ack 304, win 8457, length 1460

 This is more detailed view on some packets.

$ tcpdump -nv -r printer-1.pcap
...
17:20:29.379063 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto TCP (6), length 1500)
    192.168.160.200.80 > 192.168.4.135.54147: Flags [.], cksum 0x7233 (correct), seq 513:1973, ack 304, win 8457, length 1460
17:20:29.379100 IP (tos 0x0, ttl 64, id 62678, offset 0, flags [DF], proto ICMP (1), length 68)
    192.168.160.254 > 192.168.160.200: ICMP 192.168.4.135 unreachable - need to frag (mtu 1280), length 48
    IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto TCP (6), length 1500)
    192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 513:1973, ack 304, win 8457, length 1460
17:20:29.379103 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto TCP (6), length 1500)
    192.168.160.200.80 > 192.168.4.135.54147: Flags [.], cksum 0x5edf (correct), seq 1973:3433, ack 304, win 8457, length 1460
17:20:29.379135 IP (tos 0x0, ttl 64, id 62679, offset 0, flags [DF], proto ICMP (1), length 68)
    192.168.160.254 > 192.168.160.200: ICMP 192.168.4.135 unreachable - need to frag (mtu 1280), length 48
    IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto TCP (6), length 1500)
    192.168.160.200.80 > 192.168.4.135.54147: Flags [.], seq 1973:3433, ack 304, win 8457, length 1460
17:20:29.379251 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto TCP (6), length 1500)
    192.168.160.200.80 > 192.168.4.135.54147: Flags [.], cksum 0x0c1c (correct), seq 1:1461, ack 304, win 8457,
...

 P.S. This thread has been moved from LaserJets to Multifunction and All-in-One - HP Forums Moderator

[John_Getzke]

Its hard to understand what you are trying to do or ask here.  From what I gather you cannot reach the EWS while VPN connected right?  The logs you attached only show a problem when your router tries to contact the printer (160.254 -->160.200).  However, your PC seems to be communicating with the printer just fine (4.135 --> 160.200).  I think this is more of a limitation of the tcpdump tool that you are using than the network equiptment.

MTU size has nothing to do with accessing the Embedded Web Server (EWS).  All MTU size is responsible for is the size of the packets that are sent across the network, if a packet is too large then it is broken up into pieces and sent to the destination, not rejected.

Accessing the EWS should be a simple network access requirement.  Anyone on the correct network should be able to access the EWS in one form or another.  Only the advanced features should be locked out and restricted by an admin username and password.

How about some simplier questions to gather info:

1. Can you Ping the printer while VPN connected?

2. Can you Ping other printers while VPN connected?

3. Can you print to this printer while VPN connected?

4. Can you access the EWS while locally connected to the printers network (Non-VPN)?

5. What error message do you see when trying to access the EWS?

6. Are you entering the DNS name into your browser or the IP Address?

[John_Getzke]

As for the 2nd part of your problem I have not found a good way to remotely reboot the M425's either. 

The only way I know about is through the WebJet Admin which I actually have not tried yet for this model.  I assume the feature is there and works like it does for other printer models.  Since switching the language would require the printer to reboot it may serve as a valid techinque for you (assuming you remember to change the language back from Russian to English when you are done).  I normally email someone in the area to reboot a remote printer for me.

[John_Getzke]

Hello,

This problem has captured my attention all day.  I hope we get a response so we can have some closure!

Some more digging on your TCMPDump utility has revealed how you may be under the impression that the Path MTU Discovery is causing issues.  Apparently if a devices is configured to not fragment its responses and the MTU size is too small it will actually deny the requests.  Normally these denied requests are recieved and the PC will adapt its MTU size accordingly and re-try but that process may not be working for you. A viable solution would then be to manually configure the MTU on the network adapter as you have suggested.

If you wish to pursue the MTU size solution then take a look at this:

http://kb.linksys.com/Linksys/GetArticle.aspx?docid=fbf8e8564632422eaa8ea80bf9dcba64_386.xml

Complete the steps to isolate and confirm the MTU size that the printer is configured to respond to.  Once you know the MTU size you can then look up and configure your PC accordingly to see if you can access the EWS.

[DKazarov]

---

@John Getzke wrote:

Its hard to understand what you are trying to do or ask here. 

We have some offices connected via IPSEC tunnels. IPSEC interface's MTU is 1280 bytes (not 1500 bytes as Ethernet). All other devices successfully work over this VPN link. HP m2727 works. HP m425dn does not work. As a network administrator I've traced source of problem on all possible points and found that HP m425dn has a bug in the "Path MTU Path discovery" routine.

The logs I attached shows that any packet of the TCP stream that the printer (160.200) sends to host (4.135) has "Don't fragment" flag set. According to IP standard the router HAVE TO discard the packet with DF flag set and size bigger then MTU since it can not pass a packet further without fragmentation - IPSEC MTU is 1280 bytes only while HP sends 1500 bytes. The router informs the printer about this problem with ICMP message Type: 3 (Destination unreachable) with Code: 4 (Fragmentation needed) suggesting MTU of next hop: 1280. The router does not communicate with the printer itself, it just informs the printer about network problem. According to IP standard the printer HAVE TO resend this data with the size of packet decreased according to suggested size. This is expected behavior of the Path MTU discovery routine. But the printer  sends the packet again with the same size and DF flag set. The router again discards the packet and informs printer... This cycle repeats again and again until connection is closed due to timeout. Therefore "Path MTU discovery" routine is broken at this device.

It would not be a serious problem, but the printer resends packets at rate over 28000 pps (about 40 MBytes per seconds) and its CPU is so heavily loaded that it even does not respond to touches on its touchscreen. So an innocent attempt to print document on terminal server located at another office leads to inaccessibility of the printer.

The network dump can be downloaded in PCAP format from here.

[DKazarov]

As for the 2nd part of your problem I have not found a good way to remotely reboot the M425's either.

I know "wrong way" only, but it's disabled in English version of interface. In Russian it works. To switch to Russian - choose System menu (second menu tab), then "System setup" submenu (6-th menu item), switch Language option to Русский (just bellow "Polski"). Now to reboot the printer choose 6-th tab (3-d from right) named "Сеть", and click "Параметры" link there - 5-th link in the left block, it's first in the second menu group. The m425dn reboots.

Due to "MTU Path discovery" problem I use this procedure quite often.

[DKazarov]

If you wish to pursue the MTU size solution then take a look at this:

There is no problem with any other devices. There is a problem with the printer "HP m425dn" only.

Could you write me how to change the printer's MTU, please?

Mentioned page explain only Windows and MacOS but we need information about HP.

[John_Getzke]

Hello again and thanks for all the extra details.

I do not think it is possible to change the MTU size on the printer.  Atleast I have not been able to find a way to do so.  If there is a feature or technique that allows you to then you will most likely have to contact HP directly for the steps.  I would think the steps would require SNMPv3 or Telnet access as those techiniques tend to expose more admin settings than are normally available on the regular Embedded Web Server.

After reading your recent posts I tried VPN connecting wirelessly over my IPSec VPN on a Win7 laptop and tried to reproduce the problem.  Unfortunetly I could not, all of the models I have could be accessed remotely.  

Here are my MTU settings : (netsh > interface > ipv4 > show subinterface) 

Wireless NIC = 1500

Normal NIC = 1300

VPN VNIC = 1300 

Would it be possible to configure one of your machines to connect over a 1500 MTU adapter and see if the problem is resolved?  If so that may be easier than getting HP to respond or fix the problem for you.

[John_Getzke]

I searched around a little and found a similar thread on the forums that may interest you:

/t5/Multifunction-and-All-in-One/PhotoSmart-C4380-on-WIFI-print-job-s-stuck-in-queue-in-Windows/m-p/...

The conclusion from that user also to modify the MTU on the computer as he could not find a way to modify the printer.

[DKazarov]

The conclusion from that user also to modify the MTU on the computer as he could not find a way to modify the printer.

In my case it is easier to block the inter-network access to this printer then to decrease the network speed.