Static IP outside of router DHCP range

[Smarty]

I am using an older and very stable Linksys WRT54G router and have DHCP
enabled for the clients. One of my router's current DHCP clients is a video
server which gets a fresh IP address occasionally when the router or video
server is re-booted.

This creates a problem, since the 8 video clients which connect to this
video server have very limited ability to recover from changes to the video
server IP address change. They are small embedded Hauppauge media boxes
which cannot easily find the revised video server address, and have no way
to easily reboot themselves from the video server.

I would like to fix the video server IP address to a static IP outside the
range of the Linksys router DHCP server, but still in the same subnet as the
router. Specifically, I would like to put the video server at 192.168.1.150
as a static IP address, and only allow the DHCP server in the Linksys to
serve addresses from 192.168.1.100 through 192.168.1.149.

This should allow my 8 video clients to ALWAYS see their video server at
192.168.1.150 regardless of whether the router had to be re-booted or the
video server had to be rebooted.

Is there any reason why I can't do this? I am specifically concerned that
the Linksys will only route to those addresses it has dynamically assigned
via DHCP, and will not route to those above that range.

Is this a legitimate concern?

Many thanks in advance for guidance.

 

[ohaya]

I am using an older and very stable Linksys WRT54G router and have DHCP
enabled for the clients. One of my router's current DHCP clients is a
video server which gets a fresh IP address occasionally when the router
or video server is re-booted.

This creates a problem, since the 8 video clients which connect to this
video server have very limited ability to recover from changes to the
video server IP address change. They are small embedded Hauppauge media
boxes which cannot easily find the revised video server address, and
have no way to easily reboot themselves from the video server.

I would like to fix the video server IP address to a static IP outside
the range of the Linksys router DHCP server, but still in the same
subnet as the router. Specifically, I would like to put the video server
at 192.168.1.150 as a static IP address, and only allow the DHCP server
in the Linksys to serve addresses from 192.168.1.100 through 192.168.1.149.

This should allow my 8 video clients to ALWAYS see their video server at
192.168.1.150 regardless of whether the router had to be re-booted or
the video server had to be rebooted.

Is there any reason why I can't do this? I am specifically concerned
that the Linksys will only route to those addresses it has dynamically
assigned via DHCP, and will not route to those above that range.

Is this a legitimate concern?

Many thanks in advance for guidance.

Hi,

With most (maybe all) NAT routers, when you configure the DHCP server,
you give it a range of IP addresses that the DHCP is allowed to serve,
e.g., 192.168.1.2 through 192.168.1.32. If you assign a static IP
address to a machine on the router's LAN side that is outside of that
range, that will be fine. The router will still route the entire
192.168.1 subnet.

Jim

 

[VanguardLH]

I would like to fix the video server IP address to a static IP outside the
range of the Linksys router DHCP server, but still in the same subnet as the
router. Specifically, I would like to put the video server at 192.168.1.150
as a static IP address, and only allow the DHCP server in the Linksys to
serve addresses from 192.168.1.100 through 192.168.1.149.

Often the router won't cover the entire range for the subnet, anyway.
One reason is that the microprocessor inside the router cannot handle
much more then 20-50 concurrent hosts connected to it (since the router
only has maybe 4 LAN connects, the rest could be wireless hosts or
through switches). I forget what Linksys told me when I asked them but
what their router could actually support for the maximum number of hosts
was far smaller than the 100 count for the range that they give me. All
my dynamically IP'ed hosts start at 192.168.1.100 (with the default of
50 IP addresses in that range but the Linksys really won't handle that
many). All my static IP'ed hosts start at 192.168.1.50 (or I could
start them at 200 but I usually pick a spacer range between the dynamic
and static addresses in case I need to expand or move the range either
way.

You won't be able to define 254 IP address to be managed by the DHCP
server inside the router. You might get only 16-24 real hosts that the
router can actually handle (talking about consumer-grade switch/router
boxes here). Typically I start the dynamic address range at 100 and up.
Then I assign static IP address below that range. That way, I can move
the dynamic range anywhere I want as a sliding window without butting
into the static range below it. The host I'm on right now has a static
IP address with no problems (I wanted to use port forwarding through the
router to remote access my desktop but the Linksys that I have now
doesn't let me specify a MAC address as did the D-Link but only lets me
specify by an IP address).

