ipcop-devel Mailing List for IPCop Firewall

G'day all,

I need to have dnsmasq send out a tftpserver address.
I don't think this change would be that hard, fo now I have just hacked  
the next-server data to spit out the tftpserver instead.

I could make the change and do a diff if that would help?

-- 
'ooroo

stinga...(:)-)
---------------------------------------------------
Email: st...@wo...      o
You need only two tools.        o /////
A hammer and duct tape. If it    /@   `\  /) ~
doesn't move and it should,     >  (O)  X<  ~  Fish!!
use the hammer. If it moves and  `\___/'  \) ~
shouldn't, use the tape.           \\\
---------------------------------------------------

----- Mail original -----
> De: "lilian test" <xel...@ho...>
> À: ipc...@li...
> Envoyé: Mercredi 18 Avril 2012 10:10:18
> Objet: [IPCop-devel]  Compil IPCop with last stable Kernel 3.3.2
> 
> 
> 
> Hello,
> I am newcomer in this mailing list and my english is'nt the best one
> ! Now i can begin :)
> 
> 
> I should like to compil IPCop with the last stable Kernel : 3.3.2
> (from http://kernel.org/ ).
> 
> 
> So for that I did :
> - Usual process to compile (
> http://sourceforge.net/apps/trac/ipcop/wiki/BuildingHowToV2 )
> - The uppgrade of the lfs (download link and checksum) :
> ./trunk/lfs/linux
> ./trunk/lfs/linux-headers
> 
> 
> So the "./make.sh prefetch" worked well .
> But I got a problem in "./make.sh build" : The compil blocked at
> "udev". And I didn't find the way to solve it...
> 
> 
...
> After that I did some search and I find your post (here below).
> 
> 
> 
> 
> 
> My question is :
> 
> 
> Is it possible to have the last stable Kernel and how ?
> 
> 
> Or is it not yet possible ?
> 
> 
> Thank you !
> Xel
> 
> 
> 

As you found, that would require kmod and recent udev (and unselecting systemd from udev build).
There has been extensive changes in this area. I haven't try yet.
Not undoable but for now I prefer to finish the work to make 2.1 ready.

- grep-2.12 will be published soon (I tested the last snapshot and haven't seen anything bad)
- procps-3.3.3 is long to arrive and should arrive soon too. I have still 7 w tests failures with last master snapshot, haven't yet reported nor looked what happen in the tests issues.
- cairo-1.12.0 give me much more tests failures than 1.10.2 (from 31 to 41) so I am a bit reluctant to upgrade as 1.12.0 has been announced to contain bug. I probably prefer to wait for 1.12.1
- pango-1.30.0 I had no issue but that require glib-2.32. I have both compiled and the test suite ok (with a bit more tweak for glib-2.32 test suite). I am really unsure that both upgrade are required for ipcop-2.1

I still need to upgrade the kernel to 3.0.28 and automake to 1.11.5 but issues there are unlikely.
Then I would cherry peek some glibc patches and that would be all I want to do there.

I still had some freetype hack tweaking to validate that mostly would reduce size.

Gilles

Hello,I am newcomer  in this mailing list and my english is'nt the best one ! Now i can begin :)I should like to compil IPCop with the last stable Kernel : 3.3.2 (from http://kernel.org/).So for that I did :  - Usual process to compile (http://sourceforge.net/apps/trac/ipcop/wiki/BuildingHowToV2)  - The uppgrade of the lfs (download link and checksum) :    ./trunk/lfs/linux    ./trunk/lfs/linux-headersSo the "./make.sh prefetch" worked well .But I got a problem in "./make.sh build" : The compil blocked at  "udev". And I didn't find the way to solve it...The error from log is :*****************************extras/v4l_id/v4l_id.c:31:28: error: linux/videodev.h: No such file or directoryextras/v4l_id/v4l_id.c: In function 'main':extras/v4l_id/v4l_id.c:42: error: storage size of 'v1cap' isn't knownextras/v4l_id/v4l_id.c:85: error: 'VIDIOCGCAP' undeclared (first use in this function)extras/v4l_id/v4l_id.c:85: error: (Each undeclared identifier is reported only onceextras/v4l_id/v4l_id.c:85: error: for each function it appears in.)make[3]: *** [extras/v4l_id/v4l_id.o] Error 1make[3]: *** Waiting for unfinished jobs....udev/udev-watch.c: In function 'udev_watch_begin':udev/udev-watch.c:124: warning: ignoring return value of 'symlink', declared with attribute warn_unused_resultudev/udev-event.c: In function 'udev_event_apply_format':udev/udev-event.c:377: warning: ignoring return value of 'asprintf', declared with attribute warn_unused_resultmake[2]: *** [all-recursive] Error 1make[1]: *** [all] Error 2make[1]: Leaving directory `/usr/src/udev-166'make: *** [/usr/src/files_i486/02_base/udev-166] Error 2*****************************After that I did some search and I find your post (here below).My question is :Is it possible to have the last stable Kernel and how ?Or is it not yet possible ?Thank you !Xel******************************************************************************************************************************Thinking more, I am unsure kmod should be on 2.1 release.

There has been some kernel changes related to kmod.
It is unlikely now those changes will be backported to kernel 3.0.

We should be able to live with last udev version before kmod,
module-init-tools-3.16 like everyone else do actually.
kmod should only be a target for us when switching to the next kernel after
3.0.x.

Gilles
***************************************************************What are the list of issues to change to the latest LINUX kernel?

Those of you who are not familiar with kmod here's an explanation from the
2ed of the LINUX device driver book from O'Reilly ...
http://www.xml.com/ldd/chapter/book/ch11.html#t1

*..."The idea behind kmod is simple, yet effective. Whenever the kernel
tries to access certain types of resources and finds them unavailable, it
makes a special kernel call to the kmod subsystem instead of simply
returning an error. If kmod succeeds in making the resource available by
loading one or more modules, the kernel continues working; otherwise, it
returns the error..."*


Here's more information from IBM Developer-Work about LINUX Kernel Modules,
LKMs...
http://ibm.co/8VOn2k

...or it is KMOD <http://www.kmod.com/main.html>, a radio station 97.5 in
Tulsa, Oklahoma USA whose racy front page tells you they know nothing about
the LINUX kernel ... and for that matter not much of anything.

Cheers,
John S Wolter
"We love LINUX we just have a funny way of saying it."


On Sun, Mar 4, 2012 at 9:10 AM, Gilles Espinasse <g.esp@...> wrote:

> Thinking more, I am unsure kmod should be on 2.1 release.
>
> There has been some kernel changes related to kmod.
> It is unlikely now those changes will be backported to kernel 3.0.
>
> We should be able to live with last udev version before kmod,
> module-init-tools-3.16 like everyone else do actually.
> kmod should only be a target for us when switching to the next kernel after
> 3.0.x.
>
> Gilles
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> IPCop-devel mailing list
> IPCop-devel@...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>



-- 
Cheers
John S Wolter***************************************************************On 2012-03-04 15:10, Gilles Espinasse wrote:
> Thinking more, I am unsure kmod should be on 2.1 release.

I tend to agree.

> There has been some kernel changes related to kmod.
> It is unlikely now those changes will be backported to kernel 3.0.
>
> We should be able to live with last udev version before kmod,
> module-init-tools-3.16 like everyone else do actually.
> kmod should only be a target for us when switching to the next kernel after
> 3.0.x.

I found changing udev to latest version requires (at least, more 
certainly to come) newer linux-headers, adding /run, make changes in our 
handling of networking interfaces since persistent net devices are gone. 
Our initramfs still does not properly boot after all that fixed.
So I'd be quite happy to stick with "older" udev version, and save all 
those changes to a later day.


Olaf***************************************************************Something we could consider is dropping floppy disk installation.


Olaf***************************************************************----- Original Message ----- 
From: john s wolter
To: IPCOP devel
Sent: Sunday, March 04, 2012 5:53 PM
Subject: Re: [IPCop-devel] kmod not for 2.1


> What are the list of issues to change to the latest LINUX kernel?
>
This is not our plan to switch to linux-3.2 or 3.3 yet.
The reason to change from 2.6.32 to 3.0 is that 2.6.32 start to be old.
So there is a decline in actual hardware support. We had to add some
external driver update again.
As Greg KH announced he will no more release 2.6.32 stable update (he will
probably be replaced), this is a good timing to switch.

Gilles****************************************************************************************************************************** 		 	   		  

Hi

I want to give support to Turkish translations.
What should I do for this.

-- 
www.ersanyildirim.com

Hi all,

I was facing a kernel crash this morning. I hope someone is able to
make something out of the attached last messages from the system log
prior to the crash (If someone wants it as a file I will send it
off-list):

09:35:57 kernel irq 10: nobody cared (try booting with the "irqpoll"
option) 
09:35:57 kernel Pid: 9243, comm: squid Not tainted 2.6.32-6 #1
09:35:57 kernel Call Trace:
09:35:57 kernel [<c1050982>] __report_bad_irq+0x3d/0x8f
09:35:57 kernel [<c1050acc>] note_interrupt+0xf8/0x164
09:35:57 kernel [<c104f4e3>] ? handle_IRQ_event+0x2f/0xb3
09:35:57 kernel [<c10512e9>] handle_level_irq+0x7b/0xcc
09:35:57 kernel [<c100550b>] handle_irq+0x2a/0x43
09:35:57 kernel [<c1004c7d>] do_IRQ+0x4d/0xb2
09:35:57 kernel [<c1003390>] common_interrupt+0x30/0x40
09:35:57 kernel [<c102d367>] ? __do_softirq+0x50/0x112
09:35:57 kernel [<c102d45d>] do_softirq+0x34/0x4b
09:35:57 kernel [<c102d570>] irq_exit+0x37/0x4a
09:35:57 kernel [<c1004cbd>] do_IRQ+0x8d/0xb2
09:35:57 kernel [<c1003390>] common_interrupt+0x30/0x40
09:35:57 kernel handlers:
09:35:57 kernel [<ce86ad4d>] (usb_hcd_irq+0x0/0x77 [usbcore])
09:35:57 kernel [<cebb6fb7>] (0xcebb6fb7)
09:35:57 kernel Disabling IRQ #10
09:36:30 kernel irq 11: nobody cared (try booting with the "irqpoll"
option) 
09:36:30 kernel Pid: 0, comm: swapper Not tainted 2.6.32-6 #1
09:36:30 kernel Call Trace:
09:36:30 kernel [<c1050982>] __report_bad_irq+0x3d/0x8f
09:36:30 kernel [<c1050acc>] note_interrupt+0xf8/0x164
09:36:30 kernel [<c104f4e3>] ? handle_IRQ_event+0x2f/0xb3
09:36:30 kernel [<c10512e9>] handle_level_irq+0x7b/0xcc
09:36:30 kernel [<c100550b>] handle_irq+0x2a/0x43
09:36:30 kernel [<c1004c7d>] do_IRQ+0x4d/0xb2
09:36:30 kernel [<c1003390>] common_interrupt+0x30/0x40
09:36:30 kernel [<c102d367>] ? __do_softirq+0x50/0x112
09:36:30 kernel [<c102d45d>] do_softirq+0x34/0x4b
09:36:30 kernel [<c102d570>] irq_exit+0x37/0x4a
09:36:30 kernel [<c1004cbd>] do_IRQ+0x8d/0xb2
09:36:30 kernel [<c1003390>] common_interrupt+0x30/0x40
09:36:30 kernel [<cec040cc>] ? acpi_processor_suspend+0x4f3/0x531
[processor] 
09:36:30 kernel [<c1164178>] cpuidle_idle_call+0x70/0xb4
09:36:30 kernel [<c1001e0d>] cpu_idle+0x8e/0xa5
09:36:30 kernel [<c11da7fb>] rest_init+0x6b/0x7e
09:36:30 kernel [<c12a49da>] start_kernel+0x2dc/0x2f2
09:36:30 kernel [<c12a40a5>] i386_start_kernel+0xa5/0xbd
09:36:30 kernel handlers:
09:36:30 kernel [<ce86ad4d>] (usb_hcd_irq+0x0/0x77 [usbcore])
09:36:30 kernel [<ce86ad4d>] (usb_hcd_irq+0x0/0x77 [usbcore])
09:36:30 kernel [<ceb99d0d>] (0xceb99d0d)
09:36:30 kernel [<cebb6fb7>] (0xcebb6fb7)
09:36:30 kernel Disabling IRQ #11
09:36:30 kernel GREEN REJECT IN=lan-1 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:19:d1:a1:94:61:08:00 SRC=192.168.2.81
DST=192.168.2.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=137 DPT=137 LEN=58 
09:37:27 kernel ------------[ cut here]------------ 
09:37:27 kernel WARNING: at net/sched/sch_generic.c:261
dev_watchdog+0xbf/0x14f() 
09:37:27 kernel Hardware name: VT8623-8235
09:37:27 kernel NETDEV WATCHDOG: wan-1 (r8169): transmit queue 0 timed
out 
09:37:27 kernel Modules linked in: nf_conntrack_netlink nfnetlink
act_police sch_ingress cls_u32 sch_sfq sch_htb xt_MARK ipt_MASQUERADE
ipt_REDIRECT ipt_REJECT xt_mark xt_TCPMSS xt_state ipt_LOG xt_limit
iptable_mangle iptable_filter nf_nat_pptp nf_nat_proto_gre
nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_irc nf_conntrack_irc
nf_nat_h323 nf_conntrack_h323 nf_nat_ftp nf_conntrack_ftp iptable_nat
ip_tables nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 fan
battery ac processor ide_cd_mod i2c_viapro r8169 via_rhine thermal
thermal_sys floppy mii cdrom hwmon i2c_core evdev bitrev button crc32
usb_storage sd_mod usbhid hid ohci_hcd ext3 mbcache jbd ide_gd_mod
pata_via ata_generic pata_acpi libata ide_pci_generic via82cxxx
ehci_hcd uhci_hcd usbcore ide_core pcspkr [last unloaded:
scsi_wait_scan] 
09:37:27 kernel Pid: 0, comm: swapper Not tainted 2.6.32-6 #1 09:37:27
kernel Call Trace: 
09:37:27 kernel [<c1028386>] warn_slowpath_common+0x70/0x98 
09:37:27 kernel [<c1186f07>] ? dev_watchdog+0xbf/0x14f 
09:37:27 kernel [<c102840d>] warn_slowpath_fmt+0x2f/0x43 
9:37:27 kernel [<c1186f07>] dev_watchdog+0xbf/0x14f 
09:37:27 kernel [<c1037bf8>] ? insert_work+0x50/0x69 
09:37:27 kernel [<c103814a>] ? __queue_work+0x37/0x4e 
09:37:27 kernel [<c103142b>] run_timer_softirq+0x11e/0x184 
09:37:27 kernel [<c1186e48>] ? dev_watchdog+0x0/0x14f 
09:37:27 kernel [<c102d39c>] __do_softirq+0x85/0x112 
09:37:27 kernel [<c102d45d>] do_softirq+0x34/0x4b 
09:37:27 kernel [<c102d570>] irq_exit+0x37/0x4a
09:37:27 kernel [<c1004cbd>] do_IRQ+0x8d/0xb2 
09:37:27 kernel [<c1003390>] common_interrupt+0x30/0x40 
09:37:27 kernel [<cec040cc>] ? acpi_processor_suspend+0x4f3/0x531
[processor] 
09:37:27 kernel [<c1164178>] cpuidle_idle_call+0x70/0xb4 
09:37:27 kernel [<c1001e0d>] cpu_idle+0x8e/0xa5 
09:37:27 kernel [<c11da7fb>] rest_init+0x6b/0x7e
09:37:27 kernel [<c12a49da>] start_kernel+0x2dc/0x2f2 
09:37:27 kernel [<c12a40a5>] i386_start_kernel+0xa5/0xbd 
09:37:27 kernel ---[ end trace abb683f71f21ba1c ]--- 
09:37:27 kernel RED DROP IN=wan-1 OUT=
MAC=00:19:5b:5b:ba:31:b0:c6:9a:60:c1:40:08:00 SRC=69.171.242.74
DST=90.184.69.179 LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=51949 DF
PROTO=TCP SPT=80 DPT=46440 WINDOW=0 RES=0x00 ACK RST URGP=0 
09:37:27 kernel r8169: wan-1: link up 
09:37:30 kernel GREEN REJECT IN=lan-1 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:19:d1:a1:94:61:08:00 SRC=192.168.2.81
DST=192.168.2.255 LEN=262 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=138 DPT=138 LEN=242 
09:37:59 kernel GREEN REJECT IN=lan-1 OUT=
MAC=00:40:63:d6:2c:63:aa:00:8b:7d:f8:77:08:00 SRC=192.168.2.2
DST=192.168.2.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=16182 PROTO=UDP
SPT=53 DPT=39124 LEN=42 
09:38:03 kernel r8169: wan-1: link up 
09:38:40 kernel GREEN REJECT IN=lan-1 OUT=
MAC=00:40:63:d6:2c:63:aa:00:8b:7d:f8:77:08:00 SRC=192.168.2.2
DST=192.168.2.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=16183 PROTO=UDP
SPT=53 DPT=39124 LEN=42 
09:38:55 kernel r8169: dmz-1: link up 
09:39:03 kernel r8169: wan-1: link up 
09:39:10 kernel GREEN REJECT IN=lan-1 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:08:02:95:74:d3:08:00 SRC=192.168.2.80
DST=192.168.2.255 LEN=260 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=138 DPT=138 LEN=240 
09:39:10 kernel GREEN REJECT IN=lan-1 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:08:02:95:74:d3:08:00 SRC=192.168.2.80
DST=192.168.2.255 LEN=237 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=138 DPT=138 LEN=217 
09:39:49 kernel ORANGE REJECT IN=dmz-1 OUT=
MAC=01:00:5e:00:00:01:f4:ec:38:bd:62:fd:08:00 SRC=0.0.0.0 DST=224.0.0.1
LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 
09:39:49 kernel r8169: dmz-1: link up

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

Bugs item #3516627, was opened at 2012-04-10 13:32
Message generated for change (Tracker Item Submitted) made by dhowdeshell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3516627&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: 2.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Howdeshell (dhowdeshell)
Assigned to: Nobody/Anonymous (nobody)
Summary: dnsmasq needs setting for upstream dns for local domain

Initial Comment:
This is my first entry on sourceforge and I'm not familiar with etiquette, so please forgive newbie mistakes.

A bugfix listed here https://sourceforge.net/tracker/index.php?func=detail&aid=2806823&group_id=40604&atid=428516 changes calls to the DNSMASQ daemon to use the `--local=$DOMAINNAME` switch that causes the service not to pass DNS queries to upstream servers for the local domain.

While this is a good default, some of us have our DNS configured properly with external servers and this option causes that external DNS to stop working within our network.  

I've confirmed that removing that option from /etc/rc.d/rc.dnsmasq OR commenting out `except-interface=wan-1' in /var/ipcop/dhcp/dnsmasq.conf both result in IPCop using upstream DNS for the local domain.  

An appropriate place to put such an option might be in /var/ipcop/dhcp/dnsmasq.local (since it is not supposed to be overwritten by updates) and when rc.dnsmasq loads the daemon it could parse that file to look for a 'always_use_upstream_dns=1' option.  

I don't know how these sort of things get worked out, but I could supply a patch file for rc.dnsmasq if that is what is expected. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3516627&group_id=40604