jig
join:2001-01-05
Hacienda Heights, CA | reply to Shootist
Re: "UPDATE" DHCP on Z5 Problem
well, not for him.. he was going to redo the trace to double check but hasn't. probably busy. |
|
Anav
Sarcastic Llama? Naw, Just Acerbic
Premium
join:2001-07-16
Dartmouth, NS | Very busy from my correspondance... Best if shootist captures his data. |
|
Shootist
Premium
join:2003-02-10
Decatur, GA
| I plan on setting up 3 PCs, 2 notebooks 1 with the 3COM 3C920 (3C905C-TX compatible)(The Dell C610) integrated chip 1 with a Linksys Homelink HPNA/Ethernet PC card adapter (A IBM TP1400) and a desktop with a PCI 3COM 905 card, and do captures from all three switching between a Linksys SR41 and the Z5. The SR will have a IP of 192.168.0.254, same as my office LAN IP, and the Z5 with 192.168.1.1. This is where I have had the problem, I.E. when the NIC has a IP in a near/similar IP range. If I use a 10.x.x.x or 172.16.x.x IP on the other router the Z5 seems to reassign the correct IP to the PCs every time but I might also setup a third router with one of those ranges just to test. Now It's time to make some cables to do all this.
--
Shooter Ready--Stand By BEEP ******** |
|
bbarrera
Premium,MVM
join:2000-10-23
Sacramento, CA
clubs:
 ·SureWest Internet