Well, I say with no problems until you need to call your ISP. They
don't know about doing anything different than the defaults (which is to
use DHCP from the router). If they (or as a suggestion here) have you
bypass the router and connect your host directly to the cable/DSL modem
then you'll have to change your TCP/IP settings (for that host under
test) to use DHCP because you're getting a dynamic IP assignment from
your ISP (unless you paid for a static IP). So just be aware that if
you need to troubleshoot a network outage or problem and if you need to
bypass the router by hooking your host directly to the modem that you'll
have to switch from static to dynamic IP addressing. You can switch
back after the test (and you hook your host through the router again).

If you go with a static IP address, you will have to manually configure
the other TCP/IP settings one of which is the DNS server. If you used
the DHCP server in the router, you would also use its DNS server;
however, it's a dummy DNS server that always passes the request up to
the next DNS server (which is your ISP's DNS server). In your TCP/IP
config, and after deciding on which static IP address that is outside
the range managed by your router's DHCP server, also make sure to
configure the gateway setting to point at your router's LAN-side IP
address (e.g., 192.168.1.1). With dynamic allocations afforded by the
DHCP server, the DNS server is also specified. For static allocations
that you define which do not use the router's DHCP server, you would
have to specify the gateway setting manually (to point at your router).

 

[Rarius]

I would like to fix the video server IP address to a static IP outside
the range of the Linksys router DHCP server, but still in the same
subnet as the router. Specifically, I would like to put the video server
at 192.168.1.150 as a static IP address, and only allow the DHCP server
in the Linksys to serve addresses from 192.168.1.100 through 192.168.1.149.

This should allow my 8 video clients to ALWAYS see their video server at
192.168.1.150 regardless of whether the router had to be re-booted or
the video server had to be rebooted.

Is there any reason why I can't do this? I am specifically concerned
that the Linksys will only route to those addresses it has dynamically
assigned via DHCP, and will not route to those above that range.

Is this a legitimate concern?

Many thanks in advance for guidance.

That will work perfectly. I do a similar thing using a Netgear router. I
have most of my PCs DHCPing from a range 192.168.1.2-192.168.1.128 and
servers on fixed IPs starting at 192.168.1.254 going downwards.

As long as you set the fixed PC's default gateway and DNS servers to
point at the router's IP address and they all have a subnet mask of
255.255.255.0, everything will work.

Mixing DHCP and fixed IP addresses in this way is very common and I have
yet to come across a router that won't support it.

Rarius

 

[Smarty]

That will work perfectly. I do a similar thing using a Netgear router. I
have most of my PCs DHCPing from a range 192.168.1.2-192.168.1.128 and
servers on fixed IPs starting at 192.168.1.254 going downwards.

As long as you set the fixed PC's default gateway and DNS servers to point
at the router's IP address and they all have a subnet mask of
255.255.255.0, everything will work.

Mixing DHCP and fixed IP addresses in this way is very common and I have
yet to come across a router that won't support it.

Rarius

Thanks to all for replies.

I would very much like to fix the assignments to MAC addresses, since each
of my 8 video clients has a label with the Mac address printed on it, and
all 8 clients remain located in exactly the same network locations
regardless of when I reboot. The fact that they are, in most cases,
connected to switches fed from the router causes additional confusion when
the video server IP changes, since the switches appear to "keep" old routing
information for a while and sometimes require rebooting also.

I have looked over my Linksys settings pretty carefully but have yet to find
a method to put hard-wired Mac addresses into this Linksys router. I may
switch to another router if I can be certain that it supports this feature
and also has the ability to route to a couple dozen devices reliably.

Thanks again for the help!

 

[ohaya]

Thanks to all for replies.

I would very much like to fix the assignments to MAC addresses, since
each of my 8 video clients has a label with the Mac address printed on
it, and all 8 clients remain located in exactly the same network
locations regardless of when I reboot. The fact that they are, in most
cases, connected to switches fed from the router causes additional
confusion when the video server IP changes, since the switches appear to
"keep" old routing information for a while and sometimes require
rebooting also.

I have looked over my Linksys settings pretty carefully but have yet to
find a method to put hard-wired Mac addresses into this Linksys router.
I may switch to another router if I can be certain that it supports this
feature and also has the ability to route to a couple dozen devices
reliably.

Thanks again for the help!

Hi,

MAC addresses, for both the server and for the clients, don't/shouldn't
change at all. A MAC address is associated with a network device, e.g.,
the network adapter, and is assigned/set by the device manufacturer when
they manufacture the device, so if you are saying that it is changing, I
don't understand that.

Rather than "feeding" us one piece of information at-a-time (first you
want static IP for the server, now you want "static MAC" for the
clients...), it might be more helpful if you provided info about what
you're actually trying to do?

Jim

 

[VanguardLH]

MAC addresses, for both the server and for the clients, don't/shouldn't
change at all. A MAC address is associated with a network device, e.g.,
the network adapter, and is assigned/set by the device manufacturer when
they manufacture the device, so if you are saying that it is changing, I
don't understand that.

Not true. In Windows, go to Device Manager and look at the properties
for your network interface device (card or chip on mobo). You can set
whatever MAC address you want the OS to report. While the NIC has its
inbuilt hardcoded MAC address (of which some cards this can be
reprogrammed), what gets reported can be changed via the OS.

The OP obviously doesn't understand the replies. The static IP address
is NOT assigned at the router for a particular host. The router isn't
involved at all. The static IP address is defined in the TCP/IP
attributes defined on the host itself that chooses to use a static IP
address instead of using DHCP. Any port forwarding in the router would
be directed to static IP addresses.

If the user wanted port forwarding to work on MAC addresses then he
should have never brought up the discussion of static IP addresses. My
Linksys router won't port forward by MAC but my old D-Link could. This
meant that I didn't have to monkey around with the TCP/IP setup on any
host and that port forwarding was strictly something handled by the
router alone.

Since the OP is trying to punch through his router to have Internet
users access his video servers, he should consider whether or not he is
violating the Terms Of Service with his ISP. The OP never mentioned
having a business class contract with them. Most ISPs ban the use of
public servers by their personal account customers.

There is also the security concern of bypassing the router's inbuilt
firewall by using port forwarding. Some routers permit a separate
subnet for a DMZ in which you are expect to deploy hosts that are
hardened against Internet attack (and not just for viruses); see
http://en.wikipedia.org/wiki/DMZ_(computing). The OP never even
mentioned monitoring his router's logs to check how often it has been
hit by someone attempting to scan his network for accessible hosts.

 

[Rarius]

Thanks to all for replies.

I would very much like to fix the assignments to MAC addresses, since
each of my 8 video clients has a label with the Mac address printed on
it, and all 8 clients remain located in exactly the same network
locations regardless of when I reboot. The fact that they are, in most
cases, connected to switches fed from the router causes additional
confusion when the video server IP changes, since the switches appear to
"keep" old routing information for a while and sometimes require
rebooting also.

I have looked over my Linksys settings pretty carefully but have yet to
find a method to put hard-wired Mac addresses into this Linksys router.
I may switch to another router if I can be certain that it supports this
feature and also has the ability to route to a couple dozen devices
reliably.

Thanks again for the help!

I cannot understand why you want to do anything with the MAC addresses.
As I understand it your 8 video clients are just that "clients". Your
router does not need to know about the clients and neither does the
server. The server PC is the only one that needs a fixed IP address so
the clients can find it.

As long as the 8 clients are all DHCPing their IP settings (address,
mask, etc) it doesn't matter WHICH address they get from the DHCP
server. Every address in the DHCP range will work fine for every client
machine.

The rule of thumb is... server = fixed IP, client = DHCP.

Rarius

 

[Smarty]

Not true. In Windows, go to Device Manager and look at the properties
for your network interface device (card or chip on mobo). You can set
whatever MAC address you want the OS to report. While the NIC has its
inbuilt hardcoded MAC address (of which some cards this can be
reprogrammed), what gets reported can be changed via the OS.

The OP obviously doesn't understand the replies. The static IP address
is NOT assigned at the router for a particular host. The router isn't
involved at all.

I never stated or intended to state that the static IP address is assigned
by the router. My entire concern, as originally stated, was / is that the
router can route to addresses outside the DHCP assignment range but within
the router's subnet. I have been assured by others that this is indeed the
case, so I can thus confidently set my video server (as I originally stated)
to 192.168.1.150 and have my router DHCP server assign within the range of
192.168.1.100 through 192.168.1.149 knowing that the traffic outside the
DHCP assingment range will also be properly routed.


The static IP address is defined in the TCP/IP

attributes defined on the host itself that chooses to use a static IP
address instead of using DHCP. Any port forwarding in the router would
be directed to static IP addresses.

If the user wanted port forwarding to work on MAC addresses then he
should have never brought up the discussion of static IP addresses. My
Linksys router won't port forward by MAC but my old D-Link could. This
meant that I didn't have to monkey around with the TCP/IP setup on any
host and that port forwarding was strictly something handled by the
router alone.

Since the OP is trying to punch through his router to have Internet
users access his video servers, he should consider whether or not he is
violating the Terms Of Service with his ISP. The OP never mentioned
having a business class contract with them. Most ISPs ban the use of
public servers by their personal account customers.

What the **** are you talking about????? I have no desire and no intention
whatsoever of doing any of what you say. Where in the world did you get this
idea / requirement from? Certainly not from anything I have stated or
thought.......

There is also the security concern of bypassing the router's inbuilt
firewall by using port forwarding. Some routers permit a separate
subnet for a DMZ in which you are expect to deploy hosts that are
hardened against Internet attack (and not just for viruses); see
http://en.wikipedia.org/wiki/DMZ_(computing). The OP never even
mentioned monitoring his router's logs to check how often it has been
hit by someone attempting to scan his network for accessible hosts.

With all due respect, VanguardLH, you are either smoking something, unable
to read / understand my original post, or are one hell of a troll...........

 

[Smarty]

I cannot understand why you want to do anything with the MAC addresses. As
I understand it your 8 video clients are just that "clients". Your router
does not need to know about the clients and neither does the server. The
server PC is the only one that needs a fixed IP address so the clients can
find it.

As long as the 8 clients are all DHCPing their IP settings (address, mask,
etc) it doesn't matter WHICH address they get from the DHCP server. Every
address in the DHCP range will work fine for every client machine.

The rule of thumb is... server = fixed IP, client = DHCP.

Rarius

The issue (apparently) is that loss of power / reboot, using a dynamic IP
for the video server, can and often does result in a new video server IP
address being assigned when the router / video server come up. The 8 clients
use BootP to upload a copy of their run-time (Linux) application which
contains the client GUI, mpeg2 decoder, etc. for playback. They fail to find
the boot server, now at a new address, and are (apparently) not able to
easily get themselves booted. I am hoping that a fixed IP address for the
video server, where the 8 clients get their boot server uploads, will now be
much less difficult and time consuming.

I raised the entire matter of MAC addresses only because each of the 8
clients has a clearly labeled and unique hard-coded MAC address which (if I
had a way to create a map / table in my video server) could route
'instantly' without the ambiguity of issuing new IP addresses for both the
video server and 8 clients every time a power glitch occurs. It is my
impression that 3 100BaseT Netgear switches I use in my network also have
some "memory" in their port multicasting logic / look up table which
"remembers" the prior IP addresses of the clients attached to them, and thus
becomes a temporary dead-end for packets being routed to the new client IP
addresses after DHCP assignments occur following reboot. Unplugging the
switches and plugging them in a minute or two later seems to solve this
problem, but there is a temporary period where the switches don't seem to be
forwarding properly during the BootP process. Thus I brought up Mac
addresses as an alternative way to perhaps avoid the DHCP quagmire.

My apologies if the original post was incomplete, vague, or both. I am going
to try the recommended approach to fix the video server IP address
statically, now that I understand that the Linksys can route to the entire
range of addresses in the subnet, beyond the range I have defined for
automatic DHCP assignment. Perhaps this will be enough of a solution.

Many thanks again.

 

[ohaya]

The issue (apparently) is that loss of power / reboot, using a dynamic
IP for the video server, can and often does result in a new video server
IP address being assigned when the router / video server come up. The 8
clients use BootP to upload a copy of their run-time (Linux) application
which contains the client GUI, mpeg2 decoder, etc. for playback. They
fail to find the boot server, now at a new address, and are (apparently)
not able to easily get themselves booted. I am hoping that a fixed IP
address for the video server, where the 8 clients get their boot server
uploads, will now be much less difficult and time consuming.

I raised the entire matter of MAC addresses only because each of the 8
clients has a clearly labeled and unique hard-coded MAC address which
(if I had a way to create a map / table in my video server) could route
'instantly' without the ambiguity of issuing new IP addresses for both
the video server and 8 clients every time a power glitch occurs. It is
my impression that 3 100BaseT Netgear switches I use in my network also
have some "memory" in their port multicasting logic / look up table
which "remembers" the prior IP addresses of the clients attached to
them, and thus becomes a temporary dead-end for packets being routed to
the new client IP addresses after DHCP assignments occur following
reboot. Unplugging the switches and plugging them in a minute or two
later seems to solve this problem, but there is a temporary period where
the switches don't seem to be forwarding properly during the BootP
process. Thus I brought up Mac addresses as an alternative way to
perhaps avoid the DHCP quagmire.

My apologies if the original post was incomplete, vague, or both. I am
going to try the recommended approach to fix the video server IP address
statically, now that I understand that the Linksys can route to the
entire range of addresses in the subnet, beyond the range I have defined
for automatic DHCP assignment. Perhaps this will be enough of a solution.

Many thanks again.

Hi,

Ahhh... Ok, that's better... thanks for the explanation of what you're
actually trying to do.

So, are you saying that "your" server (the one for which you were trying
to set a fixed IP address) is also acting as a BOOTP server?

I haven't worked with this kind of stuff for awhile (use to work with
PXE/TFTP booting, etc., but years ago!), but, according to this:

