Re: failed to create llentry
co...@sdf.org writes: > Apparentlysome of the route table entries are special and should not be > deleted. indeed. > After flushing them and attempting to add a default route, I get these > messages over and over again. > > ifconfig iwm0 10.0.0.1 delete > ifconfig iwm0 10.0.0.1 > > re-creates the magical route stuff so I can add a default route again The entry with flags "UC" is a "cloning route" which instructs the kernel to perform ARP/ND and insert llinfo routes. Typically these are "UHLc". Without the C route for the subnet, a packet will still match the default route, but then there is no route for the IP addess of the gateway. Without a C route and without a UHLc route, there is no way to arp. It's the C route that directs that the prefix should be handled by arping (and on which interface). So when you are flushing routes, don't delete that one.
Re: failed to create llentry
Apparentlysome of the route table entries are special and should not be deleted. After flushing them and attempting to add a default route, I get these messages over and over again. ifconfig iwm0 10.0.0.1 delete ifconfig iwm0 10.0.0.1 re-creates the magical route stuff so I can add a default route again
Re: failed to create llentry
On Wed, Nov 21, 2018 at 07:36:27PM -0500, Greg Troxel wrote: > [...] > I am unclear on the fine points, but in general find wpa_supplicant to > be way too painful to deal with. It really seems like it should be able > to be started by default, and exit if no wifi interfaces, and have some > command-line wifi_choose program that prints out a list of SSIDs, takes > a number, and asks for a password, and stores both the ssid and the > password, and next time just connects. Sort of like how a mac works > clicking on the wifi icon, but command line. And a gui version would be > fine too of course. To me this is the biggest NetBSD wifi usability > issue, or perhaps it's just behind USB wifi adaptors being slightly > flaky. I use pkgsrc/net/wpa_gui. NetBSD comes with wpa_cli in base. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: failed to create llentry
Roy Marples writes:
>> I am unclear on the fine points, but in general find wpa_supplicant to
>> be way too painful to deal with. It really seems like it should be able
>> to be started by default,
(I realize wpa_supplicant is not your fault, and the code you did write
does the right thing when invoked with no arguments. Really, I
appreciate that.)
> It is painful without a good setup, yes.
> It can be started by default if the user so chooses.
I guess where I am coming from is that it would be nice if there was
wpa_supplicant support without having to explicitly enable it.
> So I see sysinst network config coming down to this:
> Auto-start wireless Y/N
> Auto-configure addresses Y/N
> If auto-start wireless is Y, or autoconfigure addresses is N, spawn
> dhcpcd-curses to handle both.
>
> You don't actually pick an interface by default.
That's a fair point.
> I don't even propose we have an advanced section - you want anything
> more, drop to the shell and do it.
> ifconfig and route are not hard, neither is editing resolv.conf.
That's true.What is hard is getting wpa_supplicant to pass a psk to
the single ssid you can hear.
>> and exit if no wifi interfaces,
>
> Why?
> Hotplugging of wifi is a thing.
> Pinebooks are a really good example of having no networking at boot.
> I generally plug the stick and ethernet dongle/cable in after boot.
ok, I amend my remarks to "be dormant until a wifi interface appears,
consuming little resources"
>> and have some command-line wifi_choose program that prints out a list
>> of SSIDs, takes a number, and asks for a password, and stores both
>> the ssid and the password, and next time just connects. Sort of like
>> how a mac works clicking on the wifi icon, but command line. And a
>> gui version would be fine too of course. To me this is the biggest
>> NetBSD wifi usability issue, or perhaps it's just behind USB wifi
>> adaptors being slightly flaky.
>
> By GUI you mean X11 based? dhcpcd-{gtk,qt} satisfy this on BSD at least.
yes, more or less.
> dhcpcd-curses is a thing, but it's currently just a monitor.
If it could choose an ssid and pass in a psk (to wpa_supplicant), that
would be excellent.
> Now I have a pinebook I can concentrate on fixing some recent
> dhcpcd/netbsd/platform bitrot with shared IP address and then work on
> dhcpcd-curses once more now I have a working NetBSD environment with
> wireless once again.
I think many people would be happy if the install process could walk
people through choosing an ssid and typing in the psk and having wifi
basically work, without them having to understand wpa_supplicant.
I concur iwth Maya's point about the insanity of having to tell
wpa_supplicant to use the config file in the standard location. It
seems obvious to me that if run with no arguments, it should daemonize,
log to syslog, deal with all interfaces, and use the standard config
file And I realize that of course isn't your fault either :-) and I
should probably code more and complain less.
Re: failed to create llentry
I just don't want to need to set wpa_supplicant_flags, I don't need set a billion flags for other programs, so why that one. It won't even read the canonical config location unless I tell it to...
Re: failed to create llentry
On 22/11/2018 00:36, Greg Troxel wrote:
Roy Marples writes:
On 21/11/2018 19:51, co...@sdf.org wrote:
-B -M -c /etc/wpa_supplicant.conf -s seem like really good flags,
thanks.
(are they good enough to be a default? right now anyone using wifi has
to have wpa_supplicant_flags set, so we can't break their usage)
Yes and no.
We would need to ship a default wpa_supplicant.conf - probably
enabling the default socket so wpa_cli(8) just works and commented out
entries for connecting to any open ap and a specific ap with psk.
We might want to enable (but commented out maybe to start with) the
ability instructions over the control socket to configure
wpa_supplicant.conf as well.
This would be handy for applications like dhcpcd-{gtk,qt}
Then, the user just has to set wpa_supplicant=YES in rc.conf and
voila, wireless network setup with X11 and a systray application
becomes a lot easier for the end user to setup.
I am unclear on the fine points, but in general find wpa_supplicant to
be way too painful to deal with. It really seems like it should be able
to be started by default,
It is painful without a good setup, yes.
It can be started by default if the user so chooses.
So I see sysinst network config coming down to this:
Auto-start wireless Y/N
Auto-configure addresses Y/N
If auto-start wireless is Y, or autoconfigure addresses is N, spawn
dhcpcd-curses to handle both.
You don't actually pick an interface by default.
I don't even propose we have an advanced section - you want anything
more, drop to the shell and do it.
ifconfig and route are not hard, neither is editing resolv.conf.
Job done.
and exit if no wifi interfaces,
Why?
Hotplugging of wifi is a thing.
Pinebooks are a really good example of having no networking at boot.
I generally plug the stick and ethernet dongle/cable in after boot.
and have some
command-line wifi_choose program that prints out a list of SSIDs, takes
a number, and asks for a password, and stores both the ssid and the
password, and next time just connects. Sort of like how a mac works
clicking on the wifi icon, but command line. And a gui version would be
fine too of course. To me this is the biggest NetBSD wifi usability
issue, or perhaps it's just behind USB wifi adaptors being slightly
flaky.
By GUI you mean X11 based? dhcpcd-{gtk,qt} satisfy this on BSD at least.
dhcpcd-curses is a thing, but it's currently just a monitor.
Now I have a pinebook I can concentrate on fixing some recent
dhcpcd/netbsd/platform bitrot with shared IP address and then work on
dhcpcd-curses once more now I have a working NetBSD environment with
wireless once again.
Roy
Re: failed to create llentry
Roy Marples writes:
> On 21/11/2018 19:51, co...@sdf.org wrote:
>> -B -M -c /etc/wpa_supplicant.conf -s seem like really good flags,
>> thanks.
>> (are they good enough to be a default? right now anyone using wifi has
>> to have wpa_supplicant_flags set, so we can't break their usage)
>
> Yes and no.
> We would need to ship a default wpa_supplicant.conf - probably
> enabling the default socket so wpa_cli(8) just works and commented out
> entries for connecting to any open ap and a specific ap with psk.
>
> We might want to enable (but commented out maybe to start with) the
> ability instructions over the control socket to configure
> wpa_supplicant.conf as well.
> This would be handy for applications like dhcpcd-{gtk,qt}
>
> Then, the user just has to set wpa_supplicant=YES in rc.conf and
> voila, wireless network setup with X11 and a systray application
> becomes a lot easier for the end user to setup.
I am unclear on the fine points, but in general find wpa_supplicant to
be way too painful to deal with. It really seems like it should be able
to be started by default, and exit if no wifi interfaces, and have some
command-line wifi_choose program that prints out a list of SSIDs, takes
a number, and asks for a password, and stores both the ssid and the
password, and next time just connects. Sort of like how a mac works
clicking on the wifi icon, but command line. And a gui version would be
fine too of course. To me this is the biggest NetBSD wifi usability
issue, or perhaps it's just behind USB wifi adaptors being slightly
flaky.
Re: failed to create llentry
On Wed, Nov 21, 2018 at 09:03:20PM +, Roy Marples wrote:
> On 21/11/2018 19:51, co...@sdf.org wrote:
> > -B -M -c /etc/wpa_supplicant.conf -s seem like really good flags,
> > thanks.
> > (are they good enough to be a default? right now anyone using wifi has
> > to have wpa_supplicant_flags set, so we can't break their usage)
>
> Yes and no.
> We would need to ship a default wpa_supplicant.conf - probably enabling the
> default socket so wpa_cli(8) just works and commented out entries for
> connecting to any open ap and a specific ap with psk.
>
> We might want to enable (but commented out maybe to start with) the ability
> instructions over the control socket to configure wpa_supplicant.conf as
> well.
> This would be handy for applications like dhcpcd-{gtk,qt}
>
> Then, the user just has to set wpa_supplicant=YES in rc.conf and voila,
> wireless network setup with X11 and a systray application becomes a lot
> easier for the end user to setup.
>
> > I can't unplug my card because it's PCI.
> >
> > I'll try to investigate next time it happens
>
> Another way of restarting things is to down/up the interface.
>
> ifconfig urtwn down up
>
> Does wonders - both wpa_supplicant and dhcpcd will react to this.
> There should be no need to kill anything with prejudice.
Yes a reboot usually does the trick, but savecore takes a while. It
would be faster to type 'reboot'
Re: failed to create llentry
On 21/11/2018 19:51, co...@sdf.org wrote:
-B -M -c /etc/wpa_supplicant.conf -s seem like really good flags,
thanks.
(are they good enough to be a default? right now anyone using wifi has
to have wpa_supplicant_flags set, so we can't break their usage)
Yes and no.
We would need to ship a default wpa_supplicant.conf - probably enabling
the default socket so wpa_cli(8) just works and commented out entries
for connecting to any open ap and a specific ap with psk.
We might want to enable (but commented out maybe to start with) the
ability instructions over the control socket to configure
wpa_supplicant.conf as well.
This would be handy for applications like dhcpcd-{gtk,qt}
Then, the user just has to set wpa_supplicant=YES in rc.conf and voila,
wireless network setup with X11 and a systray application becomes a lot
easier for the end user to setup.
I can't unplug my card because it's PCI.
I'll try to investigate next time it happens
Another way of restarting things is to down/up the interface.
ifconfig urtwn down up
Does wonders - both wpa_supplicant and dhcpcd will react to this.
There should be no need to kill anything with prejudice.
Roy
Re: failed to create llentry
-B -M -c /etc/wpa_supplicant.conf -s seem like really good flags, thanks. (are they good enough to be a default? right now anyone using wifi has to have wpa_supplicant_flags set, so we can't break their usage) I can't unplug my card because it's PCI. I'll try to investigate next time it happens
Re: failed to create llentry
On 21/11/2018 18:55, co...@sdf.org wrote: I don't like debugging problems with daemonized processes. wpa_supplicant for example prints nothing to syslog. the messages it gives to stdout are informative. wpa_supplicant(8) says -s Send log messages through syslog(3) instead of to the terminal. I'm quite grumpy about networking in netbsd in general. I'm actually very happy. For example my remote ssh sessions persist without dropping when the carrier goes down/up. Heck, my dhcp lease died on my pinebook half an hour ago and building pkgsrc entirely over nfs just carried on working again without the blink of an eye. It's not magic, it's NetBSD. Roy
Re: failed to create llentry
On 21/11/2018 17:18, co...@sdf.org wrote: I use wpa_supplicant and dhcpcd. When dhcpcd fails to configure the network I start doing it manually. I don't really pay attention to when the errors occur but I'll try to keep a closer track about when they start. dhcpcd will mysteriously fail while I am connected with wpa_supplicant, How does it mysteriously fail? so I'd kill it and do: pkill -9 dhcpcd That's quite harsh. route -n flush route -n flushall dhcpcd -k should do this (and remove any addresses or anything else it added) if you don't pkill -9 it. ifconfig iwm0 local-ip-i-should-have route add default gateway Usually when these problems happen one of the following occurs too: - wpa_supplicant will complain it can't assign an address every hour or so, and network traffic will stop for a bit wpa_supplicant doesn't assign any kind of address by itself. Can you post some context? - I'll accidentally restart wpa_supplicant before killling all network traffic and get a kernel panic Backtrace would be nice. I guess wpa_supplicant does more than I want to do and run into conflicts with manual setup. Often my urtwn firmware fails for some unknown reason. It's not the most stable stick on my network, but it work in my pinebook. My solution is to remove and insert the stick until the firmware loads correctly. To allow this to work, I setup wpa_supplicant in plug and play mode. wpa_supplicant_flags="-B -M -c /etc/wpa_supplicant.conf" This tells wpa_supplicant to background, match any interface and use the stated config file. dhcpcd runs with default flags and config. I've been plugging in and removing in no set order the usb wifi stick and a usb ethernet dongle and it just works * (there is an issue with IP address sharing, unsure if platform, dhcpcd or kernel issue - I'll be fixing this once I have a working desktop on the pinebook). * Sometimes either interface gets an IPv4LL address which means carrier is "UP" but there's another issue such as firmware failure or the ethernet over power adpater needs a reboot. In any case, no manual address setup or routing is needed. Roy
Re: failed to create llentry
I don't like debugging problems with daemonized processes. wpa_supplicant for example prints nothing to syslog. the messages it gives to stdout are informative. I'm quite grumpy about networking in netbsd in general.
Re: failed to create llentry
> I use wpa_supplicant and dhcpcd. When dhcpcd fails to configure the > network I start doing it manually. I don't really pay attention to when > the errors occur but I'll try to keep a closer track about when they > start. I run both too. But, I have found that things are occasionally not ok, which I think is about the driver, and it manifests by wpa_supplicant not configuring a key. Once the network works dhcpcd has been flawless for me. > dhcpcd will mysteriously fail while I am connected with wpa_supplicant, > so I'd kill it and do: > pkill -9 dhcpcd > route -n flush > route -n flushall > ifconfig iwm0 local-ip-i-should-have > route add default gateway and that works? I would try '/etc/rc.d/dhcpcd restart' instead. > Usually when these problems happen one of the following occurs too: > - wpa_supplicant will complain it can't assign an address every hour or > so, and network traffic will stop for a bit that seems odd; wpa_supplicant is just about configuring WPA2 keys. > - I'll accidentally restart wpa_supplicant before killling all network > traffic and get a kernel panic That seems like a sign of another bug. I have often restarted wpa_supplicant with ifconfig down/up, to work around what I think are driver or other bugs (urtwn, 10 year old macbookpro), but never seen a panic. > I guess wpa_supplicant does more than I want to do and run into > conflicts with manual setup. I have it configured to just negoiate the WPA2 session key.
Re: failed to create llentry
On Wed, Nov 21, 2018 at 11:56:23AM -0500, Greg Troxel wrote: > co...@sdf.org writes: > > > What are these messages about? > > whenever my connection doesn't work, I need to tinker with manual > > configuration and it prints a lot of that in dmesg. > > > > I am using wifi from a distance. > > ARP (IPv4) and NDP (IPv6) data is stored in the routing table with the L > flag. I have seen llentry (or llinfo?) errors before, when the address > resolution code is not able to create the routing able entry it wants. > Perhaps this is because there is another entry with the same key > already, but a different type. > > If you want to send me full routing table dumps (netstat -nr) and > ifconfig, I can look at it. But I wonder if you are doing something odd > (basically, anything other than configuring an address/prefix on one > interface, and a default route, and letting routing/resolution deal with > the rest). In particular, I wonder if you are running anything like > olsr. I use wpa_supplicant and dhcpcd. When dhcpcd fails to configure the network I start doing it manually. I don't really pay attention to when the errors occur but I'll try to keep a closer track about when they start. dhcpcd will mysteriously fail while I am connected with wpa_supplicant, so I'd kill it and do: pkill -9 dhcpcd route -n flush route -n flushall ifconfig iwm0 local-ip-i-should-have route add default gateway Usually when these problems happen one of the following occurs too: - wpa_supplicant will complain it can't assign an address every hour or so, and network traffic will stop for a bit - I'll accidentally restart wpa_supplicant before killling all network traffic and get a kernel panic I guess wpa_supplicant does more than I want to do and run into conflicts with manual setup.
Re: failed to create llentry
co...@sdf.org writes: > What are these messages about? > whenever my connection doesn't work, I need to tinker with manual > configuration and it prints a lot of that in dmesg. > > I am using wifi from a distance. ARP (IPv4) and NDP (IPv6) data is stored in the routing table with the L flag. I have seen llentry (or llinfo?) errors before, when the address resolution code is not able to create the routing able entry it wants. Perhaps this is because there is another entry with the same key already, but a different type. If you want to send me full routing table dumps (netstat -nr) and ifconfig, I can look at it. But I wonder if you are doing something odd (basically, anything other than configuring an address/prefix on one interface, and a default route, and letting routing/resolution deal with the rest). In particular, I wonder if you are running anything like olsr.
failed to create llentry
What are these messages about? whenever my connection doesn't work, I need to tinker with manual configuration and it prints a lot of that in dmesg. I am using wifi from a distance.
