Opened 8 years ago

Closed 7 years ago

#7228 closed defect (fixed)

PING (echo request) from IXP425 router (mi424wr) via WAN port doesn't work!

Reported by: tomaz.kavcic@… Owned by: developers
Priority: high Milestone: Backfire 10.03.1
Component: base system Version: Backfire 10.03
Keywords: ping ixp4xx echo reply Cc:


I just tested latest 10.03 (backfire) distro on our Verizon MI424WR routers. All seem to work OK, but I noticed a strange behaviour. When I try to ping some IP (or DNS hosts) via WAN port I don't get echo reply. I can ping from that router all hosts which are on LAN or on WIFI interface, but PING via WAN port from router doesn't work. Even more strange is that everything else works. I can traceroute via WAN port completely normally, I can use ssh, telnet from router to outside hosts, etc. I also can ping from router's LAN hosts or router's WIFI hosts to outside hosts via that router, but not directly from router.
It seems like a bug or driver problem as we have lots of those routers with older firmwares which work completely great. I also compiled latest backfire SVN today and flashed it to that router and it works perfectly OK! So, only that backfire 10.03 ixp4xx distribution doesn't work. Of course, I have all iptables disabled, all filters off, etc... Maybe someone has a clue what could be wrong?

Attachments (0)

Change History (6)

comment:1 Changed 8 years ago by anonymous

Just a quick update. I tried to play a little more with that issue and it looks like it's actually impossible to PING any host (wan,lan,wifi) directly from router! I can only ping from router's hosts (lan,wifi), but not directly from router!

Second thing, I also installed 10.03 RC3 and the same thing happens. When I recompile from SVN (backfire) everything works without any problems...

comment:2 Changed 8 years ago by anonymous

what about ping -s 64 host?

comment:3 Changed 8 years ago by tomaz.kavcic@…

I just tried what "anonymous" user above suggested and it works perfectly! I went through manual (man ping) and find some explanation:

-s packetsize
The number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.

I am not a networking engineer really so I can't explain to myself why that packetsize (64) in that case really matters as I never had this problem before, so I would kindly like to ask you (anonymous user) if it's possible to explain me this a little. Is this behaviour completely normal? What should I change on my router configuration (probably inside iptables, or somewhere else?) to make ordinary "ping host" return results? Otherwise, is this a "bug" or a "feature"?

Thanks again in advance for your answer!

comment:4 Changed 8 years ago by anonymous

i was observing the same behaviour on a wrv54g with backfire, it is almost the same board (gtwx5715). however the latest release is fine as you reported. i did not look at the the icmp packet itself, i can see with wireshark that the ping is indeed sent out and the pong is also sent back, so the pong might be dropped by the wan interface or hang somewhere else in the network stack, i dont know. Maybe that needs further investigation.

how about packet loss, when routing from the kendin switch with bridge to the wan interface? i had app. 10-20% and download speeds were really low.

fortunately, when using the latest release with kernel, binutils 2.20.1 and uClibc 0.9.31, packet loss has gone.

comment:5 Changed 8 years ago by ranauei@…

I experienced similar problem, if not the same, ping was broken on 10.03 stable on IXP42x NSLU2.
I just updated busybox from 1.15.x (the one in stable) with 1.16.x (the one in snapshot packages) and now ping works fine.

To update busybox I just replaced /bin/busybox with the new binary manually extracted from the package, copied in place with scp (and then i updated version information on /usr/lib/opkg/status)
I update in this way because I don't wanted to risk to broke something using opkg install and because busybox was already installed with all links in place so I just replaced the main binary file)

comment:6 Changed 7 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

fixed according to user report

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.