http://en.wikipedia.org/wiki/Bootstrap_Protocol

"The Dynamic Host Configuration Protocol (DHCP) is a more advanced
protocol for the same purpose and has superseded the use of BOOTP. Most
DHCP servers also offer BOOTP support."

Do you know whether or not whatever is acting as the DHCP server on your
network (I'm assuming that router) is also acting as a BOOTP server?

If it is, and if "your" server is also acting as a BOOTP server, maybe
that's part of your problem?

According to this:

http://www.eventhelix.com/RealtimeMantra/Networking/Bootp.pdf

the client sends a BOOTP_REQUEST using UDP, with a broadcast
(255.255.255.255) destination address.

[NOTE: If the clients are indeed sending the BOOTP_REQUESTs with UDP and
a broadcast address, then setting your server to a fixed IP address is
probably not what your problem is, since your server should see the
broadcast request regardless of its own IP address.]

So, if BOTH your router AND "your" server are acting as BOOTP servers,
maybe both of them are responding to the BOOTP_REQUEST?

It might be worthwhile to run a separate machine on the network, with a
sniffer (e.g., Wireshark) running, to see what is going on?

Jim

 

[ohaya]

What the **** are you talking about????? I have no desire and no
intention whatsoever of doing any of what you say. Where in the world
did you get this idea / requirement from? Certainly not from anything I
have stated or thought.......



With all due respect, VanguardLH, you are either smoking something,
unable to read / understand my original post, or are one hell of a
troll...........

Hi,

Can I suggest that we all refrain from comments like above?

I think that we ALL have been trying to help you.

As I stated in one of my earlier posts, it's helpful if you could
explain, overall, what you're trying to accomplish, which you did in the
post after the above, to which I just responded.

Without that, the only thing that we can do is to try to "guess" what
you're trying to do, and then offer opinions/info based on those guesses.

Maybe there's something proprietary or something about what you're
doing, that would prevent you from divulging info, but if so, just state
that.

Anyway, that's just my opinion, which I hope that you'll take the right
way ...

Later,
Jim

 

[VanguardLH]

VanguardLH wrote ...

I never stated or intended to state that the static IP address is assigned
by the router. My entire concern, as originally stated, was / is that the
router can route to addresses outside the DHCP assignment range but within
the router's subnet. I have been assured by others that this is indeed the
case, so I can thus confidently set my video server (as I originally stated)
to 192.168.1.150 and have my router DHCP server assign within the range of
192.168.1.100 through 192.168.1.149 knowing that the traffic outside the
DHCP assingment range will also be properly routed.

The static IP address is defined in the TCP/IP

What the **** are you talking about????? I have no desire and no intention
whatsoever of doing any of what you say. Where in the world did you get this
idea / requirement from? Certainly not from anything I have stated or
thought.......

With all due respect, VanguardLH, you are either smoking something, unable
to read / understand my original post, or are one hell of a troll...........

You mentioned your router. Your router doesn't care if you are
assigning static IP addresses to your hosts. That just means the
router's DHCP isn't involved. The LAN side of the router is a switch,
so I would've thought using static IP addresses was a given in your
scenario and due to the limitations of the client hosts. You wouldn't
even need a router for your video server and video clients if they were
all in a private and disconnected network. You would just be using a
switch. Because you mentioned the router, I figured your clients were
on the WAN side of your router trying to punch into the subnet under the
router. Because you brought up MAC addresses (which is not involved in
your static IP assignment), I figured you wanted the router to
port-forward from the outside clients to your video server but wanted to
have the router locate the server by its MAC address instead of relying
on just one host having that unique static IP address. Apparently
that's not what you are doing.

Why would you bring up MAC addresses when setting a static IP address at
the host? Only if you were doing something in the router so it targeted
a specific MAC address would you care. Setting a static IP address on a
host has nothing to do with "fix the assignments to MAC addresses"
(where the "assignment" were presumably the static IP addresses you were
just discussing). Why do you need to ANYTHING regarding MAC addresses
in your router if your intent is to fix your server to a static IP
address? Why would your clients care as long as the server had a static
IP address? Why bring in anything about the MAC address?

You want your video server to always have the same IP address (static).
Okay, just configure its TCP/IP settings to do that. Choose an IP
address this outside the range that the router's DHCP server manages.
The router isn't even involved in this scenario and doesn't care about
your IP addresses used outside its managed range. You want your video
clients (which apparently in intranetwork instead of Internet clients)
configured to use the server's static IP address. Okay, go ahead and do
that, too. None of this requires you putz around with your router.
None of this involves the MAC addresses of your server or clients.

 

[Smarty]

The issue (apparently) is that loss of power / reboot, using a dynamic IP
for the video server, can and often does result in a new video server IP
address being assigned when the router / video server come up. The 8
clients use BootP to upload a copy of their run-time (Linux) application
which contains the client GUI, mpeg2 decoder, etc. for playback. They
fail to find the boot server, now at a new address, and are (apparently)
not able to easily get themselves booted. I am hoping that a fixed IP
address for the video server, where the 8 clients get their boot server
uploads, will now be much less difficult and time consuming.

I raised the entire matter of MAC addresses only because each of the 8
clients has a clearly labeled and unique hard-coded MAC address which (if
I had a way to create a map / table in my video server) could route
'instantly' without the ambiguity of issuing new IP addresses for both
the video server and 8 clients every time a power glitch occurs. It is my
impression that 3 100BaseT Netgear switches I use in my network also have
some "memory" in their port multicasting logic / look up table which
"remembers" the prior IP addresses of the clients attached to them, and
thus becomes a temporary dead-end for packets being routed to the new
client IP addresses after DHCP assignments occur following reboot.
Unplugging the switches and plugging them in a minute or two later seems
to solve this problem, but there is a temporary period where the switches
don't seem to be forwarding properly during the BootP process. Thus I
brought up Mac addresses as an alternative way to perhaps avoid the DHCP
quagmire.

My apologies if the original post was incomplete, vague, or both. I am
going to try the recommended approach to fix the video server IP address
statically, now that I understand that the Linksys can route to the
entire range of addresses in the subnet, beyond the range I have defined
for automatic DHCP assignment. Perhaps this will be enough of a solution.

Many thanks again.

Hi,

Ahhh... Ok, that's better... thanks for the explanation of what you're
actually trying to do.

So, are you saying that "your" server (the one for which you were trying
to set a fixed IP address) is also acting as a BOOTP server?

I haven't worked with this kind of stuff for awhile (use to work with
PXE/TFTP booting, etc., but years ago!), but, according to this:

