Re: udhcpc in 1.10.3 doesnt like my WLAN card
The problem seems to be that your wlan-card does not see/catch the dhcp-offer. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: My DHCPD server is: * Running under Linux Debian * version : Dhcp 2.0pl5-19.1 Is this a Debian sarge (oldstable) or woody (even older) distribution? I do no longer have access to anything like that. Did you check the non-working version with another dhcp-server? What arch are you using? I see no such problems when using Debian etch dhcp3-server 3.0.4-13, some misterious m$ dhcp server, dnsmasq various versions, udhcpd 0.9.8cvs20050303-2. Is the mac address 50:00:00:00:26:00 the real thing or just an obfuscation? Maybe that BPF filter should be made into an option. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
vi.c coredump
hi list, i can produce a nasty bug in vi. I noticed it first with 10.3 but it seems to be present in earlier versions. I can produce the bug this way: start vi goto insert mode select a screenfull of data with Xcursor clip data into vi crash Your mileage may vary; picking only a few data will cause no harm. btw: it is very unlikely that the problem is related to the compiler since it happens on my desktop and in the embedded (non x86) system. The following crash is with snapshot busybox-2008-03-04 Program received signal SIGSEGV, Segmentation fault. 0x08052895 in prev_line (p=0x0) at vi.c:1308 1308if (p[-1] == '\n' p text) re, wh ps: the .config is attached pps: i have reported the bug early because i guess that the cp approach may be used by more people. # # Automatically generated make config: don't edit # Busybox version: 1.11.0.svn # Thu Jun 19 15:25:06 2008 # CONFIG_HAVE_DOT_CONFIG=y # # Busybox Settings # # # General Configuration # # CONFIG_NITPICK is not set CONFIG_DESKTOP=y # CONFIG_FEATURE_BUFFERS_USE_MALLOC is not set # CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set # CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set CONFIG_SHOW_USAGE=y # CONFIG_FEATURE_VERBOSE_USAGE is not set CONFIG_FEATURE_COMPRESS_USAGE=y # CONFIG_FEATURE_INSTALLER is not set # CONFIG_LOCALE_SUPPORT is not set # CONFIG_GETOPT_LONG is not set # CONFIG_FEATURE_DEVPTS is not set # CONFIG_FEATURE_CLEAN_UP is not set # CONFIG_FEATURE_PIDFILE is not set # CONFIG_FEATURE_SUID is not set # CONFIG_FEATURE_SUID_CONFIG is not set # CONFIG_FEATURE_SUID_CONFIG_QUIET is not set # CONFIG_SELINUX is not set # CONFIG_FEATURE_PREFER_APPLETS is not set CONFIG_BUSYBOX_EXEC_PATH=/proc/self/exe # CONFIG_FEATURE_SYSLOG is not set # CONFIG_FEATURE_HAVE_RPC is not set # # Build Options # # CONFIG_STATIC is not set # CONFIG_NOMMU is not set # CONFIG_BUILD_LIBBUSYBOX is not set # CONFIG_FEATURE_INDIVIDUAL is not set # CONFIG_FEATURE_SHARED_BUSYBOX is not set # CONFIG_LFS is not set # # Debugging Options # CONFIG_DEBUG=y # CONFIG_WERROR is not set CONFIG_NO_DEBUG_LIB=y # CONFIG_DMALLOC is not set # CONFIG_EFENCE is not set # CONFIG_INCLUDE_SUSv2 is not set # # Installation Options # # CONFIG_INSTALL_NO_USR is not set CONFIG_INSTALL_APPLET_SYMLINKS=y # CONFIG_INSTALL_APPLET_HARDLINKS is not set # CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS is not set # CONFIG_INSTALL_APPLET_DONT is not set # CONFIG_INSTALL_SH_APPLET_SYMLINK is not set # CONFIG_INSTALL_SH_APPLET_HARDLINK is not set # CONFIG_INSTALL_SH_APPLET_SCRIPT_WRAPPER is not set CONFIG_PREFIX=./_install # # Busybox Library Tuning # CONFIG_PASSWORD_MINLEN=6 CONFIG_MD5_SIZE_VS_SPEED=2 # CONFIG_FEATURE_FAST_TOP is not set # CONFIG_FEATURE_ETC_NETWORKS is not set # CONFIG_FEATURE_EDITING is not set CONFIG_FEATURE_EDITING_MAX_LEN= # CONFIG_FEATURE_EDITING_VI is not set CONFIG_FEATURE_EDITING_HISTORY= # CONFIG_FEATURE_EDITING_SAVEHISTORY is not set # CONFIG_FEATURE_TAB_COMPLETION is not set # CONFIG_FEATURE_USERNAME_COMPLETION is not set # CONFIG_FEATURE_EDITING_FANCY_PROMPT is not set # CONFIG_FEATURE_VERBOSE_CP_MESSAGE is not set CONFIG_FEATURE_COPYBUF_KB=4 # CONFIG_MONOTONIC_SYSCALL is not set # CONFIG_IOCTL_HEX2STR_ERROR is not set # # Applets # # # Archival Utilities # # CONFIG_AR is not set # CONFIG_FEATURE_AR_LONG_FILENAMES is not set # CONFIG_BUNZIP2 is not set # CONFIG_BZIP2 is not set # CONFIG_CPIO is not set # CONFIG_FEATURE_CPIO_O is not set # CONFIG_DPKG is not set # CONFIG_DPKG_DEB is not set # CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set # CONFIG_GUNZIP is not set # CONFIG_FEATURE_GUNZIP_UNCOMPRESS is not set # CONFIG_GZIP is not set # CONFIG_RPM2CPIO is not set # CONFIG_RPM is not set # CONFIG_FEATURE_RPM_BZ2 is not set # CONFIG_TAR is not set # CONFIG_FEATURE_TAR_CREATE is not set # CONFIG_FEATURE_TAR_GZIP is not set # CONFIG_FEATURE_TAR_BZIP2 is not set # CONFIG_FEATURE_TAR_LZMA is not set # CONFIG_FEATURE_TAR_COMPRESS is not set # CONFIG_FEATURE_TAR_AUTODETECT is not set # CONFIG_FEATURE_TAR_FROM is not set # CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY is not set # CONFIG_FEATURE_TAR_OLDSUN_COMPATIBILITY is not set # CONFIG_FEATURE_TAR_GNU_EXTENSIONS is not set # CONFIG_FEATURE_TAR_LONG_OPTIONS is not set # CONFIG_FEATURE_TAR_UNAME_GNAME is not set # CONFIG_UNCOMPRESS is not set # CONFIG_UNLZMA is not set # CONFIG_FEATURE_LZMA_FAST is not set # CONFIG_UNZIP is not set # CONFIG_FEATURE_DEB_TAR_GZ is not set # CONFIG_FEATURE_DEB_TAR_BZ2 is not set # CONFIG_FEATURE_DEB_TAR_LZMA is not set # # Coreutils # # CONFIG_BASENAME is not set # CONFIG_CAL is not set # CONFIG_CAT is not set # CONFIG_CATV is not set # CONFIG_CHGRP is not set # CONFIG_CHMOD is not set # CONFIG_CHOWN is not set # CONFIG_CHROOT is not set # CONFIG_CKSUM is not set # CONFIG_COMM is not set # CONFIG_CP is not set # CONFIG_CUT is not set # CONFIG_DATE is not set # CONFIG_FEATURE_DATE_ISOFMT is not set # CONFIG_DD is not set # CONFIG_FEATURE_DD_SIGNAL_HANDLING is not set # CONFIG_FEATURE_DD_IBS_OBS
Re: vi.c coredump
Hi list,
some news about the bug: It is present at least in 1.9.1 maybe earlier
It happens in insert_char when ENABLE_FEATURE_VI_SETOPTS is set
p = stupid_insert(p, c);// insert the char
#if ENABLE_FEATURE_VI_SETOPTS
if (showmatch strchr()]}, *sp) != NULL) {
showmatching(sp);
}
if (autoindent c == '\n') { // auto indent the new line
char *q;
this code here assumes that is valid BUT /* please ignore the testcode */
if (p!=NULL) {
q = prev_line(p); // use prev line as templet
for (; isblank(*q); q++) {
p = stupid_insert(p, *q); // insert the
char
}
} else {
printf(eeek\n);
}
this is not true. stupid_insert() can return NULL (see:text_hole_make() error
path)
the crash can be prevented with if (autoindent c == '\n' !p ) but i
have no clue
what side effects that may have. Other occurrences of stupid_insert() should be
visited also.
re,
wh
ps: i am sorry i forget to add the backtrace last mail
walter harms wrote:
hi list,
i can produce a nasty bug in vi.
I noticed it first with 10.3 but it seems to be present in earlier versions.
I can produce the bug this way:
start vi
goto insert mode
select a screenfull of data with Xcursor
clip data into vi
crash
Your mileage may vary; picking only a few data will cause no harm.
btw: it is very unlikely that the problem is related to the compiler
since it happens on my desktop and in the embedded (non x86) system.
The following crash is with snapshot busybox-2008-03-04
Program received signal SIGSEGV, Segmentation fault.
0x08052895 in prev_line (p=0x0) at vi.c:1308
1308if (p[-1] == '\n' p text)
re,
wh
ps: the .config is attached
pps: i have reported the bug early because i guess that the cp approach may
be used
by more people.
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Ответ: MODPROBE: next generation
Hello! 1. Noone wants to bury existing modprobe. I mean a new format for intermediate data for an utility which will provide the same functionality but is planned to be smaller, faster and cleaner. Have you ever edited modules.dep or modules.symbols files manually? Guess no. And they are the vast majority of (potentially invariant) data which we have to parse expensively on every module operation. Why not to try to advance? Or, as they say, don't touch a sewing tube unless it leaks?! 2. BB depmod right now generates (having FEATURE_ALIAS defined, my case) modules.dep which can not be parsed correctly with BB modprobe. This is modprobe's issue. Since modprobe's maintaner is now offline the updates are blocked. How people who shifted from production to BB modutils (my case again) are supposed to cope this lockout? 3. What's wrong with BB sendmail? Please do request for feature if it does not fit your needs. Regards, -- Vladimir 2008/6/18, Natanael Copa [EMAIL PROTECTED]: On Tue, 2008-06-17 at 10:24 -0700, [EMAIL PROTECTED] wrote: I suggest to invent for BB a custom modules.dep format which bites all above issues. ... Comments? Please no. My alpine linux distro is based on uclibc/busybox. If hte busybox utility is not good enough for user, then it is possible to install the real utility that just overrides the busybox version. This requires that they behave similar. Otherwise scripts and things tend to break. (so far its only the sendmail applet that causes problems so i had to turn it off) So, please, continue make busybox compatible with POSIX/GNU standards. -nc ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: vi.c coredump
I looked into the other place where stupid_insert() and it guess they will
break also.
re
wh
walter harms wrote:
Hi list,
some news about the bug: It is present at least in 1.9.1 maybe earlier
It happens in insert_char when ENABLE_FEATURE_VI_SETOPTS is set
p = stupid_insert(p, c);// insert the char
#if ENABLE_FEATURE_VI_SETOPTS
if (showmatch strchr()]}, *sp) != NULL) {
showmatching(sp);
}
if (autoindent c == '\n') { // auto indent the new line
char *q;
this code here assumes that is valid BUT /* please ignore the testcode */
ups something missing: that p is valid (read != NULL )
if (p!=NULL) {
q = prev_line(p); // use prev line as templet
for (; isblank(*q); q++) {
p = stupid_insert(p, *q); // insert the
char
}
} else {
printf(eeek\n);
}
this is not true. stupid_insert() can return NULL (see:text_hole_make() error
path)
the crash can be prevented with if (autoindent c == '\n' !p ) but i
have no clue
what side effects that may have. Other occurrences of stupid_insert() should
be visited also.
re,
wh
ps: i am sorry i forget to add the backtrace last mail
walter harms wrote:
hi list,
i can produce a nasty bug in vi.
I noticed it first with 10.3 but it seems to be present in earlier versions.
I can produce the bug this way:
start vi
goto insert mode
select a screenfull of data with Xcursor
clip data into vi
crash
Your mileage may vary; picking only a few data will cause no harm.
btw: it is very unlikely that the problem is related to the compiler
since it happens on my desktop and in the embedded (non x86) system.
The following crash is with snapshot busybox-2008-03-04
Program received signal SIGSEGV, Segmentation fault.
0x08052895 in prev_line (p=0x0) at vi.c:1308
1308if (p[-1] == '\n' p text)
re,
wh
ps: the .config is attached
pps: i have reported the bug early because i guess that the cp approach may
be used
by more people.
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
MODPROBE: next generation
Made a proof-of-concept patch. It replaces standard depmod+modprobe sweet pair if config option simplified modutils is checked. 1482 octets in size for both (debug statements commented out). Uses the following format of modules.dep (draft 2) Consider a module named X located at P which depends on Y and Z, has aliases X1 and X2 and must be loaded with options O1 and O2. We could write this definition down as follows: --- X X1 X2 Y Z P O1 O2 --- If any of parts of definition is missed we simply use empty line as placeholder. modprobe by the moment can only load modules and runs in verbose mode to help debugging. Please, do find time to try and test! TIA, -- Vladimir modprobe.patch Description: Binary data ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet from us: 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: udhcp 1.10.3 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: My DHCPD server is: * Running under Linux Debian * version : Dhcp 2.0pl5-19.1 Is this a Debian sarge (oldstable) or woody (even older) distribution? I do no longer have access to anything like that. Did you check the non-working version with another dhcp-server? What arch are you using? I see no such problems when using Debian etch dhcp3-server 3.0.4-13, some misterious m$ dhcp server, dnsmasq various versions, udhcpd 0.9.8cvs20050303-2. Is the mac address 50:00:00:00:26:00 the real thing or just an obfuscation? Maybe that BPF filter should be made into an option. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! Read here: http://en.wikipedia.org/wiki/Ethernet Ethernet frame types and the EtherType field section. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Thu, 19 Jun 2008, Denys Vlasenko wrote: On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. Yes it is :) In tcpdump I see This is the packet from us: 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x) Right. and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x) Sure. The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. The application won't see it if the kernel (as instructed) will filter it out. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). We can't do better than assume the kernel is doing TRT. That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! That's still weird, wouldn't you say? Read here: http://en.wikipedia.org/wiki/Ethernet Ethernet frame types and the EtherType field section. I'll do that in a moment. But, until we get clever WRT that, to solve the current hickup, we should better do the BPF filter optional. We'd need a full trace to be able to find out if the frame types may be the cause. There's another thing I thought about: byte order. There could be something fishy there. I somehow got the impression the problem occured on a mips-arch, but let's wait for a confirmation. The BPF filter may have a bug, there may be a bug in the kernel too. I'll Bcc: the start of this thread to a couple of my collegues (much more knowledgeable than I am in this area) and see if they can make more sense out of it: http://busybox.net/lists/busybox/2008-June/031820.html and the file we're talking about: http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/networking/udhcp/clientsocket.c?rev=21487sortby=fileview=markup It's the 'raw_socket' function and the BPF filter there. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Thursday 19 June 2008 19:58:19 Denys Vlasenko wrote: On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet from us: and this is the reply: The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. Maybe that BPF filter should be made into an option. Or should be made to work with buggy Linux versions. Some kernels don't allow a packet length of -1 to pass the full packet. Instead use a large enough number for the packet, but small enough for BPF to work. I used 65535. http://bugs.gentoo.org/show_bug.cgi?id=215174 Thanks Roy ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