| The zw5 is being used at my day job (software startup) and we recently leased office space in Silicon Valley. We share office space with other startups and unfortunately we share a T1 and are behind NAT so no VPN yet (I installed zw5 after 10 hours at a trade show). As I normally work from home, testing zw5 is problematic at the current time. I'll be down there today and Thursday, will update firmware and try setting up VPN for remote access. I've got to talk with network folks to get permission to run wireless and VPN.
As of 2 weeks ago, no DHCP problems with 2 Apple PowerBooks (normally on 10.0.1.0/24 Apple Airport DHCP) and 1 Dell WinXP Pro notebook (normally on 192.168.110.0/24 Linux DHCP). That was with beta firmware that was released prior to 4.00(WZ.2)C0. |
|
Shootist
Premium
join:2003-02-10
Decatur, GA
| Well I don't see the problem when going from a 10.x.x.x to the default Z5 range. It is when it is something in the 192.168.x.x range but then last night when I did the test with the other desktop the Z5 DID assign the correct IP to it after it was connected to a 192.168.0.x router. This whole thing leaves me scratching my head and pounding on my forehead. The real funny, not really, part of all of this is NO matter where I take my notebook and connect it to a LAN it ALWAYS gets assigned a proper IP in the range of the LAN I'm connecting to except when I take it home to the Z5. %$#@@@*&.
I'm also going to check if maybe it's something to do with the Static DHCP assignments in the Z5 because that other desktop that DID get a IP change from the Z5 is NOT setup with a static DHCP assignment. It just takes whatever the Z5 hands out. In fact I'm leaning in that direction and would like to hear from the others that have posted about this problem if all there notebooks/PCs are using Static DHCP assignments.
--
Shooter Ready--Stand By BEEP ******** |
|
bbarrera
Premium,MVM
join:2000-10-23
Sacramento, CA
clubs: | Notebook @ home office (Linux static dhcp) = 192.168.110.88
Notebook @ remote office (Zywall 5) = 192.168.112.x
The zw5 is a basic setup (NO static dhcp assignments). |
|
Shootist
Premium
join:2003-02-10
Decatur, GA | That confirms part of my suspicion, NO Static DHCP!!! I think I may be on to something.
--
Shooter Ready--Stand By BEEP ******** |
|
Brano
I hate Vogons
Premium,MVM
join:2002-06-25
Burlington, ON
·TekSavvy Solutions..
| I've just brought my laptop from work to home.
I've put it to suspend at work and later plugged to my home network running ZyWall5 with static DHCP entry for my laptop.
The IP got renewed automatically as expected. This did not work prior XD.1 firmware.
From my point of view the DHCP bug is gone. |
|
dslpartner
join:2005-02-18
| said by Brano  :I've just brought my laptop from work to home. I've put it to suspend at work and later plugged to my home network running ZyWall5 with static DHCP entry for my laptop. The IP got renewed automatically as expected. This did not work prior XD.1 firmware. From my point of view the DHCP bug is gone. Would you mind getting a packet capture next time you do this, so we can compare it to the packet capture Shootist will get when it fails.
--
The real downside of GIT may be that _my_ way of doing things is quite possibly very rare. But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong. -Linus |
|
Shootist
Premium
join:2003-02-10
Decatur, GA
1 edit | reply to Brano
Well from MY point of view it isn't. What is your IP range at work and at home?? Are they the same first 2 octets with different 3rd and forth octets. If the first 2 octets are different, 10.x or 172.16 as apposed to 192.168, that doesn't count, I win. Really the problem occurs when the first 2 octets are the same, at least from what I've seen.
I have NO problem getting the correct IP from the Z5 when the notebook has any other IP address then 192.168. If the notebook has a IP of 10.x.x.x the Z5 DHCP updates the notebook to 192.168.1.104. If the notebook has a IP of 172.16.x.x the Z5 update the notebook to 192.168.1.104. If the notebook has a IP of 192.168.0.64, work LAN IP, the Z5 DOES NOT update the notebook to the 192.168.1.104 IP. It just leaves the .0.64 IP and moves on.
I'm headed home. I'll post back in about 3 hours.
--
Shooter Ready--Stand By BEEP ******** |
|
Brano
I hate Vogons
Premium,MVM
join:2002-06-25
Burlington, ON | The first two octets are different.
I'll test it with same octets later tonight. |
|
OGalati
join:2005-08-19
Argentina | reply to Shootist
Shootist, sorry for the stupid question, but since sometimes you were working with class B IP addresses, are you sure the mask in the Z5 DHCP Server is /24 (255.255.255.0), not /16 (255.255.0.0)? |
|
Brano
I hate Vogons
Premium,MVM
join:2002-06-25
Burlington, ON
·TekSavvy Solutions..
4 edits | Shootist seems to be right. If the first two octets are the same the DHCP does not work properly.
I've done this test:
- configured my ZyWall2 as 192.168.1.0/24
- got my laptop on it and obtained an IP address using ipconfig /release /renew
- unplugged the laptop and plugged it to my ZyWall5 configured as 192.168.10.0/24
- the IP didn't get renewed |
|
Shootist
Premium
join:2003-02-10
Decatur, GA
| reply to OGalati
said by OGalati :Shootist, sorry for the stupid question, but since sometimes you were working with class B IP addresses, are you sure the mask in the Z5 DHCP Server is /24 (255.255.255.0), not /16 (255.255.0.0)? Yeah it's 255.255.255.0. Not sure you could even use the 255.255.0.0 mask with the 192.168.x.x range. I think it is hard coded not to so you can only have 254 clients using that IP range.
--
Shooter Ready--Stand By BEEP ******** |
|
Brano
I hate Vogons
Premium,MVM
join:2002-06-25
Burlington, ON
·TekSavvy Solutions..
1 edit | Thanks Shootist I'll send a link to this thread to ZyWall beta folks. Hopefully we'll see fix soon 
EDIT: I've sent it already. |
|
Shootist
Premium
join:2003-02-10
Decatur, GA
| You're welcome and thank you for reporting it. I just fired up the C610 I take back and forth to work after I disabled/removed the static DHCP assignment for it and the IP updated right away. So it is definitely tied to the Static DHCP feature. Could be because I am assigning IPs inside the DHCP server range instead of outside it?? But when you check the DHCP table it allows you to check a box TO put that MAC/PC in the static DHCP assignment??
--
Shooter Ready--Stand By BEEP ******** |
|
jig
join:2001-01-05
Hacienda Heights, CA
| i thought static dhcp was supposed to remove the availability of an assigned address whether or not the host with the mac was active or not. and i also thought that it was supposed to assign ips only within the dhcp server range.
your current problems seem exactly like what i would expect to happen if you had assigned static dhcp ips outside your dhcp server range.... some kind of little hiccup.
let me get things straight. when a host with a mac in the static dhcp list tries to acquire an ip address, but has come directly from another subnet within the same class b subnet, then the zywall doesn't respond to the request for an address.
further, this process works if the last dhcp assigned address was either outside the same class b subnet, or within the same class c subnet?
have you tested if the other router assigns an ip in the same "c" subnet that the z5 works through its issues and gets the static ip thing right when reconnected?
why do NICs remember their last ip, and why/how do they broadcast this when they ask for a new dhcp ip? I think this was answered in another thread, I just don't remember why...
anyway, maybe we've found the bug. it seems like a classic special case bug, but i can't quite get my head around it. it seems like something to do with maybe using the web interface while adjusting static dhcp settings, or maybe with how the static dhcp code keeps other dhcp clients from taking the assigned mac... it's as if they read in the broadcast previously leased ip and then push it into a memory location that gets checked against some rules that don't understand how an ip in the same class b (but not class c) subnet and with a registered mac could be requesting an ip here and now, and then hangs the dhcp handshake. |
|
Shootist
Premium
join:2003-02-10
Decatur, GA
| said by jig :i thought static dhcp was supposed to remove the availability of an assigned address whether or not the host with the mac was active or not. and i also thought that it was supposed to assign ips only within the dhcp server range. Yes it removes that IP address from being assigned to any other MAC by the DHCP server. It reserves it for the MAC it is assign TO.
YES and NO. Some router will only allow reserved IPs to be inside the DHCP range some only allow it to be outside the DHCP range, M0n0Wall only allows you to assign reserved IPs outside the DHCP range. I think the Z5 allows both inside and outside the range.
said by jig :your current problems seem exactly like what i would expect to happen if you had assigned static dhcp ips outside your dhcp server range.... some kind of little hiccup. My range is NOT the default, starting at .1.32 and going up, mine starts at .1.100.
said by jig :let me get things straight. when a host with a mac in the static dhcp list tries to acquire an ip address, but has come directly from another subnet within the same class b subnet, then the zywall doesn't respond to the request for an address. I think it responds but it doesn't force the change. In the logs it has entries that say "DHCP assigned x.x.x.x to 00:00:00:00:00:00" but it never really does. This is something for someone that knows more about all this to figure out.
said by jig :further, this process works if the last dhcp assigned address was either outside the same class b subnet, or within the same class c subnet? Class A, B, C,??? YES if the PC has a IP with the first 2 octets different then the Z5 successfully updates the PC to the correct IP. Never tried it with the first octet the same and the last 3 different, I.E. 192.5.x.x.
To be honest I never tried it with a IP in the same subnet with only the last octet different. In any event I could care less whether it did or did not change the IP of the PC in that case because as long as the PC had a IP with all the same octets, and as long as the last octet was unique (not being used be another node), you could connect to it and from it to the rest of the LAN and internet.
said by jig :have you tested if the other router assigns an ip in the same "c" subnet that the z5 works through its issues and gets the static ip thing right when reconnected? No I have not
said by jig :why do NICs remember their last ip, and why/how do they broadcast this when they ask for a new dhcp ip? I think this was answered in another thread, I just don't remember why... Lease time. As it shows in the ethereal files the NIC does broadcast "I have this IP".
What would happen is the NIC would go from x.x.0.x to 0.0.0.0 and then when it got a response from the Z5 it would go back to x.x.0.x instead of the Z5 forcing it to take the x.x.1.x IP. Or at least that is the way I see it.
said by jig :anyway, maybe we've found the bug. it seems like a classic special case bug, but i can't quite get my head around it. it seems like something to do with maybe using the web interface while adjusting static dhcp settings, or maybe with how the static dhcp code keeps other dhcp clients from taking the assigned mac... it's as if they read in the broadcast previously leased ip and then push it into a memory location that gets checked against some rules that don't understand how an ip in the same class b (but not class c) subnet and with a registered mac could be requesting an ip here and now, and then hangs the dhcp handshake. YES we have found a bug.
It has NOTHING to do with using the web interface. The web interface was NEVER open when the tests were run. Changes were made and I logged off the Z5 to start the tests. No I was not using one of the test PCs to make changes to the Z5.
If the MAC is removed from the static DHCP assignment list the Z5 does update the IP correctly, EVERY TIME.
--
Shooter Ready--Stand By BEEP ******** |
|
jig
join:2001-01-05
Hacienda Heights, CA
| said by Shootist :YES we have found a bug. It has NOTHING to do with using the web interface. The web interface was NEVER open when the tests were run. Changes were made and I logged off the Z5 to start the tests. No I was not using one of the test PCs to make changes to the Z5. If the MAC is removed from the static DHCP assignment list the Z5 does update the IP correctly, EVERY TIME. sorry, i didn't mean that you were doing something weird or strange in your tests, i meant that the special case code that i think this bug seems to be related to might have been something to try to deal with the "special case" of someone being logged into the web interface and trying to assign a different static dhcp ip, or something. they coded a special case to cover some situation (the web interface is just a guess, it has to be something about being in the same class c subnet), but they f-ed it up by checking against the wrong address or mask, or checking against it at the wrong time.... something, some rule that they kluged together.
in other words, if i was a zyxel programmer, that's where i'd look. |
|
