2704N fixed ip limitations

[#1]

I am trying to determine the limits of what the 2704N can do with devices having hardwired fixed ip - there have been references in the context of port forwarding but could not find a definitive statement of the 2704N's limitations.
For legacy reasons I have a 2704N set up on 192.168.0.1 with a mask of 255.255.255.0 and a DHCP range 192.168.0.2-128. There a number of wifi devices with hardwired ip in the range 192.168.0.240-250, ie above the DHCP range - these do not have the resources to handle DHCP, so using the 2704N facility to allocate a fixed ip to a mac via DHCP is not an option.
Other routers I use route hardwired ip devices as long as they are in the mask ip range, regardless of the DHCP range or whether they go through DHCP, so they can be accessed by any service on the LAN that knows their ip.
The 2704N does not seem to be routing these ip even though they are in the mask range - they are not visible or contactable from the LAN nor can they contact devices on the LAN.
Is it a definite (and serious) limitation of the 2704N that it will not route any ip that it has not assigned by DHCP, regardless of whether it is in its mask range? And is there any known way around it with config or firmware?

[#2]

Mine routes fine out of the DHCP range, in-fact my DHCP range is 192.168.0.65-65 router ip 192.168.0.254 all my static ip's 20 or so are below 65.
Edit: Just to note, I have ipv6 disabled as well as radvd on the same page, I don't feel the need for it at this time as some of my devices don't properly support it.

[#3]

Quote

The 2704N does not seem to be routing these ip even though they are in the mask range - they are not visible or contactable from the LAN nor can they contact devices on the LAN.

There's no routing involved with devices in the same subnet. When communicating in the same subnet, the device will send directly using the mac address. Mac addresses are obtained by each device using the arp broadcast and held in a cache on each device. So the only part of the router involved in this communication is the switch. Well that's not quite true when wifi is involved, there's a 'bridge' between the WLAN and hardwired LAN in the router but this should be transparent to any traffic.
@11110_110, are all your static IP's hardwired ?
@Safran01, If 11110_110 replies that they are , is there any chance of you trying one of your devices hardwired ?

[#4]

Yes all my stuff is hardwired and static, meaning the wifi is/was disabled because I use separate AP's, however I've just enabled the 2704n wifi and am making this post via it, again, static ip.
Edit: Just a thought, but it didn't make any odds, I changed my DNS from my own local cache's to route via the router, still works ok though.

[#5]

@11110_110, Thanks very much for trying that, but accessing the internet from a wifi static IP doesn't really test Safran01's situation. Accessing the internet will direct all traffic at the default gateway i.e the router. Any chance you could try pinging another local device from the wifi static IP and vice versa ? If I had a 2704N I'd try this myself but I'm afraid I don't

[#6]

I think this info is a bit overkill, But here goes.
[tt]
BusyBox v1.17.2 (2014-11-18 11:38:02 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# nslookup bbc.co.uk
Server:    0.0.0.0
Address 1: 0.0.0.0
Name:      bbc.co.uk
Address 1: 212.58.244.20
Address 2: 212.58.246.104
Address 3: 212.58.244.18
Address 4: 212.58.246.103
# nslookup google.co.uk
Server:    0.0.0.0
Address 1: 0.0.0.0
Name:      google.co.uk
Address 1: 2a00:1450:4009:80c::2003
Address 2: 216.58.210.3
# ping google.co.uk
PING google.co.uk (216.58.210.3): 56 data bytes
64 bytes from 216.58.210.3: seq=0 ttl=56 time=8.928 ms
64 bytes from 216.58.210.3: seq=1 ttl=56 time=8.644 ms
64 bytes from 216.58.210.3: seq=2 ttl=56 time=8.411 ms
64 bytes from 216.58.210.3: seq=3 ttl=56 time=8.365 ms
--- google.co.uk ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 8.365/8.587/8.928 ms
# route -n
Kernel IP routing table
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
195.166.128.186 0.0.0.0        255.255.255.255 UH    0      0        0 ppp1.1
10.0.0.0        0.0.0.0        255.255.255.254 U    0      0        0 eth3.2
192.168.0.0    0.0.0.0        255.255.255.0  U    0      0        0 br0
0.0.0.0        0.0.0.0        0.0.0.0        U    0      0        0 ppp1.1
#
ip route list
195.166.128.186 dev ppp1.1  proto kernel  scope link  src 87.112.XXX.XX
10.0.0.0/31 dev eth3.2  proto kernel  scope link  src 10.0.0.1
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.254
default dev ppp1.1  scope link
From me across my lan using the 2704n wifi
ping 192.168.0.17
PING 192.168.0.17 (192.168.0.17): 56 data bytes
64 bytes from 192.168.0.17: icmp_seq=0 ttl=128 time=7.303 ms
64 bytes from 192.168.0.17: icmp_seq=1 ttl=128 time=5.165 ms
64 bytes from 192.168.0.17: icmp_seq=2 ttl=128 time=2.058 ms
64 bytes from 192.168.0.17: icmp_seq=3 ttl=128 time=5.246 ms
64 bytes from 192.168.0.17: icmp_seq=4 ttl=128 time=4.554 ms
^C
--- 192.168.0.17 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.058/4.865/7.303/1.683 ms
From the router back to me…
BusyBox v1.17.2 (2014-11-18 11:38:02 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# ping 192.168.0.18
PING 192.168.0.18 (192.168.0.18): 56 data bytes
64 bytes from 192.168.0.18: seq=0 ttl=64 time=2.252 ms
64 bytes from 192.168.0.18: seq=1 ttl=64 time=145.167 ms
64 bytes from 192.168.0.18: seq=2 ttl=64 time=66.210 ms
64 bytes from 192.168.0.18: seq=3 ttl=64 time=295.225 ms
--- 192.168.0.18 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 2.252/127.213/295.225 ms
#
I hope thats all the info you may need, I’ve included a few bits ’n’ bobs from the router as well just incase.[/tt]

[#7]

Thanks for the suggestions
Tested 2704N with HP6840 printer with hardwired ip 192.168.0.253 - only device immediately available with both wifi and hardwired port
- hardwired: detected by Netscan running on 192.168.0.4, can connect & print from other devices
- wifi: not detected, cannot connect or print
Switched back to an old Netgear DG834, has identical router ip/mask/DHCP range/SSID/key -  all wifi devices reconnected without any reconfiguration
- 6840 hardwired & wifi both picked up by Netscan, can connect & print from other devices on the LAN
Have had IPv6 disabled all along as few devices on LAN support it

[#8]

Sorry I can't help test any printers etc as mine is usb only, I use a raspberry pi as a print server which allows printing from all my devices, even my old android stuff as well as AirPrint from iPads linux, and OS X seamlessly.

[#9]

@11110_110, Thanks for the help..
@Safran01,

Quote

Tested 2704N with HP6840 printer with hardwired ip 192.168.0.253 - only device immediately available with both wifi and hardwired port - hardwired: detected by Netscan running on 192.168.0.4, can connect & print from other devices - wifi: not detected, cannot connect or print

I'm conscious that constantly changing routers is not a good idea as it may cause the DLM to intervene and affect speeds. However it's interesting to try and get to the bottom of this. Given that we're only interested in local traffic for the moment it ought to be possible to do some tests on the 2704 without it actually being connected to the DSL line. If you could repeat the tests above with just the the printer and pc connected to the 2704. Assuming its a windows PC , use arp -a to see if the printer appears in the arp cache. In the situation where it fails to find it, you could try adding it to the cache manually using arp -s and see if it then finds it. You will of course need to get the MAC address for the printers Wifi interface first, probably when it's connected to the DG834 and working!. I assume the printer is capable of DHCP it's probably worth repeating the tests using a DHCP allocated address as well, that might shed further light on the problem. 

[#10]

Interesting, arp (Mint 17, Linux) did not pick up the HP6840 either hardwired or on wifi, even though it was connecting hardwired. Not in the 2704 arp table either.
Maybe the HP6840 was not a good choice for testing - only device to hand with both wifi and hardwired though
In view of other 2704N limitations have decided to change to another router anyway
- wifi coverage not quite good enough for the site
- no NAT loopback
- cannot dump/modify config (see separate post) to get SSH/modify iptables
Will come back and look at it again when I have time and devices to hand
@MisterW, @11110_110, thanks very much for the help and suggestions

[#11]

Hi there. Late responding here having been away.
A couple of questions that may have some relevance
Are you using your 2704n in ADSL mode or Fibre mode, I'm guessing ADSL from your use of a DG834?
Are you using the WiFi in 300mbps mode?

[#12]

Just to add to this, in ADSL mode I found that I could not assign a Static IP address unless it was within the defined DHCP range. So increase the DHCP range to covered the static addresses you want to use. Once they are assigned, there should be no conflicts with other DHCP assignments.