http://en.wikipedia.org/wiki/Bootstrap_Protocol

"The Dynamic Host Configuration Protocol (DHCP) is a more advanced
protocol for the same purpose and has superseded the use of BOOTP. Most
DHCP servers also offer BOOTP support."

Do you know whether or not whatever is acting as the DHCP server on your
network (I'm assuming that router) is also acting as a BOOTP server?

If it is, and if "your" server is also acting as a BOOTP server, maybe
that's part of your problem?

According to this:

http://www.eventhelix.com/RealtimeMantra/Networking/Bootp.pdf

the client sends a BOOTP_REQUEST using UDP, with a broadcast
(255.255.255.255) destination address.

[NOTE: If the clients are indeed sending the BOOTP_REQUESTs with UDP and a
broadcast address, then setting your server to a fixed IP address is
probably not what your problem is, since your server should see the
broadcast request regardless of its own IP address.]

So, if BOTH your router AND "your" server are acting as BOOTP servers,
maybe both of them are responding to the BOOTP_REQUEST?

It might be worthwhile to run a separate machine on the network, with a
sniffer (e.g., Wireshark) running, to see what is going on?

Jim

Thanks Jim for your reply. Sorry if my prior posts were too vague. The video
server does indeed act as the BootP server, since the 8 clients are (to use
a somewhat faded phrase) "diskless workstations". The clients are small
media player boxes which first initiate a DHCP request from my Linksys
router, and subsequently (once they have an IP address assigned) initiate a
BootP request to the video server. If the sequence works as planned, the
video server then serves a binary image which the video client uploads and
executes which is the client media player software, mostly GUI and playback
decoders.

The problem which I have seen is after a power glitch, when 8 clients are
simultataneously asking for IP addresses from the Linksys, but still
"remember" that the video server could be reached at its old (stale) IP
address. Now that I have pinned the video server address at 192.168.1.150
statically, I am hoping that this is no longer an issue.

I think my problem may be solved. My earlier MAC comments were merely to
contemplate that all of my 8 clients have well-defined and potentially
"hard-wired" MAC access which (if the Linksys could handle it) allow me to
avoid the dynamic routing altogether, thus adding even more stability. I do
not see a way to make use of them in my current set-up, unfortunately.

Thanks again for the help.

 

[Smarty]

Hi,

Can I suggest that we all refrain from comments like above?

I think that we ALL have been trying to help you.

As I stated in one of my earlier posts, it's helpful if you could explain,
overall, what you're trying to accomplish, which you did in the post after
the above, to which I just responded.

Without that, the only thing that we can do is to try to "guess" what
you're trying to do, and then offer opinions/info based on those guesses.

Maybe there's something proprietary or something about what you're doing,
that would prevent you from divulging info, but if so, just state that.

Anyway, that's just my opinion, which I hope that you'll take the right
way ...

Later,
Jim

I very much appreciate the help here Jim, but the person who responded began
by stating that I did not understand the replies being offered and then
followed up with some further confusion about Internet access, ISP legal
issues, and other matters which were irrelevant to my original inquiry.

It was, to put it mildly, both an insult as well as putting words in my
mouth I had never offered or intended to offer, thus adding confusion. I
apologize if I over-reacted.

 

[Smarty]

You mentioned your router. Your router doesn't care if you are
assigning static IP addresses to your hosts. That just means the
router's DHCP isn't involved. The LAN side of the router is a switch,
so I would've thought using static IP addresses was a given in your
scenario and due to the limitations of the client hosts. You wouldn't
even need a router for your video server and video clients if they were
all in a private and disconnected network. You would just be using a
switch. Because you mentioned the router, I figured your clients were
on the WAN side of your router trying to punch into the subnet under the
router. Because you brought up MAC addresses (which is not involved in
your static IP assignment), I figured you wanted the router to
port-forward from the outside clients to your video server but wanted to
have the router locate the server by its MAC address instead of relying
on just one host having that unique static IP address. Apparently
that's not what you are doing.

Why would you bring up MAC addresses when setting a static IP address at
the host? Only if you were doing something in the router so it targeted
a specific MAC address would you care. Setting a static IP address on a
host has nothing to do with "fix the assignments to MAC addresses"
(where the "assignment" were presumably the static IP addresses you were
just discussing). Why do you need to ANYTHING regarding MAC addresses
in your router if your intent is to fix your server to a static IP
address? Why would your clients care as long as the server had a static
IP address? Why bring in anything about the MAC address?

You want your video server to always have the same IP address (static).
Okay, just configure its TCP/IP settings to do that. Choose an IP
address this outside the range that the router's DHCP server manages.
The router isn't even involved in this scenario and doesn't care about
your IP addresses used outside its managed range. You want your video
clients (which apparently in intranetwork instead of Internet clients)
configured to use the server's static IP address. Okay, go ahead and do
that, too. None of this requires you putz around with your router.
None of this involves the MAC addresses of your server or clients.

Thank you for your reply. The interest in Mac addresses I stated was merely
to explore the ironic fact that each of my 8 media player boxes has a
clearly defined MAC address which my video server "could" use to facilitate
and stabilize my re-boot problem, yet there is no (apparent) way to take
advantage of them. This would avoid the need for DHCP entirely, whereas now
each of these 8 devices has to initiate a DHCP, then BootP process which can
take tens of minutes after a power glitch. I am hoping that fixing the video
server IP statically will at least avoid the problem of the clients finding
the server after a server IP address change.

Thanks for your assistance. Sorry we had a misunderstanding.

 

[Smarty]

I am using an older and very stable Linksys WRT54G router and have DHCP
enabled for the clients. One of my router's current DHCP clients is a
video
server which gets a fresh IP address occasionally when the router or video
server is re-booted.

This creates a problem, since the 8 video clients which connect to this
video server have very limited ability to recover from changes to the
video
server IP address change. They are small embedded Hauppauge media boxes
which cannot easily find the revised video server address, and have no way
to easily reboot themselves from the video server.

I would like to fix the video server IP address to a static IP outside the
range of the Linksys router DHCP server, but still in the same subnet as
the
router. Specifically, I would like to put the video server at
192.168.1.150
as a static IP address, and only allow the DHCP server in the Linksys to
serve addresses from 192.168.1.100 through 192.168.1.149.

This should allow my 8 video clients to ALWAYS see their video server at
192.168.1.150 regardless of whether the router had to be re-booted or the
video server had to be rebooted.

Is there any reason why I can't do this? I am specifically concerned that
the Linksys will only route to those addresses it has dynamically assigned
via DHCP, and will not route to those above that range.

Is this a legitimate concern?

In a word, No.

Many thanks in advance for guidance.

There may be another option that I haven't seen suggested in this
thread. You may find your router can be configured to give out the
same IP address always to your server. I use this with an XBOX (which
doesn't allow static IP addresses).

--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.]

I am somewhat familiar with a concept of "reservations" to reserve IP
addresses for specific devices, and see no way to do so with my present
Linksys. I was actually hoping to use this to fix my 8 client addresses
based on using their MAC addresses, but such is not an option in my current
router. Thanks for replying.

 

[VanguardLH]

The interest in Mac addresses I stated was merely
to explore the ironic fact that each of my 8 media player boxes has a
clearly defined MAC address which my video server "could" use to facilitate
and stabilize my re-boot problem, yet there is no (apparent) way to take
advantage of them. This would avoid the need for DHCP entirely, whereas now
each of these 8 devices has to initiate a DHCP, then BootP process which can
take tens of minutes after a power glitch. I am hoping that fixing the video
server IP statically will at least avoid the problem of the clients finding
the server after a server IP address change.

As I recall (been a long time), the clients that use BootP will pull
their code from a configured server. So once you fix to a static IP
address for the server, DHCP isn't involved anymore. Well, it's still
involved for the clients if they are still using DHCP but you could
change them to static IP addresses, too, and complete get rid of DHCP.
However, I don't think DHCP is what is taking so long. Do the clients
actually still want to use BootP to get an IP address assigned to them
if they were also using a static IP address? Unless you actually need
DHCP from the router, you could turn it off in the router and use static
IP addresses for all your hosts. With them all using static IP
addresses, none of them would need to use DHCP and probably not BootP.

 

[Smarty]

As I recall (been a long time), the clients that use BootP will pull
their code from a configured server. So once you fix to a static IP
address for the server, DHCP isn't involved anymore. Well, it's still
involved for the clients if they are still using DHCP but you could
change them to static IP addresses, too, and complete get rid of DHCP.
However, I don't think DHCP is what is taking so long. Do the clients
actually still want to use BootP to get an IP address assigned to them
if they were also using a static IP address? Unless you actually need
DHCP from the router, you could turn it off in the router and use static
IP addresses for all your hosts. With them all using static IP
addresses, none of them would need to use DHCP and probably not BootP.

Unfortunately my 8 clients are little $50 boxes with an Ethernet port and
yellow, red, and white outputs for composite NTSC video and stereo audio,
but no provisions whatsoever to flash their NVRAM. I think they are actually
PROM'ed with soldered-in firmware, and they have no ability to have static
IP assignments in their boot code. My 8 boxes have the so-called "Rev 1.0"
boot ROM which makes them the least capable of all the ones which Hauppage
offers. They are vintage-1995 hardware.

So I have no way to either reserve IP addresses based on Mac addresses, nor
do I have a way to set them up as static.

I still am wondering if my Netgear switches truly have any "memory" of the
ports associated with specific IP addresses of the connected clients, as
they have no reset or reboot function as far as I know. It seems that
removing power from the switches and then bringing them back up again does
force a "reboot" of some type, since they seem to connect and work quickly
after the power is re-cycled. I know that switches create a routing table so
as to not multicast / flood all of the ports when a device is only present
at one port. It just is not clear to me under what circumstances this table
is updated, or for that matter built from scratch.

Thanks once again for your assistance.

 

[Smarty]

As I recall (been a long time), the clients that use BootP will pull
their code from a configured server. So once you fix to a static IP
address for the server, DHCP isn't involved anymore. Well, it's still
involved for the clients if they are still using DHCP but you could
change them to static IP addresses, too, and complete get rid of DHCP.
However, I don't think DHCP is what is taking so long. Do the clients
actually still want to use BootP to get an IP address assigned to them
if they were also using a static IP address? Unless you actually need
DHCP from the router, you could turn it off in the router and use static
IP addresses for all your hosts. With them all using static IP
addresses, none of them would need to use DHCP and probably not BootP.

Unfortunately my 8 clients are little $50 boxes with an Ethernet port and
yellow, red, and white outputs for composite NTSC video and stereo audio,
but no provisions whatsoever to flash their NVRAM. I think they are actually
PROM'ed with soldered-in firmware, and they have no ability to have static
IP assignments in their boot code. My 8 boxes have the so-called "Rev 1.0"
boot ROM which makes them the least capable of all the ones which Hauppage
offers. They are vintage-1995 hardware.

So I have no way to either reserve IP addresses based on Mac addresses, nor
do I have a way to set them up as static.

I still am wondering if my Netgear switches truly have any "memory" of the
ports associated with specific IP addresses of the connected clients, as
they have no reset or reboot function as far as I know. It seems that
removing power from the switches and then bringing them back up again does
force a "reboot" of some type, since they seem to connect and work quickly
after the power is re-cycled. I know that switches create a routing table so
as to not multicast / flood all of the ports when a device is only present
at one port. It just is not clear to me under what circumstances this table
is updated, or for that matter built from scratch.

Thanks once again for your assistance.