6:48 a.m.
Although technically wireless SSIDs have to be alphanumeric, practically
speaking other "asciibetic" characters work fine in MS Windows and MacOS.
Therefore, people use them.
In multiple places I frequent (like, say, my house), iwlist scan will show
one or more SSIDs in the form of a URL, containing ":", ".", and
"/" characters. In these locations, NetworkManager crashes on startup.
Anyone else recognize this behavior?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:36 a.m.
Matthew Miller wrote:
Although technically wireless SSIDs have to be alphanumeric,
practically
speaking other "asciibetic" characters work fine in MS Windows and MacOS.
Therefore, people use them.
In multiple places I frequent (like, say, my house), iwlist scan will show
one or more SSIDs in the form of a URL, containing ":", ".", and
"/" characters. In these locations, NetworkManager crashes on startup.
Anyone else recognize this behavior?
I had this happen once while travelling on a train.
The Network manager applet crashed.
I could give you details if I knew where
bug buddy stores it's reports.
Pádraig.
8:04 a.m.
On Wed, 2007-09-05 at 07:48 -0400, Matthew Miller wrote:
Although technically wireless SSIDs have to be alphanumeric,
practically
speaking other "asciibetic" characters work fine in MS Windows and MacOS.
Therefore, people use them.
In multiple places I frequent (like, say, my house), iwlist scan will show
one or more SSIDs in the form of a URL, containing ":", ".", and
"/" characters. In these locations, NetworkManager crashes on startup.
Anyone else recognize this behavior?
I always had a '.' in my home SSID and never had a problem
(FC6/F7/Ubuntu)
Simo.
8:13 a.m.
On Wed, Sep 05, 2007 at 07:48:02AM -0400, Matthew Miller wrote:
Although technically wireless SSIDs have to be alphanumeric,
practically
speaking other "asciibetic" characters work fine in MS Windows and MacOS.
Therefore, people use them.
Actually 802.11 says SSID's are octet strings of
1-32 bytes, doesn't
have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug
and should be fixed (Showing unprintable chars using escape codes
to the user etc.)
--
Pekka Pietikainen
9:36 a.m.
On Wed, Sep 05, 2007 at 04:13:29PM +0300, Pekka Pietikainen wrote:
Actually 802.11 says SSID's are octet strings of 1-32 bytes,
doesn't
have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug
and should be fixed (Showing unprintable chars using escape codes
to the user etc.)
It's not even unprintable characters -- just punctuation.
I'm not 100% sure this is the problem, but it seems highly likely given that
the two places it reliably crashes are the two places iwlist scan shows
url-formatted ssids.
And yes, it's certainly a bug -- data literally *floating out there in the
air* should not crash any program.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
noon
On Wed, 2007-09-05 at 10:36 -0400, Matthew Miller wrote:
On Wed, Sep 05, 2007 at 04:13:29PM +0300, Pekka Pietikainen wrote:
> Actually 802.11 says SSID's are octet strings of 1-32 bytes, doesn't
> have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug
> and should be fixed (Showing unprintable chars using escape codes
> to the user etc.)
It's not even unprintable characters -- just punctuation.
I'm not 100% sure this is the problem, but it seems highly likely given that
the two places it reliably crashes are the two places iwlist scan shows
url-formatted ssids.
And yes, it's certainly a bug -- data literally *floating out there in the
air* should not crash any program.
Definitely. Can you get a backtrace of where it's crashing? It should
dump output to /var/log/messages, including a backtrace. If that
doesn't work, maybe hooking up to it with gdb would help.
Dan
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
11:40 p.m.
On Wed, Sep 05, 2007 at 01:00:44PM -0400, Dan Williams wrote:
Definitely. Can you get a backtrace of where it's crashing? It
should
dump output to /var/log/messages, including a backtrace. If that
doesn't work, maybe hooking up to it with gdb would help.
Here's the gdb backtrace from nm-applet:
Starting program: /usr/bin/nm-applet
[Thread debugging using libthread_db enabled]
[New process 2148]
[New Thread -1208629488 (LWP 2148)]
warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/ea/8072ce47bbe621338d7d78b5a928669ed731f1.debug
warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/43/f019db05b32979c7605a988adb185caa653649.debug
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208629488 (LWP 2148)]
0x0012d402 in __kernel_vsyscall ()
#0 0x0012d402 in __kernel_vsyscall ()
#1 0x00d46150 in *__GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x00d47a51 in *__GI_abort () at abort.c:88
#3 0x00be7db5 in _dbus_abort () at dbus-sysdeps.c:86
#4 0x00be3a46 in _dbus_warn_check_failed (
format=0xbf07a0 "arguments to %s() were incorrect, assertion \"%s\"
failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus
library.\n") at dbus-internals.c:283
#5 0x00bd7980 in dbus_message_new_method_call (
destination=0x806b2b8 "org.freedesktop.NetworkManager",
path=0x88a3ad0
"/org/freedesktop/NetworkManager/Devices/wlan0/Networks/http_3a_//mattdm_2e_org/wifi",
interface=0x806b620 "org.freedesktop.NetworkManager.Devices",
method=0x806b41d "getProperties") at dbus-message.c:1071
#6 0x080572f7 in nma_dbus_device_update_one_network (applet=0x8652020,
dev_path=0x88a7004 "/org/freedesktop/NetworkManager/Devices/wlan0",
net_path=0x0, active_net_path=0x88a7100 "") at applet-dbus-devices.c:630
#7 0x0805842d in nma_dbus_device_properties_cb (pcall=0x878ece8,
user_data=0x8652020) at applet-dbus-devices.c:831
#8 0x00bd9751 in _dbus_pending_call_complete (pending=0x878ece8)
at dbus-pending-call.c:198
#9 0x00bc9773 in complete_pending_call_and_unlock (connection=0x8789220,
pending=0x878ece8, message=<value optimized out>) at dbus-connection.c:2170
#10 0x00bcb369 in dbus_connection_dispatch (connection=0x8789220)
at dbus-connection.c:4296
#11 0x009fee7d in message_queue_dispatch (source=0x878b238, callback=0,
user_data=0x0) at dbus-gmain.c:101
#12 0x00c6817c in IA__g_main_context_dispatch (context=0x861b8f8)
at gmain.c:2061
#13 0x00c6b5bf in g_main_context_iterate (context=0x861b8f8, block=1,
dispatch=1, self=0x85f8498) at gmain.c:2694
#14 0x00c6b969 in IA__g_main_loop_run (loop=0x8650930) at gmain.c:2898
#15 0x0074e714 in IA__gtk_main () at gtkmain.c:1144
#16 0x0804efa1 in main (argc=Cannot access memory at address 0x864
) at main.c:67
#17 0x00d330f0 in __libc_start_main (main=0x804ee80 <main>, argc=1,
ubp_av=0xbf95a974, init=0x8069340 <__libc_csu_init>,
fini=0x8069330 <__libc_csu_fini>, rtld_fini=0x11e560 <_dl_fini>,
stack_end=0xbf95a96c) at libc-start.c:220
#18 0x0804edc1 in _start ()
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:26 a.m.
On Wed, 2007-09-05 at 16:13 +0300, Pekka Pietikainen wrote:
Actually 802.11 says SSID's are octet strings of 1-32 bytes,
doesn't
have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug
and should be fixed (Showing unprintable chars using escape codes
to the user etc.)
Shouldn't those octet character strings be converted to Unicode strings,
anyway? I thought that Gtk (via Pango) had displaying international
character down pat.
I remember seeing unprintable characters in the SSID field once (or was
it the network name field? I forget. I thought it was a bug). I think it
was U+0000 so that really doesn't tell me whether a proper 8-bit
ASCII->Unicode (UTF-8?) conversion was made.
--
Richi Plana
11:44 a.m.
On 9/5/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
On Wed, 2007-09-05 at 16:13 +0300, Pekka Pietikainen wrote:
> Actually 802.11 says SSID's are octet strings of 1-32 bytes, doesn't
> have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug
> and should be fixed (Showing unprintable chars using escape codes
> to the user etc.)
Shouldn't those octet character strings be converted to Unicode strings,
anyway? I thought that Gtk (via Pango) had displaying international
character down pat.
In order to "convert octet character strings" into Unicode and display
them, you have to know what encoding the strings are in. Bytes are
just bytes until you have an encoding.
- Owen
11:55 a.m.
On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote:
> Shouldn't those octet character strings be converted to
Unicode strings,
> anyway? I thought that Gtk (via Pango) had displaying international
> character down pat.
In order to "convert octet character strings" into Unicode and display
them, you have to know what encoding the strings are in. Bytes are
just bytes until you have an encoding.
I was under the assumption they were 8-bit ASCII strings. Anyway, it's a
NetworkManager issue. They would know what the drivers are returning,
right?
--
Richi Plana
11:59 a.m.
On Wed, 2007-09-05 at 10:55 -0600, Richi Plana wrote:
On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote:
> > Shouldn't those octet character strings be converted to Unicode strings,
> > anyway? I thought that Gtk (via Pango) had displaying international
> > character down pat.
>
> In order to "convert octet character strings" into Unicode and display
> them, you have to know what encoding the strings are in. Bytes are
> just bytes until you have an encoding.
I was under the assumption they were 8-bit ASCII strings. Anyway, it's a
NetworkManager issue. They would know what the drivers are returning,
right?
Right; it is an NM issue. If NM crashes or misbehaves with a weird
SSID, we need to fix it.
As specified in the 802.11 standard, the ESSID is a 32-byte byte array,
there are no restrictions made as to what content that 32-bytes may
contain. It is up to the program to attempt to coerce that value into
something to present to the user.
Dan
12:15 p.m.
On Wed, 2007-09-05 at 12:59 -0400, Dan Williams wrote:
Right; it is an NM issue. If NM crashes or misbehaves with a weird
SSID, we need to fix it.
As specified in the 802.11 standard, the ESSID is a 32-byte byte array,
there are no restrictions made as to what content that 32-bytes may
contain. It is up to the program to attempt to coerce that value into
something to present to the user.
Since no semantics has been proposed, then it stands to reason that one
can just assume 1 byte = 1 character and a straight "byte value =
Unicode value" conversion should be adopted, right? (No codepage
conversions).
Come to think of it, if they're just a generic 32-byte byte array, why
even convert them to strings? They only make sense if they happen to
contain alphanumeric and some symbolic characters (which isn't even a
convention or restriction). Alright, maybe it's useful for displaying to
humans when they just happen to be alphanumeric. Forget I asked.
--
Richi Plana
12:49 p.m.
On Wed, 2007-09-05 at 11:15 -0600, Richi Plana wrote:
On Wed, 2007-09-05 at 12:59 -0400, Dan Williams wrote:
> Right; it is an NM issue. If NM crashes or misbehaves with a weird
> SSID, we need to fix it.
>
> As specified in the 802.11 standard, the ESSID is a 32-byte byte array,
> there are no restrictions made as to what content that 32-bytes may
> contain. It is up to the program to attempt to coerce that value into
> something to present to the user.
Since no semantics has been proposed, then it stands to reason that one
can just assume 1 byte = 1 character and a straight "byte value =
Unicode value" conversion should be adopted, right? (No codepage
conversions).
Come to think of it, if they're just a generic 32-byte byte array, why
even convert them to strings? They only make sense if they happen to
contain alphanumeric and some symbolic characters (which isn't even a
convention or restriction). Alright, maybe it's useful for displaying to
humans when they just happen to be alphanumeric. Forget I asked.
Well, it's a really tricky problem. I'd personally do:
try UTF-8 validation
try validation from the encoding in LANG
fall back to a lot of ? for unprintables
For example, if I live in Shanghai, I should be able to make my AP SSID
some native character like 虚. However, if I live in Central Europoe
and for some reason I use ISO 8859-15 (or whatever it is) I'd probably
like my ň to show up. I believe NM should try at least a few ways of
parsing the SSID (not too many) and just fall back to ? in the end.
This is what it currently does, but apparently somewhat badly.
Dan
1 p.m.
On Wed, 2007-09-05 at 13:49 -0400, Dan Williams wrote:
try UTF-8 validation
UTF-8 validation is easy, but it would've been easierhad they actually
put in the BOM character, :).
try validation from the encoding in LANG
Pretty slim chances that whoever configured the wireless network is
using the same encoding as whoever configured LANG.
fall back to a lot of ? for unprintables
Either that or use "byte value = unicode value" (ie. 0x01 = , 0x7F = ,
0x80 = , 0xFF = ÿ, etc.) and let Pango render the characters (to at
least differentiate the characters from each other and from the "?"
character).
For example, if I live in Shanghai, I should be able to make my AP
SSID
some native character like 虚. However, if I live in Central Europoe
and for some reason I use ISO 8859-15 (or whatever it is) I'd probably
like my ň to show up. I believe NM should try at least a few ways of
parsing the SSID (not too many) and just fall back to ? in the end.
This is what it currently does, but apparently somewhat badly.
Or go upstream and have IEEE settle it, :-p.
--
Richi Plana
7:42 a.m.
On Fri, Sep 07, 2007 at 01:45:18PM +0200, Krzysztof Halasa wrote:
Dan Williams <dcbw(a)redhat.com> writes:
> Well, it's a really tricky problem. I'd personally do:
> try UTF-8 validation
> try validation from the encoding in LANG
> fall back to a lot of ? for unprintables
Perhaps asking the user for encoding would make sense.
Where would one ask?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:51 a.m.
Guys, this thread is a lot more appropriate on a Bugzilla. Say, here:
http://bugzilla.gnome.org/show_bug.cgi?id=474543
(spotted at least one bug from your backtrace that's probably causing the
crash; the encoding issue is a whole other set to which Owen's reply is the
best)
8:30 a.m.
On Fri, Sep 07, 2007 at 08:51:30AM -0400, Colin Walters wrote:
Guys, this thread is a lot more appropriate on a Bugzilla. Say,
here:
I hate to clutter up bugzilla with vague bugs. It's not helpful for anyone.
I wanted to narrow things down first.
<https://bugzilla.redhat.com/show_bug.cgi?id=281071>
(spotted at least one bug from your backtrace that's probably
causing the
crash; the encoding issue is a whole other set to which Owen's reply is the
best)
The crash is, however, *very* related to the encoding issue, because the
assumed ascii string encoding is used not only for display but as the
internal representation passed around in the program.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:32 a.m.
On 9/7/07, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Fri, Sep 07, 2007 at 08:51:30AM -0400, Colin Walters wrote:
> Guys, this thread is a lot more appropriate on a Bugzilla. Say, here:
I hate to clutter up bugzilla with vague bugs. It's not helpful for anyone.
I wanted to narrow things down first.
> http://bugzilla.gnome.org/show_bug.cgi?id=474543
<https://bugzilla.redhat.com/show_bug.cgi?id=281071>
> (spotted at least one bug from your backtrace that's probably causing the
> crash; the encoding issue is a whole other set to which Owen's reply is the
> best)
The crash is, however, *very* related to the encoding issue, because the
assumed ascii string encoding is used not only for display but as the
internal representation passed around in the program.
I'd consider the two things actually quite distinct:
* D-BUS object path: you want a *unique* *consistent* representation of the
bytes of the ESSID. So you might, say, treat them as bytes and do URI-style
%XY escaping of bytes that aren't legal ascii characters in the context
* Display to the user: you want to make a best guess at the encoding and try
to display the exact same thing that someone typed into the router
configuration,
rather some unique-but-looks-like-garbage escaped version.
- Owen
9:46 a.m.
On Fri, 2007-09-07 at 10:32 -0400, Owen Taylor wrote:
I'd consider the two things actually quite distinct:
* D-BUS object path: you want a *unique* *consistent* representation of the
bytes of the ESSID. So you might, say, treat them as bytes and do URI-style
%XY escaping of bytes that aren't legal ascii characters in the context
+1. It's so easy with computers. Just set a standard (URI specification)
and it starts to make sense everywhere. If we assume that no human will
look at the D-BUS object path except likely the developers, then you can
just adopt whatever's convenient for the devs. ASCII characters seem to
be common for them.
* Display to the user: you want to make a best guess at the encoding
and try
to display the exact same thing that someone typed into the router
configuration,
rather some unique-but-looks-like-garbage escaped version.
At least with documents, there's a lot of heuristic to work on to make
sense (encoding) of the the data. With ESSIDs, you're limited to
32-bytes and aren't even quite sure that they were meant to be treated
as text.
I don't envy the team tasked to design the algorithm for this, but I'm
guessing first, they've to determine if it's supposed to be
human-readable (0x00 bytes interspersed between non nulls is one
indication). Otherwise, re-use some existing code to determine encoding.
P.S. As much as I love reading about this issue, it probably does belong
to a NetworkManager / nm-applet bugzilla or forum.
--
Richi Plana
10:06 a.m.
On Fri, 2007-09-07 at 10:32 -0400, Owen Taylor wrote:
On 9/7/07, Matthew Miller <mattdm(a)mattdm.org> wrote:
> On Fri, Sep 07, 2007 at 08:51:30AM -0400, Colin Walters wrote:
> > Guys, this thread is a lot more appropriate on a Bugzilla. Say, here:
>
> I hate to clutter up bugzilla with vague bugs. It's not helpful for anyone.
> I wanted to narrow things down first.
>
> > http://bugzilla.gnome.org/show_bug.cgi?id=474543
>
> <https://bugzilla.redhat.com/show_bug.cgi?id=281071>
>
> > (spotted at least one bug from your backtrace that's probably causing the
> > crash; the encoding issue is a whole other set to which Owen's reply is
the
> > best)
>
> The crash is, however, *very* related to the encoding issue, because the
> assumed ascii string encoding is used not only for display but as the
> internal representation passed around in the program.
I'd consider the two things actually quite distinct:
* D-BUS object path: you want a *unique* *consistent* representation of the
bytes of the ESSID. So you might, say, treat them as bytes and do URI-style
%XY escaping of bytes that aren't legal ascii characters in the context
The decision to use the SSID as part of the D-Bus object path was
insanely wrong, which is of course clear now 3 years later :) Rectified
with 0.7, we may be able to fix it in 0.6.5 too since object paths are
essentially just pointers and are opaque.
Dan
* Display to the user: you want to make a best guess at the encoding
and try
to display the exact same thing that someone typed into the router
configuration,
rather some unique-but-looks-like-garbage escaped version.
- Owen
12:25 p.m.
On Fri, 2007-09-07 at 11:06 -0400, Dan Williams wrote:
The decision to use the SSID as part of the D-Bus object path was
insanely wrong, which is of course clear now 3 years later :) Rectified
with 0.7, we may be able to fix it in 0.6.5 too since object paths are
essentially just pointers and are opaque.
Agree. Was wondering about why the SSID was made a part of the D-BUS
object path to begin with. What was used in 0.7 to uniquely identify?
--
Richi Plana
1:23 p.m.
On Fri, Sep 07, 2007 at 11:06:28AM -0400, Dan Williams wrote:
The decision to use the SSID as part of the D-Bus object path was
insanely wrong, which is of course clear now 3 years later :) Rectified
with 0.7, we may be able to fix it in 0.6.5 too since object paths are
essentially just pointers and are opaque.
So, theoretically if I install 0.7.0-0.1.svn2736.fc8 outta koji everything
will be solved?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
5:43 p.m.
On Fri, Sep 07, 2007 at 02:23:19PM -0400, Matthew Miller wrote:
> The decision to use the SSID as part of the D-Bus object path
was
> insanely wrong, which is of course clear now 3 years later :) Rectified
> with 0.7, we may be able to fix it in 0.6.5 too since object paths are
> essentially just pointers and are opaque.
So, theoretically if I install 0.7.0-0.1.svn2736.fc8 outta koji everything
will be solved?
The answer is no: that one doesn't work at all. :)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
12:23 p.m.
On Fri, Sep 07, 2007 at 10:32:15AM -0400, Owen Taylor wrote:
> The crash is, however, *very* related to the encoding issue,
because the
> assumed ascii string encoding is used not only for display but as the
> internal representation passed around in the program.
I'd consider the two things actually quite distinct:
Right; but right now they're not treated that way at all. So in a way,
that's the bug.
* D-BUS object path: you want a *unique* *consistent* representation
of the
bytes of the ESSID. So you might, say, treat them as bytes and do URI-style
%XY escaping of bytes that aren't legal ascii characters in the context
Which it *almost* does -- the ":" in my example is escaped somewhere along
the line.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
11:41 a.m.
Krzysztof Halasa wrote:
Dan Williams <dcbw(a)redhat.com> writes:
> Well, it's a really tricky problem. I'd personally do:
>
> try UTF-8 validation
> try validation from the encoding in LANG
> fall back to a lot of ? for unprintables
Perhaps asking the user for encoding would make sense.
The whole point of NetworkManager is to just work. Asking the user for
anything is not something that should be done unless it is absolutely
necessary, and the user can be expected to know it.
Asking for encryption keys is a valid thing to ask. Asking the user to
be able to know encodings is just insane. Even I don't know what
encoding most things fall into.
4:50 p.m.
On Wed, Sep 05, 2007 at 01:49:47PM -0400, Dan Williams wrote:
some native character like ???. However, if I live in Central
Europoe
and for some reason I use ISO 8859-15 (or whatever it is) I'd probably
Depends where, but ISO-8859-* are essentially obsolete for europe in favour
of Unicode.
2:27 p.m.
On 9/5/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
On Wed, 2007-09-05 at 12:59 -0400, Dan Williams wrote:
> Right; it is an NM issue. If NM crashes or misbehaves with a weird
> SSID, we need to fix it.
>
> As specified in the 802.11 standard, the ESSID is a 32-byte byte array,
> there are no restrictions made as to what content that 32-bytes may
> contain. It is up to the program to attempt to coerce that value into
> something to present to the user.
Since no semantics has been proposed, then it stands to reason that one
can just assume 1 byte = 1 character and a straight "byte value =
Unicode value" conversion should be adopted, right? (No codepage
conversions).
That would be ISO-8859-1 encoding since Unicode < U+00FF is equal to ISO-8859-1.
Come to think of it, if they're just a generic 32-byte byte
array, why
even convert them to strings? They only make sense if they happen to
contain alphanumeric and some symbolic characters (which isn't even a
convention or restriction). Alright, maybe it's useful for displaying to
humans when they just happen to be alphanumeric. Forget I asked.
- Ian
3:11 p.m.
>>>> "RP" == Richi Plana
<myfedora(a)richip.dhs.org> writes:
RP> Since no semantics has been proposed, then it stands to reason
RP> that one can just assume 1 byte = 1 character and a straight "byte
RP> value = Unicode value" conversion should be adopted, right? (No
RP> codepage conversions).
Those two are incompatible. If you have 1 byte = 1 character, then
you're not using Unicode (ok, you could be doing UTF-8 without any
high bits set, but that's better known as ASCII).
/Benny
3:39 p.m.
On Wed, 2007-09-05 at 22:11 +0200, Benny Amorsen wrote:
>>>>> "RP" == Richi Plana
<myfedora(a)richip.dhs.org> writes:
RP> Since no semantics has been proposed, then it stands to reason
RP> that one can just assume 1 byte = 1 character and a straight "byte
RP> value = Unicode value" conversion should be adopted, right? (No
RP> codepage conversions).
Those two are incompatible. If you have 1 byte = 1 character, then
you're not using Unicode (ok, you could be doing UTF-8 without any
high bits set, but that's better known as ASCII).
Sorry. I have to remind myself that when I write, I shouldn't leave any
room for misinterpretation.
What I meant was that for character lengths, we can assume a fixed width
of 1 byte. And for the Unicode values, we just assume the byte value.
And as Ian mentioned in a previous post, apparently that's exactly what
ISO-8859-1 is so scrap any explanation I gave and let's just say
ISO-8859-1, :).
--
Richi Plana
1:57 p.m.
On 9/5/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote:
> > Shouldn't those octet character strings be converted to Unicode strings,
> > anyway? I thought that Gtk (via Pango) had displaying international
> > character down pat.
>
> In order to "convert octet character strings" into Unicode and display
> them, you have to know what encoding the strings are in. Bytes are
> just bytes until you have an encoding.
I was under the assumption they were 8-bit ASCII strings.
There's actually no 8-bit ASCII. People sometimes use that to mean
Windows codepage 1252
(http://en.wikipedia.org/wiki/Windows_code_page).
Anyway, it's a NetworkManager issue. They would know what the
drivers are returning,
right?
The drivers may well just be returning whatever bytes were sent over
the wire. Now, in any *sane* protocol, the protocol docs would define
what encoding the bytes over the wire are in, but it took a very long
time for people to realize this, so it wouldn't shock me if 802.11b
doesn't specify. Then you'd basically have to do experiments with
common access points to see how they encode things, then add
appropriate heuristics to NetworkManager.
- Owen
2:06 p.m.
On Wed, 2007-09-05 at 14:57 -0400, Owen Taylor wrote:
On 9/5/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
> On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote:
> > > Shouldn't those octet character strings be converted to Unicode
strings,
> > > anyway? I thought that Gtk (via Pango) had displaying international
> > > character down pat.
> >
> > In order to "convert octet character strings" into Unicode and
display
> > them, you have to know what encoding the strings are in. Bytes are
> > just bytes until you have an encoding.
>
> I was under the assumption they were 8-bit ASCII strings.
There's actually no 8-bit ASCII. People sometimes use that to mean
Windows codepage 1252
(http://en.wikipedia.org/wiki/Windows_code_page).
> Anyway, it's a NetworkManager issue. They would know what the drivers are
returning,
> right?
The drivers may well just be returning whatever bytes were sent over
the wire. Now, in any *sane* protocol, the protocol docs would define
what encoding the bytes over the wire are in, but it took a very long
time for people to realize this, so it wouldn't shock me if 802.11b
doesn't specify. Then you'd basically have to do experiments with
common access points to see how they encode things, then add
appropriate heuristics to NetworkManager.
The drivers return a 32-byte array containing arbitrary values to
NetworkManager, which is technically correct. It's up to NM and
userspace to deal with this somehow. 802.11 specifies nothing about
encoding or anything other than a max length of 32 bytes.
Dan
3:44 p.m.
On Wed, 2007-09-05 at 15:06 -0400, Dan Williams wrote:
The drivers return a 32-byte array containing arbitrary values to
NetworkManager, which is technically correct. It's up to NM and
userspace to deal with this somehow. 802.11 specifies nothing about
encoding or anything other than a max length of 32 bytes.
Right-o. And it's probably only chance coincidence that most wireless
dev manufacturers allowed text input for the ESSID (or maybe it was a
common stroke of brilliance).
At any rate, because of a lack of specification, we have to deal with
partial chaos (a recurring theme. Yay well-written specs!).
--
Richi Plana
4:01 p.m.
On Wed, 2007-09-05 at 14:44 -0600, Richi Plana wrote:
On Wed, 2007-09-05 at 15:06 -0400, Dan Williams wrote:
> The drivers return a 32-byte array containing arbitrary values to
> NetworkManager, which is technically correct. It's up to NM and
> userspace to deal with this somehow. 802.11 specifies nothing about
> encoding or anything other than a max length of 32 bytes.
Right-o. And it's probably only chance coincidence that most wireless
dev manufacturers allowed text input for the ESSID (or maybe it was a
common stroke of brilliance).
At any rate, because of a lack of specification, we have to deal with
partial chaos (a recurring theme. Yay well-written specs!).
Yeah and also keep in mind that if they are 32bytes with anything
inside, you can find also embedded NULLs, so NM should cope with that
too in theory.
This would be valid I guess:
EVIL\0\0SSID\0\0HERE\0\0\0\0\0\0\0\0\0\0\0\0\0\032
Simo.
4:06 p.m.
On Wed, 2007-09-05 at 17:01 -0400, Simo Sorce wrote:
Yeah and also keep in mind that if they are 32bytes with anything
inside, you can find also embedded NULLs, so NM should cope with that
too in theory.
This would be valid I guess:
EVIL\0\0SSID\0\0HERE\0\0\0\0\0\0\0\0\0\0\0\0\0\032
Right! Good catch. There goes Unicode. As far as I remember, U+0000 does
not exist. And even if it did exist, to accurately capture the ESSID,
you'd end up with a string that's 32 characters long _all the time_.
--
Richi Plana
12:01 p.m.
On Wed, 2007-09-05 at 07:48 -0400, Matthew Miller wrote:
Although technically wireless SSIDs have to be alphanumeric,
practically
speaking other "asciibetic" characters work fine in MS Windows and MacOS.
Therefore, people use them.
In multiple places I frequent (like, say, my house), iwlist scan will show
one or more SSIDs in the form of a URL, containing ":", ".", and
"/" characters. In these locations, NetworkManager crashes on startup.
Anyone else recognize this behavior?
RPM versions, kernel version, wpa_supplicant version, and any changes
you may have made to drivers or whatever could help. Also, was it NM,
or the applet that died?
Dan
9:34 p.m.
On Wed, Sep 05, 2007 at 01:01:45PM -0400, Dan Williams wrote:
> Anyone else recognize this behavior?
RPM versions, kernel version, wpa_supplicant version, and any changes
you may have made to drivers or whatever could help. Also, was it NM,
or the applet that died?
Originally NM itself. But see below...
This is rawhide; it's been happening since Fedora 7-era or so, but it just
dawned on me what the cause of the problem is. Or likely is -- I haven't
actually proved it yet. Currently, NetworkManager 0.6.5-9.fc8, kernel
2.6.23-0.164.rc5.fc8, and wpa_supplicant-0.5.7-7. I'm using the stock
orinoco_pci driver.
In the last couple of days (weeks?) NM doesn't completely die, but instead
logs crashy sorts of things while nm-applet vanishes and can't be restarted.
There's backtraces like this in /var/log/messages, but I'm not exactly sure
what's
going on when they appear. (Note: see below the log message for more text.)
Sep 3 11:37:16 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Sep 3 11:37:17 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1
Sep 3 11:41:26 ylla NetworkManager: <WARN> nm_hal_deinit(): libhal shutdown failed
- Connection is closed
Sep 3 11:41:26 ylla NetworkManager: <WARN> nm_signal_handler(): Caught signal 11.
Generating backtrace...
Sep 3 11:41:26 ylla NetworkManager: <info> Successfully reconnected to the system
bus.
Sep 3 11:41:27 ylla NetworkManager: ******************* START
**********************************
Sep 3 11:41:28 ylla NetworkManager: (no debugging symbols found)
Sep 3 11:41:29 ylla NetworkManager: Using host libthread_db library
"/lib/libthread_db.so.1".
Sep 3 11:41:29 ylla NetworkManager: (no debugging symbols found)
Sep 3 11:41:29 ylla NetworkManager:last message repeated 12 times
Sep 3 11:41:29 ylla NetworkManager: [Thread debugging using libthread_db enabled]
Sep 3 11:41:29 ylla NetworkManager: [New Thread -1208538624 (LWP 1909)]
Sep 3 11:41:29 ylla NetworkManager: [New Thread -1208542320 (LWP 15022)]
Sep 3 11:41:29 ylla NetworkManager: [New Thread -1219032176 (LWP 15019)]
Sep 3 11:41:29 ylla NetworkManager: [New Thread -1229522032 (LWP 2139)]
Sep 3 11:41:29 ylla NetworkManager: (no debugging symbols found)
Sep 3 11:41:29 ylla NetworkManager:last message repeated 6 times
Sep 3 11:41:29 ylla NetworkManager: 0x0012d402 in __kernel_vsyscall ()
Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall ()
Sep 3 11:41:29 ylla NetworkManager: #1 0x0035b47b in waitpid () from
/lib/libpthread.so.0
Sep 3 11:41:29 ylla NetworkManager: #2 0x0806d3b0 in ?? ()
Sep 3 11:41:29 ylla NetworkManager: #3 0x0806d4a1 in ?? ()
Sep 3 11:41:29 ylla NetworkManager: #4 <signal handler called>
Sep 3 11:41:29 ylla NetworkManager: #5 0x08056147 in nm_get_device_by_iface ()
Sep 3 11:41:29 ylla NetworkManager: #6 0x0807bb9f in nm_dhcp_manager_process_signal ()
Sep 3 11:41:29 ylla NetworkManager: #7 0x0805faed in ?? ()
Sep 3 11:41:29 ylla NetworkManager: #8 0x001bc664 in dbus_connection_dispatch () from
/lib/libdbus-1.so.3
Sep 3 11:41:29 ylla NetworkManager: #9 0x00198e7d in ?? () from
/usr/lib/libdbus-glib-1.so.2
Sep 3 11:41:29 ylla NetworkManager: #10 0x0025917c in g_main_context_dispatch () from
/lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: #11 0x0025c5bf in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: #12 0x0025c969 in g_main_loop_run () from
/lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: #13 0x080693c8 in main ()
Sep 3 11:41:29 ylla NetworkManager:
Sep 3 11:41:29 ylla NetworkManager: Thread 4 (Thread -1229522032 (LWP 2139)):
Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall ()
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #1 0x0035a52b in read () from /lib/libpthread.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #2 0x0025a11d in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #3 0x0027c77f in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #4 0x0035353b in start_thread () from
/lib/libpthread.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #5 0x004380ee in clone () from /lib/libc.so.6
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager:
Sep 3 11:41:29 ylla NetworkManager: Thread 3 (Thread -1219032176 (LWP 15019)):
Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall ()
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #1 0x0042e053 in poll () from /lib/libc.so.6
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #2 0x0025c5f3 in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #3 0x0025c969 in g_main_loop_run () from
/lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #4 0x0805696e in ?? ()
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #5 0x0027c77f in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #6 0x0035353b in start_thread () from
/lib/libpthread.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #7 0x004380ee in clone () from /lib/libc.so.6
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager:
Sep 3 11:41:29 ylla NetworkManager: Thread 2 (Thread -1208542320 (LWP 15022)):
Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall ()
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #1 0x0042e053 in poll () from /lib/libc.so.6
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #2 0x0025c5f3 in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #3 0x0025c969 in g_main_loop_run () from
/lib/libglib-2.0.so.0
Sep 3 11:41:29 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:29 ylla NetworkManager: #4 0x0805696e in ?? ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #5 0x0027c77f in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #6 0x0035353b in start_thread () from
/lib/libpthread.so.0
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #7 0x004380ee in clone () from /lib/libc.so.6
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager:
Sep 3 11:41:30 ylla NetworkManager: Thread 1 (Thread -1208538624 (LWP 1909)):
Sep 3 11:41:30 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #1 0x0035b47b in waitpid () from
/lib/libpthread.so.0
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #2 0x0806d3b0 in ?? ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #3 0x0806d4a1 in ?? ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #4 <signal handler called>
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #5 0x08056147 in nm_get_device_by_iface ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #6 0x0807bb9f in nm_dhcp_manager_process_signal ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #7 0x0805faed in ?? ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #8 0x001bc664 in dbus_connection_dispatch () from
/lib/libdbus-1.so.3
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #9 0x00198e7d in ?? () from
/usr/lib/libdbus-glib-1.so.2
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #10 0x0025917c in g_main_context_dispatch () from
/lib/libglib-2.0.so.0
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #11 0x0025c5bf in ?? () from /lib/libglib-2.0.so.0
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #12 0x0025c969 in g_main_loop_run () from
/lib/libglib-2.0.so.0
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #13 0x080693c8 in main ()
Sep 3 11:41:30 ylla NetworkManager: No symbol table info available.
Sep 3 11:41:30 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall ()
Sep 3 11:41:30 ylla NetworkManager: The program is running. Quit anyway (and detach it)?
(y or n) [answered Y; input not from terminal]
Sep 3 11:41:30 ylla NetworkManager: ******************* END
**********************************
Just now, when I rebooted to try to generate a nice clean log of the problem
under a semi-controlled environment, everything came up apparently fine and
working. (First time ever at my house.) Then I realized that for whatever
reason, iwlist scan wasn't showing the URL SSID. So I moved around the house
until it showed up -- and boom, there goes nm-applet.
When I try to restart nm-applet, I get this error (familiar to me from the
times nm-applet isn't even there at boot time):
process 2230: arguments to dbus_message_new_method_call() were incorrect, assertion
"_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted
So I then try to restart NetworkManager (sudo service NetworkManager
restart), and then I get this in the logs. (Again, more text below the log.)
Sep 5 21:50:17 ylla NetworkManager: <info> starting...
Sep 5 21:50:18 ylla NetworkManager: <info> New VPN service 'vpnc'
(org.freedesktop.NetworkManager.vpnc).
Sep 5 21:50:18 ylla NetworkManager: <info> New VPN service 'openvpn'
(org.freedesktop.NetworkManager.openvpn).
Sep 5 21:50:18 ylla NetworkManager: <info> wlan0: Device is fully-supported using
driver 'orinoco_pci'.
Sep 5 21:50:18 ylla NetworkManager: <info> nm_device_init(): waiting for
device's worker thread to start
Sep 5 21:50:18 ylla NetworkManager: <info> nm_device_init(): device's worker
thread started, continuing.
Sep 5 21:50:18 ylla NetworkManager: <info> Now managing wireless (802.11) device
'wlan0'.
Sep 5 21:50:18 ylla NetworkManager: <info> Deactivating device wlan0.
Sep 5 21:50:18 ylla NetworkManager: <info> eth0: Device is fully-supported using
driver 'e100'.
Sep 5 21:50:18 ylla NetworkManager: <info> nm_device_init(): waiting for
device's worker thread to start
Sep 5 21:50:18 ylla NetworkManager: <info> nm_device_init(): device's worker
thread started, continuing.
Sep 5 21:50:18 ylla NetworkManager: <info> Now managing wired Ethernet (802.3)
device 'eth0'.
Sep 5 21:50:18 ylla NetworkManager: <info> Deactivating device eth0.
Sep 5 21:50:18 ylla NetworkManager: <info> Found dial up configuration for Verizon
via Modem: Verizon
Sep 5 21:50:18 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device eth0 link now 0
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device-802-3-ethernet.c -
nm_device_802_3_ethernet_link_deactivated (149) device eth0 scheduled
link_deactivated_helper
Sep 5 21:50:18 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Sep 5 21:50:18 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Sep 5 21:50:18 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device eth0 link now 1
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device-802-3-ethernet.c -
link_deactivated_helper (129) device eth0 will set active link to FALSE
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device-802-3-ethernet.c -
link_activated_helper (102) device eth0 will set active link to TRUE
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device.c - nm_device_set_active_link
(596) device eth0 link state set to 1
Sep 5 21:50:18 ylla NetworkManager: <info> Will activate wired connection
'eth0' because it now has a link.
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device-802-3-ethernet.c -
nm_device_802_3_ethernet_link_activated (122) device eth0 scheduled link_activated_helper
Sep 5 21:50:18 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device eth0 link now 0
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device-802-3-ethernet.c -
nm_device_802_3_ethernet_link_deactivated (149) device eth0 scheduled
link_deactivated_helper
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device-802-3-ethernet.c -
link_deactivated_helper (129) device eth0 will set active link to FALSE
Sep 5 21:50:18 ylla NetworkManager: <info> nm-device.c - nm_device_set_active_link
(596) device eth0 link state set to 0
Sep 5 21:50:18 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1
Sep 5 21:50:32 ylla NetworkManager: <WARN> request_and_convert_scan_results():
card took too much time scanning. Get a better one.
Sep 5 21:50:55 ylla NetworkManager: <info> Updating allowed wireless network
lists.
Sep 5 21:50:55 ylla NetworkManager: <WARN> nm_dbus_get_networks_cb(): error
received: org.freedesktop.NetworkManagerInfo.NoNetworks - There are no wireless networks
stored..
Sep 5 21:50:55 ylla NetworkManager: <info> Updating VPN Connections...
Sep 5 21:51:02 ylla NetworkManager: <WARN> nm_hal_deinit(): libhal shutdown failed
- Connection is closed
Sep 5 21:51:02 ylla NetworkManager: nm_get_device_by_iface: assertion `data != NULL'
failed
Sep 5 21:51:02 ylla NetworkManager: <info> Successfully reconnected to the system
bus.
Sep 5 21:51:52 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Sep 5 21:51:54 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1
Sep 5 21:52:32 ylla NetworkManager: <WARN> nm_hal_deinit(): libhal shutdown failed
- Connection is closed
Sep 5 21:52:32 ylla NetworkManager: <info> Successfully reconnected to the system
bus.
Sep 5 21:54:42 ylla NetworkManager: <WARN> nm_hal_deinit(): libhal shutdown failed
- Connection is closed
Sep 5 21:54:42 ylla NetworkManager: <info> Successfully reconnected to the system
bus.
Sep 5 21:55:10 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Sep 5 21:55:10 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0
Sep 5 21:55:12 ylla NetworkManager: <info> nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1
So then I say "screw it", and type "/sbin/ifup wlan0", which just
works,
enabling me to scp those logs to you over the network with the URL ssid.
Oh -- hmmm, there's this NetworkManagerDispatcher thing -- sorry, I hadn't
thought to restart that. Well, if I restart NetworkManagerDispatcher *and*
NetworkManager, I can run nm-applet, and it'll be several seconds before
it crashes with the above assertion failure again.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
6110
days inactive
6114
days old
38 comments
13 participants
participants (13)
-
Alan Cox -
Benny Amorsen -
Christopher Aillon -
Colin Walters -
Dan Williams -
Ian Burrell -
Krzysztof Halasa -
Matthew Miller -
Owen Taylor -
Pekka Pietikäinen -
Pádraig Brady -
Richi Plana -
Simo Sorce