1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Router cannot get IP from Provider DHCP

Discussion in 'Tomato Firmware' started by awer1967, Aug 29, 2009.

  1. awer1967

    awer1967 Addicted to LI Member

    Hello all !

    I have a big problem.
    My WRT54GL with a Tomato Victec Mod 1.25 cannot get IP address from provider DHCP server from 100Mb LAN connection . But , when I connect either Linux or Windows XP workstations thru the same 100MB line - THEY OBTAIN IT WITHOUT ANY PROBLEM.
    This problem was started month ago, before it I have no problem with DHCP on the router. But on that bad day some changes done in the my provider network. And router could not got their IP.

    My provider identifies the customer at the MAC address. On their client database store MAC of my router WAN connection and I clone it on Windows and Linux machines when I connect them to network.

    At the IP packets level - problem seen as - router send DHCP Discover packet and no reply on it from DHCP server.

    Now I use address which I got from provider on Windows machine, like a static IP on WAN interface but it is not right solution.

    Thanks for your patience:)

    Andrew.
     
  2. rhester72

    rhester72 Network Guru Member

    Sounds like you need to clone the MAC onto your router, too.

    Rodney
     
  3. mstombs

    mstombs Network Guru Member

  4. awer1967

    awer1967 Addicted to LI Member

    I did it first of all, when I connect router to the provider LAN and router was obtains IP succesfully till last month...
     
  5. awer1967

    awer1967 Addicted to LI Member

    Thanks, sounds good ! Will try it and write about my results. Thanks again.:thumbup:
     
  6. awer1967

    awer1967 Addicted to LI Member

    mstombs - sorry, no happy on your advice...
     
  7. awer1967

    awer1967 Addicted to LI Member

    Well, I have one decision but I need some help from society. I think that provider change TTL hops to their DHCP server, because when I change TTL on my windows or linux station- to 64 - I CANNOT OBTAIN IP like on Tomato !

    I change ip_default_ttl at the /proc/sys/net/ipv4 in the init script like

    echo 128 >/proc/sys/net/ipv4/ip_default_ttl

    this affects only on ttl in the my local ip addresses,but WAN interface did not change TTL - i saw DHCPDISCOVER packets sending by this interface with TTL=64 .

    I read that TTL on WAN interface can change with iptables . I found example for DD-WRT

    iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 128

    but it did not works in Tomato

    Please, help - how can I write rules in Tomato iptables who changes ttl on Postrouting packets ?

    Great thanks.
    Andrew.
     
  8. awer1967

    awer1967 Addicted to LI Member

    Well , no good news. that impossible on Tomato, but possible on DD-WRT.
    Sorry..

    Good Bye.
     
  9. Demon50

    Demon50 Addicted to LI Member

    try going into advanced -> dhcp / dns and checking the "reduce packet size" option and reboot, see if that connects.
     
  10. menses

    menses Addicted to LI Member

    Hey Andrew, you might like to check my thread about a similar looking problem: http://www.linksysinfo.org/forums/showthread.php?p=351537

    By the way, why the iptables command you posted above doesn't work in Tomato? Is the iptables mangle module compiled in the Victec Mod 1.25?
     
  11. awer1967

    awer1967 Addicted to LI Member

    It seems to me ,not. When I do terminal session with my router and type above command , answer is "there is no target/chain/" or so . It shows that mangles option did not enabled in the kernel configuration. :frown:
     
  12. awer1967

    awer1967 Addicted to LI Member

    I did it, but it don't affects on situation .
     
  13. awer1967

    awer1967 Addicted to LI Member

    Menses, I read Your post, and seems to me than we had common problem. I think that my ISP neither drop all incoming packets from clients with TTL lt 128 :wink:
    or substracts on their router 64 from TTL in all packets from clients.

    I did a little trial-trip yesterday - change TTL on Windows workstation and miracle happened - STATION COULD NOT GET IP FROM ISP. We have the answer.:smile:
     
  14. menses

    menses Addicted to LI Member

    The TTL in my laptop (Mac OS X) for DHCP packets seems to be 255. That must be why the connection works. I don't know yet how to change it... for testing purposes.

    So the TTL in Tomato is just 64? Why is it so low?

    Have you found a way to change it in Tomato without using iptables?

    Maybe there is a Tomato mod with the mangle iptables module compiled? The tomato wikibook lists at least 10:
    hardc0re
    jyavenard
    Neorouter
    roadkill
    SgtPepperKSU
    slodki
    Teddy Bear
    Thor
    Trzepako
    Victek
     
  15. awer1967

    awer1967 Addicted to LI Member

    Sorry, I cannot help You - I am not so familiar in Mac OS, but I know that it based on BSD kernel..may be like in FreeBSD -

    sysctl -w net.inet.ip.ttl=value



    It is standart TTL value for Linux system and it is recommends unix guru - like most good that delete any possibility network loops. Windows IP stack has TTL 128 by default and never Linuxes like Ubuntu too.

    There is no way to do it by another way. Changing /proc/sys/net/ipv4/ip_default_ttl cannot helps .

    May be.. but I want to work without unneeded experiments.And there is no enough time for that .

    Standart Tomato and Victek don"t use kernel mangle option..may be other ?
     
  16. awer1967

    awer1967 Addicted to LI Member

    ~ # iptables -t mangle -A POSTROUTING -o vlan1 -j TTL --ttl-set 128
    iptables: No chain/target/match by that name

    Here is an answer of system, talk above. It the same in Tomato 1.25 STD and Victec mod.
     
  17. menses

    menses Addicted to LI Member

    Hi!

    I just check the default TTL on my Mac OS X with the command you told about:
    Code:
    $ sysctl net.inet.ip.ttl
    net.inet.ip.ttl: 64
    So in OS X the default TTL is 64.

    However using Wireshark I found out that when my network card searches an IP address using DHCP the TTL of the packets are always 255.

    So at least OS X doesn't use the default 64 TTL with DHCP, but the longer 255.

    How about Tomato? Did you intercept the DHCP communication between your Tomato and your ISP?
     
  18. menses

    menses Addicted to LI Member

    Hey Andrew... Maybe you have already thought about this, but how about using the ipttl parameter with udhcpc?

    ipttl is supposed to change the TTL of the DHCP packets.

    I cannot test this today myself, maybe tomorrow...

    Let me know if this works!
     
  19. awer1967

    awer1967 Addicted to LI Member

    Good day !
    Hmmm..dont know about this fact , ask about it Mac guru .

    Yes, all traffic was caught by Wireshark and
    investigated:cool:

    TTL in router outgoing packets was 64 .
     
  20. awer1967

    awer1967 Addicted to LI Member

    That may helps only in DHCP exchange, but another packets will have TTL =64 and all traffic stops immediately after IP address obtained by PC.
     
  21. menses

    menses Addicted to LI Member

    Hi, thanks for your replies!

    Is it true that all packets with TTL = 64 will be discarded before they get to your ISP?

    For me this is not true.
    In OS X DHCP packets are all TTL 255.
    All other packets inside IP like HTTP are TTL 64... and the connection works perfectly after obtaining the IP through DHCP.

    This is why I think my laptop (OS X) can get IP address using DHCP and can connect to Internet without any problems.

    However when I add Tomato in the middle, I cannot get IP address using DHCP.

    So the conclusion to me seems that we only need bigger TTL during the DCHP process.

    Keep me updated:wink:
     
  22. awer1967

    awer1967 Addicted to LI Member

    Hmmm.. sounds interests.. I check this at the day after tomorrow.
    But ! there is the question - how can we change standart script file "dhcpc-event" and where it is, because "ipttl" is parameter ,used by this script.
     
  23. mstombs

    mstombs Network Guru Member

    Tomato doesn't use simple scripts for dhcpc, they all link back to the C-code rc router control logic.

    Throughout the Tomato code the TTL used is a compiler definition

    Code:
    #define    IPDEFTTL    64        /* default ttl, from RFC 1340 */
    My guess is you would need to change a line of code in busybox/networking/udhcp/packet.c to change the TTL used for the broadcast discovery phase

    Code:
        packet.ip.ttl = IPDEFTTL;
     
  24. awer1967

    awer1967 Addicted to LI Member

    Wow !!!

    Very interesting situation...udhcpc use their own TTL in broadcast discovery and that dont captured by iptables ? Can I use chain POSTROUTING in table "mangles" to change TTL ?

    And otherwise I am not ready to compile my own Tomato build...
     
  25. awer1967

    awer1967 Addicted to LI Member

    Hi,all !

    The happy end .But not so good , as seen.

    1.DD-WRT was installed on my WRT54GL, and I add comand to firewall for changing TTL all packets in POST- and PREROUTING chains in mangles table. It works, the command "iptables -t mangles -L " shows correct info.
    2. In outgoing DHCP DISCOVER packets TTL=64 :eek: WHY ???? AFAIK IP stack uses iptables for all their traffic and all IP packets going thru it.
    3. Connection with ISP works :eek: but it seems to me they change some parameters in its active devices, because my IP address changed from NAT-ted, to real IP.
     
  26. rhester72

    rhester72 Network Guru Member

  27. awer1967

    awer1967 Addicted to LI Member

  28. menses

    menses Addicted to LI Member

    Hey Andrew,

    Is your connection working now? Your ISP changed some settings and then it started to work??? I don't understand :confused: :biggrin:

    Yesterday I had the change to configure my Tomato, and it's true that the script udhcpc uses is a binary file, which makes it hard to change the ipttl parameter.
    I downloaded the tomato source but couldn't find the dhcp-event script, which udhcpc uses. Where can I find this script and how easy it is to compile it? Is it possible to replace a newly compiled file with an old file in the tomato system or does it require that everything is compiled from scratch?

    By the way, Andrew, how did you first came to the conclusion that the TTL is the problem?
     
  29. awer1967

    awer1967 Addicted to LI Member

    Yes , connection works but big changes were made -

    1.My router works with DD-WRT v.24SP2 ,not with Tomato.
    2.I add strings to change TTL in mangles table.It works , I saw they here when I typed "iptables -t mangle -L"
    3.My provider change own address pool - it takes real IP addresses to clients instead private, like it was before, and it change something in its network..
    4.Router start obtain IP normally :)


    O, that file is hardlink to binary script in memory, but you can change it on your own very easy, but ! IPTTL is read-only system variable who used in the script only to detect default TTL, no more..

    Google "udhcpc+script" helps you. And try to explore busybox sources.I think you"ll find it there.


    No, it is not. You may create your script, put it in /opt (dont know rather, seems to me - /opt) ,chmod +755 to it and then write something like next

    killall udhcpc
    udhcpc -i vlan1 -s /opt/yournicescript ...(here you may add other params)

    in your init script (from WebGUI).

    Very simple. I just change TTL on my laptop with WinXP ,from 128 to 64 and laptop
    could not obtains IP address from ISP. The same procedure was done with Ubuntu laptop and same situation repeat.

    Sorry for my bad English.

    Good luck !
     
  30. menses

    menses Addicted to LI Member

    Hi, thanks for the long post!

    I searched the forums with "iptables -t mangle -L" as you suggested and found this post: http://www.linksysinfo.org/forums/showthread.php?t=57121

    In this post they enable the TTL mangling module by
    Code:
    insmod ipt_TTL
    I'm sorry if I'm asking a stupid question :wink: but did you try this in your Tomato??
     
  31. awer1967

    awer1967 Addicted to LI Member

    Wow..I did these commands on DD-WRT at the init script..hmm ! I will try to upload Tomato again at my router and work with it...May be it will helps us ? Great thanks !
     
  32. menses

    menses Addicted to LI Member

    Good to hear!

    I will go to config my Tomato tomorrow.

    Just to make sure... what is the correct iptables command to change the TTL of the DHCP packets?
    Should I use the POSTROUTING or OUTPUT chain?
    Code:
    iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 128
    iptables -t mangle -I OUTPUT -o `nvram get wan_iface`-j TTL --ttl-set 128
    How about adding '-p udp --dport 67' to make sure only DHCP packets are changed?
    Code:
    iptables -t mangle -I OUTPUT -o `nvram get wan_iface`-p udp --dport 67 -j TTL --ttl-set 128
    And where should I copy the command to make sure it's enabled every time tomato startS?
     
  33. awer1967

    awer1967 Addicted to LI Member

    Good evening !

    REALLY GOOD !

    IT WORKS.

    MENSES, YOU ARE GREAT MAN !

    Thanks for your previous post !

    And it is the time to help you.

    POSTROUTING, sure. This is because transit packets do not went by system thru OUTPUT chain.


    Hmm..and if provider check ALL packets ?

    Code:
    insmod ipt_TTL
    
    at Init script

    and
    Code:
    iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 128
    
    at Firewall script

    Seems to me.
     
  34. awer1967

    awer1967 Addicted to LI Member

    My mistake, menses !

    The commands

    Code:
    insmod ipt_TTL
    iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 128
    
    must be written in the Firewall script together ! I check it now.
     
  35. awer1967

    awer1967 Addicted to LI Member

    Tomato works fine now...and provider too ;)
     
  36. rhester72

    rhester72 Network Guru Member

    Just a quick note...your provider is broken.

    DHCP allows for virtually any arbitrary TTL, and in fact older releases of Ubuntu used a DHCP TTL of 64 (it was raised to 128 about 3 major releases ago). Windows has always used 128, but that should *NOT* be assumed - and your ISP definitely had a problem.

    Rodney
     
  37. menses

    menses Addicted to LI Member

    Hi, I'm glad to hear you got your Tomato working! :biggrin:

    And thanks for all your help!

    One more thing about the chains... If I only want to change the TTL of the DCHP packets my Tomato creates, then the OUTPUT chain should be enough? Am I right??

    But if I want to change all the packets that go through the Tomato, then I should use POSTROUTING?

    Trying to make sense of the guides here :)

    By the way, does POSTROUTING include the OUTPUT chain... I mean POSTROUTING even changes the packets generated locally by the Tomato?
     
  38. menses

    menses Addicted to LI Member

    My provider is probably broken too.
    Have you heard previously about cases where DHCP doesn't work because the TTL is "wrong"? Is this a problem of some commercial DHCP server software or just bad configuration by the ISP? I really can't figure out what could be the intention not to accept packets with "low" TTLs like 64.
     
  39. menses

    menses Addicted to LI Member

    I was just going to leave to configure the tomato with the new iptables settings, but I wanted to test it out with Linux first.

    So I run the iptables commands in ubuntu, and the TTL remains unchanged for DHCP packets, but after the DHCP negotiation is over, all other packets are affected by the TTL change?? I cannot figure out why DHCP packets are immune to iptables?

    The command i used on my Ubuntu was:
    Code:
    iptables -t mangle -I POSTROUTING -o wlan0 -j TTL --ttl-set 169
    
    also tried the OUTPUT chain
    Code:
    iptables -t mangle -I OUTPUT -o wlan0 -j TTL --ttl-set 169
    
    but no success??
     
  40. awer1967

    awer1967 Addicted to LI Member

    Yes, I know it - but my ISP think that I must not use Wifi router for connect to Internet..It say something about "You must go to I-net from your laptop only. We had made connection to your laptop and if you would connected by some devices between laptop and our switch - we would not guaranteed stable connection " Such a stupid situation !
     
  41. awer1967

    awer1967 Addicted to LI Member

    POSTROUTING in mangle only . This is last chain in last table (mangle) in the packet way on Linux system . And seems to me You are mistaken ,because chains does not contain itself..
    The tables contains chains and packet going thru CHAINS AT TABLES . By example - all packets who forwards by router do not going thru chains INPUT and OUTPUT of table by default (i forgot its name) but going thru chain FORWARD jf the same table etc...
     
  42. awer1967

    awer1967 Addicted to LI Member


    This is the STUPID PROVIDER POLICY and no more seems to me. Or fight with young hackers ? :mad: But why it affects me ?:mad:
     
  43. awer1967

    awer1967 Addicted to LI Member

    No need OUTPUT. That's enough do it for POSTROUTING chain.:)

    I saw it .. and say about it above in this thread...I dont know why this very strange behaviour of DHCP presents and I am not so big guru in Linux that understand it.. Is there anybody who help us and give good answer ?
     
  44. menses

    menses Addicted to LI Member

    Hi,

    I added the lines
    Code:
    insmod ipt_TTL
    iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 128
    And now the tomato gets IP through DHCP and the connection works smoothly!
    Big thanks to you! :biggrin:

    Yep, even though everything works now, I still don't quite understand why... After I found out that the iptables mangle command didn't affect DHCP packets in Ubuntu, I was extremely confused... and almost sure that my Tomato won't work either. But it still works!? Happy but confused :wink:

    Hopefully somebody can explain this...
     
  45. menses

    menses Addicted to LI Member

    Hmm...

    I just checked the iptables mangle rules
    Code:
    # iptables -t mangle -L
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain POSTROUTING (policy ACCEPT)
    target     prot opt source               destination
    So the list is empty, which means that the TTL rule has not been committed. The reason seems to be that the ipt_TTL module cannot be launched with insmod, rather it should be launched with modprobe.
    But the funny thing is that the connection still works! Even though I reboot my Tomato and ADSL modem, it still works...

    The very first time I tried Andew's way to change the TTL, I launched ipt_TTL with insmod and found out that it didn't work, so I tried to launch it with modprobe which worked fine. After this I committed the iptables mangle TTL rule. And when I checked the table, I saw that the rule was in the list and thus working. Then I release&renewed my IP and I finally(!!!) got a public IP... and I felt like heaven!
    Then I copy the lines
    Code:
    insmod ipt_TTL
    iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 128
    to the firewall script, and reboot tomato, and everything still worked... even though I didn't remember that the insmod command doesn't work until just now.

    So why does it STILL work?
    My best guesses are these:
    1. My ISP changed some settings and everything started to work. (My configurations didn't have any effect.)
    2. The TTL changing did work (using modprobe and iptables mangle) but it was required only once... maybe my ISP's DHCP servers require some defined TTL values when it saves a new MAC to its registers the first time. (However this explanation has one flaw, because as far as I know, the iptables ttl mangling does not affect DHCP packets at all)
    3. Feel free to share your explanation :)


    By the way, Andrew, I would be interested to know what your tomato says when you check the iptables mangle table with:
    Code:
    # iptables -t mangle -L
     
  46. awer1967

    awer1967 Addicted to LI Member

    Wow ! I am very glad that you have a glorious victory under your buggy ISP !:thumbup::thumbup::thumbup:

    Hmm.. I can't think now, we had my father-in-law birthday,:biggrin: but I mean there is two things ,which prevent set ttl to 128 in DHCP packets

    1.some rules in firewall
    2.Special behaviour of broadcast packets - not only DHCP (I dont believe on it actually , but the miracles happens)

    I will be read wise books from morning..may be I would find decision.
     
  47. awer1967

    awer1967 Addicted to LI Member

    Good night all !:biggrin::biggrin::biggrin:
     
  48. awer1967

    awer1967 Addicted to LI Member

    I think that most likely reason is 2.But who knows...

    Here is it

    Code:
    
    # iptables -L -t mangle
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination
    
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain POSTROUTING (policy ACCEPT)
    target     prot opt source               destination
    TTL        0    --  anywhere             anywhere            TTL set to 128
    
    
    I use Tomato Victec RAF mod , btw.
     
  49. awer1967

    awer1967 Addicted to LI Member

    Yo-ho-ho ! menses ,we have first part of answer !


    http://www.mail-archive.com/netfilter@lists.samba.org/msg03907.html


    Re: Can't block DHCP with iptables?

    Marcus Sundberg
    Thu, 13 Jun 2002 10:30:20 -0700

    Roar Bjшrgum Rotvik <[EMAIL PROTECTED]> writes:

    > In this scenario, the policy DROP exists before DHCP client starts up, but
    > still the DHCP client manages to assign a new IP-address.
    >
    > ifconfig shows shows that eth0 has been assigned new IP-address. ping or
    > any network traffic after that does not work, as expected.
    >
    > What I want to accomplish is to block all network traffic in/out up until
    > a certain point, and that includes DHCP.

    Iptables only deals with IP packets. DHCP-clients don't use the
    IP-stack, but uses raw sockets to talk directly to the network
    interface. Very simplified, what you have is this:

    eth0 ----+------- iptables ----- IP-stack
    | filtering
    Raw socket
    |
    DHCP-client

    /Marcus
    --
     
  50. menses

    menses Addicted to LI Member

    I have the basic Tomato 1.25 ND.
    What does the console say when you run insmod and modprobe?
    Here's how it looks like in the basic Tomato:
    Code:
    # insmod ipt_TTL
    insmod: can't insert 'ipt_TTL': Operation not permitted
    # modprobe ipt_TTL
    #
    Hmm... but when I capture traffic with Wireshark I can see that the DHCP-packets are inside IP-packets (which have TTLs like all valid IP-packets).

    By the way Andrew, have you tried if your connection works now without the TTL changing iptables line?
     
  51. awer1967

    awer1967 Addicted to LI Member

    Here is output.. All works fine.

    Code:
    # insmod ipt_TTL
    #
    

    It is strange for me too. If packets was created by raw socket they must not include IP header (by example - STP BPDU packets works only with raw sockets and have no IP header)

    It not works without these lines :frown:
     
  52. RonWessels

    RonWessels Network Guru Member

    Incorrect.

    DHCP uses UDP/IP ports 67 and 68 and uses the IP subnet broadcast address for initial address acquisition.

    Here's the Wikipedia article on DHCP that explains the protocol.
     
  53. kanstin

    kanstin Addicted to LI Member

    It uses IP but it doesn't use the standard IP stack. It writes/reads packets directly to/from the network device, e.g. /dev/eth0. It can't use the IP stack because the IP stack needs to be configured, which is what DHCP does...
     
  54. awer1967

    awer1967 Addicted to LI Member

    I know it, but you"d better see sources of udhcpc and you"ll see that it uses RAW SOCKET unless of standart unix client "dhclient" which works with a TCP/IP stack rather (it uses APIPA addresses at initial step, by default) Ubuntu,Debian,Mandrake and many others linux distributions operate in such way.
     
  55. awer1967

    awer1967 Addicted to LI Member

    Yes, it is right. udhcpc uses this mechanism.
     
  56. awer1967

    awer1967 Addicted to LI Member

    Well, some investigation was done. I found six wireless routers and test them with my privider. Two of them - chinese TP-LINK and Anline uses own linux-like OS, where TTL is initially set to 128. They have no problem with connection. Other four did not connect anyway with ISP and they had different values of TTL - between 64 and 100 .

    I have a little question. Will it good ask Tomato"s masters (Victec by example )set

    Code:
    
    #define    IPDEFTTL    64        /* default ttl, from RFC 1340 */ 
    
    
    to 128 ? And where may I do this request ?
     
  57. mstombs

    mstombs Network Guru Member

    If you search the source you will find lots of repeats that line in lots of header files - I'm sure it would be easier just to change the use in Busybox

    I think it should be this line 186:-

    Git
     
  58. awer1967

    awer1967 Addicted to LI Member

    thank you , mstombs !
     

Share This Page