Change TTL-value of DHCP Requests
-
that looks like a cool patch, but don't see where you can modify default-ip-ttl?
And to be honest I have tried putting them in, and does not seem like the dhclient makes use of them. Which is the big issue, does not matter how you get them to the dhclient - if he is not going to pay attention to them ;)
-
Use the Config File Override option.
Yes, whether or not dhclient will make use of that option specified in a config file is another matter. This patch just makes customization easier.
Though the OP'er still hasn't confirmed the dhcp server hop count. So it may not even be relevant.
-
I've tried to trace down the DHCP, but the tracert gives no responses, and It just traces until reaching max defined hops…... Tried with a max of 30 hops, and it went all the way to 30 hops and stopped there. - Guess the ISP have some firewalls blocking the icmp responses all the way.....
So I've sent them an email requesting some info - I'll post back as soon as I get an response from them.
In the meantime I've also tried to circumvent the DHCP issue by using the D-link to initiate the DHCP, and then hotswap the cable with the pfsense (configured with the exact same IP-settings, only static, and ofcourse with the d-link's mac spoofed.... so that em0 uses the d-link's mac.....Hoping I could use this as a workarond solution, But thats also a "no go" - I was hoping the firewall of the ISP would enable traffic once DHCP was established, and then never be the wiser about pfsense suddenly beeing the source..... but I was wrong.... It surely senses the connection drop, even if it's only seconds, and breaks the established connections....Atleast I never get any traffic through (reswapping the cable to the d-link, and link is straight back after a renegotiate of dhcp)
So still running my pfsense behind the d-link here, waiting for some feedback from the ISP (but I'm not optimistic - since my setup is so far off in regards to what they support, I believe the will only blow me off with some bullshit....) - but crossing fingers hoping I get a decent support-representative on my case....
-
There are ways for the determined.
I've gone so far as to do this before. A bit tricky and delicate, but it works.
http://www.dslreports.com/forum/r27210694-FiOS-Dual-Router-Separated-Computer-TV-Service-Networks
Except in your case since pfSense is unable to get a DHCP lease it would have to be static of the ISP's router DHCP address.
Who knows. It might work. Never know what can be accomplished unless you try.
Best of luck to you with the ISP.
-
Ok here you go - I changed the packet.c source of dhclient to reflect a new ttl 128 vs the 16
I tried getting the development version of pfsense working, but the ova they have wasn't working just kept running some background script every 30 and failing. So I just grabbed real copy of freebsd 8.3, installed developers version on a vm. Then simple edit of the packet.c
ip.ip_ttl = 128;
then a simple make, and there you go - now it uses ttl of 128, see attached screenshot. I tested it on my pfsense as you can see by the screenshot so should run on your pfsense no issues.. You are using 32 bit right?
Just rename your /sbin/dhclient to dhclient.old or something and replace with the new version and if your problem is really just too low of TTL you should be good to go.
[2.1-BETA0][root@pfsense.local.lan]/sbin(2): ls -la dh* -r-xr-xr-x 1 root wheel 90150 Jul 28 03:16 dhclient -rwxr-xr-x 1 root wheel 9938 May 12 07:25 dhclient-script -r-xr-xr-x 1 root wheel 78828 Mar 21 07:54 dhclient.oldguess you can not add .zip files Here is link off my dropbox
https://www.dropbox.com/s/igj7z92e6eogyme/dhclient.zipif this works - then yeah we need to get this supmitted as actual bug and updated or fixed correct by freebsd, and then pfsense can update to the new version of dhclient. If I get a chance this weekend maybe I will take a look to why its not reading the options that are suppose to be there, now that I have a freebsd vm I can build on.
Please let me know if this works for you - hope it does! Not really sure why its so much bigger? All I did was edit that one line from 16 to 128.. Just so you know, I am not by any means a developer or programmer. I just dabble and just enough know how to find stuff like this that can be edited and any idiot can run make ;)
-
Thanks a lot for your effort with recompiling the dhclient, but sadly I was stupid enough to install the 64-bit edition of pfsense, so it will probably not work for me…... - But since it's easy enough to install on ESXi, I can keep my currently installed server, just shut it down, and then just try out a 32-bit with your recompiled DHclient..... If it works, well, then I can always run on the 32bit from there.... or go for a recompiled dhclient for 64bit, but 64 bit is actually not necessary, so if it works with your 32-bit fie, i'll probably run with 32-bit from there :-)
Thanks a lot - I'll go right ahead and intall the 32-bit and try out your new dhclient. I'll post my results once tested :-)
-
Is there any requirement (RFC etc) for dhclient using a ttl of 16 ? Because I couldn't find any.
On the other hand, it hard to imagine why this issue hasn't been fixed yet, since it has been 10 years since those Debian bug reports …
-
I would have to fire up debian to verify, or look at their code - but I have to assume it was fixed in their version of the dhclient.
But as you can see from this thread the one in freebsd only uses 16 as the ttl, I don't understand why doesn't just use the default os setting?
Then again its got to be rare as hell that your dhcp server would be more than 16 hops?? We are not even sure that is the OP problem. We should find out soon enough once he runs with my recompiled dhclient that has 128 ttl vs the 16.
I sure hope it fixes his problem, then we can work on getting the code fixed and maybe someone can explain why you would set it to 16? I can understand thinking - well why and the hell would a broadcast ever go over 16 hops ;) But then again why set a limit in the client in the first place? Why not just use the OS default?
-
Just rename your /sbin/dhclient to dhclient.old or something and replace with the new version and if your problem is really just too low of TTL you should be good to go.
[2.1-BETA0][root@pfsense.local.lan]/sbin(2): ls -la dh* -r-xr-xr-x 1 root wheel 90150 Jul 28 03:16 dhclient -rwxr-xr-x 1 root wheel 9938 May 12 07:25 dhclient-script -r-xr-xr-x 1 root wheel 78828 Mar 21 07:54 dhclient.oldFileupload broken?? I can't seem to upload files to the 32 bit pfsense. Using the built in gui (under diagnostic) to upload, nothing happens when upload is pressed, and the file never get transferred. I then installed the FileManager package, but whenever trying to upload i get the error "File Upload stopped by extension!"…. Tried ff and inet explorer.... both have same error....
Any ideas?
-
just sftp to the box - that is how i move files on and off my pfsense.
edit: And you want to make sure you client sends binary and not ascii.
-
johnpoz, You're THA' MAN! :-)
Seems your recompiled DHCLIENT actually solved my issue. This message is sent from my PC through pfsense, now for the first time with an offical IP straight from my ISP on the wan interface. Bye bye D-link inbetween.
If it actually was the number of hops beeing more than 16, or my ISP having a security setting whacking off DHCP-requests with less normal TTL's (most OS'es and standalone router boxes uses 64 or 128 TTL), I don't know - but with DHclient now sending out requests with TTL 128, I now have a DHCP lease on my em0 interface via bridged ISP-modem through my VLAN on core switch and via ESXi vswitch down to my pfsense…. Damn It feels good finally getting this piece of puzzle fitted :-)
I should probably get off to bed, because I'm off to work in 5 hours - but right now I feel I have to celebrate first with one beer!..... Cheers! and thank's for the help all of you!!!!
-
Glad it fixed your issue, it was fun for me to get a freebsd up and running I can compile stuff on in the future ;)
You know the security issue –- hmm I wonder?? Guess we could up the ttl and see what is the min to work, if its like 64 then most like a security thing.
I would love to know how many hops its away ;) It just blows my mind that you could be 16 hops away, that just nuts!! And seems like piss poor network design to me as well. But without a understanding of their network - maybe its 17 hops and that is the best way to setup what they want? But seems unlikely..
Just finally glad we got you working.. Now should report this to freebsd and actually get it fixed, I wonder others out there just don't get an IP and give up?? I was pretty impressed that you noticed the ttl being low, I am curious if I would of spotted that if I was having a sim issue. I now for sure will if I ever see such a problem in the future!
-
I don't know if it's a security issue or not - because my ISP hasen't responded to my support-ticket yet (if they ever will), but I'm also thinking it would be a pretty piss-poor network design if the DHCP could actually be more than 16 hops away…. But then again I have been working with computers and network for so long time, that nothing actually surprises me anymore. Since your modified dhclient solved the problem, it seems likely that the TTL have been the issue (unless the ISP quietly have been doing some stuff regarding my support-ticket - but i don't think so) and the most likely scenario would then be some sort of firewall blocking odd-requests (and since the majority of systems send out requests with 64/128 TTL, anything else is considered abnormal and killed)....
If I ever find the answer, if they respond, and I can say for sure that it was the hops or a security issue - I'll update this tread so that we can find pice of mind on this issue :-P
In regard of reporting this, since a vast majority of people are just plugging their pfsense behind ISP routers (unbridged) or have ISP with less rigid/picky security systems, nor running advanced setups including both VLAN's and virtualization, then the TTL of 16 have been sufficient through earlier releases and no need for change have been noticed nor reported. But, as you say, for all of those who have been trying to get a DHCP through a bridged modem, directly from their ISP and NOT succeded, and then gave up after trying "everything" - this actually might be the overlooked solution.
I can see no requiered reason for the dhclient to use TTL 16 when the default for all other traffic is either 64 or 128 - so this for sure is one thing that could/should make it into a new release of pfsense - or they could atleast make it something you can change easily with an optionsetting in the gui, or a config file :-)
Me for sure is happy that I can now focus 100% on config and further setup, instead of wiresharking and troubleshooting network/vlan traffic. It have been fun in some odd way, and I've probably once again learned something.... at least that even the smallest and most unlikely things, might be the big difference ;-)
-
Yeah I can see no reason for the 16 either, other OSes are not using such a low ttl for dhcp. I would be curious what netbsd or openbsd are using.
Maybe one of the developers for pfsense can help us with the official way of submitting the bug/issue and fixed in freebsd. What I can tell you is I updated my pfsense yesterday and its back to the original dhclient - so if you update your going to have to replace your dhclient again.
If for some reason they want to leave the default at 16, then it should be fixed so that the options of changing it works.
-
What I can tell you is I updated my pfsense yesterday and its back to the original dhclient - so if you update your going to have to replace your dhclient again.
Np, one thing I've definitely have learned over the years is the value of backup. Your modified dhclient, is ofcourse backed up, and duplicated both on my NAS, and somewhere in the cloud (Livedrive), just in case I have to do a reinstall/update of pfsense some time in the future…. ;-)
Now, I'm off to battle the next phase in my setup - getting OpenVPN to work with ActiveDirectory and DuoSecurity Radius Proxy (2 factor auth). Hopefully that wil go smoother than getting DHCP to work ;-)
-
I have submitted this as bug to freebsd, just waiting on confirmation that it was taken, will post link to report as soon as I get it here in this thread.
Ok the problem has been posted - you can follow it here
http://www.freebsd.org/cgi/query-pr.cgi?pr=170279
