Allow existing DHCP options to be modified about dhcpoptinj HOT 16 CLOSED

hello
thanks for your efforts on this project , when do you think you will add manipulation for existing options
i am interested in changing/mangling the router option ,
could you tell me if it is possible to change it with the existing code ?
thanks a lot again

from dhcpoptinj.

I never depended on this feature, but I thought others might want it. I am happy to see that there are other users, so I'll start working on implementing this.

from dhcpoptinj.

perfect i am looking forward to it

from dhcpoptinj.

Try the latest version in the dev branch and see if it suits your needs. You need to specify the new "-r" option in order to remove/replace existing options.

from dhcpoptinj.

it works perfect
but i had to do this in iptables
iptables -t mangle -A PREROUTING -m physdev --physdev-in eth0 -p udp --sport 67 -j NFQUEUE --queue-num 42
eth0 is the side where dhcp leases are offered.

from dhcpoptinj.

is it possible not to use cmake so we can cross compile ?
i am trying to cross compile to openwrt but cmake is throwing many errors .
perhaps we can just make a good old makefile ,will it work?
thank you so much

from dhcpoptinj.

i created a makefile and i was able to port the code into openwrt and it seems to be working as expected.how does the code do in dhcp renewal ?
thanks

from dhcpoptinj.

The iptables line in the README is just an example, so you most likely have to change it. The "physdev" options are only necessary if you want to intercept traffic on a bridge interface.

I can only guess, but I don't think CMake is to blame for the errors. I think the issue might be either the lack C99 support in your compiler or that I somehow have missed warnings that are not triggered by my gcc (5.3.1-19). If you could please show me the error or warning messages, I will hopefully be able to help.

I don't want to replace CMake. However, I am no CMake expert, so there are surely a number of improvements I can make, like accommodate for cross-compiling. You can easily replace CMake with a simple Makefile (or a gcc/clang one-liner), though, since building the binary is not at all complicated:
mkdir build && cd $_ && gcc -O3 -o dhcpoptinj -Wall -Wextra -pedantic -std=c99 -D_POSIX_SOURCE -D_DEFAULT_SOURCE -DDHCPOPTINJ_VERSION=\"0.3.0\" -I../src ../src/*.c -lnetfilter_queue

from dhcpoptinj.

Hello
Sorry for late reply , as you suggested i created a makefile and it is compiled fine on openwrt .
but i am having bus error now here is the debug output
thanks .
Received 378 bytes
Inspecting packet from 58:7F:57:12:E7:F6 to 192.168.30.7 …
Mangling packet
Found option 53 (0x35) (DHCP message type): DHCPACK (copying)
Found option 54 (0x36) with payload C0 A8 1E FE (copying)
Found option 51 (0x33) with payload 00 00 0E 10 (copying)
Found option 1 (0x01) with payload FF FF FF 00 (copying)
Found option 3 (0x03) with payload C0 A8 1E FE (removing)
Found option 6 (0x06) with payload C0 A8 1E FE (copying)
Found END option (removing)
Injecting 1 option(s) …
Inserting END option …
Padding with 26 byte(s) to meet minimal BOOTP payload size …
Bus error

from dhcpoptinj.

You obviously shouldn't experience any segmentation faults or bus errors, but I cannot rule out that there are bugs. I have only access to simple test setup at the moment, but I haven't been able to find any (serious) errors so far using valgrind. Is this a recurring problem that you can reproduce? If so, I might be able to help you if you can provide me with more details. Do you have gdb installed on the target device? Build dhcpoptinj with -O0 and -g and run it in gdb. If it crashes, give me the backtrace (press "bt"). I'd also like to know the full command line (what options did you use). If you can, also save a dump of the traffic (using dumpcap, for instance). You may not want to publish a traffic dump on the Internet, so just hang on to it in case I can't find the problem in the backtrace and need more details.

Ideally I should have automated test with sufficient coverage. Unfortunately, I don't have enough time to give this project at the moment.

from dhcpoptinj.

I may be on to something. I'll keep you posted.

from dhcpoptinj.

Yes, there is definitely a bug: an unfortunate mistake in the calculation of the new packet size. I'll fix it as soon as possible and make sure the new version works in my own production setup (in which I hadn't tested until now).

from dhcpoptinj.

hello
this is what i am running
iptables -t mangle -A PREROUTING -m physdev --physdev-in eth0.40 -p udp --sport 67 -j NFQUEUE --queue-num 42
dhcpoptinj -d -f -q 42 -o'03 C0 A8 1E 03' -r
the weird thing is it runs on the 64 bit machine but on mipsel it throws an error .
I hope the bug you found solves the issue
thanks a lot

from dhcpoptinj.

I believe I have fixed the issue now. Tell me if you experience any more problems. And thank you very much for finding the bug.

from dhcpoptinj.

i will try right away

from dhcpoptinj.

it seems to be working as expected
i will test more and report back
thank you so much

from dhcpoptinj.