search for: eaddrnotavail

...fine and starting as expected. But I did a server reboot once and mongrel has refused to start up since. I get the following error: /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in `initialize_without_backlog'': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL) from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in `initialize'' from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open'' from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open_server'' from /usr/lib/ruby/1.8/drb/drb.rb:759:in...

...can a network with any method except plain ping results in an error: truss nmap -sT -p 21 '172.19.17.*' [...] sendto(0x4,0x8094200,0,0x0,{ AF_INET 172.19.17.0:0 },0x10) ERR#49 'Can't assign requested address' [...] What's strange that man on send(2) doesn't state that EADDRNOTAVAIL can ever be returned from sendto(). Quick look at nmap's site didn't show me any clues. However, I've reproducted the problem under both 5.2.1 and 4.8 releases. Do I have all my boxes broken, or should I rebuild kernel with some options, or does nmap be known not to work on FreeBSD?...

Just did a quick scan for that error message in the kernel source. Turns out it''s triggered in net/bridge/br_fdb.c:289. if (!is_valid_ether_addr(addr)) return -EADDRNOTAVAIL; Interestingly enough, it''s claiming that the mac addy isn''t any good! 8-( I''ll go add a printk line to that to see if I can determine what kind of data it''s getting to fdb_insert to cause this glitch... unless someone else tells me somethign obvious and stupid...

...930 read(6, " {9011 C82F0FE ZBFC8 .DC".., 16384) = 112 19279: 15.5934 stat64("/usr/openwin/bin/xauth", 0xFFBFEFA0) = 0 19279: 15.5938 so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5940 bind(8, 0x00072238, 32, 3) Err#126 EADDRNOTAVAIL 19279: 15.5942 close(8) = 0 19279: 15.5944 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5946 bind(8, 0x0007F108, 16, 3) Err#125 EADDRINUSE 19279: 15.5947 close(8) = 0...

three drivers updated, but this can be used in many others. Jiri Pirko (4): net: introduce new priv_flag indicating iface capable of change mac when running virtio_net: use IFF_LIFE_ADDR_CHANGE priv_flag team: use IFF_LIFE_ADDR_CHANGE priv_flag dummy: use IFF_LIFE_ADDR_CHANGE priv_flag drivers/net/dummy.c | 15 ++------------- drivers/net/team/team.c | 9 +++++----

three drivers updated, but this can be used in many others. Jiri Pirko (4): net: introduce new priv_flag indicating iface capable of change mac when running virtio_net: use IFF_LIFE_ADDR_CHANGE priv_flag team: use IFF_LIFE_ADDR_CHANGE priv_flag dummy: use IFF_LIFE_ADDR_CHANGE priv_flag drivers/net/dummy.c | 15 ++------------- drivers/net/team/team.c | 9 +++++----

three drivers updated, but this can be used in many others. v1->v2: %s/LIFE/LIVE Jiri Pirko (4): net: introduce new priv_flag indicating iface capable of change mac when running virtio_net: use IFF_LIVE_ADDR_CHANGE priv_flag team: use IFF_LIVE_ADDR_CHANGE priv_flag dummy: use IFF_LIVE_ADDR_CHANGE priv_flag drivers/net/dummy.c | 15 ++------------- drivers/net/team/team.c

three drivers updated, but this can be used in many others. v1->v2: %s/LIFE/LIVE Jiri Pirko (4): net: introduce new priv_flag indicating iface capable of change mac when running virtio_net: use IFF_LIVE_ADDR_CHANGE priv_flag team: use IFF_LIVE_ADDR_CHANGE priv_flag dummy: use IFF_LIVE_ADDR_CHANGE priv_flag drivers/net/dummy.c | 15 ++------------- drivers/net/team/team.c

...seems to be in: channels.c Function: x11_create_display_inet Line:2908: ( 4.7p1 code ) if (ai->ai_next) continue; That's right after the bind fails. If I follow the behavior, the first ai from getaddrinfo is an IPV6 address that's not valid. Errno is EADDRNOTAVAIL. Now in 4.7 the continue would make it just try the next ai. In 5.2 that continue isn't there, so instead it breaks and tries the next port number, on the same ai, which fails all the way until MAX_DISPLAYS is reached. For this situation I want to put back the if/continue, but I assume it was...

https://bugzilla.mindrot.org/show_bug.cgi?id=1950 Bug #: 1950 Summary: sshd tries to bind over and over to ::1 for several seconds Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2

...ens that CVE. The problem is that on Solaris 9 and Solaris 10 if you don't have IPv6 addresses configured, getaddrinfo() returns both AF_INET and AF_INET6 entries, and it returns AF_INET6 *first*. An attempted bind() to an AF_INET6 address on a system without IPv6 addresses configured returns EADDRNOTAVAIL, and the distributed code will not try the AF_INET (IPV4) bind at all; my patch allows it to continue on, but as you say that creates a potential security issue. What probably should happen in this code is that the bind result should be checked for EADDRNOTAVAIL error and not consider that a bail...

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Resend due to send with too long recipients list. Sorry! Thanks to Joe

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Resend due to send with too long recipients list. Sorry! Thanks to Joe

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Resend due to send with too long recipients list. Sorry! Thanks to Joe

http://bugzilla.mindrot.org/show_bug.cgi?id=1356 Summary: X11 forwarding broken. Product: Portable OpenSSH Version: 4.5p1 Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: bitbucket at mindrot.org ReportedBy: marka at isc.org Created

...AssignedTo: bitbucket at mindrot.org ReportedBy: yann at pleiades.fr.eu.org Created an attachment (id=1481) --> (http://bugzilla.mindrot.org/attachment.cgi?id=1481) Ignore a EADDRNOTAVAIL error when binding to the X11 forwarding port This bug happen with 5.0p1 (but this version was not available in the version field of the bug report form). The patch for CVE-2008-1483 applied in this release has a side effect on Solaris (at least Solaris 10, I didn't test on other solaris vers...

Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Third patch introduced a new vq control command to set mac address, it's atomic. V2: check return of sending command, delay eth_mac_addr() V3: restore software address when fail to set hardware address V4: split eth_mac_addr, fix error handle V5: rebase patches to net-next tree Amos