I'm trying to diagnose a connectivity issue between my LaserJet M551dn (lj500) and my FreeBSD system (hal9k). The problem is that I can no longer browse the LaserJet's Web Interface (times out after 30s or so) or print. Both are directly connected on 192.168.0/24 via LAN and an intermediate Netgear 8 port switch.

What works:

  • I can ping lj500 from hal9k just fine.
  • I have no connectivity problems to any other part of the internet.
  • I can access the web interface from a Windows notebook on the same LAN.
  • I can print from the Windows notebook. So the printer looks alright.

What I've done recently (which might have messed up things):

  • Updated the LaserJet's firmware to the latest (2309046_000288).
  • Updated FreeBSD to the latest (14.0-CURRENT #0 main-n246296-77651151f3ca).

What I've tried without success:

  • Disable firewall.
  • Shuffle LAN cables to different ports on the Netgear switch.
  • Directly connect FreeBSD and printer (eliminate switch).
  • Use different browsers (Firefox, lynx, netcat).
  • Access ports 80 (HTTP) and 433 (HTTPS).

As a last resort, I looked at traffic on the wire. I found that the systems generate spurious traffic (re-transmits and ACKs). Can anyone diagnose what is happening and why? Here is the traffic as captured with Wireshark and the filter host lj500 and not arp (ARP works fine and is just noise). It looks like the packets with black background should not be there (are spurious).


enter image description here


enter image description here

  • Have you tried an older FreeBSD to narrow down which upgrade might have changed things? Does booting Linux on the same hardware have a different result?
    – user1686
    May 16 at 10:58
  • @user1686 Rolling back FreeBSD versions is not an easy task. Maybe booting from official memory stick images is an option. I'll investigate.
    – Jens
    May 16 at 14:22
  • In both cases, the TCP 3-way handshake completes, and hal9k sends the next packet (the first data-carrying packet of the TCP connection; the TLS Client Hello or the HTTP GET), and lj500 Ack's it, but hal9k acts as if it never receives that Ack. I can't think of a good reason why that would be.
    – Spiff
    May 16 at 18:04
  • @Spiff Further analysis reveals it is a TCP timestamp option issue. See my answer.
    – Jens
    May 20 at 10:25

It turns out that the LaserJet advertises support for the TCP Timestamp option in the handshake, but then does not use it. FreeBSD then drops the packets. This can be modified on the FreeBSD end by relaxing the checking for TCP timestamps with

sysctl net.inet.tcp.tolerate_missing_ts=1      # Drops packets when 0.

A better fix would be for the LaserJet to properly implement TCP timestamps. HP, if you're listening...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.